ТРЕБОВАНИЯ К ПРОЕКТИРОВАНИЮ РАЗДЕЛОВ
АВТОМАТИЗАЦИЯ, ДИСПЕТЧЕРИЗАЦИЯ И СЛАБОТОЧНЫЕ
СИСТЕМЫ
ТРЕБОВАНИЯ К РАЗДЕЛУ АВТОМАТИЗИРОВАННЫЕ
СИСТЕМЫ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ
ПРОЦЕССАМИ (АСУТП)
1.Общие положения
Основной целевой задачей АСУТП АО "Мосводоканал" является обеспечение
автоматического
режима
управления
технологическими
процессами
производственных подразделений. Также АСУТП решает задачи контроля,
мониторинга, диспетчеризации управления технологическими процессами.
Автоматизированная система диспетчерского контроля и управления
(АСДКУ) АО "Мосводоканал" охватывает весь уровень управления производством
от шкафов местного управления, включая дистанционное управление
технологическими процессами из локальных диспетчерских пунктов и до
централизованных диспетчерских систем управления отдельными предприятиями, а
также систем водоснабжения и канализации города в целом.
Все работы по проектированию систем автоматизации объектов канализации и
водопровода АО "Мосводоканал" выполняются в соответствии с конкретными
требованиями сформулированными в заданиях на разработку проектов, либо
техническими условиями или техническими заданиями, выдаваемых по запросу
проектных организаций.
Общие требования к составу и содержанию разделов проекта
"Автоматизированная система управления технологическими процессами"
определяются разделом "5. Типовые требования к составу и содержанию проектной
и рабочей документации АСУТП" внутреннего стандарта АО "Мосводоканал"
"СТП-42439-02-05-15. Требования к оформлению технической документации
АСУТП", которое уточняет и конкретизирует требования ГОСТ 34.601-90
"Автоматизированные системы. Стадии создания", ГОСТ 34.201-89 "Виды,
комплектность и обозначение документов при создании автоматизированных
систем", и РД 50-34.698-90 "Автоматизированные системы. Требования к
содержанию документов" применительно к объектам водоснабжения и канализации.
Проектные организации также должны руководствоваться нормативными
документами, ссылки на которые приведены в указанном стандарте.
Если иное не оговорено в задании на разработку проекта, то типовыми
требованиями проектов автоматизации АО "Мосводоканал" предусматривается
следующее:
1.1.Полная автоматизация режима управления технологическими процессами
с реализацией режимов управления:
местный – управление с местного пульта или щита управления,
используется в качестве резервного - при проведении ремонтных работ
либо полном отключении систем АСУТП;
автоматический – управление от контроллера с заданием режимов
управления из диспетчерских пунктов – основной режим работы;
дистанционный - телеуправление и контроль работы сооружений для
предотвращения аварийных ситуаций при частичном отказе систем
АСУТП, может использоваться в любом из следующих диспетчерских
пунктов:
o диспетчерского пункта локального объекта/цеха (МДП);
o главного объектового диспетчерского пункта водопроводной станции
либо канализационных сооружений (ГДП);
o центрального диспетчерского управления АО "Мосводоканал" (ЦДУ)
определяется заданием на разработку проекта либо предоставленными
техническими условиями Заказчика.
1.2.В составе работ проекта кроме строительно-монтажных и местных пусконаладочных работ средств контроля и управления должно быть предусмотрено
следующее:
разработка алгоритмов программного обеспечения и согласование их с
Заказчиком (Управление АСУТП и связи АО "Мосводоканал");
программирование контроллеров на объектах и наладка всех режимов
работы технологических сооружений (на действующих сооружениях по
графику согласованному с Заказчиком);
организация передачи данных на существующий либо проектируемый
сервер систем диспетчерского контроля и управления (SCADA);
организация сбора данных и параметров работы оборудования в базу
данных истории технологических процессов, разработка мнемосхем,
журналов действий оператора, аварий и работы оборудования,
разработка исполнительной документации, разработка инструкций
операторов и диспетчеров, а также регламентов эксплуатации систем и
другие необходимые работы по обеспечению полной автоматизации
управления объектом.
1.3.Электропитание программируемых контроллеров, шкафов телеуправления,
приборов, средства контроля и управления, серверов и АРМ SCADA должно быть
предусмотрено по первой особой категории энергоснабжения в соответствии с ПУЭ
(от двух независимых источников через АВР) и оснащены источниками
бесперебойного питания (ИБП) on-line типа, обеспечивающими работу
оборудования автоматизации не менее 2 часов при отказе систем внешнего
энергоснабжения. Все системы электроснабжения и заземления систем
автоматизации должны быть выполнены в соответствии с утвержденными АО
"Мосводоканал" "Требованиями по электроснабжению, электротехническим
устройствам и заземлению средств автоматизации технологических процессов и
слаботочных систем".
1.4.Шкафы автоматики, контроллеры, приборы и средства контроля и
управления должны быть выполнены в защищенном исполнении, степень защиты не
ниже IР-55. В зоне возможного затопления – в герметичном исполнении в
зависимости от согласованных Заказчиком требований к их установке. Должно быть
предусмотрено соблюдение температурных и влажностных режимов работы
автоматики (кондиционирование/отопление и вентиляция) в зависимости от
паспортных требований к устанавливаемому оборудованию автоматизации.
1.5.Все приборы и средства измерений, применяемые в проектах
автоматизации, должны быть оснащены аналоговым выходом 4-20 мА, а также
цифровым выходом, определяемым по согласованию с Заказчиком. Управляемые
интеллектуальные технические средства автоматизации также должны иметь
цифровой интерфейс, определяемый по согласованию с Заказчиком. Все
спецификации приборов и средств автоматизации предварительно согласовываются
с АО "Мосводоканал", на этапе согласования основных технических решений
проекта автоматизации.
1.6.В зависимости от условий и эксплуатационных требований объектов
предусмотреть звуковую и световую сигнализацию срабатывания аварийных
сигналов и средств контроля загазованности, затопления или иных средств
промышленной безопасности. Вывод на программируемый котроллер и передачу
информации в SCADA от вышеперечисленных систем аварийной сигнализации, а
также средств контроля доступа в помещение и к оборудованию, систем
бесперебойного энергоснабжения, систем охранной и пожарной сигнализации,
устройств защиты и т.п. необходимо предусматривать проектом в обязательном
порядке.
2.Общие требования к АСУТП
Проектируемая АСУТП должна соответствовать следующим принципам:
Надежность – обеспечение максимально возможного времени работы
системы без сбоев и аварий, например, путем резервирования;
Реализуется
путем
выбора
оптимальных
по
соотношению
цена/надежность компонент, а также путем обеспечения надлежащего
обслуживания и ремонта.
Ремонтопригодность
–
возможность
восстановления
работоспособности систем за минимальное время при экономически
оправданной стоимости ремонта;
Реализуется на уровне разработки как использование максимально
простых, распространенных и универсальных компонент системы (реле,
модулей ввода/вывода и т.п.) для обеспечения простой покомпонентной
замены неисправных частей, а также для исключения взаимного влияния
и предотвращения распространения последствий аварии.
Тестируемость – возможность установления факта правильного
функционирования системы и её составляющих частей;
Реализуется как система диагностики состояния основных подсистем
АСУ ТП: энергоснабжения и линий связи и управления, так и состояния
контроллеров, узлов SCADA, активного оборудования ЛВС.
Минимальные требования – возможность локальной проверки работы на
месте, максимальные – создание централизованных систем мониторинга
состояния систем и компонентов.
Диагностируемость – возможность быстрого нахождения неисправной
части/компонента системы;
Реализуется в части системотехники как возможность визуального
определения неисправных компонентов систем управления и
оборудования связи (индикаторы и пр.), а также обеспечение поиска
неисправности при помощи специализированного ПО либо штатными
средствами контроллеров АСУ ТП.
Простота обслуживания и эксплуатации – минимальные требования к
квалификации и дополнительному обучению эксплуатирующего
систему персонала;
Реализуется также как требования минимального количества
максимально универсальных инструментальных и программных
средств, необходимых для эксплуатации и выбора простых в освоении
технических и программных средств.
Экономичность – обеспечение минимальных расходов при внедрении и
в процессе функционирования систем при условии выполнения
основных производственных требований;
Реализуется как ограничение максимального уровня и объёма
автоматизации технологических процессов рамками экономической
целесообразности с учетом требований надежности и безопасности
работы. Учитывается оптимальная унификация программных и
технических средств, обеспечивающая интеграцию уже имеющихся
решений.
Внедряемость – минимальное время на проектирование
развертывание (монтаж и пуско-наладку) системы.
и
Модифицируемость – возможность модернизации систем без замены их
ключевых
компонентов
для
обеспечения
работы
с
новыми/дополнительными технологическими процессами;
Расширяемость – возможность ввода в систему дополнительных
сигналов, устройств или функциональных возможностей контроля и
управления, не предусмотренных в первоначальном техническом
задании;
Наращиваемость – возможность масштабирования, увеличения размера
автоматизированной системы при увеличении размера или числа
объектов автоматизации;
Открытость – соответствие современным промышленным стандартам,
которое обеспечивает возможность интеграции с другими открытыми
системами, возможность простой интеграции доступных модулей и
частей системы достаточно широкого ряда производителей;
Взаимозаменяемость – возможность замены любого компонента
системы на аналогичный другого производителя, имеющийся в
свободной продаже;
Модульность – способность аппаратного или программного
обеспечения к модификации путем добавления, удаления или замены
отдельных модулей системы без влияния на оставшуюся ее часть;
Универсальность – возможность перенастройки системы для работы с
новыми
технологическими
процессами
при
модернизации
технологического оборудования;
Стандартность пользовательского интерфейса – стандартизация
пользовательского интерфейса с целью сокращения расходов на
обучение и количества ошибок персонала в процессе эксплуатации
систем;
Актуальность – максимальная длительность жизненного цикла без
существенного морального и физического старения системы,
достигаемая путем постоянного обновления аппаратных и программных
компонентов, на базе выбранных долгоживущих промышленных
стандартов;
Автономность – слабая связанность элементов архитектуры между
собой, т.е. деление системы на части следует производить так, чтобы
поток информации через связи был минимален и через них не
замыкались контуры автоматического регулирования;
Реализуется как максимальная независимость на горизонтальном уровне
систем управления отдельными технологическими процессами.
Безопасность – соответствие требованиям промышленной безопасности
в
отношении
управляемых
и
контролируемых
объектов
технологического процесса и технике безопасности обслуживающего и
оперативного персонала;
Реализуется
разработка
максимально
надежных
алгоритмов
автоматической работы сооружений, не позволяющих ввод не
корректных параметров и вмешательство в работу систем управления.
Действия оператора и дистанционное управление максимально
ограничиваются рамками технологического регламента работы
сооружений.
Защищенность – обеспечение современных требований по защите
систем от действий злоумышленников и неквалифицированных
пользователей;
Реализуется путем максимальной изоляции АСУ ТП со стороны
корпоративных сетей, а также полной изоляции от общедоступных
сетей. Разрабатывается также политика физического и программного
ограничения доступа к АСУ ТП, управления доступом, мониторинга
действий
персонала,
разграничения
и
управления
правами
авторизованных пользователей АСУ ТП.
3.Типы объектов для АСУТП
С точки зрения проектирования внедрения или модернизации АСУТВ в
АО"Мосводоканал" существует три типа технологических (производственных)
объектов.
3.1.Объекты первого типа
К объектам первого типа АО "Мосводоканал" относятся крупные
производственные подразделения: водопроводные станции (РСВ, ЗСВ, ВСВ, ССВ),
очистные сооружения (КОС, ЛОС), отдельные производственные управления (ЗВК,
ТиНАО), с преобладающим автоматическим управлением. В этих подразделениях
функционируют собственные местные диспетчерские пункты управления
отдельными технологическими процессами и главные диспетчерские пункты
объектов, которые должны обеспечивать круглосуточный контроль и управление с
высокой степенью надежности (время восстановления АСУТП после аварии не
должно превышать 1-2 часа). На объектах данного типа обязательно
предусматривается автономное ручное (местное) и автоматическое управление
каждым отдельным технологическим процессом. Дистанционное управление
предусматривается, как правило, для химически опасных объектов, объектов
находящихся в зоне возможного затопления, а также на объектах без дежурного
персонала в случаях необходимости реализации сценариев дистанционного
управления при ликвидации аварийных ситуаций. Для объектов первого типа
является критически важным работоспособность систем автоматического
управления, но может не являться критичным кратковременный выход из строя
систем автоматического управления отдельными технологическими процессами.
Полнофункциональное управление объектами подразделений первого типа без
действующей АСУТП не возможно либо сильно затруднено.
В подразделениях первого типа контроллеры управления технологическими
процессами, как правило, взаимодействуют по собственной отказоустойчивой
внутренней сети передачи данных подразделения с резервированными объектовыми
SCADA системами подразделения. Связи контроллеров непосредственного
управления объектами для наиболее критичных объектов подразделений
дублируются дополнительными каналами связи либо закольцовываются
альтернативным кабелем связи. Данные передаются непосредственно между
контроллерами и основными SCADA системами подразделений, а также
резервными SCADA системами подразделения. Данные также могут передаваться
между контроллерами АСУТП в локальной промышленной сети подразделения с
целью реализации надежных алгоритмов управления.
SCADA серверы подразделения и их клиенты объединены защищенной
компьютерной
сетью
предприятия,
гарантирующей
необходимую
производительность и исключающей не авторизованное подключение. Клиенты
уровня производственного подразделения – МДП, ГДП взаимодействуют
непосредственно с основными SCADA серверами подразделения, получая от них
все необходимые данные для реализации автоматических режимов управления.
Сети, используемые АСУТП, как контроллерные объектовые сети, так и
используемые для подключения SCADA отделены от административных и прочих
сетей подразделений и являются составной частью единой сети АСУТП АО
"Мосводоканал", к которой относятся также все прочие SCADA серверы и SCADA
клиенты других подразделений и центрального офиса АО Мосводоканал.
Каналы передачи данных SCADA подразделений первого типа в МВК в
обязательном порядке резервируются. Персонал ЦДУ использует данные
объектовых SCADA, непосредственно влияющих и необходимых для управления
городской системой водоснабжения и водоотведения в целом.
Мобильные пользователи могут быть подключены к SCADA серверам
подразделений для просмотра оперативных данных на месте аварии либо в дороге
через терминальный либо WEB сервисы SCADA, при этом используются только
просмотровые, не управляющие клиенты SCADA.
Количество SCADA систем в подразделениях первого типа определяется в
зависимости от общего количества сигналов контроля и Управления (из
соображений производительности нагрузку на один двухпроцессорный сервер
SCADA iFix не желательно превышать 30 тысяч тэгов), а также от количества
автономных производственно-технологических блоков и требований надежности и
автономности при реализации управления технологическими процессами (на
полностью автономных блоках технологических сооружений подразделений
целесообразно иметь свои SCADA серверы).
SCADA системы подразделений первого типа должны быть расположены в
оборудованных серверных помещениях, соответствующих требованиям к
помещениям такого типа, установленным АО "Мосводоканал".
Для оперативного восстановления работоспособности объектовой SCADA
системы в случае сбоя, обеспечивается реализация SCADA серверов "горячего"
резерва в серверных комнатах подразделений. Помимо "горячего" резервирования
основных SCADA серверов в подразделении первого типа, должно быть
реализовано "холодное" резервирование (создание резервных копий серверов
SCADA) на случай серьезных аварий в серверной производственного
подразделения.
Для контроля и управления отдельных объектов подразделений, оснащенных
местными диспетчерскими пунктами контроля и управления, используются пульты
и компьютерные сенсорные панели местного управления, реализующие функции
SCADA, достаточные для управления данными объектами.
Прямого взаимодействия с целью обмена данными на уровне SCADA систем
не осуществляется, т.е. данные не копируются с одного SCADA сервера на другой, а
используются клиентами непосредственно с исходных SCADA серверов.
3.2.Объекты второго типа
Регулирующие водопроводные узлы, высоковольтные насосные станции и ряд
других объектов находящихся в режиме автоматического управления и контроля,
оснащенных местными диспетчерскими пунктами управления, но не имеющих
столь же жестких требований по объёмам и срокам восстановления автоматического
управления, как объекты первого типа (время восстановления АСУТП после аварии
не должно превышать 1-2 суток). Для объектов этого типа критичным является
наличие контроля состояния объектов. Управление на некоторое время может быть
переведено в режим ручного/местного автоматического. Реализуется управление
технологическими системами с местного пульта управления контроллером объекта
в автоматическом режиме, ручное управление объектом по месту либо
использование SCADA клиента на объекте, соединенного с сервером SCADA в ЦОД
АО "Мосводоканал", данные на который поступают от контроллера объекта.
Контроллеры управления технологическими системами взаимодействуют по
резервированному каналу связи с центральной SCADA системой в ЦОД АО
"Мосводоканал".
Клиенты SCADA как местные (на объектах второго типа), так и в ЦДУ либо
других подразделениях взаимодействуют со SCADA системой в ЦОД.
3.3.Объекты третьего типа
К объектам третьего типа относятся все автономные небольшие
производственные объекты и точки контроля без диспетчерского или дежурного
персонала (канализационные станции, отдельные скважины, регулирующие камеры,
точки контроля параметров городской водопроводной и канализационной сети и
т.п.).
Контроллеры управления технологическими системами взаимодействуют с
центральной SCADA системой в ЦОД. Передача данных в ЦОД осуществляется по
дублированному (для критичных объектов) или обычному каналу передачи данных.
На данных объектах, как правило, нет управления либо реализовано
управление технологическими системами в местном ручном режиме. АСУТП
осуществляет только контроль параметров работы объекта. Отдельные объекты
третьего типа, относящиеся к зоне ответственности ЦДУ, управляются в
автоматическом и в дистанционном режиме.
Клиенты SCADA на объектах третьего типа отсутствуют. В ЦДУ либо других
подразделениях клиенты взаимодействуют со SCADA системой в ЦОД.
4.Режимы управления
В АСУТП АО "Мосводоканал" предусматривается два основных режима
управления: "Местное" и "Автоматическое ".
Типичная схема автоматизации производственных процессов приведена на
рисунке 1, ниже. Технологическое оборудование (насосы, поворотно-дисковые
затворы и т.п.) расположено в цеху и снабжено местными электрифицированными
пультами управления. Сигналы с пультов продублированы кнопками управления на
шкафу автоматики, который, в свою очередь, передает данные и получает рецепты
управления технологическим процессом через SCADA от диспетчера АСДКУ.
Шкафы управления АСУТП располагаются либо непосредственно в цеху,
вблизи основного технологического оборудования (при необходимости визуального
контроля объектов управления оператором) либо в местном диспетчерском пункте
или помещениях РТЗО.
На шкафах АСУТП должен быть предусмотрен ключ переключения режимов
управления: 1. Местное – с кнопок управления или графического терминала шкафа
автоматики; 2. Автоматическое, а также дистанционное – посредством АСУТП с
использованием контроллера; 3. Отключено – управление возможно только с
кнопочных пультов непосредственно по месту установки оборудования.
ЦДП
2.
АВТОМАТИЧЕСКОЕ
ДИСТАНЦИОННОЕ
SCADA
АРМ диспетчера
МДП
ЦЕХ
Шкаф управления
АСУ ТП
О
М
А
Расход 354,0
1.
МЕСТНОЕ
Насос
Вкл.
Выкл.
Авария
2.
АВТОМАТИЧЕСКОЕ
3.
3.
Вкл.
Закр.
Откр.
Выкл.
ПДЗ
Закр.
Откр.
Авария
ПДЗ
Насос
Рисунок 1
Традиционное "Местное" управление реализовано непосредственно с
кнопочных пультов по месту установки оборудования (затворов, насосов и пр.).
Местное управление оборудованием служит для гарантированного управления
технологическим
оборудованием
в
случае
выполнения
ремонтных,
профилактических и или иных работ, выходящих за рамки алгоритмов систем
автоматического управления, а также для обеспечения эксплуатации
производственных объектов в случаях отказа систем автоматического управления.
Также местное управление продублировано на шкафах управления для удобства
оператора. Для достаточно сложных объектов управления, затрудняющих
расположение значительного количества элементов управления на шкафу
автоматики либо требующих вывода значительного количества информации
оператору, местное управление от шкафа АСУТП может быть реализовано через
графический терминал шкафа с использованием контроллера. В режиме "Местного"
управление всегда осуществляет человек – оператор технологического процесса,
принимающий и непосредственно выполняющий все решения по переключениям
оборудования, в то время как контроллер либо не задействован в управлении либо
используется для обеспечения функционирования графического терминала
управления. В современной концепции управления технологическими процессами
АО "Мосводоканал" местное управление не является основным режимом работы
производственного оборудования и сохранено для обеспечения надежности в случае
отказа вычислительной техники и линий связи, а также для проведения работ не
предусмотренных алгоритмами автоматического управления.
Режим "Автоматического" управления является основным режимом
функционирования технологических процессов, охваченных системами АСУТП. В
этом режиме управление осуществляет контроллер по заранее заданному алгоритму
проведения технологического процесса. Контроллер автоматически поддерживает
работу оборудования без участия оператора. Оператор вмешивается в работу
контроллера только эпизодически, меняя режимы работы системы посредством
отправки "рецептов" управления с графического терминала шкафа управления либо
через человеко-машинный интерфейс (ЧМИ) системы диспетчерского контроля и
управления (SCADA). Для сложных объектов, не имеющих проработанных
сценариев автоматического предотвращения последствий аварийных ситуаций либо
не обладающих требуемой надежностью систем управления, может быть
предусмотрен режим "Дистанционного" телеуправления оборудованием через
интерфейс SCADA или графический терминал шкафа АСУТП.
Положение переключателя "Отключено" на шкафах управления используется
для проведения ремонтных либо регламентных работ с оборудованием и
обусловлено требованиями "Межотраслевых правила по охране труда (правила
безопасности) при эксплуатации электроустановок" и "Правил технической
эксплуатации электроустановок потребителей". Переключатель режимов местного и
автоматического управления на шкафах автоматики обязательно выполняется
механическим. Переключение автоматического режима в дистанционный, с АРМ
оператора, напротив, реализуется программным способом.
При оснащении шкафов автоматического управления АСУТП сенсорным
пультом оператора, должны предусматриваться следующие пользователи с
соответствующими правами доступа и интерфейсами управления: 1. Просмотр
данных (без пароля, без управления, только просмотр текущих режимов), 2.
Оператор (с паролем и доступам к изменению технологических параметров
управления объектом – уставок, режимов и пр.), 3. Инженер (с паролем и доступом к
изменению параметров настроек и характеристик оборудования, диапазонов
измерения приборов, параметров конкретных приводов и пр.). Для каждого из
режимов должна разрабатываться инструкция пользователя.
5.Требования к выбору архитектуры и технических средств АСДКУ (SCADA)
SCADA cистема должна быть открытой, состоящей решений, основанных на
действующих промышленных стандартах и технологиях.
В качестве серверов АСДКУ (SCADA) должно применяется стандартное для
АО "Мосводоканал" оборудование, дополненное требованиями в части обеспечения
надежности систем АСДКУ в зависимости от требований конкретного проекта и
условий производственного подразделения.
Физические серверы АСДКУ (SCADA) должны оснащаться:
вторым (резервным) блоком питания;
дополнительными сетевыми интерфейсами (картой) для связи с нижним
уровнем – сетью контроллеров и средств управления производством;
необходимым для организации надежного хранения данных набором
дисков для организации RAID массива не ниже 5-го;
а также иметь не менее двух процессоров и 4-х Гб оперативной памяти на
каждый процессор (в зависимости от планируемого количества обрабатываемых
базой данных реального времени SCADA сигналов контроля и управления).
В качестве аппаратной платформы сервера SCADA в АО "Мосводоканал" в
настоящее время рекомендован к применению сервер Dell PowerEdge R730 в
вышеуказанной конфигурации либо его современный аналог. Допускается
проектирование и реализация виртуальных серверов SCADA на базе платформы
виртуализации VMware.
Для SCADA северов в зависимости от требований к времени восстановления
может применяться "горячее" резервирование на базе технологии SCADA GE iFix
или средствами виртуальной платформы, либо "холодное" резервирование за счет
аварийного запаса технических средств – аппаратной части сервера и
периодического резервного копирования программных средств и данных каждого
SCADA сервера.
В качестве основной в АО "Мосводоканал" принята SCADA производства GE
iFix. Рекомендовано использование текущей версии системы iFIX - 5.8 или более
новой. Использование в разработке проектов предыдущих версий SCADA: FIX
DMAX, FIX32, GE iFIX версий 1.0, 2.0, 2.1, 2.21, 2.5, 2.6, 3.0, 3.5, 4.0, 4.5, 5.0, 5.1,
5.5) допускается только в рамках реализации совместимости с ранее установленным
и действующим программным обеспечением отдельных технологических процессов
на объектах АО "Мосводоканал", в случаях, если производится комплексная
модернизация (реконструкция) объекта. При этом должно выбираться программное
обеспечение в варианте поставки GE iFIX Plus, поддерживающем распределенное
клиент-серверное сетевое взаимодействие с другими узлами SCADA iFIX.
SCADA iFIX обладает следующими характеристиками:
Поддержка платформы PC под управлением операционных систем
семейства Windows (7-32/64, server 2008 R2);
Поддержка SQL/ODBC;
Поддержка обмена данными с помощью следующих интерфейсов и
протоколов: Ethernet; OPC; PROFIBUS; Modbus.
Для связи со вспомогательными системами доступны следующие
возможности сервера либо вспомогательного оборудования: интерфейсы
RS-232C, RS-422 и RS-485 с поддержкой полнодуплексного и
полудуплексного режимов и выбора скорости передачи данных (19200
бод, 38400 бод, 57600 бод и 115200 бод) и протокол IEEE 802.3 Ethernet
10Мбит, 100Мбит, 1000Мбит с поддержкой TCP/IP.
При
разработке
проектов
реконструкции/модернизации,
проектная
организация обязана учитывать возможность обновления существующих лицензий
SCADA iFix, имеющихся в АО "Мосводоканал" с целью снижения закупочной
стоимости программного обеспечения.
При разработке проектов автоматизации и определении лицензирования
SCADA iFix для технологических объектов должен быть обеспечен запас по точкам
ввода/вывода не менее 20% относительно количества сигналов, входящих в проект.
Для
обеспечения
работы
центральных
SCADA-узлов
крупных
производственных объектов, объединяющих несколько технологических процессов
или поддерживающих взаимодействие с другими серверами SCADA iFIX, должен
выбираться вариант поставки Development либо более функциональный,
допускающий on-line доработку SCADA без остановки функционирования АРМ
диспетчеров и операторов.
Для автономных объектов и отдельных технологических процессов, на
которых требуется полноценная SCADA оператора, но не планируется доработка
интерфейсов SCADA систем без отключения функционирования АРМ
диспетчерского пункта, допустимо использовать Runtime версию.
В качестве клиентского программного обеспечения SCADA в АО
"Мосводоканал" в настоящее время рекомендовано программное обеспечение GE
iFIX iClient версии Development, поддерживающей разработку ПО SCADA (не менее
одного клиента на каждый узел SCADA iFix) и Runtime – для поддержки работы
диспетчеров и операторов, без разработки ПО SCADA.
Для организации работы специалистов, не требующей доступа к управлению
технологическим оборудованием, должна использоваться версия клиента Read-Only,
предназначенная только для просмотра, где запись в базу данных и OPC-серверы
отключена.
Для записи оперативных данных истории технологического процесса
рекомендовано применение программы GE iHistorian – специализированной базы
данных для систем промышленной автоматизации, обработка данных в которой
происходит по принципу реального времени в виде временных рядов. Независимо
от использования GE iHistorian должна обеспечиваться запись данных на MS SQL –
собственный сервер истории технологических процессов, в формате, выбранном АО
"Мосводоканал".
Типовыми для АО "Мосводоканал" принимаются следующие возможные
конфигурации АСУТП объектов применительно к использованию SCADA:
1. Объекты без SCADA-серверов и без клиентов SCADA;
2. Объекты без SCADA-серверов, но с клиентскими АРМ SCADA;
3. Объекты с несколькими SCADA-серверами и клиентскими АРМ SCADA.
Объектом
считается
территория
производственных
подразделений,
принадлежащая на тех или иных правах АО "Мосводоканал", на которой может
быть реализована надежная проводная связь между компонентами АСУТП:
управляемым и контролируемым оборудованием, контроллерными шкафами
управления, SCADA-серверами и АРМ. В случаях, когда несколько территорий
подразделений Общества не могут быть объединены собственной кабельной
системой связи и управления, а используются каналы связи внешних провайдеров
услуг связи, целесообразно различать, как несколько отдельных объектов
управления, ввиду требований информационной и промышленной безопасности
АСДКУ.
Критерии выбора типового решения по использованию SCADA следующие:
1. Объекты без SCADA-серверов и без клиентов SCADA:
1.1.
Отсутствие постоянного диспетчерского персонала, для обеспечения
работы которого непрерывно требуется SCADA;
1.2.
Отсутствие необходимости осуществлять управление объектом
автономно, в отрыве от АСДКУ АО "Мосводоканал", длительное время
с полной функциональностью, которая может быть реализована только
посредством интерфейсов SCADA (и не может быть реализована с
локальных органов управления либо графических терминалов шкафов
контроллеров);
1.3.
Возможность реализации основных функций управления и контроля с
кнопок управления локального щита управления либо графического
терминала шкафа контроллера (то есть достаточная полнота систем
автоматического контроля и управления, позволяющая реализовать все
основные алгоритмы и режимы работы объекта без участия либо с
минимальным участием оператора через продолжительные интервалы
времени);
1.4.
Наличие вышестоящего центра управления объекта, подразделения или
всего АО "Мосводоканал" выполняющего данные функциональные
задачи контроля и управления, к которому с достаточной надежностью
могут
быть
подключены
контроллеры
АСУТП
объекта,
обеспечивающие
централизованный
контроль
посредством
вышестоящей SCADA.
Если критерии 1.1. – 1.4. выполнены, то SCADA на объекте не
проектируется.
2. Объекты без SCADA-серверов, но с клиентскими АРМ SCADA
2.1.
Наличие постоянного диспетчерского персонала, для обеспечения
работы которого непрерывно требуется SCADA (например, в случае
нескольких контроллеров на территориально распределенном объекте,
управление которыми проще объединить через интерфейс SCADA, чем
организовывать местный щит управления либо сводить вместе
графические терминалы шкафов контроллеров);
2.2.
Отсутствие необходимости осуществлять управление объектом
автономно, в отрыве от АСДКУ АО "Мосводоканал", длительное время
с полной функциональностью, которая может быть реализована только
посредством интерфейсов SCADA либо при наличии резервного канала
связи с объектом, обеспечивающего достаточную надежность (то есть
функции SCADA не требуются в течении времени, за которое реально
может быть восстановлена связь с объектом управления и в течении
которого можно продолжать управлять объектом в местном режиме);
2.3.
Наличие вышестоящего центра управления объекта, подразделения или
всего АО "Мосводоканал" выполняющего данные функциональные
задачи контроля и управления SCADA.
Если критерии 2.1. – 2.3. выполнены, то SCADA-сервер на объекте не
проектируется, а устанавливается в центральном офисе (ЦОД или в серверной
подразделения Общества), а на объекте планируется АРМ SCADA. Установка и
расположение местных органов управления и частично дублирующих функции
SCADA графических терминалов шкафов контроллеров определяется проектом.
3. Объекты с несколькими SCADA-серверами и клиентскими АРМ SCADA
3.1.
Наличие постоянного диспетчерского персонала, для обеспечения
работы которого непрерывно требуется SCADA (например, в случае
нескольких контроллеров на территориально распределенном объекте,
управление которыми проще объединить через интерфейс SCADA, чем
организовывать местный щит управления либо сводить вместе
графические терминалы шкафов контроллеров);
3.2.
Наличие необходимости осуществлять управление объектом автономно,
в отрыве от АСДКУ АО "Мосводоканал", длительное время с полной
функциональностью, которая может быть реализована только
посредством интерфейсов SCADA;
3.3.
Наличие необходимости дублирования и резервирования функций
контроля и управления между несколькими диспетчерскими пунктами
объекта с целью обеспечения большей надежности контроля и
управления;
3.4.
Отсутствие возможности контроля и управления с локальных/местных
органов управления либо графических терминалов шкафов
контроллеров из-за отсутствия достаточного количества персонала либо
недостаточной развитости локальных систем контроля и управления;
3.5.
Отсутствие вышестоящего центра управления объекта, подразделения
или
всего
АО
"Мосводоканал"
достаточной
мощности,
зарезервированного под выполнение данных функциональных задач
контроля и управления.
Если критерии 3.1. – 3.5. выполнены, то на объекте проектируются и
устанавливаются как SCADA-серверы, так и АРМ SCADA. Установка и
расположение местных органов управления и частично дублирующих функции
SCADA графических терминалов шкафов контроллеров определяется проектом.
Во всех случаях в данном разделе под надежностью понимается проектная
оценка и расчет надежности по сформулированным заказчиком временным
критериям доступности и работоспособности узлов управления.
Варианты с установкой сервера без клиентского ПО SCADA либо сервера
SCADA с реализацией АРМ SCADA непосредственно на сервере не
рассматривается ввиду нецелесообразности.
Детально принципы проектирования и создания SCADA рассмотрены в
документе СТП-42439-02-12-14 "Стандарт разработки SCADA (iFix). Правила
разработки систем диспетчерского контроля и управления (баз данных, мнемосхем,
аварийной и предупредительной сигнализации, организации управления) SCADA
(iFix) ОАО Мосводоканал", предоставляемом по запросу организации,
выполняющей работы по проектированию и созданию АСУТП на объектах
Общества.
5а. Требования к перспективной SCADA
Нижеследующие технические требования относятся к внедрению
перспективной системы диспетчерского контроля и управления, применимы к
пилотным проектам внедрения SCADA в АО "Мосводоканал".
5а.1. ОБЩИЕ ТРЕБОВАНИЯ
5а.1.1.
Программное обеспечение SCADA должно состоять из системы
человеко-машинного интерфейса (ЧМИ) с поддержкой контроля и управления
процессом, сбора данных в реальном времени, управления аварийными сигналами
и событиями, сбора архивных данных, создания отчетов, локальной
или дистанционной телеметрической связи с контроллерами (PLC, PAC)
и удаленными терминалами (RTU) и доступа в интернет/интранет. ПО должно быть
доступно для использования специалистам, не имеющим опыта программирования,
иметь объектно-ориентированную графическую среду разработки и открытую
архитектуру, поддерживаемую серверными и клиентскими операционными
системами Microsoft Windows последних версий, а также Linux.
5а.1.2.
Система должна иметь интуитивно-понятный интерфейс, чтобы
обеспечивать конфигурирование в соответствии с индивидуальными требованиями
конечного пользователя, а также быструю и легкую модификацию конечным
пользователем в полевых условиях.
5а.1.3.
ПО должно состоять из набора готовых модульных компонентов
от одного разработчика ПО, тесно интегрированных между собой для выполнения
всех функций системы SCADA. В набор должны входить следующие компоненты:
ЧМИ для визуализации процесса, реляционная база данных реального времени
для сбора архивных данных с открытым и доступным интерфейсом запросов,
клиентские инструменты для анализа тенденций и отчетности как в составе ЧМИ,
так и в виде автономных утилит. Коммуникационные драйверы для контроллеров
(PLC, PAC) и удаленных терминалов (RTU) должен предоставлять и поддерживать
поставщик ПО.
5а.1.4.
Система должна быть масштабируемой, позволяющей легко
развернуть небольшое отдельное автономное приложение в большую
распределенную сеть управления с одиночными или резервированными серверами
баз данных, с одиночными или резервированными коммуникационными серверами,
предоставляющими информацию множеству клиентских рабочих станций. ПО
также должно легко взаимодействовать с внешними базами данных; с системами
моделирования, управления ресурсами предприятия (EAM; Enterprise Asset
Management), мониторинга на основе состояний (CBM; Condition Based Monitoring);
с системами управления обслуживанием (CMMS), ERP, LIM и GIS.
5а.2. ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ
АО "Мосводоканал" –
ПО
–
ЧМИ
–
АСУ ТП
–
Акционерное общество "Мосводоканал"/Общество;
Программное обеспечение;
Человеко-машинный интерфейс;
Автоматизированная
система
управления
технологическими процессами;
SCADA
–
Система диспетчерского контроля и управления (сокр.
от англ. Supervisory Control And Data Acquisition).
5а.3. ОТКРЫТЫЙ ПОДХОД К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ SCADA
5а.3.1.
Использование широко распространенных промышленных
интерфейсов и коммерческого ПО
ПО должно иметь возможность обмена данными и взаимодействия с наиболее
распространенными аппаратными и программными компонентами промышленного
производства, включая, помимо прочего, периферийные устройства ввода/вывода,
базы данных и бизнес-системы Общества.
5а.3.2.
Расширяемость
5а.3.2.1.
Поставляемое ПО должно иметь возможность расширения силами
компетентного системного интегратора или системного инженера.
5а.3.2.2.
К обслуживающему персоналу не должны предъявляться
требования иметь специальные навыки программирования. ПО должно содержать
современные
инструментальные
средства,
позволяющие
интегрировать
пользовательские программные компоненты в ПО SCADA и получать по ним
техническую поддержку.
5а.3.2.3.
Программная архитектура должна поддерживать до одного канала
неограниченного ввода-вывода и неограниченное число узлов в распределенной
сети.
5а.3.3.
Стандарты
5а.3.3.1.
ПО
должно
соответствовать
открытому
подходу
к
программированию, а также должно поддерживать отраслевые стандарты
предприятия.
5а.3.3.2.
предприятия.
При программировании следует строго использовать стандарты
5а.3.3.3.
Графика всей системы должна подчиняться основной теме стилей
и придерживаться основного определения цвета и шрифта, определённого
стандартом предприятия на разработку SCADA.
5а.4. ПОДДЕРЖИВАЕМЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ
5а.4.1.
ПО должно быть лицензировано для поддержки последних версий
любой из перечисленных ниже операционных систем на соответствующем
оборудовании в любых комбинациях:
Microsoft Windows 8 (Professional, Enterprise) (32/64-битные);
Microsoft Windows 10 (Professional, Enterprise) (32/64-битные);
Microsoft Windows 2012 R2 Server (Standard и Data Center) (64-битные);
Microsoft Windows 2016 Server (Standard и Data Center) (64-битные);
Linux;
iOS;
Android.
5а.4.2.
Должны поддерживаться версии перечисленных выше клиентских
операционных систем для планшетного компьютера и смартфона.
5а.4.3.
При выпуске более поздней версии операционной системы
поставщик должен подготовить определенную декларацию и план реализации
поддержки этой операционной системы.
5а.4.4.
ПО SCADA должно также поддерживаться в среде виртуальных
машин, включая среды Microsoft Hyper-V и VMware, при соответствии требованиям
высокого уровня готовности (HA; High Availability), восстановления после аварий
(DR; Disaster Recovery) и отказоустойчивости (FT; Fault Tolerance).
5а.4.5.
Аппаратная поддержка должна распространяться на многоядерные
и многопроцессорные компьютеры.
5а.5. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
СРЕДЫ РАЗРАБОТКИ
5а.5.1.
Единая среда разработки
Среда разработки должна представлять собой единое интегрированное
приложение, позволяющее управлять всеми аспектами разработки и тестирования
приложений SCADA.
5а.5.2.
Многопользовательская среда разработки
Среда разработки должна обеспечивать одновременную работу множества
пользователей, причем пользователи должны получать полномочия в зависимости
от персональных ролей в системе.
5а.5.3.
Модели объектов
5а.5.3.1.
В среде разработки должны использоваться модели объектов,
позволяющие разрабатывать приложение, которое моделирует физические
характеристики системы SCADA, включая географическую топологию, физическое
оборудование и места расположения компьютеров. В системе должна
использоваться концепция прикладных объектов (Application Objects). Эти объекты
могут моделировать устройства реального мира, такие как компьютеры, контуры
ПИД-регулирования, двигатели, насосы, клапаны и т. д., либо информационные
объекты, такие как внешние средства чтения и записи баз данных, средства чтения и
записи файлов XML и т. д.
5а.5.3.2.
Прикладные объекты должны максимально точно моделировать
физическое представление промышленного оборудования и устройств и не
ограничиваться использованием только одних тегов.
Сюда должна включаться возможность создания сложных структур данных
с множеством переменных.
5а.5.4.
Представления среды разработки
Среда разработки должна давать следующие возможности:
организовывать шаблоны объектов в настраиваемые пользователем
инструментарии шаблонов (Template Toolbox);
организовывать графику визуализации в настраиваемые пользователем
инструментарии графических шаблонов (Graphic Template Toolbox);
связывать графику визуализации с настраиваемыми пользователем
инструментариями графических шаблонов;
просматривать и настраивать приложения с точки зрения промышленной
модели;
просматривать и настраивать приложения с точки зрения развертывания
прикладного объекта;
просматривать и настраивать объекты, отображая генеалогию объекта от
него самого до его родительских шаблонов и до базового объекта, независимо от
длины цепочки отношений «родитель-потомок»;
просматривать и настраивать приложения с точки зрения подключения
устройств ввода-вывода.
5а.5.5.
Безопасность работы пользователей
Среда разработки должна допускать использование средств безопасности
операционной системы Microsoft, например, доменов Active Directory, для
предоставления пользователям доступа к просмотру, настройке или изменению
шаблонов и прикладных объектов.
5а.5.6.
Журнал аудита разработки
Среда разработки должна вести журнал аудита блокировки и освобождения
объектов и истории изменений для каждого шаблона или прикладного объекта,
включая в идентификатор пользователя лица, вносившего изменения, отметку
времени и даты, а также подробное описание сделанных изменений.
5а.5.7.
Централизованная настройка общесистемных параметров
Среда разработки должна допускать централизованное конфигурирование
общесистемных параметров, включая следующее:
Настройка стандартного графического представления качества и статуса.
Настройка стандартных стилей графических элементов.
Настройка стандартных стилей форматирования чисел.
Организация аварийных сигналов в четыре категории серьезности:
critical, high, medium и low (критическая, высокая, средняя и низкая) для удобства их
интерпретации операторами.
Сопоставление приоритетов и серьезности аварийных сигналов.
Выбор серьезности аварийных сигналов, реагирование на которые можно
отложить.
Исключение сигналов высокой серьезности.
Выбор значков для представления каждого из поддерживаемых уровней
серьезности.
Выбор уровней серьезности аварийных сигналов, которые следует
архивировать.
Выбор типов событий, которые следует архивировать.
Настройка аварийной сигнализации о состоянии установки.
Агрегирование аварийных сигналов – возможность подсчета и
подведения итогов по всем аварийным сигналам в каждой зоне и выделения
информации о наиболее серьезном аварийном сигнале.
Все решения аварийной сигнализации, включенные в отраслевой
стандарт и описанные в соответствующих международных стандартах, должны
встраиваться в свойства продукта. Они не должны разрабатываться заново или
программироваться в виде скрипта.
5а.5.8.
Повторное использование объектов и программного кода
Среда разработки должна поддерживать повторное использование кода
определяя прикладные объекты на основе шаблонов. Шаблоны должны быть
изменяемыми, чтобы создавать новые шаблоны прикладных объектов и настраивать
отношения "родитель-потомок" в определениях объектов.
5а.5.9.
Репозиторий объектов
5а.5.9.1.
В среде разработки должен использоваться централизованный
репозиторий для хранения шаблонов и прикладных объектов, иерархии объектов,
конфигурации развертывания и генеалогии. Должна также обеспечиваться
возможность использования одного и того же репозитория для хранения и
обработки графических шаблонов и приложений визуализации.
5а.5.9.2.
В качестве сервера базы данных для репозитория должна
использоваться реляционная или документ-ориентированная БД. Разработчик этого
ПО должен предоставить его лицензионную копию.
5а.5.10.
Целостность конфигурации
Среда разработки должна позволять пользователям с правами
конфигурирования просматривать объекты. Среда должна гарантировать, что
в любой момент времени только один человек сможет заблокировать для изменения
конкретный шаблон или прикладной объект.
5а.5.11.
Репозиторий объектов во время выполнения
Репозиторий должен использоваться только для настройки и, соответственно,
допускать отключение от запущенной системы без ущерба для ее работы.
Репозиторий может использоваться и во время выполнения, но это не должно быть
обязательным.
5а.5.12.
Шаблоны объекта
Среда разработки должна предоставлять механизм для разработки шаблонов
прикладных объектов. Эти шаблоны объектов должны использоваться для создания
отдельных экземпляров объектов, выполняющих задачи SCADA. Шаблоны
объектов должны позволять включение в свой состав других шаблонов объектов
в иерархическом порядке (отношение "родитель-потомок"). Дочерний шаблон
должен наследовать атрибуты и характеристики своего "родителя", но разрешать
управляемое переопределение или настройку этих унаследованных функций.
Объекты должны содержать общую конфигурацию, определения ввода/вывода и
внутренних атрибутов, внутреннюю документацию, облегчающую настройку,
определения пользовательских атрибутов, аварийных сигналов и истории, средства
безопасности и встроенные скрипты. В состав прикладного объекта должна входить
связанная с ним графика или графика для его визуализации.
5а.5.13.
Мастера для объектов
Среда разработки должна предоставлять механизм для создания мастера
объектов, позволяющего включать атрибуты, входы/выходы, символы и скрипты
в настраиваемый шаблон объекта. Эти мастера должны обеспечивать создание
экземпляров объектов путем простого выбора параметров. Эти мастера должны
уменьшать потребность в глубоком дереве наследования объектов и улучшать
масштабируемость.
5а.5.14.
Шаблоны стандартных объектов
В среде разработки должны быть представлены базовые шаблоны, как
предоставляемые производителем ПО, так и определяемые пользователем. Должен
быть доступен инструментарий объектов, позволяющий пользователям создавать
новые базовые объекты в среде Microsoft Visual Studio, на языках таких как C++, C#,
а так же в ОС Linux на языках таких как gcc, mono, python.
5а.5.15.
Защита объектов
Системы разработки должны иметь возможность настраивать защиту в рамках
модели. Система безопасности должна поддерживать объектно-ориентированную
иерархическую модель. Эта модель должна поддерживать создание групп
безопасности и привязку к ним прикладных объектов. Модель должна поддерживать
присвоение операторам ролей и привязку этих ролей к группам безопасности. Роли
операторов должны определять назначаемые им полномочия, такие как
конфигурирование баз данных, функциональные полномочия времени выполнения,
доступ к визуализации определенных окон. Как минимум, функциональные
полномочия времени выполнения должны позволять следующее:
Разрешение или запрет возможности подтверждения аварийного сигнала в
среде выполнения.
Изменение атрибутов конфигурации, позволяющее пользователям
настраивать значения этих атрибутов (например, регистра ПЛК, который определяет
дискретный вход).
Изменение функциональных атрибутов, позволяющее пользователям с
функциональными полномочиями выполнять некоторые обычные повседневные
задачи, такие как изменение ставки, режим вывода и управления для ПИД объекта
или управления объектами-устройствами.
Открытие и просмотр окон процесса или приложения.
Изменение атрибутов настройки, позволяющих пользователям настраивать
атрибут в среде выполнения. Примерами настройки могут служить атрибуты,
регулирующие контрольные точки аварийной сигнализации и чувствительности
системы ПИД.
Возможность откладывать реагирование на аварийный сигнал.
Пользователи, привязанные к определенной роли, должны наследовать все
параметры, которые были присвоены этой роли и группе безопасности.
5а.5.16.
Встроенное конфигурирование архивных данных
Настройка сохранения архивных данных атрибута в объекте должна
обеспечиваться простой установкой флажка в шаблоне этого объекта.
Использование дополнительных инструментов не допускается.
5а.5.17.
Встроенное конфигурирование данных аварийных сигналов
Шаблон объекта должен обеспечивать настройку соединения с подсистемой
аварийной сигнализации, поддерживающей сигналы, ориентированные на состояния
(LoLo, Lo, Hi, HiHi, отклонения скорости изменения данных и т. д.), и сигналы,
ориентированные на события (True/False, сбой открытия, сбой закрытия,
несогласованность команд и т. д.), с помощью предварительно определенных
инструментов, которые помогают разработчику пошагово настраивать
конфигурацию.
5а.5.18.
Встроенная графика
Шаблон объекта должен поддерживать объединение и настройку одного или
нескольких графических представлений для визуализации. Само приложение
визуализации должно поддерживать представление и включение в шаблон объекта.
5а.5.19.
Логические скрипты приложения в шаблоне объекта
5а.5.19.1. Шаблон объекта должен поддерживать объединение и настройку
одного или нескольких логических скриптов.
5а.5.19.2. В скриптах, содержащихся в шаблоне объекта, должна
использоваться технология Microsoft .NET (dot NET). Скрипты должны
компилироваться в код общеязыковой среды исполнения .NET (CLR; Common
Language Runtime). Скрипты должны легко составляться из англоязычных
операторов; при этом не должно выдвигаться требование знать другие языки
программирования. Пользователю должно быть доступно редактирование или
изменение логических скриптов, когда система контролирует процесс.
5а.5.19.2. В интерфейсе редактора скриптов должны быть устанавливаемые
флажки и раскрывающиеся меню, обеспечивающие создание операторов без ввода
имен тегов или специальных команд. Программное обеспечение должно
поддерживать основные команды и операции, такие как IF, THEN, ELSE, ELSE IF,
AND, OR, NOT, ADD, SUBTRACT, MULTIPLY, DIVIDE, EQUAL TO, NOT EQUAL
TO, GREATER THAN и LESS THAN.
5а.5.19.3. Редактор
автозаполнения.
скриптов
должен
поддерживать
функции
5а.5.19.4. Должна быть доступна полная библиотека более сложных
функций математических и системных скриптов. По нажатию специальной кнопки
должна запускаться проверка правильности синтаксиса с отображением ошибок, что
позволит предотвратить возможные проблемы во время выполнения.
5а.5.19.5. Язык скриптов должен поддерживать использование встроенных
в Microsoft .NET вызовов функций скрипта.
5а.5.19.6. Интерактивная справка по каждой функции скрипта должна
содержать реальные рабочие примеры, которые можно скопировать и вставить в
редактор скриптов. Функции Dot NET, предоставляемые компанией Microsoft,
должны соответствовать документации Microsoft.
5а.5.19.7. Системная логика должна поддерживать настройку объектов на
автоматическое выполнение таких функций, как увеличение уставок, вычисление
сводных данных и проверка состояния параметров процесса для принятия
соответствующих мер.
5а.5.20.
Мониторинг состояния и аварийные сигналы
Системная логика должна поддерживать конфигурацию объектов,
позволяющую отслеживать состояние любого тега или атрибута иерархического
имени в системе и выполнять заданные функции в зависимости от типа и состояния
условий выдачи аварийного сигнала.
5а.5.21.
Логика управления приложением и обмена данными
Система должна поддерживать конфигурацию объектов, управляющую
приложениями и позволяющую изменять состояние дискретных точек, отображать
окна, загружать рецептуру и т. д. Эта прикладная логика должна также запускать и
останавливать другие прикладные программы, такие как Microsoft Excel, Microsoft
Word, Crystal Reports и другие приложения под управлением Windows. Система
должна поддерживать выполнение скриптов по заданному условию, например, при
запуске экземпляра объекта и при выполнении им программного цикла, при
выполнении условий "true", "while true", "false" и "while false", с заданной
периодичностью, при выходе экземпляра объекта из программного цикла и при его
отключении.
5а.5.22.
Логика условного управления и обмена данными
5а.5.22.1. Система должна поддерживать конфигурацию объектов,
управляющую приложениями в зависимости от определяемого пользователем
состояния объекта и атрибута или от результата выражения, включающего
несколько имен тегов или иерархических имен объектов, в том числе состояния
"вкл/выкл" тегов или дискретных объектов; от аварийных состояний определенного
значения, таких как Lo, LoLo, Hi, HiHi или их аналогов.
5а.5.22.2. Необходима возможность создания скриптов условной логики,
которые выполняются либо один раз, когда условное выражение становится
истинным или ложным; либо с заданной пользователем периодичностью (не менее
50 мс), пока условие остается истинным или ложным; либо при изменении значения,
проверяемого скриптом по какому-либо событию.
5а.5.23.
Конфигурирование объектов ввода-вывода
5а.5.23.1. В среду разработки должен быть включен диспетчер
коммуникаций прикладных объектов сервера ввода-вывода, обеспечивающий
удаленную установку сервера данных, активацию и использование настроек, а также
поиск неисправностей с полной диагностикой протоколов.
5а.5.23.2. Среда разработки должна поддерживать автоматическую привязку
прикладных объектов к устройствам и указание в атрибутах входных источников и
выходных пунктов назначения.
5а.5.24.
Производный шаблон объекта, создание экземпляра объекта и
наследование
5а.5.24.1. Необходима возможность получения новых шаблонов из
существующих, как из базовых (то есть предоставленных производителем ПО), так
и из определенных пользователем. Производный шаблон должен наследовать всю
конфигурацию родительского объекта при создании нового экземпляра шаблона. В
иерархии шаблонов могут содержаться другие шаблоны. Производные шаблоны
должны поддерживать любую иерархию, входящую в родительский шаблон.
5а.5.24.2. Среда разработки должна блокировать заданные атрибуты, чтобы
обеспечить перенос изменений родительского шаблона в новый экземпляр и все
дочерние объекты этого нового экземпляра. Заблокированные атрибуты запрещено
изменять в дочернем шаблоне.
5а.5.25.
Развертывание объекта
5а.5.25.1. В среде разработки должна использоваться концепция
развертывания. Развертывание следует определять как дистанционную установку
любого прикладного объекта, его дочерних объектов, зависимостей и любого
другого необходимого ПО, связанного с прикладным объектом, чтобы этот
прикладной объект успешно работал, включая, помимо прочего, управляющие
элементы .NET и динамические библиотеки (DLL).
5а.5.25.2. Все компоненты экземпляров прикладных объектов должны
настраиваться и развертываться на целевые рабочие станции и серверы из среды
разработки.
5а.5.25.3. Изменения атрибутов прикладного объекта, произошедшие во
время выполнения, должны сохраняться, даже если головной процесс
перезапускается, прекращает работу из-за сбоя или развертывается повторно из
среды конфигурирования. При повторном развертывании сохраняемые данные
должны восстановиться не позже, чем через 2-3 цикла.
5а.5.26.
Состояние объектов
5а.5.26.1. Среда разработки должна обеспечивать визуальную обратную
связь относительно состояния развертывания любого прикладного объекта.
5а.5.26.2. Среда разработки должна обеспечивать визуальную обратную
связь о состоянии любого прикладного объекта, ожидающего изменений.
5а.5.27.
Утилита импорта и экспорта
5а.5.27.1. Среда разработки должна поддерживать импорт и экспорт
прикладных моделей в формат, читаемый человеком, например, CSV (значения,
разделенные запятыми), для редактирования в программах электронных таблиц,
таком как Microsoft Excel.
5а.5.27.2. Должна обеспечиваться возможность создавать шаблоны и
прикладные объекты из загруженных файлов CSV, предварительно заполнив в
электронной таблице соответствующие столбцы, необходимые для создания или
настройки желаемых объектов.
5а.6. ТРЕБОВАНИЯ К ПО ДЛЯ РАЗРАБОТКИ ЧЕЛОВЕКОМАШИННОГО ИНТЕРФЕЙСА
5а.6.1.
Вся разработка и параметры конфигурации должны сохраняться в
одном или нескольких общих репозиториях в виде файлов или баз данных,
обеспечивающих единую точку настройки.
5а.6.2.
Среда разработки должна обеспечивать возможность размещения
приложения визуализации в общем репозитории и управления этим приложением.
Кроме того, следует строго придерживаться соглашения об именовании объектов
и тегов, которое обеспечивается инструментами разработки.
5а.6.3.
В дополнение к встроенной поддержке приложений в
вышеупомянутых системах, должна быть возможность настройки одних и тех же
приложений для работы в сеансах тонкого клиента или в сеансах удаленного
рабочего стола, запущенных на дисковых или бездисковых ПК под управлением
Microsoft Windows 2012 R2 или более поздних версий службы удаленного рабочего
стола (RDS, ранее известной как "Службы терминалов").
5а.7. ТРЕБОВАНИЯ К ЛОКАЛИЗАЦИИ
5а.7.1.
ПО разработки системы SCADA должно обеспечивать создание
приложения, которое во время выполнения может динамически переключаться с
одного языка на другой.
5а.7.2.
Система должна поддерживать любую доступную на данный
момент языковую настройку операционной системы.
5а.7.3.
двух).
Необходима возможность настройки нескольких языков (более
5а.7.4.
Строки, используемые в текстовых объектах с графикой, должны
отображаться на одном из нескольких языков, выбираемом динамически в
соответствии с предпочтениями оператора при входе в систему.
5а.7.5.
Необходима настройка отображения аварийных сообщений на
выбранном в данный момент языке.
5а.7.6.
При отсутствии эквивалентной переведенной строки
выбранном языке должна отображаться строка на языке по умолчанию.
на
5а.8. РАЗРАБОТКА ГРАФИЧЕСКОГО ЭКРАНА
В состав системного ПО SCADA должен входить генератор экранов объектноориентированной цветной графики с возможностями полноценной анимации,
позволяющей дать пользователям реалистичную и эффективную визуализацию
системного процесса SCADA. Этот генератор должен предоставлять графические
возможности, позволяющие разрабатывать высокоэффективные приложения для
ЧМИ, помогающие операторам без труда разобраться в состоянии процесса.
Все операции графического редактирования должны вызываться по щелчку
мышью значков на плавающих и закрепляемых панелях инструментов, выбором
пунктов раскрывающихся меню или по командам, вводимым с клавиатуры.
В состав среды разработки графики должны входить инструменты
оптимизации графики, отображающие ожидаемую производительность графической
системы во время выполнения. Необходимо предусмотреть возможность
функциональной проверки любого графического экрана путем переключения
в режим выполнения одним щелчком мыши.
Среда разработки должна работать в сеансе удаленных рабочих столов (или
служб терминалов).
Редактор экранов должен содержать инструменты черчения, компоновки и
анимации, подробно описанные в этом подразделе.
Графический редактор должен иметь библиотеку с широким выбором готовых
сложных графических объектов и символов процесса, таких как счетчики, кнопки,
движки, датчики, насосы, двигатели, резервуары, клапаны, графики трендов,
аварийные сигналы и лицевые панели контроллеров. Все сложные объекты должны
быть масштабируемыми до любого размера и, возможно, иметь связь с анимацией
для отображения динамической реакции на данные, получаемые в реальном
времени, или на действия пользователя.
Редактор должен давать возможность разработки многократно используемых
настраиваемых библиотечных символов без использования инструментов или
средств разработки ПО.
Рабочая станция разработчика должна работать под управлением любой из
операционных систем, перечисленных в разделе 1.1.
5а.8.1.
Графические объекты
Графика (аналогично прикладным объектам) должна основываться на
объектно-ориентированной технологии. Графические объекты должны иметь
возможность включать в себя другие графические объекты, а также отображать
атрибуты и свойства и манипулировать ими.
5а.8.2.
Графический редактор
5а.8.2.1. Графический редактор должен входить в состав среды разработки и
содержать набор основных инструментов черчения, достаточных для создания
простых и сложных графических объектов. При выборе значка на панели
инструментов черчения должен выбираться один из примитивов графической
формы. Пользователь в редакторе должен легко создавать простые графические
объекты с использованием этих примитивов. В числе примитивов должны быть
линии, прямоугольники, многоугольники, эллипсы, круги, открытые и замкнутые
кривые, двух- и трехточечные дуги и сегменты круга, фигуры с заливкой и текст.
5а.8.2.2. Любому из этих объектов должны назначаться различные атрибуты,
такие как цвет линии, цвет заливки, размер и ориентация. Объекты должны быть
статическими или динамическими. Текстовые объекты должны быть
масштабируемыми, в них должны использоваться шрифты True Type с
возможностью выделения полужирным шрифтом, курсивом или подчеркиванием.
Все объекты должны быть масштабируемыми и перемещаться в любом направлении
с шагом один пиксель или перетаскиваться мышью. Должен использоваться
стандартная палитра из 48 предварительно выбранных цветов. Пользователю
должны быть доступны действия создания, экспорта и импорта цветовой палитры.
Цветовая палитра должна создаваться как подмножество набора из 16,7 млн. цветов.
Система также должна предоставлять пользователю выбор прозрачных цветов для
всех графических объектов и фонов. Должны быть доступны варианты цветовой
заливки, такие как сплошная заливка, цветовой градиент из одного, двух и трех
цветов, узор, текстура и отсутствие заливки. Направление градиента должно быть
вертикальным, горизонтальным, радиальным, точечным и настраиваемым.
Дополнительные элементы управления градиентом должны контролировать форму
распределения цвета, максимум и минимум, ширину и высоту.
5а.8.3.
Редактор экранных профилей
5а.8.3.1. Редактор экранных профилей должен входить в состав среды
разработки и содержать набор основных профилей.
5а.8.3.2. Экранные профили определяют способы настройки экранов каждой
рабочей станции или устройства, которые будут настроены или использованы для
ЧМИ. Следует учесть, что рабочая станция может физически находиться в разных
местах, таких как диспетчерская, цех предприятия и зал управления, или
встраиваться в большой комплект оборудования. Она также может быть мобильной,
такой как планшетный компьютер или смартфон.
5а.8.3.3. При создании макетов экрана для проекта разработчики могут в
редакторе макетов брать за основу определения экрана требуемой ширины и
высоты.
5а.8.3.4. Каждой рабочей станции в системе будет присвоен один профиль
экрана, используемый по умолчанию во время разработки. Один из профилей можно
назначить профилем по умолчанию, чтобы уменьшить объем необходимых настроек
в больших системах. Клиент времени выполнения при запуске будет выбирать
нужный профиль экрана, учитывая это назначение. Макеты экрана и его
содержимое должны автоматически занять правильное положение на привязанных к
ним экранах.
5а.8.4.
Редактор макетов экрана
Редактор макетов должен входить в состав среды разработки и содержать
набор основных инструментов черчения для создания простых или сложных
графических панелей. Макет может содержать символы, приложения и другие
макеты. Панели имеют свойства, такие как заполнение, панорамирование и
масштабирование, выравнивание содержимого, непрозрачность, фон и т. д.
Назначение макета — сделать содержимое независимым от ограничений формфактора.
5а.8.5.
Редактор пользовательских приложений
5а.8.5.1. Редактор приложений ЧМИ должен поддерживать привязку макетов к
экранным профилям, создаваемым в редакторе макетов при разработке приложения
ЧМИ. Редактор должен по ссылкам на навигацию, модель, безопасность и
пространство имен выбирать содержимое для последующего отображения. Редактор
должен поддерживать редактирование макета и экранного профиля. Он должен
также поддерживать одновременную работу нескольких разработчиков над одним и
тем же приложением ЧМИ.
5а.8.5.2. Навигация должна предоставляться автоматически без необходимости
создания скриптов и/или использования функций отображения графики с помощью
приводимых ниже способов.
5а.8.5.3. Для навигации по содержимому система должна автоматически
выдавать содержимое одной папки или ресурса, чтобы пользователь мог прокрутить
список отображенных значков или выбрать вариант щелчком мыши.
5а.8.5.4. Для навигации по иерархии система должна автоматически
отображать эту иерархию и давать возможность перемещаться по ней вверх и вниз
для просмотра нужного содержимого, переходя от папки к папке или от одного
ресурса к другому.
5а.8.5.5. Для автозаполнения, основанного на метаданных графики, система
должна автоматически определять размещение графики в макете и выбирать
нужный экран. Это должно выполняться без написания скриптов.
5а.8.6.
Манипуляции с графикой
5а.8.6.1.
Графический редактор должен поддерживать стандартные
функции работы с объектами, такие как вырезание, копирование, вставка и
удаление. Для упрощения надлежащего расположения объектов должны
использоваться инструменты для выравнивания. Должны быть доступны команды
выравнивания объектов по левому, правому, верхнему или нижнему краю либо по
центру. В состав команд работы с объектами следует также включить распределение
по вертикали и по горизонтали, перемещение на задний и передний план, поворот,
группирование и разгруппирование.
5а.8.6.2.
Графический редактор должен давать возможность изменения
члена группы без разгруппирования.
5а.8.7.
Панорамирование и масштабирование в редакторе
Графический редактор должен давать возможность панорамирования и
масштабирования среды редактирования от 75% до 500%.
5а.8.8.
Графическая библиотека, поставляемая производителем
Графический редактор должен иметь библиотеку с большим выбором
сложных объектов и символов процесса, таких как счетчики, кнопки, движки,
датчики, насосы, двигатели, резервуары, клапаны, графики трендов, аварийные
сигналы, лицевые панели контроллеров и растровые изображения.
5а.8.9.
Редактор произвольных библиотечных символов
Графический редактор должен позволять пользователю формировать
собственную библиотеку многократно используемых настраиваемых сложных
объектов и символов процесса.
5а.8.10.
Масштабирование графики
Все сложные графические объекты должны быть масштабируемыми до
любого размера и, возможно, иметь связь с анимацией для отображения
динамической реакции на данные, получаемые в реальном времени, или на действия
пользователя.
5а.8.11.
Эффекты анимации графики
Графический редактор должен поддерживать настройку, как минимум,
следующего перечня анимации:
5а.8.11.1. Анимация изменением цвета - цвет графического символа может
изменяться динамически в зависимости от значений логических, аналоговых или
строковых параметров. Не должно быть жестко ограничено количество изменений
цвета, доступных для одного символа. Процент заполнения объектов вверх, вниз,
влево или вправо в зависимости от имени тега или иерархического имени.
5а.8.11.2. Анимация миганием - графический объект может мигать в
зависимости от значения любого логического выражения, аварийного сигнала,
события или определенной группы аварийных сигналов. Мигание должно по
выбору работать в медленном, среднем или быстром темпе.
5а.8.11.3. Анимация аварийного сигнала изменением рамки - пользователь
должен иметь возможность настраивать рамку вокруг выбранного графического
элемента, которая может отображать состояние аварийного сигнала для этого
элемента. При активизации аварийного сигнала эта рамка должна мигать, а ее цвет
должен соответствовать уровню серьезности аварийного сигнала. Мигание рамки
должно прекращаться при возврате в нормальное состояние, после устранения
аварийного состояния рамка должна гаснуть. При включении анимации должен
также отображаться дополнительный значок, связанный с соответствующей
серьезностью аварийного сигнала.
5а.8.12.
Видимость и прозрачность
Каждый объект должен иметь атрибуты видимости и прозрачности,
позволяющие менять видимость и прозрачность этого объекта в зависимости от
состояния аналоговой или дискретной точки, аварийного сигнала или уровня
безопасности оператора.
5а.8.13.
Размер, положение и ориентация
Система должна поддерживать анимацию объектов путем изменения
размеров, перемещения и/или поворота в зависимости от изменения тега или
объекта, заданного иерархическим именем. Должна поддерживаться анимация
объектов в зависимости от любых пользовательских критериев, составленных из
имен тегов в системе. Сюда относится использование выражений, содержащих
математические функции и состояние аналоговых и дискретных параметров в
системе.
5а.8.14.
Работа со слоями
Графический редактор должен поддерживать размещение объектов в разных
слоях, позволяющее активировать выбранные объекты в зависимости от условий в
процессе. Графический редактор должен управлять порядком наложения друг на
друга графических элементов по слоям (Z-порядок) и визуально отображать этот
порядок.
5а.8.15.
Сетка
Инструменты разработки графики должны позволять размещать объекты,
используя функцию привязки к сетке с настраиваемыми интервалами между
линиями этой сетки.
5а.8.16.
Именование графических элементов
Всем графическим элементам должны присваиваться имена. Пользователь
должен иметь возможность изменить имя, присвоенное системой. Анимационная
логика должна иметь возможность ссылаться на это имя.
5а.8.17.
Отмена и повторение действий в редакторе
Средства
разработки
графики
должны
поддерживать
функцию
"отменить/повторить" с настраиваемым количеством уровней и отображением
команд.
5а.8.18.
Стили графических элементов
Среда разработки должна поддерживать централизованное конфигурирование
стандартного набора стилей графических элементов, чтобы поддерживать
согласованность графического дизайна по приложению в целом, включая такие
аспекты, как шрифт, цвет и размер текста; цвет, «вес» и толщина линии; шаблоны и
цвета заливки и контура, а также условия мигания.
5а.8.19.
Стили численных форматов
Среда разработки должна обеспечивать централизованное конфигурирование
стандартного набора стилей численного формата элементов, чтобы поддерживать
согласованность отображения чисел по приложению в целом.
5а.8.20.
Региональные числовые форматы
Числовые данные могут вводиться и отображаться на графическом экране в
национальном формате страны, выбранной в качестве локальной настройки
компьютера, на котором работает приложение ЧМИ. Во время выполнения числа
можно вводить или отображать с символами разделителей тысяч и десятичной
точки, соответствующими численному формату выбранной страны. Клавиатура в
режиме выполнения должна содержать клавиши запятой, точки и тонкого пробела
для ввода чисел в соответствии с форматом страны, выбранной в качестве
локальной настройки компьютера, на котором работает приложение WindowViewer.
5а.8.21.
Интеллектуальная графика
Система должна предоставить библиотеку «самонастраивающихся» объектов,
которые изменяют свойства в зависимости от значений, вводимых в диалоговом
окне во время разработки. Например, представим стандартный объект загрузчика
уставки, который имеет градуированную шкалу с диапазоном по умолчанию от 0 до
100,0. По вводимым в диалоговом окне значениям должны изменяться диапазон
загрузчика уставок, количество основных и дополнительных делений шкалы и
шрифт текста для надписей.
После ввода данных изображение объекта должно обновиться с новым
количеством делений, новым интервалом, новыми надписями и новым шрифтом.
5а.8.22.
Импорт файлов с изображениями
Графический редактор должен также позволять пользователю импортировать
чертежи и изображения в форматах BMP, JPEG, PCX и TGA.
5а.8.23.
Копирование и вставка
5а.8.23.1. Среда разработки графики должна поддерживать копирование
одного или нескольких анимированных графических объектов и символов всего
двумя нажатиями клавиш, а также немедленную замену тегов в копии объекта без
выхода из графического редактора.
5а.8.23.2. Среда разработки графики должна поддерживать копирование
одного или нескольких анимированных графических объектов и символов между
окнами или экранами с сохранением всех характеристик анимации, ссылок и
атрибутов. Эта функция устраняет двойную работу. Кроме того, необходима
возможность импорта окон из другого приложения аналогичным образом.
5а.8.23.3. Графический редактор должен поддерживать копирование и
вставку настроек анимации из одного графического элемента в другой.
5а.8.23.4. Пользователь должен иметь возможность добавлять имена тегов
или иерархические имена при разработке экрана без выхода из графического
редактора.
5а.8.24.
Справочная подсистема
Разработка экрана должна поддерживаться контекстной справкой.
Пользователи должны иметь возможность получать немедленную справку по
всем объектам конфигурации нажатием одной функциональной клавиши.
5а.8.25.
Разработка графики
Пользователю должно быть доступно определение графических экранов,
когда система контролирует процесс.
5а.8.26.
Развертывание графического приложения
Пользователь должен иметь возможность распространять приложение
визуализации и/или его изменения по одному или нескольким узлам по
собственному выбору.
5а.8.27.
Графические апплеты
5а.8.27.1. Разработчики приложений должны иметь возможность создавать
независимые автономные графические мини-программы (апплеты) со встроенными
скриптами, собственным пространством имен и пользовательскими атрибутами.
5а.8.27.2. Для написания скриптов должен использоваться язык основных
логических скриптов ЧМИ. В языке сценариев должна быть возможность
использования системных вызовов из библиотеки .NET. В состав скриптов
графического апплета должны входить скрипты обработки условий On Show, On
Hide, While Showing (периодический) и пользовательские скрипты обработки
условий On True, On False, While True (периодический), While False и событий
изменения данных. Разработчик приложений должен иметь возможность определять
локальные и внешние именованные атрибуты следующих типов данных: Integer,
String, Boolean, Float, Double, Time и Elapsed Time.
5а.8.28.
Диспетчер графических апплетов
5а.8.28.1. С помощью диспетчера графических апплетов разработчики
приложений должны иметь возможность создавать группы графических символов,
которые затем образуют единый именованный символ, отображаемый в виде
именованного шаблона.
5а.8.28.2. Не должно быть никаких практических ограничений на
количество графических символов, из которых создается один составной символ,
вплоть до целого окна символов, включая само это окно. Эти шаблоны должны
привязываться либо к объектам базы данных объектов, либо к локальным тегам
ЧМИ, либо к тегам ЧМИ через удаленные ссылки. Изменения графического
шаблона распространяются на все экземпляры объектов, созданные по этому
шаблону. Библиотеки повторно используемых графических апплетов можно
создавать и организовывать, а также управлять ими с помощью диспетчера
символов.
5а.8.29.
Организация графики
Диспетчер графических апплетов должен обеспечивать создание и удаление
иерархического дерева папок. Должно поддерживаться перемещение графических
символов между папками перетаскиванием мышью.
5а.8.30.
Импорт и экспорт графики
Диспетчер графических апплетов должен обеспечивать импорт и экспорт
символов апплета.
5а.8.31.
Управление графикой
5а.8.31.1. Диспетчер
графических
апплетов
должен
обеспечивать
возможность переименования графических символов. Символы могут содержать
вложенные друг в друга символы. Не должно быть жесткого ограничения
количества уровней вложенности. При изменении родительского символа должны
обновляться все экземпляры вложенного символа.
5а.8.31.2. Экземпляр символа графического апплета должен создаваться в
окне ЧМИ путем выбора этого символа в диспетчере символов и нажатия кнопки
ОК. При выборе символа должно открываться диалоговое окно, позволяющее
просматривать и выбирать новые теги или атрибуты из базы данных объектов или
тегов и разрешать создание совершенно новых именованных объектов в базе
данных. Размер созданного символа должен изменяться простым перетаскиванием
мышью маркера масштабирования до желаемого размера.
5а.8.31.3. Диспетчер
графических
апплетов
должен
обеспечивать
возможность редактирования символа. По окончании процесса редактирования
должно отображаться диалоговое окно, позволяющее подтвердить изменения,
отменить их или вернуться к редактированию. Во время выполнения атрибуты
тегов/объектов символа графического апплета должны изменяться или передаваться
альтернативному набору атрибутов тегов/объектов одной командой скрипта.
5а.8.32.
Независимость экранов от разрешения монитора
Среда времени выполнения должна поддерживать отображение графических
элементов времени выполнения, созданных в графическом редакторе, при заданных
разрешениях и настройках монитора после однократной настройки только для
конкретного разрешения. Допускается использовать несколько форм-факторов
(включая телефоны и планшеты), разрешений экрана, соотношений сторон и
комплекты из нескольких мониторов, при этом содержимое должно автоматически
менять размер в соответствии с целевым монитором.
Система должна поддерживать однократное конфигурирование
проектирование и повторное использовать в любом форм-факторе.
5а.8.33.
или
Поддержка мониторов с сенсорными экранами
Графика времени выполнения должна поддерживать жесты для одного и
нескольких пальцев, такие как панорамирование, масштабирование, прокрутка,
закрытие и двойное касание. Устройства с сенсорными экранами должны
распознаваться автоматически. Сенсорные жесты во время работы с несколькими
мониторами должны быть независимыми, чтобы действия, выполняемые на одном
мониторе, не влияли на изменения, внесенные на другом мониторе.
5а.8.34.
Приложение в режиме выполнения
В состав приложения ЧМИ должна входить встроенная навигация для
создания стартового приложения со встроенными средствами защиты, публикацией
в нескольких версиях и встроенными лицевыми панелями, обеспечивающая
ускоренную сборку приложений.
5а.8.35.
Производительность приложения в режиме выполнения
Минимальная производительность приложений времени выполнения во время
рендеринга должна обеспечивать расчет 50 000 элементов без кеширования, 1-2
секунд экранного времени и использовать многоядерную обработку.
5а.8.36.
Архивная статистика
В среде времени выполнения должны отображаться архивные значения
связанного с ними свойства, собранные за заданный период работы.
5а.8.37.
Аварийный сигнал как экранный объект
5а.8.37.1. Аварийные сигналы должны отображаться через объединенный
пользовательский сигнальный объект, который можно поместить отдельно или в
окне вместе с другими объектами. Размер этого объекта должен настраиваться. По
двойному щелчку мышью должно открываться диалоговое окно настройки. Для
сигнальных объектов должны отображаться настройки по умолчанию с
возможностью изменения вида любого параметра, для отображения во время
выполнения.
5а.8.37.2. Диалоговое окно настройки сигнального объекта должно
содержать параметры с флажками, позволяющими выбрать и включить или
отключить варианты отображения аварийных сигналов во время выполнения.
Аварийные сигналы должны иметь цветовую кодировку, соответствующую
состояниям и приоритетам сигнала, таким как подтвержденный аварийный сигнал,
неподтвержденный аварийный сигнал и аварийный сигнал от устройства,
вернувшегося в нормальное состояние, но пока не подтвержденный. Пользователь
должен иметь возможность выбора из 256 различных цветов для отображения
каждого состояния аварийного сигнала. Экранный сигнальный объект должен также
поддерживать индикатор событий с цветом, используемым для событий и
выбираемым из тех же 256 различных цветов. Отображаться должны либо
аварийные сигналы реального времени, либо архивные аварийные сигналы. Один и
тот же объект должен быть связан либо с текущим процессом, либо с базой данных
архивных аварийных сигналов.
5а.8.38.
Приложение картографии/ГИС
В зависимости от настройки картографического приложения в ЧМИ должны
отображаться данные ГИС или карты с поддержкой OpenStreetMap, WMS, ArcGIS и
с использованием слоев. В данное приложение можно импортировать параметры
управления картой и экспортировать их из приложения.
5а.8.39.
Поддержка элементов управления ActiveX, .Net и WPC
5а.8.39.1. ПО ЧМИ SCADA должно обеспечивать расширяемость за счет
встроенной поддержки технологии OLE Controls (OCX) или .Net Control. ПО ЧМИ
SCADA должно служить контейнером для элементов управления ActiveX или
пользовательских элементов управления .Net и поддерживать методы, свойства и
события этих объектов.
5а.8.39.2. Поддержка
технологии
ActiveX
должна
обеспечивать
разработчику приложений прямой доступ к сотням объектов OCX, разработанных
десятками независимых разработчиков ПО. Для использования в прикладной
системе
объекты
OCX
должны
регистрироваться
автоматически.
Зарегистрированные объекты OCX должны отображаться в диалоговом окне
добавления в приложение или удаления из приложения. Объекты OCX,
добавленные в приложение, должны отображаться в диалоговом окне для быстрого
добавления в новые и/или существующие приложения. В режиме разработки
пользователь сосредоточен на выборе объекта OCX для размещения, сопоставлении
свойств OCX, событий и методов с именами тегов и написании логики,
управляющей поведением объекта OCX через его свойства и методы.
5а.8.40.
Поддержка элементов управления .NET
Кроме поддержки технологии управления ActiveX, ПО SCADA должно
обеспечивать расширяемость за счет встроенной поддержки элементов управления
.NET. Система должна автоматически распространять сборки и зависимости .NET
на клиентские узлы в процессе публикации/развертывания.
5а.8.41.
Управление приложением ЧМИ
Среда разработки системы SCADA должна управлять приложениями
визуализации и распространять выбранные приложения ЧМИ простым
перетаскиванием мышью. Изменения, внесенные в приложение визуализации,
должны распространяться на все экземпляры объектов всей системы SCADA. Для
упрощения управления клиентскими приложениями в систему SCADA должен быть
включен диспетчер приложений с браузером, подобным Проводнику Windows.
Диспетчер приложений должен давать возможность динамического изменения
разрешения окон приложения. Это позволит разрабатывать графические экраны на
рабочих станциях с разными разрешениями мониторов и быстро приводить их к
требуемому разрешению для полной совместимости по внешнему виду.
5а.8.42.
Управление приложениями в распределенной сети
ПО SCADA должно поддерживать стандартные функции, облегчающие
настройку, эксплуатацию, устранение неисправностей и обслуживание приложения,
предоставляя средства для простого распространения приложения в сетевых средах.
Управляющее ПО должно позволять разрабатывать и поддерживать в сети одно
основное приложение. Среда разработки должна обеспечивать автоматическое
распространение основного приложения на все узлы сети управления SCADA, а
также распространение изменений главного приложения на все его экземпляры в
системе.
5а.8.43.
Уведомление клиента об изменениях приложения
5а.8.43.1. Когда на клиентском узле развернуто приложение ЧМИ, клиент
должен сохранить копию приложения на своем локальном жестком диске и
зарегистрироваться как пользователь этого приложения.
5а.8.43.2. При обнаружении изменений в шаблоне приложения каждый узел
зарегистрированного пользователя должен получить уведомление об этом
изменении. Среда проектирования должна позволять пользователю выбрать способ
уведомления клиентского узла об изменении приложения. Клиентский узел должен
либо автоматически загружать новые приложения, либо спрашивать пользователя о
загрузке изменений или отказе от нее, либо автоматически игнорировать такие
изменения. При неисправности сети, связывающей клиента с репозиторием, клиент
должен продолжать использование последней полученной версии приложения.
После восстановления сети и изменения приложения на сервере система должна
передать новое приложение клиенту.
5а.8.44.
Файлы журналов приложения
5а.8.44.1. Файлы журналов приложения, создаваемые для диагностики и
устранения неисправностей, должны храниться на локальном жестком диске в
течение заданного пользователем количества суток. На каждом узле сети должен
поддерживаться независимый файл журнала для приложений, являющихся
уникальными для каждого узла. Ежедневно должен создаваться и архивироваться
новый файл журнала в соответствии с указанным пользователем временем и
местоположением.
5а.8.44.2. Для просмотра журналов событий должна быть предоставлена
оснастка просмотра системной консоли Microsoft. Оснастка просмотра должна
поддерживать цветовую маркировку разных потоков, процессов или программ.
Оснастка просмотра файлов журналов должна поддерживать просмотр файлов
журнала локального и удаленных узлов.
5а.9. СРЕДА ВРЕМЕНИ ВЫПОЛНЕНИЯ
5а.9.1.
Управление аварийными сигналами
5а.9.1.1.
Аварийные сигналы должна обнаруживать и обрабатывать служба
Alarm Manager (диспетчер аварийных сигналов). Диспетчер аварийных сигналов
должен обеспечивать одновременное отображение не менее 200 (двухсот)
аварийных экранов на клиентских мониторах. При возникновении лавины
аварийных сигналов (порядка сотен или тысяч аварийных сигналов в секунду)
диспетчер аварийных сигналов должен передавать, а клиент должен отображать до
1000 (тысячи) новых аварийных сигналов в течение не более 10 (десяти) секунд
обнаружения этих сигналов.
5а.9.1.2.
Система должна иметь возможность отложенной обработки
аварийных сигналов, чтобы уполномоченные операторы могли временно удалять
выбранные сигналы из списка активных и подавлять их обработку в течение
заданного периода времени. Система должна запрашивать операторов ввести
причину отложенной обработки.
5а.9.1.3.
Система должна обеспечивать возможность выборочного
подавления обработки аварийных сигналов в зависимости от выбранных состояний
установки, чтобы избежать отображения мешающих аварийных сигналов во время
определенных состояний.
5а.9.1.4.
Система должна предоставлять общее количество агрегированных
аварийных сигналов каждой категории серьезности (критическая, высокая, средняя
и низкая) на каждом уровне пространства.
5а.9.1.5.
Система должна иметь возможность выдавать аварийные сигналы
о системных ресурсах (использование ЦП, памяти и т. д.).
5а.9.1.6.
Должна быть возможность регистрации аварийных сигналов в базе
данных. Записываемые аварийные события должны включать в себя возникновение
аварийного сигнала, возврат из аварийного состояния к нормальному и
подтверждение аварийного сигнала. В числе регистрируемых элементов, кроме
события тревоги, должны быть дата и время аварийного события, имя группы
аварийных сигналов, имя и тип тега аварийного сигнала (real/integer/Boolean), тип
аварийного сигнала (LoLo, Lo, Hi, HiHi, скорость изменения, отклонение и т. д.),
имя оператора, узел оператора, подтвердившего аварийный сигнал и приоритет
этого сигнала.
5а.9.1.7.
Система аварийной сигнализации должна обрабатывать 2000
сообщений в секунду с возможными всплесками до 10 000 сигналов в секунду в
течение 10 секунд. Для резервного копирования или восстановления записей
аварийных сигналов не должно требоваться знание языка SQL.
5а.9.1.8.
Аварийные сигналы должны печататься на локальном или сетевом
принтере. С каждого узла должны распечатываться аварийные сигналы всех
разновидностей, а именно только неподтвержденные или подтвержденные сигналы,
сигналы из определенных групп, сигналы в определенном диапазоне приоритетов
или сигналы от нескольких источников.
5а.9.1.9.
Ни одно из перечисленных решений не должно быть реализовано с
использованием скриптов.
5а.9.2.
Архитектура связи
5а.9.2.1.
Среда выполнения должна создаваться на основе системы с
распределенной одноранговой архитектурой. Должна быть возможность
масштабирования архитектуры от одного автономного узла до сети из более чем 200
узлов. Архитектура должна содержать модель из множества компьютеров, которая
рассматривается как единое распределенное пространство имен в среде выполнения
и не требует репликации данных с одного узла на другой.
5а.9.2.2.
Прикладные объекты и их атрибуты должны быть доступны по
иерархическим именам объектов или по глобально уникальным именам тегов.
5а.9.3.
Серверы ввода-вывода для интеграции устройств
В систему SCADA должно входить множество серверов интеграции
устройств, предназначенных для организации интерфейсов ввода-вывода с
периферийными устройствами, такими как удаленные терминалы (RTU),
контроллеры (ПЛК) и распределенные системы управления (DCS).
5а.9.4.
Серверы интеграции устройств общего назначения
Серверы интеграции устройств общего назначения должны быть доступны
для всех основных ПЛК производства компаний Allen Bradley, GE, Modicon или
Siemens, а также для различных RTU и систем DCS. Серверы связи с ПЛК должны
поддерживать интерфейсы через прямое последовательное подключение и
локальные сети управления, такие как Data Highway Plus, Modbus Plus или TCP/IP
Ethernet. Должна обеспечиваться поддержка нескольких сотен различных устройств,
использующих протоколы DDE, SuiteLink, OPC (DA) и OPC UA (DA).
Инструментарий сервера доступа к данным должен быть доступен для сторонних
разработчиков, создающих индивидуальные конфигурации серверов ввода-вывода.
5а.9.5.
Связи между объектами
Прикладные объекты должны иметь возможность подключения к любому
серверу ввода-вывода по протоколам DDE/NetDDE, SuiteLink или OPC. Вход и
выход должны определяться как любая входная и/или выходная переменная,
включая отдельные точки сбора данных и любой переменный параметр, созданный
для обмена данными между объектами в системе. Как минимум, должны
поддерживаться следующие типы данных: Boolean, Float, Double, String,
Internationalized String, Integer (8, 16 и 32 бит со знаком и без знака), Time и Elapsed
time (логический, с плавающей запятой, двойной точности, строковый,
многоязыковый строковый, целый, текущее и затраченное время).
5а.9.6.
Аварийное переключение системы SCADA
Системное ПО SCADA должно обеспечивать высокую готовность всех
функций в обычной среде управления SCADA. В системе SCADA требуется
резервирование прикладных объектов и их родительских объектов, связей с ПЛК и
RTU и системы передачи аварийных сигналов. Требования к высокой готовности
также применимы к журналам архивных данных процесса. В избыточной
конфигурации с аварийным переключением должны быть главный и резервный
системные объекты, которые управляют дочерними главным и резервным
объектами. Система должна запускать активные объекты и синхронизировать
активные объекты с резервными. В случае обнаружения сбоев в работе активного
объекта или нарушения связи с активным объектом запускаются резервные объекты
и начинают обмен данными в системе.
5а.9.10.
Определенные события неисправностей
Система SCADA должна обнаруживать следующие события в самой системе и
в сетевых объектах:
сбой связи с единичным RTU/ПЛК;
сбой связи с несколькими RTU/ПЛК;
сбой связи с коммуникационным сервером; сбой прикладной логики;
сбой связи с архиватором данных;
отклонение скорости сбора данных в архиваторе;
нехватка дискового пространства для любого архиватора данных в сети.
Система SCADA должна обнаруживать любые или все возможные
неисправности и обеспечивать восстановление данных клиентов без вмешательства
оператора.
5а.9.11.
Резервирование приложения
Система должна обеспечивать запуск резервных прикладных объектов,
которые становятся активными при сбое в работе активных объектов или при
отсутствии связи с активными объектами. Отдельная настройка резервных объектов
не требуется. Объекты должны быть привязаны к главному обработчику диспетчера
объектов, который, в свою очередь, гарантирует создание резервных объектов и их
развертывание в режиме ожидания. При нормальной работе главный обработчик
вместе с содержащимися в нем объектами должен быть активным. Резервный
обработчик и содержащиеся в нем объекты должны оставаться в режиме ожидания и
синхронизироваться со своими активными партнерами с периодичностью,
настраиваемой пользователем. Настройка резервирования приложений должна
сводиться к установке флажка и перетаскиванию мышью. Резервирование
приложений должно представлять собой встроенную готовую функцию. Написание
специальных скриптов для реализации этой базовой функции неприемлемо.
5а.9.12.
Резервирование аварийной сигнализации
Система должна обеспечивать обработку аварийных сигналов от резервных
прикладных объектов, которые становятся активными при сбое в работе активных
объектов или при отсутствии связи с активными объектами. Отдельная настройка
аварийной сигнализации в резервных объектах не требуется. Аналогично
резервированию приложений, объекты должны привязываться к объекту главного
диспетчера, который, в свою очередь, гарантирует создание дочерних резервных
объектов и их развертывание в режиме ожидания на случай возникновения аварий.
5а.9.13.
Резервирование коммуникаций
Система SCADA должна следить за состоянием связи с коммуникационными
серверами и связи этих серверов с каждым ПЛК и RTU. В случае сбоя с вязи
система SCADA должна передавать коммуникационные функции назначенному
резервному серверу связи.
5а.9.14.
Безопасность режима выполнения
5а.9.14.1. Среда выполнения должна конфигурироваться таким образом,
чтобы операторам с разными возможностями, ролями и обязанностями по мере
необходимости либо разрешался, либо запрещался доступ к функциям системы.
5а.9.14.2. Перечисленные выше ограничения безопасности должны
поддерживаться с помощью встроенных возможностей ПО SCADA, а не с помощью
специально разрабатываемого приложения.
5а.9.15.
Изменения данных времени выполнения
5а.9.15.1. Изменения параметров объекта во время выполнения должно
разрешаться только при условии авторизации. Для авторизации во время
выполнения должны автоматически проверяться разрешения, настроенные в среде
разработки, включая идентификацию и проверку прав доступа инициатора запроса
на изменение текущих параметров.
5а.9.15.2.
журнал.
Отвергнутые запросы на авторизацию должны записываться в
5а.9.15.3. Архитектура
системы
времени
выполнения
должна
соответствовать модели безопасности атрибута объекта, определенной в среде
конфигурирования.
5а.9.15.4. При этом не должны использоваться специально разработанные
решения (скрипты).
5а.9.16.
Журнал аудита времени выполнения
5а.9.16.1. Должна быть возможность настройки системы таким образом,
чтобы любые изменения переменной во время выполнения фиксировались в
журнале аудита с указанием идентификатора и полного имени пользователя,
предыдущего и нового значений этой переменной.
5а.9.16.2. Атрибуты, предназначенные для проверки, должны содержать
запись журнала аудита с идентификатором и полным именем пользователя, имени
учетной записи и полного имени проверяющего, предыдущего и нового значения
атрибута.
5а.9.17.
Безопасность оператора
5а.9.17.1. На рабочей станции оператора должна использоваться модель
безопасности, определенная в базе данных конфигурации.
5а.9.17.2. ПО должно использовать защиту на уровне данных, в которой
возможность изменения уставки или другого значения определена в базе данных
конфигурации. Любые изменения модели безопасности на уровне данных должны
отображаться на всех операторских станциях без каких-либо изменений самих этих
станций.
5а.9.17.3. В системе безопасности необходимо предусмотреть возможность
запрещения доступа ко всем элементам управления операционной системы
(например, в Microsoft Windows: меню "Файл", закрытие и минимизация окна и т. д.;
командам клавиатуры Ctr-ESC и Alt-Tab и т. д.; ограничения внешнего доступа к
системе через комбинацию клавиш Ctrl-Alt-Del).
5а.9.18.
Регистрация действий оператора
5а.9.18.1. Все действия оператора должны регистрироваться в журнале
событий. Журнал событий должен отслеживать каждый новый вход оператора в
систему, выход из системы, изменение уставки или управление устройством.
5а.9.18.2. В каждой записи журнала событий должна содержаться дата,
время, оператор, входивший в систему, и тип выполненного действия (изменение
уставки, изменение состояния и т. д.).
5а.9.19.
Регистрация событий изменения значения
5а.9.19.1. Необходимо предусмотреть возможность настройки любого
имеющегося тега типа Integer, Real, Discrete или String как источника,
порождающего событие. Точка должна регистрироваться как событие при каждом
изменении ее значения.
5а.9.19.2. События должны регистрироваться в базе данных Microsoft SQL
Server. Элементы, регистрируемые вместе с самим событием, должны содержать
дату, время и приоритет события.
5а.10. АРХИВАТОР ДАННЫХ (HISTORIAN)
Системное ПО SCADA должно иметь в своем составе архиватор реляционной
базы данных реального времени, предназначенный для долговременного хранения
данных процесса. Архиватор данных должен обеспечивать хранение текущих и
архивных данных для каждого аналогового, дискретного или строкового тега.
Архиватор данных должен также хранить сводные данные, данные событий,
аварийных сигналов и конфигурации. СУБД для архиватора должна создаваться на
основе широко распространённых, кроссплатформенных баз данных и
поддерживать архитектуру «клиент-сервер». Для установки и эксплуатации
архиватора пользователь не должен изучать или дорабатывать установленное ПО
Базы данных.
База данных архиватора должна получать и хранить данные процесса в
полном разрешении, с возможностью указания мертвой зоны по времени, мертвой
зоны по значению или зоны нечувствительности (алгоритм «вращающейся двери»).
В базе данных архиватора должны быть нормализованные таблицы расширений для
данных реального времени и набор клиентских инструментов для анализа данных и
отчетности, упомянутый в предыдущих разделах.
Архиватор данных должен работать также в автономном режиме без
подключения к системе SCADA или настройки со стороны этой системы. Несмотря
на наличие физических ограничивающих факторов, таких как объем дискового
пространства, не должно накладываться никаких программных ограничений на
количество данных, которые могут храниться в режиме онлайн. Кроме того, не
должно быть намеренного снижения скорости доступа к более «старым» данным. Не
должно быть заметных различий в скорости поиска данных в зависимости от
«возраста» этих данных. Например, скорость извлечения двухчасового объема
данных, сохраненных два года назад, должна быть такой же, как для такого же
объема данных, сохраненных в прошлые сутки. Система должна сохранять историю
аварийных сигналов и событий в том же архиваторе, что и данные процесса.
5а.10.4.
Сбор и анализ данных на удаленных станциях
5а.10.4.1. Архиватор должен давать возможность его настройки на
удаленном узле для локального сбора данных и передачи этих данных второму
архиватору в многоуровневой сетевой архитектуре. Должны быть доступны
варианты копирования в многоуровневый архиватор всех данных, выбранного
подмножества данных или итоговых данных.
5а.10.4.2. Данные должны храниться локально на удаленном узле и
анализироваться с помощью клиентских инструментов поставщиков.
5а.10.4.3. Должна предоставляться возможность агрегирования данных и
передачи их архиватору второго уровня для дальнейшего анализа.
5а.10.4.4. Несколько удаленных архиваторов должны иметь возможность
отправлять консолидированную или необработанную информацию одному
архиватору второго уровня или отправлять одну и ту же информацию нескольким
системам второго уровня.
5а.10.4.5. Архиватор должен быть устойчивым, вести себя предсказуемо и
последовательно в сетевой среде в случае замедления и периодического нарушения
связи в сети.
5а.10.4.6. Архиватор должен иметь возможность принимать данные,
отправленные из отключенного удаленного места после восстановления соединения.
Данные должны храниться в удаленной системе сбора и после восстановления
сетевого подключения отправляться архиватору без вмешательства оператора.
5а.10.4.7. Должна
быть
реализована
гарантирующая отсутствие потерь информации
подключения.
5а.10.5.
архитектура
архиватора,
в случае сбоя сетевого
Сжатие данных
База данных должна поддерживать скоростной сбор данных и их эффективное
сжатие. При сжатии данных для архиватора не должны использоваться алгоритмы,
препятствующие записи данных тега со скоростью их извлечения. Сохраненные
записи данных должны обеспечивать восстановление данных процесса без потерь.
Ниже приведены методы хранения данных, предназначенные для использования с
различными типами данных.
5а.10.6.
Требования к хранению дискретных данных
Для каждого сохраняемого дискретного значения, записанного в архиватор
данных, должно использоваться около 8 байт памяти.
5а.10.7.
Требования к хранению аналоговых данных
Для записи сохраняемого разностного аналогового значения в архиватор
данных должно выделяться около 10 байт памяти.
5а.10.8.
Требования к хранению строковых данных
Должна быть возможность хранения строковых (или текстовых) данных.
Каждая строка может состоять максимум из 512 символов.
5а.10.9.
Качество данных
Вместе с каждым значением, хранящимся в архиве, должен также храниться
индикатор качества данных.
5а.10.10.
Стандартные таблицы базы данных
5а.10.10.1. Создание таблиц базы данных должно выполняться автоматически
без обращения к разработчикам баз данных. Определения данных, включая создание
объектов базы данных, таких как таблицы, индексы, ограничения, значения по
умолчанию, правила, хранимые процедуры, триггеры и представления, должны
соответствовать стандартной, опубликованной и легко доступной схеме базы
данных.
5а.10.10.2. Эта стандартная схема базы данных должна описывать взаимные
связи между таблицами, столбцами таблиц, ключами и индексами и поддерживать
сторонние разработки клиентских приложений. Объем базы данных на физическом
носителе должен определяться динамически при установке базы данных в
зависимости от количества тегов, которое должен хранить архиватор данных.
5а.10.11.
Система формирования сводных данных
5а.10.11.1. Архиватор
данных
должен
вычислять
настраиваемые
пользователем сводные значения для аналоговых, дискретных и строковых данных
и автоматизировать сбор совокупной хронологической информации по заданному
событию. Должны использоваться предварительно определенные расписания
расчета итогов через одну, пять, пятнадцать минут, каждый час, каждую смену и
ежесуточно. Пользователь может определять произвольные расписания.
5а.10.11.2. Аналоговая сводка должна содержать начальное значение с
временной меткой, максимальное значение с временной меткой максимума,
минимальное значение с временной меткой минимума, среднее значение,
стандартное отклонение, интегральное значение и процент хороших значений в
расчете этой сводки.
5а.10.11.3. Сводка по состояниям дискретных, целочисленных и строковых
значений должна содержать общее число переходов в какое-либо состояние,
суммарное, максимальное, минимальное и среднее время нахождения в каждом
состоянии. Для целочисленных и строковых значений должно поддерживаться не
менее десяти состояний.
5а.10.11.4. Кроме доступа к сводным данным с помощью SQL-запросов,
система должна давать возможность легко получать сводные данные для
визуализации в ЧМИ.
5а.10.12.
Единая настройка архивирования данных
5а.10.12.1. Хронологическое архивирование данных из объектов SCADA
должно настраиваться один раз при конфигурировании этих объектов с
использованием соответствующего редактора в системе SCADA.
5а.10.12.2. Архиватор данных должен автоматически получать эти
настроенные параметры архивирования при развертывании сконфигурированных
прикладных объектов.
5а.10.12.3. Конфигурация должна обеспечивать работу с двумя архиваторами,
чтобы при необходимости передавать одни и те же данные обоим архиваторам.
5а.10.13.
Хранение и пересылка архивных данных
Если архиватор отключен или недоступен, то обработчики, обслуживающие
активные объекты, должны сохранять архивируемые данные локально и при
восстановлении доступа к серверу архивов пересылать буферизованные данные в
архиватор вместе с метками времени и информацией о качестве.
5а.10.14.
Конфигурирование хронологической точки данных
Архиватор должен включать в себя редактор баз данных для изменения
параметров любого тега, в том числе без обращения к редактору базы данных
SCADA. Должна быть предусмотрена возможность настройки скорости сохранения
данных для каждой точки в зависимости от определенной пользователем
периодичности (циклическое сохранение) или в случае изменения (разностное
сохранение). Периодичность циклического сохранения должна настраиваться для
каждой точки в пределах от 1 секунды до нескольких часов. База данных архиватора
должна поддерживать разрешение в 1 миллисекунду для тегов, настроенных на
разностное сохранение.
5а.10.15.
Сбор и извлечение архивных данных
5а.10.15.1. Архиватор должен получать данные автоматическими и ручными
способами. Автоматический сбор данных должен выполняться с помощью
стандартных для отрасли средств обмена данными. В дополнение к фирменным
средствам передачи, должны поддерживаться сбор данных через динамический
обмен данными (DDE) и OLE для управления процессами (OPC). Данные должны
извлекаться с использованием структурированного языка запросов (SQL). Должна
обеспечиваться возможность записи данных с одним разрешением, а их извлечения
— с другим разрешением. Должны существовать способы циклического запроса и
получения данных с миллисекундным разрешением, независимо от режима
хранения.
5а.10.15.2. Должна быть доступна возможность запроса и извлечения
разностных данных с выбранными пользователем критериями мертвой зоны и
миллисекундным разрешением, независимо от режима хранения. Должно быть
возможным запрашивать и получать данные с постоянной периодичностью в
течение длительных интервалов времени, когда критерием является количество
строк, независимо от режима хранения. Должна быть доступна возможность запроса
и получения всех сохраненных значений.
5а.10.15.3. Должна быть доступна возможность запрашивать и получать
сводные аналоговые значения и сводку по состояниям, наилучшее соответствие,
градиент и интегральные итоговые значения.
5а.10.16.
Динамическая настройка и плавная инициализация данных
5а.10.16.1. Архиватор должен автоматически начинать сбор данных тега
сразу после занесения конфигурации тегов в базу данных. Добавление одного или
нескольких тегов в существующую базу данных архиватора не должно влиять на
сбор данных определенных ранее тегов.
5а.10.16.2. Клиентские соединения не должны затрагиваться из-за
динамической перенастройки. Кроме того, при отсутствии изменений конфигурации
сбора данных не должно быть потерь данных для тегов. Теги, требующие изменения
конфигурации сбора данных, будут, естественно, терять данные в течение их
повторной инициализации.
5а.10.17. Данные, введенные вручную, данные вне последовательности и
замещаемые данные
5а.10.17.1. Архиватор должен поддерживать данные, введенные вручную,
непоследовательные данные и замещаемые данные.
5а.10.17.2. Вводимые вручную данные, такие как лабораторные и
непоследовательные данные (например, архивные данные, накопленные на
удаленном терминале), должны обрабатываться механизмом извлечения, как если
бы они сохранялись автоматически. Должна предоставляться возможность ручного
замещения любых архивированных данных, путем ввода правильного значения и
флага, указывающего на сам факт замещения. Редактирование или уничтожение
первоначальных данных не допускается. Клиентские инструменты SQL могут
запрашивать исходные данные, замененные данные или оба вида данных. Данные,
введенные вручную, непоследовательные данные и замещаемые данные должны
вводиться в архиватор с помощью оператора SQL Insert или в пакетном режиме
через файл с данными, разделенными запятыми (CSV). Вводить или изменять
данные вручную разрешается только пользователям с надлежащими учетными
данными.
5а.10.18.
Качество данных
Все сохраненные данные должны иметь атрибуты качества данных. Основной
атрибут качества данных должен отражать качество данных, определенное
стандартом OLE для управления технологическими процессами (OPC; OLE for
Process Control). Для исходных данных (с флагом startup) и замененных данных
должны использоваться дополнительные атрибуты качества.
5а.10.19.
Конфигурирование системы событий
Архиватор данных должен содержать подсистему событий для мониторинга,
записи и/ или реагирования на события процесса или системы и для запуска какоголибо действия при обнаружении события. Система событий должна обнаруживать
появление события по заранее определенным и настраиваемым критериям,
хронологически регистрировать возникновение события и запускать назначенные
настраиваемые действия для события по факту его обнаружения. Атрибуты событий
должны регистрироваться в базе данных. В их числе должны быть дата и время
возникновения события, а также критерии, которые были выполнены.
5а.10.20.
Конфигурирование событий
5а.10.20.1. Система должна позволять пользователям простым щелчком
мыши создавать и определять имена тегов событий и связывать эти имена с
детекторами событий и результирующими действиями.
5а.10.20.2. Пользователь должен иметь возможность добавлять задержку в
миллисекундах перед запуском действия по данному событию и задавать приоритет
этого события: normal (обычный) или (critical) критический. Необходимо
предусмотреть возможность обнаружения события на заданном интервале времени,
по определенному аналоговому значению, пересекающему некоторый порог, или по
дискретному значению, меняющемуся с 0 на 1 (передний фронт), с 1 на 0 (задний
фронт) или по обоим этим изменениям. В систему должен быть включен редактор
событий, позволяющий создавать сложные детекторы событий на языке SQL
и определения действий, выполняемых по событиям.
5а.10.21.
Действие, выполняемое по событию
5а.10.21.1. Детекторы событий архиватора данных должны определять
возникновение события и инициировать связанное с ним действие.
5а.10.21.2. Детекторы должны опрашивать события с периодичностью,
заданной пользователем для каждого события. Пользователь должен иметь
возможность выбирать любое из четырех действий, выполняемых при обнаружении
события. По событию должно быть доступно выполнение следующих действий:
запуск команды SQL для выполнения SQL-запроса в базе данных;
сохранение моментального снимка с записью метки времени и значений
одного или нескольких выбранных аналоговых или дискретных тегов;
отправка сообщения электронной почты через сервер Microsoft Exchange
назначенным получателям;
изменение периодичности и/или разностного значения циклической
записи для одного или нескольких аналоговых тегов.
5а.10.21.3. Возможность изменения периодичности записи на основе событий
позволяет быстро регистрировать данные и собирать больше ценных данных
процесса, облегчая устранение неисправностей.
5а.10.22.
Интерфейс архиватора с другими реляционными базами данных
Архиватор должен использовать стандартные службы преобразования данных
операционных систем для упрощения обмена хронологическими данными процесса
с другими базами данных SQL Server, такими как Microsoft SQL Server, Oracle,
Mongo. В состав базы данных архиватора должен входить поставщик служб OLE
DB (связывание и внедрение объектов для баз данных), чтобы любой другой
сторонний SQL-клиент мог получить доступ к данным реального времени или
архивным данным процесса от архиватора данных.
5а.10.23.
Управление дисковым пространством
5а.10.23.1. Архиватор данных не должен требовать специализированных
инструментов для управления дисковым хранилищем. Должна быть возможность
архивировать и извлекать файлы хронологических данных стандартными способами
копирования операционной системы.
5а.10.23.2. Должна быть доступна возможность извлекать выбранные части
архивированных данных без извлечения всех этих данных. При извлечении
архивных данных они должны автоматически помещаться в оперативный доступ
для извлечения архиватором данных.
5а.10.23.3. Кроме того, архиватор данных должен как можно меньше
требовать администрирования. Архиватор данных должен иметь механизм
автоматического перемещения текущих файлов с диска, близкого к заполнению, на
вторичное устройство. Файлы и доступное пространство на вторичном диске также
должны отслеживаться, чтобы при достижении заданного пользователем порога
самые старые файлы могли автоматически удаляться для сохранения целостности
системы. Архивные файлы не должны никогда удаляться с основного устройства
хранения, если настроено соответствующее вторичное устройство.
5а.11. ГАРАНТИИ, ОБСЛУЖИВАНИЕ И ПОДДЕРЖКА ПО
Поставщик должен предоставить программу обслуживания и поддержки ПО,
гарантирующую пользователю получение полной отдачи от ПО в течение всего
жизненного цикла. Эта программа должна обеспечивать базовое гарантийное
покрытие и включать расширенную гарантию на приоритетную поддержку
и обновление ПО по мере его разработки. Телефонная поддержка должна
предоставляться через бесплатный номер в обычные рабочие часы. Поддержка
должна также предоставляться по факсу, по электронной почте или через веб-сайт
технической поддержки.
5а.11.1.
Гарантийное обслуживание
Поставщик ПО должен гарантировать работу продукта в течение трёх лет
после поставки. В течение гарантийного срока поставщик должен предоставлять
бесплатную техническую телефонную поддержку в обычные рабочие часы по
бесплатному номеру. Все ошибки в ПО должны своевременно устраняться.
5а.11.2.
Расширенная поддержка и обслуживание ПО
По окончании гарантийного срока пользователь может продолжать получение
технической поддержки по факсу, по электронной почте или на веб-сайте
технической поддержки. Чтобы гарантировать постоянный доступ пользователя к
последним версиям ПО, долгосрочную гарантийную и техническую поддержку,
поставщик должен предлагать расширенную программу поддержки за
фиксированную ежегодную плату.
5а.11.3.
Обновления программного обеспечения
Расширенная программа поддержки должна давать право пользователю на
получение последних версий системного ПО SCADA и обновлений версий по мере
их появления. Для качественной поддержки всех пользователей все лицензии на
данном объекте должны обслуживать одинаковые версии ПО.
5а.11.4.
Поддержка исправлений операционной системы
Поставщик должен тестировать и поддерживать исправления операционной
системы, периодически выпускаемые компанией Microsoft. Поставщик должен
иметь определенную политику поддержки таких исправлений, касающихся
безопасности.
5а.11.5.
Поддержка по телефону
В программу расширенной поддержки должна входить телефонная поддержка
в обычные рабочие часы. Телефонную поддержку должен осуществлять инженер
технической поддержки, имеющий сертификат от поставщика ПО по программе
аттестации персонала техподдержки. При вызове в обычные рабочие часы
полноценную телефонную поддержку должно предоставлять реальное лицо.
Система технической поддержки по голосовой почте неприемлема.
5а.11.6.
Поддержка по электронной почте
В расширенную программу должна входить поддержка по электронной почте
с реагированием не позднее одного рабочего дня и более высоким приоритетом, чем
для пользователей, не имеющих гарантийной поддержки, и направление
пользователей в ближайший сертифицированный центр технической поддержки.
Электронная поддержка также должна включать в себя расширенный доступ к
большему числу услуг на веб-странице технических служб. В программу
расширенной поддержки должен входить оперативный доступ к текущим и
прошлым заявкам в базе данных отслеживания вызовов, а также возможность
оформлять новые заявки, которые должны немедленно передаваться инженеру
технической поддержки для решения.
5а.11.7.
Загрузка электронных файлов
В программу расширенной поддержки должен входить доступ к защищенному
веб-сайту для загрузки электронных файлов. С защищенного веб-сайта для
пользователей поддержки должны быть доступны новые версии ПО, пакеты
обновлений, исправления уязвимостей, обновленные серверы ввода-вывода и другие
файлы поддержки.
5а.11.8.
Поддержка через интернет
Поставщик ПО должен иметь веб-сайт, ориентированный на разработку и
поддержку и предоставляющий техническую информацию о ПО SCADA,
рекомендации по внедрению ПО SCADA и доступ к пользовательским форумам.
5а.11.9.
Информационный бюллетень и диск техподдержки
Поставщик ПО должен не менее двух раз в год присылать информационный
бюллетень и диск технической поддержки, содержащий технические замечания для
всех пользователей программы расширенной поддержки. Диск технической
поддержки должен содержать полную сводку технических замечаний и
предупреждений, приложения, прикладные и диагностические утилиты, элементы
управления ActiveX, драйверы, скрипты, функции скриптов, мастеров и полезные
советы, которые могут оптимизировать разработку приложений.
5а.11.10.
Обратная совместимость ПО
Поставщик ПО должен иметь опыт поддержки обратной совместимости ПО не
менее 10 лет и план непрерывной модернизации для защиты инвестиций в
разработку. Старые приложения должны легко переноситься в новейшие версии ПО
без технических изменений.
6.Промышленные сети и протоколы АСУТП
В данном разделе описываются общие требования и архитектурные решения
построения промышленной сети производственных объектов АСУТП АО
"Мосводоканал" и её стыковки с сетями предприятия верхнего уровня.
Промышленные сети АО "Мосводоканал" должны поддерживать физические
интерфейсы связи Ethernet: "10BASE-T"/"100BASE-TX"/"100BASE-FX"/"100BASEFX WDM" и RS485 с промышленными протоколами обмена данными с
устройствами и средствами автоматизации: Modbus RTU, Modbus TCP, CANOpen,
Profibus DP, Ethernet/IP, DNP3, МЭК 60870-101/104, AS-Interface, HART.
На Рисунке ниже показан пример схемы подключения коммутаторов
технологической сети к оборудованию КВС объекта. Показанные подключения
предоставляют максимальную гибкость в применяемых топологиях для
коммутаторов АСУТП (кольцо, звезда, расширенная звезда и др.).
Коммутаторы
АСУТП
Пограничные
коммутаторы
Пограничный
маршрутизатор 1
Пограничный
маршрутизатор 2
C2960
LAN Lite
C2960
LAN Lite
МСЭ
Cisco ASA
Стек
коммутаторов
ядра
Коммутаторы доступа
C2960+
Failover
Active/
Standby
Stack
C2960 LAN Lite
IP телефон
ПК
Серверное оборудование
Структурная схема подключения технологического сегмента в корпоративную
вычислительную сеть объекта
Группа коммутаторов технологической сети, представляющая из себя
неделимый массив в виде звезды, кольца или иной топологии, подключается к стеку
коммутаторов ядра КВС. Для нужд подключения оборудования технологической
сети резервируется не менее двух SFP-портов на каждом коммутаторе ядра. Это –
предпоследние по нумерации оптические порты на коммутаторе уровня ядра КВС
или коммутаторе распределения КВС, в зависимости от физического размещения
кабелей от оборудования АСУТП. В зависимости от модели коммутатора КВС это
будут порты G0/3, G0/27 или G0/51 на обоих коммутаторах в стеке (модели Cisco
2960X), либо G1/0/27 и G2/0/27 (G1/0/51 и G2/0/51) для стекируемых 24-портовых
(48-портовых) коммутаторов Cisco 3750Х или Cisco 3850.
Для обеспечения отказоустойчивости необходимо использовать резервные
физические линии. Также при осуществлении взаимодействия между
коммутаторами ядра КВС и сетью АСУТП допустимо использовать технологию
агрегирования каналов (Etherchannel).
Выделение IP-подсетей для АСУТП осуществляется в соответствии с общим
планом адресации Общества. Для различных нужд АСУТП выделяется диапазон
номеров VLAN (c 21 по 29). Если на технологических коммутаторах филиала не
применяются VLAN, то порты коммутаторов ядра КВС, предназначенные для
подключения коммутаторов АСУТП конфигурируются как порты доступа в VLAN
21. В случае применения VLAN на технологических коммутаторах стык между КВС
и сетями АСУТП осуществляется с помощью транковых соединений.
Для защиты от петель коммутации применяется протокол STP (рекомендуется
использование Rapid-STP).
Для задач АСУТП с целью обеспечения безопасности на межсетевых экранах
создаются соответствующие логические интерфейсы. Шлюзом по умолчанию для
оборудования АСУТП указываются IP-адреса этих интерфейсов. На Рисунке ниже
показан пример подобного разделения, а также логика маршрутизации трафика
между оборудованием КВС. Минимально для задач АСУТП создается один
логический интерфейс на Cisco ASA для VLAN 21. При необходимости могут быть
сконфигурированы дополнительные логические интерфейсы.
Static route 0.0.0.0/0 via
172.21.15.193
Static route 172.21.0.0/20
via 172.21.15.195
Коммутаторы ядра
Catalyst stack
VLAN Пользователей (101)
Interface Vlan 101
172.21.0.1/23
Голосовой VLAN (121)
Interface Vlan 121
172.21.4.1/23
Серверный VLAN (31)
Interface Vlan 31
172.21.12.1/24
EIGRP
МСЭ Cisco ASA
Interface Vlan 91
172.21.15.195/28
INSIDE
Vlan 91
172.21.15.193/28
EIGRP
Interface gi0/0.92
172.21.15.211/28
BGP
Пограничный
маршрутизатор 1
АСВТ
OUTSIDE
Vlan 92
172.21.15.209/28
Пограничный
маршрутизатор 2
Список VLAN для нужд
технологической сети (2x)
Блок адресов 172.21.8.0/22
Пример:
Controllers1
Vlan 21
172.21.8.1/23
Controllers2
Vlan 22
172.21.10.1/24
Operators
Vlan 23
172.21.11.1/26
КОМКОР
Interface gi0/0.92
172.21.15.212/28
EIGRP
BGP
SCADA
Vlan 24
172.21.11.65/26
Terminal Servers
Vlan 25
172.21.11.129/26
Маршрутизация трафика и обеспечение безопасности подсетей АСУТП
Политики безопасности и гибкой фильтрации трафика для доступа к
оборудованию АСУТП на технологических объектах Общества осуществляются на
межсетевых экранах Cisco ASA.
На них применяются следующие методы обеспечения безопасности:
Списки управления доступом и инспектирование сетевого трафика;
Политики инспектирования трафика по различным протоколам;
Подробное логирование;
Детектирование аномалий сетевого трафика (сканирование сети, атаки
фрагментами и т.п.).
Также может быть осуществлена дополнительная аутентификация
пользователей, обращающихся к оборудованию АСУТП из подсетей общего
назначения.
Подробнее реализация политик защиты АСУТП в соответствии требованиям к
обеспечению защиты информации в автоматизированных системах управления
производственными и технологическими процессами на критически важных
объектах (Приказ ФСТЭК России № 31 от 14 марта 2014 г.) и другими
нормативными документами описывается в соответствующих стандартах
предприятия (см. нормативные ссылки).
7.Контроллеры и ПО контроллеров АСУТП
7.1. ОБЩИЕ ТРЕБОВАНИЯ
Контроллерное оборудование АО "Мосводоканал", исходя из поставленных
руководством
задач,
предназначено
для
решения
основных
задач
автоматизированного контроля и управления всеми технологическими процессами
Общества. Отдельные технологические процессы и участки, исходя из общей
технической политики автоматизации АО "Мосводоканал" сводятся в рамках
единой иерархической системы управления производством.
7.2. ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ
АО "Мосводоканал" –
АРМ
–
ПО
–
–
ОЭАИТ
SCADA
–
Акционерное общество "Мосводоканал"/Общество;
Автоматизированное рабочее место;
Программное обеспечение;
Отдел эксплуатации автоматизации информационных
технологии;
Система диспетчерского контроля и управления (сокр.
от англ. Supervisory Control And Data Acquisition).
7.3. НОРМАТИВНЫЕ ССЫЛКИ
Требования составлены на основании следующих документов:
7.3.1. ГОСТ Р МЭК 61131-3-2016 Контроллеры программируемые. Часть 3.
Языки программирования;
7.3.2. ГОСТ Р МЭК 61508-1-2012 Функциональная безопасность систем
электрических, электронных, программируемых электронных, связанных с
безопасностью. Часть 1. Общие требования;
7.3.3. ГОСТ Р МЭК 62061-2015 Безопасность оборудования. Функциональная
безопасность систем управления электрических, электронных и программируемых
электронных, связанных с безопасностью.
Примечание: При пользовании Требований целесообразно проверить
действие ссылочных документов. Если ссылочный документ заменен (изменен), то
при пользовании Требованиями следует руководствоваться замененным
(измененным) документом. Если ссылочный документ отменен без замены, то
положение, в котором дана ссылка на него, применяется в части, не затрагивающей
эту ссылку.
7.4. ТРЕБОВАНИЯ К КОНТРОЛЛЕРАМ АСУ ТП. НАЗНАЧЕНИЕ И ТИПЫ
ПРИМЕНЯЕМЫХ КОНТРОЛЛЕРОВ
7.4.1. Контроллерные шкафы управления являются основой АСУ ТП. Они
принимают сигналы от приборов, датчиков, электроприводов, частотных
регуляторов, прочего технологического оборудования и исполнительных устройств
и реализуют алгоритмы управления технологическими процессами всех
производственных подразделений Общества. Контроллеры АСУ ТП
устанавливаются автономно в шкафах управления АСУ ТП либо объединяются
между собой локальными сетями контроля и управления и каналами передачи
данных и команд с исполнительными устройствами для обмена данными,
обеспечения управления отдельными участками производства или
технологическими линиями. Вышестоящим уровнем управления для контроллеров
АСУ ТП служат сервера SCADA АО "Мосводоканал", с которыми контроллеры
АСУ ТП объединены каналами связи и управления.
7.4.2. В АСУ ТП АО "Мосводоканал" реализована концепция
автоматизированного контроля и управления производством при которой операторы
и диспетчеры отвечают лишь за выбор конкретных параметров и режимов
технологических процессов, а непосредственное управление оборудованием
осуществляется программой контроллера соответствующего участка производства в
соответствии с заданными операторами режимом и параметрами работы.
7.4.3. На случай отказа оборудования или средств управления
предусматривается местное (без контроллера) либо дистанционное (с сенсорной
панели управления шкафа контроллера или от АРМ SCADA) управление
технологическим процессом.
7.4.4. Таким образом, сеть контроллеров является ключевым элементом
системы управления производством без которой достижение высоких
производственных показателей затруднено либо (в случаях сложных
и быстропротекающих технологических процессов) не возможно. Также
контроллерное оборудование в ряде технологических процессов выполняет функции
систем безопасности, выполняя алгоритмы аварийного останова технологического
оборудования, ввода резерва, предотвращения последствий аварийных ситуаций
и сбоев в работе. Эти функции требуют повышенной надёжности и устойчивости
в работе АСУ ТП.
7.4.5. Большая часть контроллеров АСУ ТП эксплуатируется в условиях
промышленных цехов и помещений в том числе в специально предназначенных для
установки контроллерного оборудования помещениях (РТЗО, серверных и прочих).
7.4.6. Меньшая часть оборудования устанавливается в удаленных,
необорудованных местах (в камерах, не отапливаемых временных конструкциях
и т.п.).
7.4.7. Задачи контроллерного оборудования в АО "Мосводоканал"
разделяются на задачи только контроля (точки контроля давления, уровня, качества,
модули удаленного сбора данных от приборов и т.п.) и задачи автоматизированного
контроля и управления технологическими процессами и оборудованием (ЗРА,
насосами и др.).
7.4.8. Исходя из специфики масштабирования задач управления и контроля
производственными объектами и технологическими процессами Общества
в АО "Мосводоканал" должны эксплуатироваться три типа контроллеров разного
назначения и производительности, условно разделенные на:
малый - до 100 сигналов ввода/вывода;
средний - от 100 до 1000 сигналов;
большой - от 1000 до 5000 сигналов.
Малый контроллер предусматривается для решения задач управления и
контроля небольшими объектами, в том числе для создания сетей контрольных
точек параметров водоснабжения и канализации (давления, расходов, качества и
т.п.).
Средний контроллер применяется для решения широкого спектра задач АСУ
ТП всеми технологическими процессами Общества и используется как основное
типовое решение в большинстве проектов автоматизации.
Большой контроллер используется в проектах комплексной автоматизации
крупных объектов либо производственных участков, требующих от систем
автоматизации повышенной надёжности и производительности, в случаях когда
мощности основного (среднего) контроллера не достаточно и необходимы
специфические возможности управления – горячее резервирование, дублирование
сетей контроля и управления на объектах, решение задач, требующих высокой
производительности. Данные технические решения унифицированы и покрывают
весь спектр основных задач контроля и управления Общества.
7.4.9. Помимо перечисленных типовых решений, допустимы и могут
использоваться специализированные, предназначенные для решения узкого класса
задач, технические решения, например, с экстремально низким потреблением
энергии для реализации периодического контроля на объектах без постоянного
энергоснабжения либо встроенные устройства контроля и управления различных
производителей, поставляемые совместно с технологическим оборудованием, в том
числе, например, специализированные контроллеры вентиляционных систем и
подобные готовые технические решения. Все такие решения, отличающиеся от
типовых, должны обосновываться соответствующими проектами.
7.4.10.
Допускается также применение не типовых контроллеров в
отдельных – "пилотных" проектах с целью проверки и уточнения их
эксплуатационных характеристик для рассмотрения вопроса об их перспективном
использовании в проектах Общества.
7.5. ОБЩИЕ ТРЕБОВАНИЯ И ПРИНЦИПЫ ВЫБОРА КОНТРОЛЛЕРОВ
7.5.1. Выбираются контроллеры одного производителя совместимые
по возможности подключения модулей и удаленных устройств ввода/вывода, а
также обмена данными и имеющие стандартные встроенные средства и
подключаемые модули связи построения промышленной сети контроля и
управления. Это требование обусловлено резким (в число, пропорциональное
количеству применяемых систем) ростом эксплуатационных расходов в случаях
применения множества устройств различных производителей, что, в свою очередь,
вызывает необходимость:
закупки запасных частей для
номенклатуре применяемых модулей;
каждого
вида
устройств по
всей
приобретения и поддержки разнородного ПО, необходимого для
технического обслуживания и внедрения (разработки нового ПО, доработки
существующего ПО, создания резервных копий ПО для аварийного восстановления
и прочих);
обучения персонала работе с разнотипным оборудованием и ПО;
соответствующего роста затрат и стоимости услуг подрядных организаций,
обслуживающих разнотипные системы автоматизации.
7.5.2. При сходных ценовых и технических характеристиках и соблюдении
указанных в данном документе требований, выбираются контроллеры,
производимые на территории Российской Федерации.
7.5.3. Выбираются контроллеры имеющие возможности масштабирования
производительности – мощности процессора и объёма памяти, а также подключения
дополнительных устройств ввода/вывода и модулей связи.
7.5.4. Все применяемые АО "Мосводоканал" контроллеры исходя из
требований надёжности обеспечения технологических процессов и эффективности
технического обслуживания должны быть рассчитаны производителем на
круглосуточную работу в течении не менее 15 лет в условиях эксплуатации в
помещениях промышленного назначения. Оборудование не имеющее
подтвержденных производителем сроков эксплуатации не менее 15 лет должно
применяться только с обоснованием необходимости его использования в
конкретных проектах.
7.5.5. Все контроллеры должны иметь полную, гарантированную поддержку
производителем этапов жизненного цикла оборудования: эксплуатации в части
обеспечения запасными частями и ремонта; договоров на техническое
обслуживание и ремонт; обучения и модернизации; в части консультирования и
обмена опытом; управления проектами и экспертизы проектных решений;
подготовки технических и коммерческих предложений.
7.5.6. Производителем должны гарантироваться поставка комплектующих
и принадлежностей, модулей (связи, ввода/вывода/ процессорных, блоков питания и
прочих), программного обеспечение и техническая поддержка в течении указанного
выше срока эксплуатации – 15 лет.
7.5.7. При снятии контроллерного оборудования с производства,
изготовителем должна обеспечиваться совместимость использованных
программных и технических средств посредством ввода в эксплуатацию
технических решений следующего поколения, поддерживающих работу с
оборудованием предыдущего поколения систем путём переноса проектов
программного обеспечения и подключения модулей ввода/вывода устаревших
систем, а также совместная работа разных поколений по стандартизованным
протоколам связи.
7.5.8. Все закупаемые АО "Мосводоканал" контроллеры в процессе
жизненного цикла их эксплуатации должны делиться на не более чем три
поколения:
7.5.8.1.
устаревшие – контроллеры снимаемые и уже снятые с
производства изготовителем;
7.5.8.2.
устаревшим;
современные – используемые в настоящее время на замену
7.5.8.3.
будущем.
перспективные – предлагаемые для замены современных в
7.5.9. Современные контроллеры планируются к замене перспективными
в момент, когда производителем подтверждается ограничение срока их выпуска
менее 5 лет и срока поддержки (выпуска запасных частей и комплектующих) менее
10 лет. Перспективные и вновь внедряемые модели не должны иметь действующих
ограничений производителем срока выпуска либо таковой должен превышать
пятнадцать лет.
7.5.10.
Срок плановой эксплуатации контроллеров в шкафах управления
на производстве по опыту, исходя из условий эксплуатации АО "Мосводоканал"
составляет десять лет. Срок предельной, сверхплановой эксплуатации контроллеров
может быть продлен до 15 лет, по решению специалистов ОЭАИТ в результате
анализа технического состояния и условий эксплуатации систем.
7.5.11.
К моменту окончания срока эксплуатации контроллеры или
шкафы управления в целом (в зависимости от степени износа и доступности
установленных в них запасных частей и комплектующих) должны быть заменены на
новые аналогичной или более современной модели.
7.5.12.
Все устаревшие контроллеры, выпуск комплектующих для
которых прекращен производителем и имеющиеся на складах Общества запасы ЗИП
(запасных частей – модулей) для которых не позволяют обеспечить их
работоспособность в течении не менее двух лет, должны планироваться к замене
современными в текущих производственных планах подразделений
АО "Мосводоканал".
7.5.13.
На объектах не являющихся опасными производственными
объектами (ОПО) или в составе систем противоаварийной защиты (ПАЗ) и не
являющихся критичными с точки зрения архитектуры систем автоматизированного
управления (то есть, фактически допускающих возможность ручного местного
управления технологическим оборудованием или участком производства
длительное время) допускается продление срока эксплуатации контроллеров свыше
15 лет, до момента их физического износа, но не более срока прекращения
поддержки производителем (доступности приобретения запасных модулей).
7.6. КОММУНИКАЦИОННЫЕ ВОЗМОЖНОСТИ
7.6.1. Контроллеры должны иметь встроенную возможность подключения
не менее чем по двум портам к сети 10BASE-T/100BASE-TX Ethernet,
с использованием протокола связи Modbus/TCP.
7.6.2. Контроллеры должны поддерживать открытые стандарты шин обмена
данными с верхним уровнем (системами диспетчерского контроля и управления),
а также полевых шин обмена данными (с датчиками и устройствами контроля
и управления) технологии Transparent Ready для подключения интеллектуальных
устройств управления (регуляторов частоты, устройств плавного пуска,
электроприводов и прочих) и построения систем управления интеллектуальными
устройствами. В том числе должны поддерживаться нижеследующие службы связи
для устройств с поддержкой Transparent Ready, предназначенные для использования
в приложениях автоматизации:
служба сообщений Modbus/TCP;
служба опроса входов/выходов;
служба замены неисправных устройств (FDR);
служба управления сетью SNMP (простой протокол управления сетью);
служба глобальных данных (Global Data);
служба управления полосой пропускания;
служба синхронизации времени NTP (Network Time Protocol);
служба уведомления по электронной почте через сервер SMTP с функцией
блокировки.
7.6.3. Контроллеры должны иметь модули, обеспечивающие
коммуникационные возможности протоколов: Modbus TCP, Modbus RTU, Modbus
Plus, Profibus DP и Profibus PA (в том числе должны позволять дистанционно
осуществлять настройку устройств на шине PROFIBUS через Ethernet), а также
CANopen, HART, AS-Interface (V3 master), DNP3, МЭК 60870-101/104.
7.6.4. Контроллеры должны иметь подтвержденную производителем
возможность построения сложных сетей управления, включая: подключение
удалённых "корзин" расширения, модулей сбора данных; дублирование линий связи
с контроллером; построения кольцевой резервированной сети связи, содержащей не
менее 24 контроллеров с поддержкой протоколов автоматического восстановления
работы при обрыве сети, в том числе с использованием оптико-волоконных и
беспроводных каналов связи. Контроллеры должны поддерживать обмен
информацией по GSM, радио-каналам и ADSL через встроенные модули либо
внешние устройства связи.
7.6.5. Контроллеры должны иметь порт USB для подключения терминала
программирования или терминала – сенсорной панели контроля и управления
(ЧМИ).
7.7. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
7.7.1. Все контроллеры должны иметь готовые сертифицированные,
продающиеся "в коробке" или скачиваемые бесплатно средства разработки
программного кода соответствующее стандарту "ГОСТ Р МЭК 61131-3-2016
Контроллеры программируемые. Часть 3. Языки программирования"
и поддерживающие работу под управлением современных версий операционных
систем на базе MS Windows. Базовое, стандартное программное обеспечение
(операционная система) контроллера не должно подвергаться изменениям, чтобы
удовлетворить какие-либо требования пользователя. Прикладное программное
обеспечение должно разрабатываться таким образом, чтобы не требовалась
модификация базового программного обеспечения контроллера (операционной
системы). Проектирование программного обеспечения должно обеспечиваться
таким, чтобы будущее изменение или обновление программного обеспечения
операционной системы не повлияло на успешное функционирование системы с
конкретным прикладным программным обеспечением. Поставщик должен
предлагать единую программную платформу, как для безопасных, так и
небезопасных приложений. Прикладное программное обеспечение не должно
требовать изменения для возможности запуска в новых версиях программного
обеспечения операционной системы. Любая новая версия базового программного
обеспечения системы должна быть совместима с файлами, созданными с
использованием предыдущих версий прикладного программного обеспечения. При
установке новой версии базового ПО, должна быть возможность создать резервную
копию пользовательских данных, так как производитель может изменить данные в
новом релизе.
7.7.2. ПО должны поддерживаться все языки стандарта МЭК 61131-3, а
именно: Instruction List (IL); Ladder (LD); Structured Text (ST); Function Block
Diagram (FBD); Sequential Function Chart (SFC)/Grafcet.
7.7.3. Должно поддерживаться многозадачное программирование: основная
задача (Mast 10+ мс), быстрая задача (Fast 2+ мс), а также задачи вызываемые
событиями (Event-triggered).
7.7.4. Должны быть реализованы функции автоматической диагностики
работы системы и приложений со средствами контроля и поиска возникающих
ошибок. ПО должна поддерживаться разработка и контроль конфигурации полевых
шин с подключенными к ним средствами контроля и управления, а также
подключенных устройств удаленного ввода/вывода к контроллеру. ПО должна
поддерживаться разработка пользовательских функциональных блоков EFB
(Elementary Function Blocks) и функциональных блоков данных DFB (Data Function
Blocks).
7.7.5. Должен поддерживаться редактор и библиотеки пользовательских
данных и функциональных блоков. Библиотека диагностических блоков
программной оболочки контроллера (DFB и EFB) должна содержать готовые блоки
для диагностики системы: сбой отдельного ввода/вывода; сбой модуля или шины
связи, когда подключенное устройство отсутствует либо неисправно; готовые блоки
диагностики приложения: контроль имеет ли событие (битовое состояние)
правильное значение в определенное время; контроль изменения состояния бита в
соответствии с указанными временными условиями; контроль состояния сочетания
двух битов; а также возможность создания пользовательских диагностических
функциональных блоков.
7.7.6. Контроллеры должно поддерживать возможность свободной и полной,
без ограничений функциональности, загрузки и выгрузки исполняемой программы и
данных в любой момент времени. Выгрузка или изменение программы должны
происходить без остановки выполнения программы контроллера. Должны быть
реализованы средства проверки идентичности программного кода без его загрузки и
перезапуска контроллера (верификация ПО).
7.7.7. ПО контроллеров должно содержать полные библиотеки стандартных
блоков построения программ контроллера, в том числе: таймеры и счетчики;
целочисленные операции; управление таблицами; функции сравнения; дата/таймменеджмент; логические операции; математические функции; статистические
функции; работа со строковыми переменными; преобразование типов данных; ПИДрегулирование и другие, необходимые для разработки ПО управления
технологическими процессами общества. В том числе:
Следующие функции ввода должны поставляться как стандартные пункты
настройки ПО контроллера:
Извлечение квадратного корня, для измерения расхода;
Линеаризация типа B, E, N, J, K, L, R, S, T, и U – термопар;
Линеаризация термометров (RTD);
Цифровой вход импульсного усреднения;
Импульсный вход для преобразования частоты.
Следующие вычислительные функции должны быть поставлены как
стандартные конфигурируемые элементы или простые алгебраические инструкции
ПО контроллера:
Сложение/вычитание;
Генератор пилообразной функции;
Опережение – запаздывание;
Интегратор/Аккумулятор;
Время запаздывания;
Выбор высокого/низкого;
Умножение/Деление;
Усреднения по времени;
Переключение выбора сигнала %;
Экспоненциальный многочлен;
Логарифмы;
Квадратный корень;
Абсолютное значение;
Задержка закрытия;
Выбор min/max;
Функция сглаживания;
Генератор шума;
Сглаживание сигнала/Низкочастотный фильтр;
Задержка сигнализации;
Непрерывные функции управления.
Следующие функции контроля должны представлять собой настраиваемые
элементы ПО контроллера:
Пропорционально-интегрально-дифференциальный регулятор (PID);
Автоматическое/ручное управление с регулировкой смещения;
Управление соотношением;
Шаговый контроллер;
Каскадное управление;
Управление ручной коррекцией;
PID -регулятор с прямой связью;
PID-регулятор с предиктором Смита;
PID-регулятор с логикой безопасности и контролем управления с обратной
связью;
PID-регулятор с адаптацией точка - ориентированных операционных
параметров;
Модель интеллектуального управления;
Адаптивная настройка (опция);
Многопараметрическое управление (опция).
Следующие дискретные функции управления должны поставляться как
стандартные элементы настройки ПО контроллера:
Логические функции - and, or, not, nand, nor, xor;
Обнаружение изменения состояния;
Установка/сброс триггеров;
Таймеры и счетчики;
Элементы сравнения - greater than, less than, equal to, not equal to;
Мультиплексор (выбирает один из 16 сигналов);
Положительные, отрицательные и двунаправленный краевой триггер.
ПО контроллера должно быть в состоянии поддерживать технологические
модули (контроллеры, позиционеры, счетчики и т.д.).
Алгоритм вычисления должен осуществляться в технических единицах с
плавающей запятой или другими эквивалентными методами, которые не требуют
масштабирования.
7.7.8. Должны быть реализованы средства отладки исполняемой программы,
в том числе: автоматическая проверка кода, построчное выполнение программы
(Step by step execution), точки останова (Breakpoint), и точки контроля (Watchpoint).
Должны быть реализованы тренды переменных и средства анимации – экраны
оператора (Operator screens) и таблицы анимации (Animation tables) для отладки ПО,
а также средства диагностики состояния контроллера.
7.7.9. В ПО контроллера должны иметься средства импорта экспорта в формат
XML/XVM.
7.7.10.
Должна поддерживаться удалённая диагностика контроллера через
WEB-сервер. Должна поддерживаться запись и чтение файлов данных контроллера
через стандартный сервис FTP.
7.7.11.
ПО контроллеров должно иметь коммуникационные драйверы для
обмена данными с наиболее распространенными в Обществе контроллерами
платформ Modicon: Momentum, Premium, Quantum.
7.7.12.
Должна поддерживаться online отладка и изменение программы в
контроллере, работающем непосредственно на пусковом объекте.
7.7.13.
Должен поддерживаться словарь данных (Data dictionary) и
динамический обмен данными со SCADA системами общества (Dynamic exchange),
а также статический обмен посредством экспортных файлов форматов XML/XVM.
7.7.14.
Должно поддерживаться автоматизированное документирование и
представление разрабатываемой программы.
7.7.15.
ПО контроллеров обязано поддерживать стандарт FDT/DTM (Field
Device Tool / Device Type Manager) для интеграции оборудования различных
производителей в управляющую программу контроллера.
7.7.16.
ПО контроллеров должно иметь встроенные стандартные средства
безопасности не допускающие не санкционированные сторонние подключения,
загрузку/выгрузку и отладку ПО без ввода пароля, выполнение не предусмотренных
разработчиком инструкций, ограничение доступа к ПО контроллера посредством
HTTP и FTP сервисов.
7.7.17.
В ПО должна быть реализована встроенная функция эмулятора
контроллера, которая позволяет в точности воспроизвести поведение программы
управления контроллера на компьютере с целью организации процессов отладки
работы программ контроллера вне управляемого объекта. Должно существовать
полное описание реализации языка программирования, учебная литература и курсы
обучения языку для специалистов подразделений автоматизации.
7.8. ТРЕБОВАНИЯ К СМЕННЫМ КАРТАМ ПАМЯТИ
7.8.1. Контроллеры средней и большой производительности должны иметь
возможность установки карты памяти емкостью не менее 4 Мб для хранения
исполняемой программы, данных, а также для создания резервных копий.
7.8.2. Исходная исполняемая программа должна иметь возможность быть
полностью загружена на сменную Flash-карту памяти контроллера типа SD (Secure
Digital). Карта памяти и процессорный модуль контроллера должны иметь
возможность работы без установленных батарей поддержки. Должны
поддерживаться объёмы памяти контроллера не менее 4 Мб, карты памяти не менее
8 Мб. Сменная карта памяти должна иметь возможность использования для
хранения и переноса исполняемой программы контроллера, а также возможность
дублирования с целью обеспечения оперативной замены процессорного модуля
контроллера. Карта памяти должна иметь возможность использования для
резервного копирования областей памяти контроллера: области программ,
символов, комментариев и область констант.
7.9. СЕРТИФИКАЦИОННЫЕ ТРЕБОВАНИЯ
7.9.1. Контроллер и все входящие в его состав модули должны иметь
надлежащие технические сертификаты соответствия "TP TC 020/2011
Электромагнитная совместимость технических средств". Также применяемые
контроллеры обязаны удовлетворять и превышает требования промышленных
стандартов по механическим ударам, вибрации, воздействию температуры, высоте и
стойкости к электромагнитным помехам, а именно:
Механическая стойкость по стандарту МЭК/IEC 60068-2:
Ударная нагрузка [27 Ea]
не менее 30 g
Вибрации [6 Fc]
не менее 3 g
Электромагнитная совместимость по стандарту МЭК / IEC 61000-4:
Напряжённость поля
не менее 10 В/м
Электростатика
не менее 8 кВ
Окружающая среда по стандартам МЭК/IEC 61000-4, МЭК/IEC 61131-2:
Температурный режим
не менее 0 .. 60°C
Относительная влажность
не менее 5% .. 95% (без конденсации)
Высота над уровнем моря
не менее 4000 м
7.9.2. Питание контроллеров должно осуществляться собственными
источниками питания минимальным напряжением: 24...48 В постоянного тока или
100...240 В переменного тока номинальной частоты 50..60 Гц. Диапазон
выдерживаемых температур для всех модулей контроллера определяется
конкретными проектными решениями, но не хуже чем 0..60 0С (с возможностью
эксплуатации -25..70 0С в варианте в специальном корпусе/исполнении).
Относительная влажность: 5...95 % (без образования конденсата).
7.9.3. Требования к характеристикам питания контроллеров представлены
в таблице:
100 - 120/200 24 В
48 В
100 - 240 В
Номиналь
240 В
постоянн постоянног переменно
ное
переменного
ого тока
о тока
го тока
тока
Напряжение
18 - 31,2
85 - 115/230 18 - 62,4 В
85 - 264 В
Предельно В
264 В
постоянног переменно
е
постоянн
переменного
о тока
го тока
ого тока
тока
Номиналь
50/60 Гц
50/60 Гц
ная
Частота
Предельна
47/63 Гц
47/63 Гц
я
Кратковреме Длительно ≤ 10 мс
≤ 1/2
≤ 10 мс (*)
≤ 1/2 периода
нное
сть
(*)
периода
отключение
Повтор
≥1с
≥1с
≥1с
≥1с
питания
Гармоническ
ая
10%
10%
составляюща
я
Остаточная
пульсация
5%
5%
(от 0 до пика)
(*) Уменьшается до 1 мс при максимальной нагрузке и минимальном напряжении
питания (18 В постоянного тока).
7.9.4. Аналоговые модули ввода/вывода контроллеров должны иметь
свидетельство об утверждении типа средств измерений, выданное Федеральным
Агентством по техническому регулированию и метрологии.
7.10. КОНСТРУКТИВНЫЕ ТРЕБОВАНИЯ
7.10.1.
Все закупаемые контроллеры должны поддерживать конструкцию
монтажного шасси позволяющую устанавливать и извлекать модули ввода/вывода и
модули связи непосредственно во время работы (Hot Swap) без использования
специальных инструментов. Должны поддерживаться корзины с 4, 6, 8 или 12
слотами для установки процессоров и модулей ввода/вывода.
7.10.2.
Контроллеры должны допускать установку резервированных
модулей электропитания, а также модулей удаленного ввода/вывода.
7.10.3.
Контроллеры большой производительности должны иметь
встроенную функцию горячего резервирования Hot Standby для использования в
условиях повышенных требований к надёжности систем контроля и управления.
7.10.4.
Контроллеры должны поддерживать изменение конфигурации "на
лету" без остановки процесса, а именно:
добавление или удаление модулей дискретного и аналогового
ввода/вывода в шасси станций удалённого ввода/вывода (без меток времени) или в
локальном шасси;
добавление новой станции удалённого ввода/вывода;
модификация параметров конфигурации каналов ввода/вывода;
автоматическая реконфигурация модулей при горячей замене;
изменения онлайн в приложении во время процесса, включая добавление
новых переменных, используемых также в человеко-машинных интерфейсах
(ЧМИ).
7.10.5.
Контроллеры должны поддерживать архитектуру уделенного
ввода-вывода и распределенного ввода-вывода, а также смешанную архитектуру
ввода-вывода.
7.10.6.
Базовые контроллеры (среднего типа) должны обеспечивать
следующие значения параметров ввода/вывода:
от 512 до 1024 дискретных вводов/выводов;
от 128 до 256 аналоговых вводов/выводов;
от 20 до 36 каналов специализированного применения (счетчик процесса,
управление движением и линия последовательной передачи данных, RTU);
до 3 портов Ethernet Modbus/TCP (со встроенным портом и без него,
а также с макс. 2 сетевыми модулями) с возможностью подключения в зависимости
от типа сети: по Ethernet TCP/IP через сетевой модуль до 63 устройств с сервисом
опроса ввода/вывода (I/O Scanning) или по Modbus/TCP до 32 устройств.
4 шины приводов/датчиков V3 AS-интерфейса с "полным расширенным
ведущим устройством", профиль M4.0;
порт USB TER (для подключения терминала для программирования или
терминала ЧМИ).
7.10.7.
Контроллеры должны обладать развитыми средствами аппаратной
диагностики как работы процессорного модуля, так и подключенных модулей
ввода/вывода и связи, в том числе:
индикатор Run (зеленый): процессор находится в рабочем режиме
(выполнение программы);
индикатор ERR (красный): неполадка системы или процессора;
индикатор I/O (красный): ошибка модуля ввода/вывода;
индикатор SER COM (желтый): использование линии последовательной
передачи данных Modbus;
индикатор CARD ERR (красный): карта памяти отсутствует или
неисправна.
7.10.8.
При отключении контроллера, модули дискретного ввода-вывода
и система программирования контроллеров должны поддерживать установку
"безопасного состояния", которое устанавливается для каждого модуля при
настройке конфигурации твердотельных выходов постоянного тока в двух
вариантах:
"безопасное состояние": каналы устанавливаются на 0 или 1 в зависимости
от заданного программистом значения безопасного состояния;
"удержание": выходы остаются в состоянии, в котором они пребывали до
остановки ПЛК.
7.10.9.
Все модули контроллера должны иметь средства локальной
диагностики светодиодными индикаторами, расположенными на их передней панели.
Для модулей дискретного ввода/вывода должны также отображаться их состояния 0
или 1.
7.10.10.
Кроме средств локальной диагностики индикаторами, должны
поддерживаться программные средства диагностики для выявления неисправности
на уровне конфигурации оборудования, уровне модуля и уровне канала вводавывода, а также средства удаленной диагностики через web-браузер посредством
встроенной в процессорный модуль функции стандартного web-сервера.
7.10.11.
Должны поддерживаться модули ввода с плотностью до 64 штук
сигналов 24, 48, 110 В как постоянного, так и переменного тока, а также 220 В
переменного тока. Должны поддерживаться следующие типы дискретных входов: 524 В постоянного тока (которые могут быть снабжены отметками времени с
точностью до 1мс); 125 В постоянного тока; 24-48 В переменного/постоянного тока,
50/60Гц; 120В переменного тока, 50/60Гц; 230В переменного тока, 50/60Гц.
7.10.12.
Для модулей вывода должны быть доступны как транзисторные
выходы 24 В постоянного тока, так и релейные выходы 220 В переменного тока.
7.10.13.
Модули аналогового ввода должны поддерживать стандартные
унифицированные диапазоны (0-20 мА, 4-20 мА, 0-10 В в различных вариациях),
а также: ±20 мА постоянного тока, изолированные и неизолированные входы; 1-5 В
постоянного тока, ±10 В постоянного тока и ±1 В постоянного тока, изолированные
и неизолированные входы; типы термопар B, E, J, K, L, R, S, T, U; платиновые
датчики температуры (RTD) — Pt100, Pt500, Pt1000, Ni100, Ni1000, Cu10 – в
соответствии с IEC 60751; высокоскоростной импульсный вход - 1, 10, 20, 100, 250,
500кГц. Должны быть обеспечены линеаризация температуры и компенсация
холодного спая термопары. Модули аналогового входа должны работать при
температуре 25 0C с основной погрешностью не более ±0,25% от диапазона
входного сигнала.
7.10.14.
Модули аналогового вывода должны быть доступны с плотностью
не менее чем до 8 каналов на один модуль с выходным сигналом 4-20 мА.
7.10.15. Разрядность АЦП модулей аналогового ввода-вывода должна быть не
менее 16 бит, или 15 бит плюс знак. Модули аналогового выхода должны работать с
предельной погрешностью, не превышающей следующие значения: напряжение не
более ±0,2% от выходного сигнала; ток не более ±0,3% от выходного сигнала.
7.10.16.
Должны поддерживаться счетные модули, поддерживающие
подключение энкодеров с push-pull выходом, модули подключения SSI-энкодера
и модули контроля движения с РТО-выходом для управления сервоприводами.
7.10.17.
Процессорные модули, блоки питания и основные типы модулей
расширения должны поддерживать варианты изготовления в исполнении
с полиуретановым покрытием электронных плат для работы в условиях агрессивной
окружающей среды и с расширенным диапазоном рабочих температур до -25...+70
С.
7.10.18.
Механической основой системы должна являться монтажная шина
(корзина), на которую устанавливаются блок питания, процессорный модуль и
модули расширения.
7.10.19.
Архитектура должна позволять соединять до четырех таких
монтажных корзин в единую систему с одним головным процессором, а сами
корзины должны иметь возможность размещения на суммарную длину до 30 метров
без внедрения дополнительных полевых шин связи корзин.
7.11. ТРЕБОВАНИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
7.11.1.
Платформа автоматизации ПЛК должна обеспечивать
следующими возможностями:
расширенный контроль доступа к ПЛК с помощью списка доступа
используемых IP-адресов и TCP-портов;
защита паролем для дистанционных программных изменений;
запрет неиспользуемых сервисов (FTP/TFTP, HTTP, DHCP и т.д.);
автоматическая
обеспечения;
проверка
целостности
встроенного
программного
возможность блокировки команд удалённой записи;
возможность блокировки команд удаленного чтения/изменения программы
контроллера;
проверка целостности исполняемых файлов программы управления;
любые события безопасности должны быть зафиксированы в базе данных
(системное логирование);
обмен данными со SCADA или Системой разработки программ должны
быть защищены протоколом IPSEC.
7.11.2.
Контроллеры, применяемые в АО "Мосводоканал" для реализации
систем контроля и управления опасными производственными объектами (ОПО) или
в составе систем противоаварийной защиты (ПАЗ) должны иметь сертификацию
в области надёжности и функциональной безопасности для использования
в приложениях уровня SIL 1 и SIL 2 либо пройти аналогичную сертификацию
по системе национальных стандартов Российской Федерации в соответствии с ГОСТ
Р МЭК 61508-1-2012 "Функциональная безопасность систем электрических,
электронных, программируемых электронных, связанных с безопасностью. Часть 1.
Общие требования"; ГОСТ Р МЭК 62061-2015 Безопасность оборудования.
Функциональная безопасность систем управления электрических, электронных и
программируемых электронных, связанных с безопасностью.
ТРЕБОВАНИЯ К РАЗДЕЛУ ТЕХНИЧЕСКИЕ СИСТЕМЫ
БЕЗОПАСНОСТИ И ТЕЛЕФОННАЯ СВЯЗЬ
Основополагающие нормативные документы для проектирования технических
систем безопасности и телефонной связи:
- ГОСТ Р 21.1101.2013.
- Постановление Правительства Российской Федерации №87 от 16.02.2008г. (ред. от
12.11.2016 с изм. от. 28.01.2017).
- ГОСТ Р МЭК 60065-2002.
- ГОСТ Р 50009-2000.
- ГОСТ Р 50776-95.
- ГОСТ 12.1.046-2014.
- Пособие к РД 78.145-93.
- РД 25.952-90.
- Р 78.36.002-2010.
- Р 78.36.005-2011.
- Р 78.36.032-2013.
- Р 78.36.032-2014.
- Р 78.36.039-2014.
- Приказ №937 МВД РФ от 16.11.2006г. (в ред. от 05.06.2007).
- Постановление Правительства Российской Федерации №272 от 25.03.2015г.
- ГОСТ Р 51558-2000.
Проектируемое оборудование должно быть согласовано с Управлением режима и
отделом слаботочных систем и телефонной связи управления АСУТПиС.
Общие технические требования для проектирования систем охранной и
преиметральной охранной сигнализации:
1.
Проектные работы выполняются в соответствии с требованиями ГОСТ
21.1101.2013, ГОСТ Р 50776-95, СНиП 11-01-95.
2.
Проектно-сметная документация должна содержать следующий
комплект документации:
- техническое задание на разработку проекта, выполненное в соответствии с
требованиями РД 25.952-90;
- пояснительную записку;
- общие данные;
- планы разводок (схемы закладных) трубопроводов, кабелей, проводов и мест
установки технических средств охраны на объекте (по требованию заказчика или
монтажной организации);
- планы разводок шлейфов сигнализации и линий связи технических средств охраны
(совмещенный или раздельный по каждому виду сигнализации);
- схему соединений структурную общую (совмещенная или раздельная по каждому
виду сигнализации);
- схемы электрические подключения технических средств охраны;
- схемы установки технических средств охраны в охраняемых помещениях;
- схемы блокировки отдельных конструкций (окон, дверей, воздуховодов, стен и
других конструкций);
- схему установки оборудования в помещении охраны,
- схему (таблицу) разводки электропитания;
- расчет постоянного тока потребления технических средств охраны в режиме
тревоги (выбор резервного источника питания);
- кабельный журнал (по требованию заказчика или монтажной организации);
- спецификацию оборудования;
- таблицу исходных данных дли программирования технических средств охраны;
- чертежи общих видов нетиповых решений, конструкций и оборудования.
3.
Технические средства охранной сигнализации периметра должны
выбираться в зависимости от вида предполагаемой угрозы объекту, помеховой
обстановки, рельефа местности, протяженности и технической укрепленности
периметра, типа ограждения, наличия дорог вдоль периметра, зоны отторжения, ее
ширины.
4.
Охранная сигнализация периметра объекта проектируется, как правило,
двух , либо, однорубежной. Для усиления охраны, определения направления
движения нарушителя, блокировки уязвимых мест следует применять
многорубежную охрану. При проектировании двух и более рубежной охраны
необходимо обеспечить наличие в системах охранной сигнализации средств
защиты, основанных на различных физических принципах действия.
5.
Технические средства охранной сигнализации периметра могут
размещаться на ограждении, зданиях, строениях, сооружениях или в зоне
отторжения. Охранные извещатели должны устанавливаться на стенах, специальных
столбах или стойках, обеспечивающих отсутствие колебаний, вибраций.
6.
Периметр, с входящими в него воротами и калитками, следует разделять
на отдельные охраняемые участки (зоны) с подключением их отдельными
шлейфами сигнализации к ППК малой емкости или к пульту внутренней охраны,
установленных на КПП или в специально выделенном помещении охраны объекта.
Длина участка определяется исходя из тактики охраны, технических характеристик
аппаратуры, конфигурации внешнего ограждения, условий прямой видимости и
рельефа местности, но не более 200 м для удобства технической эксплуатации и
оперативности реагирования. Следует выделять следующие основные зоны охраны:
Фронт, Тыл, Правый фланг, Левый фланг. Основные ворота должны выделяться в
самостоятельный участок периметра. Запасные ворота, калитки должны входить в
тот участок периметра, на котором они находятся.
7.
В качестве пультов внутренней охраны могут использоваться ППК
средней и большой емкости (концентраторы), СПИ, автоматизированные системы
передачи извещений (АСПИ) и радиосистемы передачи извещений (РСПИ). Пульты
внутренней охраны могут работать как при непосредственном круглосуточном
дежурстве персонала на них, так и автономно в режиме "Самоохраны".
8.
При использовании для блокировки периметра извещателей, требующих
зону отторжения, необходимо организовать ее следующим образом: Зона
отторжения должна быть тщательно спланирована и расчищена. В ней не должно
быть никаких строений и предметов, затрудняющих применение технических
средств охраны и действия службы безопасности. Зона отторжения может быть
использована для организации охраны объекта с помощью служебных собак. В этом
случае зона отторжения должна иметь предупредительное сетчатое или штакетное
ограждение высотой не менее 2,5 м. Ширина зоны отторжения, в которой
размещаются технические средства охраны периметра, должна превышать ширину
их зоны обнаружения.
9.
Установка охранных извещателей по верху ограждения должна
производиться только в случае, если ограждение имеет высоту не менее 2 м.
10. На КПП, в помещении охраны следует устанавливать технические
устройства графического отображения охраняемого периметра (компьютер,
световое табло с мнемосхемой охраняемого периметра и другие устройства.
11. Все оборудование, входящее в систему охранной сигнализации
периметра должно иметь защиту от вскрытия.
12. Открытые площадки с материальными ценностями на территории
объекта должны иметь предупредительное ограждение и оборудоваться объемными,
поверхностными или линейными извещателями различного принципа действия.
13. Техническими
средствами
охранной
сигнализации
должны
оборудоваться все помещения с постоянным или временным хранением
материальных ценностей, а также все уязвимые места здания (окна, двери, люки,
вентиляционные шахты, короба и т. п.), через которые возможно
несанкционированное проникновение в помещения объекта.
14. Объекты подгрупп AI, AII и БII оборудуются многорубежной системой
охранной сигнализации, объекты подгруппы БI – однорубежной (в соответствии с Р
78.36.032-2013).
15. Первым рубежом охранной сигнализации, в зависимости от вида
предполагаемых угроз объекту, блокируют:
- деревянные входные двери, погрузочно-разгрузочные люки, ворота - на
"открывание" и "разрушение" ("пролом");
- остекленные конструкции - на "открывание" и "разрушение" ("разбитие") стекла;
- металлические двери, ворота - на "открывание" и "разрушение",
- стены, перекрытия и перегородки, не удовлетворяющие требованиям настоящего
Руководящего документа или за которыми размещаются помещения других
собственников, позволяющие проводить скрытые работы по разрушению стены - на
"разрушение" ("пролом"),
- оболочки хранилищ ценностей - на "разрушение" ("пролом") и "ударное
воздействие";
- решетки, жалюзи и другие защитные конструкции, установленные с наружной
стороны оконного проема - на "открывание" и "разрушение";
- вентиляционные короба, дымоходы, места ввода/вывода коммуникаций сечением
более 200x200 мм - на "разрушение" ("пролом");
Вместо блокировки остекленных конструкций на "разрушение", стен, дверей и
ворот на "пролом" и "ударное воздействие", допускается, в обоснованных случаях,
производить блокировку указанных конструкций только на "проникновение" с
помощью объемных, поверхностных или линейных извещателей различного
принципа действия. При этом следует иметь в виду, что использование в данных
целях пассивных оптико-электронных извещателей обеспечивает защиту
помещений только от непосредственного проникновения нарушителя.
16. При невозможности блокировки входных дверей проемов (тамбуров)
техническими средствами раннего обнаружения, необходимо в дверном проеме
между основной и дополнительной дверью устанавливать охранные извещатели,
обнаруживающие проникновение нарушителя. Данные извещатели следует
включать в один шлейф охранной сигнализации блокировки дверей.
Для исключения возможных ложных срабатываний при взятии объекта под охрану
указанный шлейф сигнализации необходимо выводить на ППК, имеющий задержку
на взятие объекта под охрану.
17. Извещатели, блокирующие входные двери и неоткрываемые окна
помещений, следует включать в разные шлейфы сигнализации, для возможности
блокировки окон в дневное время при отключении охранной сигнализации дверей.
Извещатели, блокирующие входные двери и открываемые окна допускается
включало в один шлейф сигнализации.
18. Вторым рубежом охранной сигнализации защищаются объемы
помещений на "проникновение" с помощью объемных извещателей различного
принципа действия.
19. В помещениях больших размеров со сложной конфигурацией,
требующих применение большого количества извещателей для защиты всего
объема, допускается блокировать только локальные зоны (тамбуры между дверьми,
коридоры, подходы к ценностям и другие уязвимые места).
20. Третьим рубежом охранной сигнализации в помещениях блокируются
отдельные предметы, сейфы, металлические шкафы, в которых сосредоточены
ценности.
21. Устанавливаемые в зданиях технические средства охраны должны
вписываться в интерьер помещения и по возможности устанавливаться скрыто или
маскироваться.
22. В разных рубежах необходимо применять охранные извещатели,
работающие на различных физических принципах действия.
23. Количество шлейфов охранной сигнализации должно определяться
тактикой охраны, размерами зданий, строений, сооружений, этажностью,
количеством уязвимых мест, а также точностью локализации места проникновения
для оперативного реагирования на сигналы тревоги.
24. Периметр охраняемого здания, как правило, следует разделять на
охраняемые зоны (фасад, тыл, боковые стороны здания, центральный вход и другие
участки) с выделением их в самостоятельные шлейфы сигнализации и выдачей
раздельных сигналов на ППК или внутренний пульт охраны объекта.
25. Для усиления охраны и повышения ее надежности на объектах следует
устанавливать дополнительные извещатели - ловушки. Сигналы ловушек выводятся
по самостоятельным или, при отсутствии технической возможности, по имеющимся
шлейфам охранной сигнализации.
26. Каждое помещение подгрупп AI и AII (в соответствии с Р 78.36.0322013) должно оборудоваться самостоятельными шлейфами охранной сигнализации.
Помещения подгрупп БI и БII (в соответствии с Р 78.36.032-2013), закрепленные за
одним материально ответственным лицом, собственником или объединяемые по
каким-либо другим признакам также должны оборудоваться самостоятельными
шлейфами охранной сигнализации, причем, для удобства эксплуатации, одним
шлейфом следует блокировать не более пяти соседних помещений, расположенных
на одном этаже.
27. В помещениях, где круглосуточно должен находиться персонал,
охранной сигнализацией должны оборудоваться отдельные участки периметра
помещения, а также сейфы и металлические шкафы для хранения ценностей и
документов.
28. Пропуск сотрудников и посетителей на объект через пункты контроля
доступа следует осуществлять:
- в здание и в служебные помещения - по одному признаку;
- входы в зоны ограниченного доступа (хранилища ценностей, сейфовые комнаты,
комнаты хранения оружия) - не менее чем по двум признакам идентификации.
Общие технические требования для проектирования автоматизированной
системы контроля доступа:
1.
АСКД должна обеспечивать выполнение следующих основных
функций:
- открывание УПУ (устройств преграждающих управляемых) при считывании
идентификационного признака, доступ по которому разрешен в данную зону
доступа (помещение) в заданный временной интервал или по команде оператора
АСКД;
- запрет открывания УПУ (устройств преграждающих управляемых) при
считывании идентификационного признака, доступ по которому не разрешен в
данную зону доступа (помещение) в заданный временной интервал;
- санкционированное изменение (добавление, удаление) идентификационных
признаков в УУ (устройств управления) и связь их с зонами доступа (помещениями)
и временными интервалами доступа;
- защиту от несанкционированного доступа к программным средствам УУ
(устройств управления) для изменения (добавления, удаления) идентификационных
признаков;
- защиту технических и программных средств от несанкционированного доступа к
элементам управления, установки режимов и к информации;
- сохранение настроек и базы данных идентификационных признаков при
отключении электропитания;
- ручное, полуавтоматическое или автоматическое открывание УПУ (устройств
преграждающих управляемых) для прохода при аварийных ситуациях, пожаре,
технических неисправностях в соответствии с правилами установленного режима и
правилами противопожарной безопасности;
- автоматическое закрытие УПУ (устройств преграждающих управляемых) при
отсутствии факта прохода через определенное время после считывания
разрешенного идентификационного признака;
- выдачу сигнала тревоги (или блокировку УПУ (устройств преграждающих
управляемых) на определенное время) при попытках подбора идентификационных
признаков (кода);
- регистрацию и протоколирование текущих и тревожных событий;
- автономную работу считывателя с УПУ (устройств преграждающих управляемых)
в каждой точке доступа при отказе связи с УУ (устройств управления).
2.
На объектах, где необходим контроль сохранности предметов, следует
устанавливать АСКД, контролирующих несанкционированный вынос данных
предметов из охраняемых помещений или зданий по специальным
идентификационным меткам.
3.
УПУ (устройств преграждающих управляемых) с устройствами
исполнительными должно обеспечивать:
- частичное или полное перекрытие проема прохода;
- автоматическое и ручное (в аварийных ситуациях) открывание;
- блокирование человека внутри УПУ (для шлюзов, проходных кабин);
- требуемую пропускную способность.
4.
Считыватели УВИП (устройств ввода идентификационных признаков)
должно обеспечивать:
- считывание идентификационного признака с идентификаторов;
- сравнение введенного идентификационного признака с хранящимся в памяти или
базе данных УУ;
- формирование сигнала на открывание УПУ при идентификации пользователя;
- обмен информацией с УУ.
УВИП должны быть защищены от манипулирования путем перебора или подбора
идентификационных признаков.
Идентификаторы УВИП должны обеспечить хранение идентификационного
признака в течении:
- всего срока эксплуатации - для идентификаторов без встроенных элементов
электропитания;
- не менее 3 лет - для идентификаторов со встроенными элементами
электропитания.
Конструкция, внешний вид и надписи на идентификаторе и считывателе не должны
приводить к раскрытию применяемых кодов.
5.
УУ (устройств управления) должно обеспечивать:
- прием информации от УВИП, ее обработку, отображение в заданном виде и
выработку сигналов управления УПУ;
- ведение баз данных сотрудников и посетителей объекта с возможностью задания
характеристик их доступа (кода, временного интервала доступа, уровня доступа и
другие);
- ведение электронного журнала регистрации проходов сотрудников и посетителей
через точки доступа;
- приоритетный вывод информации о тревожных ситуациях в точках доступа;
- контроль исправности и состояния УПУ, УВИП и линий связи с ними.
6.
Конструктивно АСКД должны строиться по модульному принципу и
обеспечивать:
- взаимозаменяемость сменных однотипных технических средств;
- удобство технического обслуживания и эксплуатации, а также
ремонтопригодность;
- исключение возможности несанкционированного доступа к элементам управления;
- санкционированный доступ ко всем элементам, узлам и блокам, требующим
регулирования, обслуживания или замены в процессе эксплуатации.
Общие технические требования для проектирования систем охранной
телевидения и видеонаблюдения.
1.
Системы охранного телевидения и видеонаблюдения (далее системы
видеонаблюдения) должны обеспечивать передачу визуальной информации о
состоянии охраняемых зон, помещений, периметра и территории объекта в
помещение охраны. Применение охранного телевидения позволяет в случае
получения извещения о тревоге определить характер нарушения, место нарушения,
направление движения нарушителя и определить оптимальные меры
противодействия. Кроме того, система охранного телевидения позволяет проводить
наблюдение охраняемых зон объекта.
2.
В охране объектов должны использоваться системы цветного
изображения.
3.
В системах видеонаблюдения должно использоваться оборудование,
приоритетно, российского производства.
4.
Работа аппаратных средств систем видеонаблюдения должна быть
синхронизирована.
5.
Видеокамеры (в дальнейшем ВК), предназначенные для контроля
территории объекта или ее периметра, должны иметь класс защиты не менее IP-65 и
должны быть ориентированы на местности под углом к линии горизонта (лучи
восходящего и заходящего солнца не должны попадать в объектив ВК). Размещение
ВК должно препятствовать их умышленному повреждению.
6.
В темное время суток, если освещенность охраняемой зоны ниже
чувствительности ВК, объект (зона объекта) должен иметь встроенные источники
или оборудоваться дополнительнвми источниками охранного освещения видимого
или инфракрасного диапазона. Зоны охранного освещения должны совпадать с
зоной обзора ТК.
7.
Для наблюдения с помощью одной ВК больших территорий объекта
рекомендуется применять объективы с переменным фокусным расстоянием либо ВК
с поворотными устройствами с дистанционным управлением.
8.
В помещениях объекта следует использовать ВК с электронным
затвором, укомплектованные объективом с ручной регулировкой диафрагмы.
Вне помещений объекта (на улице) следует применять ТК с автоматической
регулировкой диафрагмы объектива.
9.
В системах видеонаблюдения следует использовать обнаружители
движения, либо интегрировать данные системы с системами охранной сигнализации
таким образом, чтобы выджаваемый сигнал системой видеонаблюдения
дублировался в систему охранной сигнализации и наоборот.
10. При необходимости записи телевизионных изображений должны
применяться специализированные цифровые видеонакопители с объемом памяти,
позволяющем вести круглосуточную запись видеоинформации как по детектору
движения, так и в режиме реального времени, не менее 30 суток, с последующей
перезаписью.
11. Время реагирования систем видеонаблюдения на сигнал извещения о
тревоге должно быть не более времени, достаточного на преодоление нарушителем,
двигающимся со скоростью 3 м/с, половины зоны наблюдения ВК по ширине, в
любом месте зоны.
12. Устройства управления и коммутации должны обеспечивать
приоритетнее автоматическое отображение на экране мониторов зон, откуда
поступило извещение о тревоге.
13. Конструктивно системы видеонаблюдения должны строиться по
модульному принципу и обеспечивать:
- взаимозаменяемость сменных однотипных технических средств;
- удобство технического обслуживания и эксплуатации, а также
ремонтопригодность;
- исключение несанкционированного доступа к элементам управления;
- санкционированный доступ ко всем элементам, узлам и блокам, требующим
регулирования, обслуживания или замены в процессе эксплуатации.
Общие технические требования для проектирования систем тревожного
оповещения.
1.
Оповещение людей, находящихся на объекте, должно осуществляться с
помощью технических средств, которые должны обеспечивать:
- подачу звуковых и/или световых сигналов в здания и помещения, на участки
территории объекта с постоянным или временным пребыванием людей;
- трансляцию речевой информации о характере опасности, необходимости и путях
эвакуации, других действиях, направленных на обеспечение безопасности
2.
Эвакуация людей по сигналам оповещения должна сопровождаться:
- включением аварийного освещения;
- передачей специально разработанных текстов, направленных на предотвращение
паники и других явлений, усложняющих процесс эвакуации (скопление людей в
проходах, тамбурах, на лестничных клетках и другие местах);
- включением световых указателей направления и путей эвакуации;
- дистанционным открыванием дверей дополнительных эвакуационных выходов
(например, оборудованных электромагнитными замками).
3.
Сигналы оповещения должны отличаться от сигналов другого
назначения.
Количество оповещателей, их мощность должны обеспечивать необходимую
слышимость во всех местах постоянного или временного пребывания людей.
4.
На
охраняемой
территории
следует
применять
рупорные
громкоговорители. Они могут устанавливаться на опорах освещения, стенах зданий
и
других
конструкциях.
Правильность расстановки и количество громкоговорителей на территории
определяется расчетом и уточняется на месте экспериментальным путем на
разборчивость передаваемых речевых сообщений, но не менее одного 10-ваттного
громкоговорителя на каждый участок территории.
5.
Коммуникации систем оповещения в отдельных случаях допускается
проектировать совмещенными с радиотрансляционной сетью объекта.
6.
Управление системой оповещения должно осуществляться из
помещения охраны, диспетчерской или другого специального помещения.
Общие технические требования для проектирования систем охранного
освещения.
1.
Периметр территории, здания охраняемого объекта должен быть
оборудован системой охранного освещения согласно ГОСТ 12.1.046-2014.
2.
Охранное освещение должно обеспечивать необходимые условия
видимости ограждения территории, периметра здания, зоны отторжения, тропы
наряда (путей обхода).
3.
Система охранного освещения должна обеспечивать:
- освещенность горизонтальную на уровне земли или вертикальную на плоскости
ограждения, стены не менее 0,5 лк в темное время суток;
- равномерно освещенную сплошную полосу шириной 3-4 м;
- возможность автоматического включения дополнительных источников света на
отдельном участке (зоне) охраняемой территории (периметра) при срабатывании
охранной сигнализации;
- ручное управление работой освещения из помещения КПП, помещения охраны,
- совместимость с техническими средствами охранной сигнализации и охранного
телевидения;
- непрерывность работы на КПП, в помещении и на постах охраны.
4.
Сеть охранного освещения по периметру объекта и на территории
должна выполняться отдельно от сети наружного освещения и разделяться на
самостоятельные участки в соответствии с участками охранной сигнализации
периметра и/или охранного телевидения. Сеть охранного освещения должна
подключаться к отдельной группе щита освещения, расположенного в помещении
охраны или на КПП. Допускается установка щита освещения на внешней стене КПП
со стороны охраняемой территории. Щит освещения должен быть закрыт на
висячий (навесной) замок и заблокирован охранной сигнализацией.
5.
Осветительные приборы охранного освещения могут быть любого типа:
подвесные, консольные, прожектора и другие типы. В качестве источника света
рекомендуется использовать лампы накаливания, либо энергосберегающие
светодиодные прожекторы, напряжением 220 В.
6.
Светильники охранного освещения по периметру территории должны
устанавливаться не выше ограждения. Магистральные и распределительные сети
охранного освещения территории объекта должны прокладываться, как правило,
под землей или по ограждению в трубах. При невозможности выполнить данные
требования воздушные сети охранного освещения должны располагаться
достаточно глубоко на территории объекта, чтобы исключить возможность
повреждения их из-за ограждения.
7.
В ночное время охранное освещение должно постоянно работать.
Дополнительное охранное освещение должно включаться только при нарушении
охраняемых участков в ночное время, а при плохой видимости и в дневное.
8.
Лампы охранного освещения должны быть защищены от механических
повреждений.
Общие технические требования для проектирования систем электропитания
технических средств безопасности.
1.
Установленные на объекте технические средства охраны следует
относить к 1 категории электроприемников по надежности электроснабжения
согласно ПУЭ, в силу чего их электропитание должно быть бесперебойным (либо от
двух независимых источников переменного тока, либо от одного источника
переменного тока с автоматическим переключением в аварийном режиме на
резервное питание от аккумуляторных батарей).
2.
Рабочий ввод электропитания, как правило, должен выполняться от
электрической сети переменного тока напряжением 220 В.
3.
Резервный ввод электропитания должен выполняться от одного из
следующих источников питания или их любых сочетаний:
- электрической сети переменного тока напряжением 220 В;
- аккумуляторных батарей бесперебойных источников электропитания.
4.
Электроснабжение технических средств охраны от электрической сети
переменного тока осуществляется от отдельной группы электрощита дежурного
освещения.
При отсутствии на объекте электрощита дежурного освещения или отдельной
группы на нем, необходимо запроектировать самостоятельный электрощит на
соответствующее количество групп. Помещение, в котором размещены
электрощиты,
необходимо
оборудовать
охранной
сигнализацией.
Вне охраняемого помещения электрощиты следует размещать в запираемых
металлических шкафах, заблокированных охранной сигнализацией.
5.
При использовании в качестве резервного источника питания
аккумуляторных батарей источников бесперебойного электропитания, должна
обеспечиваться работа систем охранной сигнализации, систем тревожного
оповещения и автоматизированных систем контроля доступа в течение не менее 24
часов в дежурном режиме и в течение не менее 3 часов в режиме тревоги. Для
систем охранного телевидения и видеонаблюдения - в течение не менее 4 часов в
дежурном режиме и в течение не менее 1 часа в режиме тревоги, учитывая тот факт,
что в режиме тревоги электропитание систем охранного телевидения и
видеонаблюдения должно обеспечивать запись изображения от всех технических
средств на цифровые носители в режиме реального времени.
6.
Переход технических средств охраны на работу от резервного источника
электропитания и обратно должен осуществляться автоматически без выдачи
сигналов тревоги.
7.
Линии электропитания, проходящие через незащищаемые охранной
сигнализацией помещения, должны быть выполнены скрытым способом или
открытым способом в трубах, коробах или металлорукавах.
8.
Линии электропитания технических средств охраны периметра следует
выполнять:
- кабелями в траншее, в подземном коллекторе или открыто по внутренней стороне
бетонного ограждения (стене здания) бронированными кабелями. В обоснованных
случаях допускается прокладка небронированных кабелей (проводов) по внутренней
стороне бетонного ограждения (стене здания) в стальных трубах и ПНД трубах с
толщиной
стенки
не
менее
2мм;
- подвеской кабелей на тросе на высоте не менее 3 м или на отдельных участках в
охраняемой зоне, при условии защиты кабеля от механических повреждений до
высоты 2,5 м.
9.
Соединительные или ответвительные коробки должны устанавливаться
в охраняемых помещениях (зонах), и иметь класс защищенности не менее IP-54.
10. Защитное заземление или зануление технических средств охраны,
соединительных и ответвительных коробок и других элементов должно
соответствовать требованиям ПУЭ, СНиП 3.05.06-85, РД 78.145-93 (пособия к нему)
и технической документации на изделия.
Общие технические требования для проектирования ip телефонии.
При проектировании ip телефонии согласовать применяемое оборудование
с отделом слаботочных систем и телефонной связи Управления АСУТПиС.
2. IP-АТС должна отвечать следующим требованиям:
- Поддерживать не менее 25 одновременных вызовов;
- Иметь аналоговые порты FXO;
- Поддерживать порты
FXO/FXS при установке дополнительных
модулей;
- Поддерживать до GSM-порты (Quad-Band GSM/GPRS850/900/1800/1900
MHz) при установке дополнительных модулей;
- Поддерживать UMTS-порты (UMTS 900/2100МГц или 850/2100МГц или
850/1900МГц) при установке дополнительных модулей;
- Поддерживать BRI-порты при установке дополнительных модулей;
3.
Иметь следующие функции:
1.
-
-
Запись всех телефонных разговоров с возможностью хранения записей
на внешнем жестком диске с последующим их копированием в сетевую
папку файлового сервера;
Оповещение абонента о записи телефонного разговора;
Запись голосовой почты с возможностью хранения до 3000 минут
голосовых сообщений на встроенной флеш-памяти;
Трансфер вызова;
Переадресация вызова;
Парковка вызова;
Захват вызова;
Групповой вызов;
Маршрутизация вызова;
Режим ожидания;
Оповещение (Paging Call);
Интерком;
Конференц-комнаты;
Режим не беспокоить (DND);
Очередь;
Интерактивный голосовой автоответчик (IVR) с гибкой конфигурацией;
Музыка в режиме ожидания (Music On Hold);
Быстрый набор;
Система внешнего доступа к линиям АТС (DISA - Direct Inward System
Access);
Личный кабинет пользователя;
Отображение статуса абонента (BLF);
Autoprovision;
Доступ к линиям по PIN-коду;
Привязка мобильного номера к внутреннему номеру абонента;
Записная книга;
Черный список;
Детализация звонков (CDR);
SIP SMS;
Функция вмешательства (прослушивание, подсказка, вмешательство);
Поддержка видео.
Поддерживать не менее 64 внешних SIP-регистраций;
Поддерживать не менее 64 транков;
Поддерживать не менее 32 меню IVR;
Поддерживать не менее 128 входящих/исходящих маршрутов;
Поддерживать не менее 16 групп обзвона;
Поддерживать не менее 16 очередей;
Поддерживать VoIP-протоколы SIP 2.0 (RFC3261) и IAX2;
Поддерживать транспортные протоколы UDP, TCP, TLS;
Поддерживать аудиокодеки G.711, GSM, SPEEX, G.722, G.726, ADPCM,
G.729A;
Поддерживать видеокодеки H261, H263, H263p, H264, MPEG4;
Поддерживать стандарты факсимильной связи Т.30, Т.37, Т.38, G.711
Passthrough;
Поддерживать режимы DTMF Inband, RFC2833, SIP INFO;
-
-
Поддерживать следующие режимы работы с вычислительной сетью:
Статический IP;
Динамический IP;
PPPoE.
Иметь встроенный межсетевой экран;
Иметь встроенный DHCP-сервер;
Поддерживать функционал VLAN, DDNS, QoS;
Иметь полностью русифицированный web-интерфейс управления;
Иметь не менее 1 порта LAN 10/100/1000 Мб/с;
Иметь не менее 1 порта WAN 10/100/1000 Мб/с;
Иметь не менее 1 порта USB 2.0;
Иметь не менее 1 порта audio in;
Иметь не менее 1 порта audio out;
Иметь форм-фактор для монтажа в серверную стойку шириной 19
дюймов;
Иметь высоту не более 1U;
Иметь энергопотребление не более 60 Вт;
Иметь сертификат соответствия требованиям нормативных документов
ГОСТ Р МЭК 60950-1-2009, ГОСТ Р 51318.22-99, ГОСТ Р 51318.24-99,
ГОСТ Р 51317.3.2-2006 Разд. 6 и 7, ГОСТ Р 51317.3.3-2008;
Иметь декларацию о соответствии требованиям ТР ТС 004/2011 и ТР ТС
020/2011;
ТРЕБОВАНИЯ К РАЗДЕЛУ СЕТИ СВЯЗИ
1.Общие положения
Для связи внутри объектов или между объектами, расположенными на территории
подразделений АО "Мосводоканал" применяются локальные вычислительные сети
(ЛВС). Для связи между территориально распределенными подразделениями и
технологическими объектами АО "Мосводоканал" используется услуга организации
защищенной сети предприятия и передачи данных по каналам L2/L3 VPN,
предоставляемая провайдерами (операторами связи).
Провайдер, предоставляющий услуги передачи данных обеспечивает:
гарантированную полосу пропускания;
гарантированное качество обслуживания отдельных категорий сетевого
трафика (QoS);
уровень обслуживания согласно заявленным требованиям;
дублирование и автоматизированное резервирование каналов связи,
исключающее совпадение трасс каналов вплоть до входа в здание;
поддержку MPLS L3 VPN.
Предоставляемые операторами каналы связи должны иметь Аттестат
соответствия требованиям по безопасности информации по классу защищенности
1«Г» в части защиты от НСД к информации.
Операторы обязаны иметь точки присутствия на площадках РЦОД ОБщества
и обеспечивать связь данных объектов с точкой обмена интернет-трафиком MSKIX.
ЛВС территориально распределенных подразделений и технологических
объектов реализуется на собственном оборудовании АО "Мосводоканал".
Все проектируемые локальные вычислительные сети объектов Общества
должны иметь резерв по количеству возможных подключений к ним и по
пропускной способности не менее 20%.
Все технические решения по архитектуре, применяемому оборудованию и
материалам должны быть согласованы с УАСУТПиС АО"Мосводоканал".
2.Внутренние сети объектов
При проектировании создания или модернизации локальных вычислительных
сетей объектов Общества (производственных и структурных подразделений)
необходимо решать вопросы создания структурированной кабельной сети и
обеспечения
необходимым
активным
сетевым
(телекоммуникационным)
оборудованием (АСО).
Архитектура сети должна представлять собой иерархическую звезду,
состоящую из набора медных кабелей неэкранированная витая пара UTP,
коммутационных патч-панелей, патч-кордов, телекоммуникационных розеток и
вспомогательного оборудования.
Пропускная способность сети должна позволять использовать ее для
поддержки работы всех основных приложений, а также предоставлять возможность
гибкого изменения конфигурации кабельной сети. Все компоненты компьютерной
сети должны иметь характеристики передачи, соответствующие требованиям
категории 5е.
Узлами
архитектуры
должны
являтья
19-дюймовый
шкафы,
функциональными элементами которых является активное коммутационное
оборудование. Расположение узлов архитектуры обеспечивает физическую длину
канала горизонтальной подсистемы, не превышающей 100 м.
В соответствии со стандартом ISO/IRC 11801 на каждом рабочем месте
должно быть предусмотрено не менее двух телекоммуникационных розеток RJ-45.
Телекоммуникационные информационные розетки должны соответстввовать
стандарту разъема RJ-45.
2.1.Структурированная кабельная система (СКС).
СКС должна состоять из:
Горизонтальной подсистемы;
Подсистемы коммутации;
Подсистемы рабочих мест (конечных подключений).
Горизонтальная подсистема предназначена для связи Подсистемы коммутации
с Подсистемой рабочих мест. При этом в качестве физической среды передачи
данных используется:
между зданиями, находящимися на территории АО "Мосводоканал" –
одномодовые оптические каналы связи не менее, чем с восьмью
волокнами;
между зданиями в сложных условиях рельефа, при расстоянии более 8
км или при необходимости прокладывания каналов связи по территории,
не принадлежащей АО "Мосводоканал" – радиорелейная связь;
внутри зданий – витая пара категории не ниже 5e для подключения
пользователей и серверов; оптические каналы могут применяться для
межкоммутаторных соединений в зависимости от расстояния и условий
эксплуатации.
Максимальная длина кабельных трасс горизонтальной подсистемы не должна
превышать требований стандартов. Полоса пропускания должна обеспечить
передачу данных со скоростью 1000 Мбит/с.
Подсистема коммутации обеспечивает: соединение кабельной системы с
коммутационными панелями, а также коммутацию кроссового поля кабельной
системы. Подсистема коммутации состоит из телекоммуникационного
оборудования, 19- дюймовых патч-панелей, патч-кордов.
Подсистема рабочих мест (конечных подключений) служит для подключения
оконечных устройств (компьютеров и другого сетевого оборудования). Подсистема
рабочих мест должна состоять из комплектов монтажа розеток RJ-45 cat.5e.
2.2.Телекоммуникационное оборудование
Согласно принципам построения отказоустойчивых систем внутриобъектовой
коммутации, требуется блок устройств и соединений, обеспечивающий
сбалансированное и отказоустойчивое прохождение трафика между всеми
пользователями вычислительных сетей, серверами, вспомогательными системами (
такими как IP-телефоны, IP-камеры видеонаблюдения, терминалы ВКС и т.д.).
Активное сетевое (телекоммуникационное) оборудование должно обеспечить
реализацию и взаимодействие со следующими существующими логическими
подсетями:
пользовательская;
серверная;
АСУТП;
IP-телефония;
СКУД и СВН;
ВКС.
В качестве типового оборудования для построения подсистемы коммутации и
маршрутизации используется следующее оборудование:
Коммутаторы ядра – два коммутатора Cisco 2960-X, объединяемых в
стек для обеспечения отказоустойчивого подключения коммутаторов
доступа и серверного оборудования;
Коммутаторы доступа – Cisco 2960+ с 24 или 48 портами 10/100 Мбит/c.
Для подключения IP телефонов и другого оборудования, работающего
по стандарту 802.3af, используются модели с поддержкой PoE и
функционалом LAN Base. Для подключения рабочих мест
пользователей используются модели с функционалом LAN Lite.
Пограничные
коммутаторы
обеспечивают
отказоустойчивое
взаимодействие
между
пограничными
маршрутизаторами
и
межсетевыми экранами. Оборудование операторов связи также
подключается к данным коммутаторам. В качестве пограничных
коммутаторов используются коммутаторы Cisco 2960 с функционалом
LAN Lite.
Межсетевые экраны Cisco ASA 5505 объединяются в отказоустойчивый
кластер (failover) по принципам Active/Standby.
Оборудование СКС и телекоммутационное оборудование должно размещаться
в напольном 19-дюймовом шкафу, размещаемом в специализированном серверном
помещении.
Защитное заземление (зануление) кабельных каналов и оборудования должно
быть выполнено в соответствии с требованиями ПУЭ, СНиП 3.05.06-85, ГОСТ
12.1.030-81, технической документацией предприятий-изготовителей на данное
оборудование.
3.Подключение объектов к корпоративной вычислительной сети (КВС)
Корпоративная вычислительная сеть обеспечивает информационный обмен
между
компонентами
ИТ-инфраструктуры,
автоматизированными
информационными системами и пользователями Общества. КВС предназначена для
организации единого информационного пространства для обеспечения бизнес- и
технологических
процессов
компании.
КВС
обеспечивает:
гибкость,
мультисервисность, отказоустойчивость и расширяемость для сервисов,
работающих по протоколу IPv4 (в перспективе и IPv6)
В зависимости от типа и роли объекта выбирается способ подключения его к
КВС.
К объектам первого типа АО "Мосводоканал" относятся крупные
производственные подразделения: водопроводные станции (РСВ, ЗСВ, ВСВ, ССВ),
очистные сооружения (КОС, ЛОС), отдельные производственные управления (ЗВК,
ТиНАО), районы водопроводной (РЭВС) и канализационной (РКС) сети. Такие
объекты должны быть подключены к КВС по волоконно-оптическим линиям связи
(ВОЛС) на скорости не менее 100 Мбит/с со 100% "горячим" резервированием.
К объектам первого типа АО "Мосводоканал" относятся регулирующие
водопроводные узлы, высоковольтные насосные станции и ряд других объектов
находящихся в режиме автоматического управления и контроля, оснащенных
местными диспетчерскими пунктами управления. Такие объекты должны быть
подключены к КВС по волоконно-оптическим линиям связи (ВОЛС) на скорости не
менее 30 Мбит/с (определяется фактической информационной мощностью объекта и
оснащенностью различными автоматизированными системами) со 100% "горячим"
резервированием, допускающим резервирование по беспроводным (сотовым)
каналам связи.
К объектам третьего типа относятся все автономные небольшие
производственные объекты и точки контроля без диспетчерского или дежурного
персонала (канализационные станции, водозаборные узлы, отдельные скважины,
регулирующие камеры, точки контроля параметров городской водопроводной и
канализационной сети и т.п.). Для таких объектов приоритетным является
подключение к КВС по волоконно-оптическим линиям связи (ВОЛС) на скорости не
менее 2 Мбит/с (определяется фактической информационной мощностью объекта и
оснащенностью различными автоматизированными системами) со 100% "горячим"
резервированием по беспроводным (сотовым) каналам связи. Допускается
применение также основного беспроводного (сотового) канала связи.
4.Создание серверных помещений
Требования составлены на основании следующих документов:
3.1. ГОСТ 2.051-2013 "Единая система конструкторской документации.
Электронные документы. Общие положения" (введен в действие приказом
Федерального агентства по техническому регулированию и метрологии от 22 ноября
2013 г. N 1628-ст).
3.2. ГОСТ 34.003-90 Информационная технология. Комплекс стандартов
на автоматизированные системы. Автоматизированные системы. Термины
и определения.
3.3. ГОСТ 34.201-89 Комплекс стандартов на автоматизированные системы.
Виды комплексность и обозначение документов при создании автоматизированных
систем.
3.4. ГОСТ 34.601-90 Информационная технология. Комплекс стандартов
на автоматизированные системы. Автоматизированные системы. Стадии создания.
3.5. ГОСТ 34.602-89 Информационная технология Комплекс стандартов
на автоматизированные
системы.
Техническое
задание
на
создание
автоматизированной системы.
3.6. ГОСТ 34.603-92 Информационная
автоматизированных систем.
технология.
Виды
испытаний
3.7. Национальный стандарт РФ ГОСТ Р 50839-2000 "Совместимость
технических средств электромагнитная. Устойчивость средств вычислительной
техники и информатики к электромагнитным помехам. Требования и методы
испытаний" (введен в действие постановлением Государственного комитета РФ
по стандартизации и метрологии от 26 декабря 2000 г. N 416-ст).
3.8. СНиП 21-01-97 "Пожарная безопасность зданий и сооружений" Госстроя
России.
3.9. Изменение N 2 СН 512-78 "Инструкция по проектированию зданий
и помещений для электронно-вычислительных машин" (принято постановлением
Госстроя РФ от 24 февраля 2000 г. N 17).
3.10. Инструкция по устройству молниезащиты зданий и сооружений
РД 34.21.122-87 (утв. Главтехуправлением Минэнерго СССР 12 октября 1987 г.).
3.11. EIA/ TIA-568B - стандарт по проводке в коммерческих зданиях,
определяет кабельную систему, которая поддерживает активное оборудование
от различных производителей.
3.12. EIA/TIA-569 – Требования к серверному помещению.
3.13. Требования по электроснабжению, электротехническим устройствам
и заземлению средств автоматизации технологических процессов и слаботочных
систем.
3.14. СН 512-78 "Инструкция по проектированию зданий и помещений для
электронно-вычислительных машин"
3.15. СП 4.13130.2013 "Свод правил. Системы противопожарной защиты.
Ограничение распространения пожара на объектах защиты"
3.16. СП 5.13130.2009 "Свод правил. Системы противопожарной защиты.
Установки пожарной сигнализации и пожаротушения автоматические нормы
и правила проектирования"
3.17. Правила противопожарного режима в Российской Федерации.
3.18. СП 3.13130.2009 "Свод правил. Системы противопожарной защиты.
Система оповещения и управления эвакуацией людей при пожаре. Требования
пожарной безопасности"
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СЕРВЕРНОМУ ПОМЕЩЕНИЮ
4.1. Выбор серверного помещения
4.1.1. Серверное помещение рекомендуется размещать как можно ближе
к магистральным кабельным каналам. Желательно расположить серверное
помещение рядом с главным распределительным пунктом (Main Cross, MC), а если
есть возможность, то установить главный распределительный пункт в серверном
помещении. Не допускается размещение серверного помещение рядом с лифтовыми
шахтами, лестничными пролетами, вентиляционными камерами и другими
элементами здания, которые могут ограничить расширение аппаратного помещения
в будущем.
4.1.2. Серверное помещение рекомендуется размещать так, чтобы была
возможность расширения серверного помещения за счет площади смежного
помещения.
4.1.3. Размер серверного помещения выбирается исходя из размера
обслуживаемой рабочей области и количества устанавливаемого оборудования.
Важно учесть не только размеры самого оборудования, но и способы монтажа,
обеспечения доступа и обслуживания оборудования, возможность установки
дополнительных устройств. Высота серверного помещения должна быть не менее
2,5 метра. Минимально рекомендуемый размер серверной должен быть не менее
14 м2.
4.1.4. Несущие конструкции здания в помещении серверной, где планируется
размещение оборудования, должны выдерживать расчетную нагрузку, включающую
вес компьютерного и телекоммуникационного оборудования, обслуживающего
персонала, оборудования систем инфраструктуры.
4.2. Требования к отделке серверного помещения
Стены, потолок, и пол должны иметь покрытие, которое затрудняет
выделение, оседание и накапливание пыли на поверхности. Потолок должен иметь
гидроизоляцию, чтобы исключить протечку воды. Стены должны быть окрашены
светлой краской.
Допускается использование подвесных потолков для возможности
размещения над подвесным потолком воздуховодов и воздухораспределителей,
аппаратуры потолочных люминесцентных светильников, установок газового
пожаротушения.
В серверном помещении запрещается использование ковровых покрытий.
4.3. Требования к фальшполу
4.3.1. Наличие фальшпола и использования прецизионных кондиционеров
в серверной обоснованно при суммарной тепловой нагрузке от технологического
оборудования не менее 10 кВт (4 стойки).
4.3.2. Просвет между фальшполом и потолком должен быть не менее 2,5 м.
4.3.3. Расстояние между строительным полом и фальшполом должно быть
не менее 200 мм (рекомендуемое 400 мм).
4.3.4. Крутизна устанавливаемого на входе в серверную пандуса не должна
превышать значение 1:10.
4.3.5. Конструкция фальшпола должна выдерживать расчетные нагрузки
и состоять из легко съемных модулей (плиток). При этом необходимо учитывать то,
что отдельные устройства вычислительной системы могут создавать точечную
нагрузку на пол до 455 кг.
6.3.6. Материал покрытия фальшпола должен иметь электрическое
сопротивление относительно земли от 1,0 МОм (минимум) до 20 МОм (максимум)
при изменениях относительной влажности от 20 до 60% и температуры от +18
до +24°С, а также обладать повышенной износостойкостью,
возгораемостью, повышенной стойкостью к царапанью и выкрашиванию.
плохой
4.3.7. Поверхности
под
фальшполом
должна
окрашиваться
или герметизироваться для предотвращения отслаивания и пыления штукатурки
или бетона перекрытия.
4.3.8. В строительном перекрытии под фальшполом обязательно необходимо
сделать дренаж для оттока воды в случае аварийного протекания.
4.3.9. Конструкция съемного пола должна обеспечивать:
свободный доступ к коммуникациям при обслуживании;
устойчивость к горизонтальным усилиям при частично снятых плитах;
возможность выравнивания поверхностей пола с помощью регулируемых
опорных элементов;
взаимозаменяемость плит съемного пола.
4.3.10. Конструкция съемного пола должна быть рассчитана на равномерно
распределенную
нормативную
нагрузку
1000 кг/м2
и сосредоточенную
нормативную нагрузку 250 кг, приложенную в любом месте плиты на площади
25 см2. Прогиб плиты не должен превышать 1 мм.
4.3.11. Плиты съемного пола в собранном состоянии должны плотно
прилегать друг к другу, обеспечивая герметичность в стыках.
4.3.12. Плиты съемного пола должны быть трудносгораемыми, с пределом
огнестойкости не менее 0,5 ч, или несгораемыми. Опоры и стойки съемных полов
должны быть несгораемыми. Покрытие плит пола допускается предусматривать
из сгораемых материалов.
Покрытие плит пола должно быть гладким, прочным, антистатическим,
позволяющим выполнять уборку пола пылесосом или влажную уборку.
Конструкция плит должна обеспечивать стекание и отвод электростатического
электричества.
Расположение отверстий в плитах для прокладки соединительных кабелей,
заземления, воздуховодов централизованного охлаждения устройств следует
определять по месту установки устройств в соответствии с технологическими
планами размещения ЭВМ и техническими характеристиками устройств.
4.4. Требования к прокладке коммуникаций
4.4.1. В помещении серверной не должно проходить никаких магистралей
и ответвлений инженерных систем, включая общую хозяйственную канализацию,
холодное и горячее водоснабжение, общую вентиляцию и кондиционирование,
распределительная сеть электропитания и освещение, и другие слаботочные
системы, за исключением систем, располагаемых в самой серверной.
4.4.2. В зданиях и помещениях ЭВМ с односменным и двухсменным режимом
работы следует предусматривать центральное водяное отопление в сочетании
с приточной вентиляцией или кондиционированием воздуха.
4.4.3. Отопление помещений с трехсменным режимом работы, как правило,
проектируется воздушным.
4.4.4. Расчет водяных систем отопления помещений,
предусматривается
кондиционирование
воздуха,
следует
на поддержание внутренней температуры воздуха 17°С.
в которых
производить
4.4.5. В помещениях, внешних запоминающих устройств, графопостроителей
и графоповторителей, сервисной аппаратуры, подготовки данных, архивов
машинных носителей, вскрытия и обработки дисков, барабанов и лент должна
предусматриваться возможность отключения системы отопления.
4.4.6. Температура на поверхности нагревательных приборов в зданиях
и помещениях для ЭВМ не должна превышать 95°С.
4.4.7. Нагревательные приборы, устанавливаемые в зданиях и помещениях
для ЭВМ, должны иметь гладкую, легко очищаемую поверхность.
4.4.8. В помещениях, которые должны иметь гидроизоляцию, не допускается
наличие разъемных соединений и размещение запорной и регулирующей арматуры
на трубопроводах систем отопления.
4.5. Химическое воздействие
Содержание в воздухе серверного помещения загрязняющих веществ
не должно превышать следующих предельных значений:
Хлор – 0,01%;
Сероводород – 0,05%;
Окислы азота – 0,1%;
Двуокись серы – 0,3%;
Углеводороды – 4х10-6 (г/м3) в сутки.
ТРЕБОВАНИЯ К ИНФРАСТРУКТУРЕ СЕРВЕРНОГО ПОМЕЩЕНИЯ
В помещении серверной должны быть установлены следующие системы:
4.6. Система электропитания, освещения и заземления (СЭ), включающая
в себя:
4.6.1. Подсистема гарантированного электропитания (ПГЭ):
ПГЭ предусматривает наличие двух вводов электропитания от разных
электроподстанций. Оба источника электроэнергии подаются на автомат ввода
резерва (АВР), осуществляющий автоматическое переключение фидеров
при пропадании электропитания на основном (резервном) фидере. Параметры линий
электропитания АВР определяются исходя из суммарной потребляемой мощности
оборудования и подсистем серверной. Линии внешнего электропитания должны
быть выполнены по пятипроводной схеме с жилами неравного сечения. Вывод
информации состояния и срабатывания АВР со звуковой и световой индикацией
о пропадании электроэнергии.
4.6.2. Подсистема бесперебойного электропитания (ПБЭ):
ПБЭ предусматривает электроснабжение оборудования и систем серверной
через источники бесперебойного питания (ИБП). Мощность и конфигурация ИБП
рассчитывается с учетом всего запитываемого оборудования и запаса для будущего
развития. Время автономной работы от ИБП рассчитывается с учетом потребностей,
а так же с учетом необходимого времени для перехода на резервные линии
(не менее 20 минут) и обратно. ИБП должен обеспечивать не менее 30% запаса
по мощности для развития оборудования серверной.
4.6.3. Подсистема технологического заземления (ПТЗ):
В помещение серверной должно быть обеспечено наличие контура
заземления. Сопротивление технологического заземления должно быть менее 1 Ом.
Присоединение технологического заземления к защитному заземлению здания
производится непосредственно у защитных электродов, расположенных в грунте.
Все металлические части и конструкции серверной должны быть заземлены.
Каждый шкаф (стойка) с оборудованием заземляется отдельным проводником.
Не сварные металлические конструкции серверной должны иметь заземляющие
шайбы в болтовых соединениях, улучшающие электрический контакт между
частями конструкции.
4.6.4. Подсистема электрического освещения (ПЭО)
Освещенность помещения серверной определяется в соответствии
с Таблицей 4 СН 512-78 "Инструкция по проектированию зданий и помещений
для электронно-вычислительных машин". Для освещения серверной допустимо
применять светильники с люминесцентными или светодиодными лампами.
Применение
газоразрядных
ламп
не рекомендовано
из-за
наличия
электромагнитных помех при их работе. Питание ПЭО осуществляется от системы
гарантированного электропитания серверной.
4.7. Система кондиционирования (СК)
В помещении серверной должны соблюдаться следующие климатические
условия:
Температура воздуха в помещении: 18-24°С;
Допустимые отклонения температуры: +/-2°С;
Относительная влажность воздуха: 40-50%;
Точность поддержания влажности: +/-1%.
Фактическая холодильная мощность системы кондиционирования воздуха
должна превышать суммарное тепловыделение всего оборудования и систем,
размещенного в помещении серверной. Система кондиционирования должна
обеспечивать возможность удаленного мониторинга (с использованием протоколов
HTTP, SNMP). Электропитание кондиционеров серверной должно осуществляться
от ПГЭ или ПБЭ.
Кондиционирование серверных помещений рационально иметь с показателем
50 - 100% резервирования.
Для небольшой серверной, где теплопритоки составляют от 3 до 10 кВт
необходимо
использовать
сплит-систему
"DAIKIN",
оснащённую
низкотемпературным комплектом, позволяющим использовать кондиционер
в режиме "охлаждения" при температурах наружного воздуха ниже нулевой
отметки.
При работе системы кондиционирования при температурах наружного
воздуха до -30оС в ней должно быть предусмотрено:
обогрев картера компрессора для улучшения вязкости масла и устранения
эффекта "вскипания" хладагента при пуске;
уменьшение потока воздуха через теплообменник наружного блока
чиллера для стабилизации давления конденсации.
В качестве альтернативы, можно использовать для серверной комнаты
кондиционеры "HAIER", "Matsushita" или "General Fujitsu".
Наиболее эффективным решением для кондиционирования серверных
помещений, где теплоприток более 10 кВт являются прецизионные системы
кондиционирования со свободным охлаждением. В соответствующих случаях
с дублирующей системой кондиционирования и вентиляции.
Прецизионные кондиционеры представляют собой специализированные
системы кондиционирования серверных помещений, способные с большой
точностью поддерживать требуемую температуру и влажность круглый год. Также
осуществляется очистка воздуха. Таким образом, в помещении образовывается
идеальная
атмосфера
для
функционирования
стоек
с дорогостоящим
оборудованием.
4.8. Система организации оборудования и кабельного хозяйства (СО),
включающая в себя:
4.8.1. Средства распределения кабелей и организации кабельных потоков
Для распределения кабелей и организации кабельных потоков
в телекоммуникационном помещении необходимо использовать кабелепроводы
и организаторы.
Средства распределения и организации кабельных потоков должны быть
надежно закреплены, выдерживать вес кабеля, должны обеспечить защиту
и распределение кабелей с минимально допустимым радиусом изгиба кабеля.
Кабелепроводы должны быть установлены от кабельного ввода
в телекоммуникационное помещение до телекоммуникационных шкафов.
Кабелепроводы расположенные под потолком, должны быть открыты и доступны
для проведения дальнейших работ по прокладке кабелей, шнуров или перемычек.
Для упрощения коммуникаций и исключения поломки разъемов
оборудования, необходимо применять патч-панели. Все кабели, кроссовые
коммуникации и патч-панели должны иметь маркировку, позволяющую однозначно
идентифицировать каждый кабель (разъем, порт).
4.8.2. Подсистема телекоммуникационных шкафов и стоек (ПШС)
Все оборудование серверной размещается в закрытых шкафах или открытых
стойках. Количество стоек (шкафов) определяется исходя из имеющегося
оборудования и его типоразмеров, способов монтажа. Промежутки между шкафами
не допускаются. Распределение оборудования по шкафам (стойкам) осуществляется
с учетом совместимости (возможного взаимного влияния), оптимального
распределения потребляемой мощности (а значит и тепловыделения),
оптимальности коммуникаций, габаритам и массе оборудования. Вводные каналы
в телекоммуникационные шкафы и стойки должны обеспечивать свободную
протяжку требуемого количества кабелей вместе с оконечными разъемами.
4.9. Система безопасности (СБ), включающая в себя:
4.9.1. Подсистема контроля доступа (ПКД)
Подсистема контроля и управления доступом должна исключить попадание
в серверную лиц, в чьи обязанности не входит монтаж, эксплуатация и техническое
обслуживание размещённого в серверной оборудования. Для идентификации
допущенных лиц применяются следующие средства:
Ключи от механических замков;
Кодонаборные панели;
Карты и метки электронной идентификации;
Комбинация вышеперечисленных методов.
Для блокирования доступа в помещение могут применятся:
Механические замки;
Электромеханические замки;
Электромагнитные замки;
Комбинация вышеперечисленных средств.
4.9.2. Подсистема охранной сигнализации (ПОС)
Охранная сигнализация серверной должна быть выполнена отдельно
от систем безопасности здания. Сигналы оповещения выводятся в помещение
круглосуточной охраны в виде отдельного пульта. Дополнительно сигналы
оповещения могут доставляться средствами связи: телефон, СМС, пейджер.
Контролю и охране подлежат все входы и выходы серверной, объем помещения,
оконные проемы (если есть). ПОС должна иметь собственный источник
резервированного питания.
4.9.3. Подсистема видеонаблюдения (ПВН)
Система охранного видеонаблюдения предназначена для визуального
наблюдения и фиксации текущей обстановки в помещениях серверной. Камеры
необходимо разместить таким образом, чтобы контролировать входы и выходы
в помещение, пространство возле технологического оборудования (ИБП,
кондиционеры, серверные шкафы и телекоммуникационные стойки). Разрешения
видеокамер должно быть достаточным, чтобы уверенно различать лица
сотрудников, обслуживающих технологическое оборудование. Видеокамеры
должны быть снабжены светодиодной подсветкой для наблюдения в темноте.
При построении системы охранного видеонаблюдения серверной глубина
хранения видеоархива должна быть не менее 14 дней. В случае если ёмкости
видеосервера не достаточно для реализации такой глубины сохранения архива,
то необходимо предусмотреть увеличение дискового массива основного сервера
при помощи добавления к нему дополнительных полок с дисками.
4.9.4. Подсистема пожарной сигнализации (ППС)
Помещение серверной, не зависимо от площади, необходимо оборудовать
пожарной сигнализацией. В случаи наличия пожарной сигнализации в остальном
здание необходимо предусмотреть интеграцию пожарной сигнализации помещения
серверной с пожарной сигнализацией и системой оповещения и управления
эвакуацией людей (СОУЭ) здания. При не возможности интеграции пожарной
сигнализации помещения серверной допускается вывести сигнал на отдельный
пульт управления в помещения с круглосуточным пребыванием персонала, но так
же необходимо произвести коммутацию системы пожарной сигнализации
помещения серверной и СОУЭ здания.
В помещение серверной, как правило, применяют дымовые пожарные
извещатели. Извещатели должны контролировать как общее пространство
помещений, так и полости, образованные фальшполом и фальшпотолком. Сигналы
оповещения ППС дополнительно выводятся в SCADA- систему и на входную дверь.
ППС может быть объединена с ПОС серверной.
С целью предотвращения распространения очага пожара помещение
серверной необходимо отделять от остальных помещений противопожарной
перегородкой 1-го типа (противопожарная дверь с пределом огнестойкости не менее
60 минут).
4.9.5. Подсистема газового пожаротушения (ПГП)
Помещения серверных площадью более 24 м2 должны оборудоваться
автоматической системой газового пожаротушения (АУГП). ПГП размещается
непосредственно в помещении серверной (или вблизи ее) в специально
оборудованном для этого шкафу. Запуск ПГП производится от датчиков раннего
обнаружения пожара, реагирующих на появление дыма, а также от ручных
пожарных извещателей, расположенных у входа в помещение или с пульта
управления в ручном режиме. ПГП должна иметь световые табло оповещения
о срабатывании тушения, размещаемые внутри и снаружи помещения. Звуковой
оповещатель располагается снаружи у входа в серверное помещение. Кабели
и способы их прокладки должны соответствовать требованиям СП 5.13130.2009
п. 13.15.3 и ГОСТ Р 53315 и ГОСТ Р 53325. Необходимо использовать огнестойкие
кабели и провода типа НГ-FRLS или НГ-FRHF.
4.9.6. Подсистема газо и дымоудаления (ПГУ)
Подсистема
должна
обеспечивать
отвод
газовоздушной
смеси
от автоматической системы газового пожаротушения в объеме, втрое превышающем
объем серверной. Допускается использование переносных дымососов.
4.10. Требования пожарной безопасности к серверным помещениям
4.10.1. Помещения серверных должны выделяться противопожарными
перегородками не ниже 1-го типа и перекрытиями не ниже 3-го типа.
4.10.2. Помещения серверной площадью 24 м2 и более должны быть
защищены установкой автоматического пожаротушения, а площадью менее 24 м2
системой автоматической пожарной сигнализации.
4.10.3. Помещения серверной должны оснащаться системой оповещения
и управления эвакуацией при пожаре.
4.10.4. Помещения должны оснащаться огнетушителями.
4.10.5. Двери помещений серверной должны быть противопожарными.
