=== ФАЙЛ: Приложение 2 к ТТ (Аналогичный договор и специалисты) Модиф_ КПА(38958288_256_06_10_2026).docx | docs/32616441078/Приложение 2 к ТТ (Аналогичный договор и специалисты) Модиф_ КПА(38958288_256_06_10_2026).pdf
Приложение № 2
к Техническим требованиям
Приложение №1 к Конкурсной документации
по конкурсу в электронной форме на право
заключения договора на выполнение работ по
модификации программы для ЭВМ
«Конструктор логических моделей/схем
противоаварийной автоматики»
1. Требования к опыту Исполнителя
1.1. На момент подачи Конкурсной заявки предпочтительно наличие у
Исполнителя за последние 3 (три) года до срока окончания подачи
Участниками Конкурсных заявок опыта выполнения аналогичных договоров.
Аналогичными считаются договоры оказания услуг по техническому
обслуживанию (сопровождению) и (или) на выполнение работ по созданию
(разработке) и(или) модификации программ для ЭВМ, применяемых в
электроэнергетике в области моделирования схем устройств и/или каналов
передачи сигналов противоаварийной автоматики.
2.Требования к специалистам
2.1. Необходимо выполнить работы силами квалифицированных
специалистов в количестве не менее 7 (Семи) специалистов с высшим
образованием в области информационных технологий и (или)
электроэнергетики и (или) математики, в том числе не менее 1 (Одного)
специалиста, имеющего документы о повышении квалификации (обучении) в
области администрирования операционной системы Astra Linux.
2.2. Предпочтительно наличие у специалистов Исполнителя,
привлекаемых для выполнения Работ по Договору, резюме на каждого
специалиста с указанием опыта участия в аналогичных договорах.
2.3 На момент подачи Конкурсной заявки предпочтительно наличие в
штате у Исполнителя или находящихся с ним в гражданско-правовых
отношениях не менее 7 (Семи) специалистов с высшим образованием в
области информационных технологий и (или) электроэнергетики и (или)
математики (подтверждается копиями дипломов о высшем образовании), в
том числе не менее, чем 1 (одного) специалиста, имеющего документы о
повышении квалификации (обучении) в области администрирования
операционной системы Astra Linux,
предпочтительно
наличие
у
специалистов Исполнителя, привлекаемых для выполнения Работ по
Договору, резюме на каждого специалиста с указанием опыта участия в
аналогичных договорах.

=== ФАЙЛ: КД_Модификация КПА 2026-2027(38958332_256_06_10_2026).docx | docs/32616441078/КД_Модификация КПА 2026-2027(38958332_256_06_10_2026).pdf
УТВЕРЖДАЮ
Директор по автоматизированным
системам диспетчерского
управления АО «СО ЕЭС»
________________ Р.А. Богомолов
«___» ____________ 2026 года
Конкурсная документация
КОНКУРС В ЭЛЕКТРОННОЙ ФОРМЕ
НА ПРАВО ЗАКЛЮЧЕНИЯ ДОГОВОРА НА ВЫПОЛНЕНИЕ РАБОТ ПО
МОДИФИКАЦИИ ПРОГРАММЫ ДЛЯ ЭВМ «КОНСТРУКТОР
ЛОГИЧЕСКИХ МОДЕЛЕЙ/СХЕМ ПРОТИВОАВАРИЙНОЙ АВТОМАТИКИ»
Москва 2026
2
СОДЕРЖАНИЕ
1.
ИЗВЕЩЕНИЕ О ПРОВЕДЕНИИ КОНКУРСА В
ЭЛЕКТРОННОЙ ФОРМЕ...................................................................4
2. ОБЩИЕ ПОЛОЖЕНИЯ........................................................................12
2.1. Общие сведения о конкурсе................................................................................... 12
2.2. Начальная (максимальная) цена Договора........................................................12
2.3. Разъяснение Конкурсной документации.............................................................13
2.4. Внесение изменений в Конкурсную документацию..........................................13
2.5. Правовой статус документов.................................................................................14
2.6. Обжалование.............................................................................................................14
2.7. Прочие положения...................................................................................................15
3.
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ....................................................17
4.
ПРОЕКТ ДОГОВОРА........................................................................18
5.
ТРЕБОВАНИЯ
К
УЧАСТНИКАМ
КОНКУРСА.
ПОДТВЕРЖДЕНИЕ
СООТВЕТСТВИЯ
ПРЕДЪЯВЛЯЕМЫМ ТРЕБОВАНИЯМ........................................60
5.1. Требования к Участникам конкурса...................................................................83
5.2. Подтверждение соответствия Участников конкурса установленным
требованиям............................................................................................................. 85
6.
ПОРЯДОК
ПРОВЕДЕНИЯ
КОНКУРСА.
ИНСТРУКЦИИ ПО ПОДГОТОВКЕ КОНКУРСНЫХ
ЗАЯВОК................................................................................................ 90
6.1. Общий порядок проведения конкурса................................................................90
6.2. Порядок подачи Конкурсной заявки...................................................................90
6.3. Срок действия Конкурсной заявки...................................................................... 92
6.4. Продление срока окончания подачи Конкурсных заявок...............................92
6.5. Порядок изменения Конкурсных заявок............................................................92
6.6. Порядок отзыва поданных Конкурсных заявок................................................92
6.7. Порядок вскрытия Конкурсных заявок.............................................................92
6.8. Рассмотрение, оценка и сопоставление Конкурсных заявок..........................93
6.9. Порядок подведения итогов конкурса...............................................................102
6.10. Подписание Протокола о результатах конкурса.............................................102
6.11. Заключение Договора........................................................................................... 103
6.12. Антидемпинговые меры.......................................................................................103
3
6.13. Уведомление Участников конкурса о результатах конкурса.......................104
7.
ОБЕСПЕЧЕНИЕ ИСПОЛНЕНИЯ ОБЯЗАТЕЛЬСТВ
УЧАСТНИКА КОНКУРСА............................................................105
8.
ОБРАЗЦЫ ФОРМ ДОКУМЕНТОВ, ВКЛЮЧАЕМЫХ
В КОНКУРСНУЮ ЗАЯВКУ...........................................................110
8.1. Письмо о подаче оферты (форма 1)....................................................................110
8.2. Техническое предложение (форма 2)...................................................................116
8.3. Анкета Участника конкурса (форма 3).............................................................118
8.4. Справка о перечне и годовых объемах выполнения аналогичных
договоров (форма 4)..............................................................................................120
8.5. Справка о кадровых ресурсах (форма 5)...........................................................122
8.6. Независимая гарантия (форма 6).......................................................................124
Приложение № 1 к Конкурсной документации – Технические требования на
выполнение работ по модификации программы для ЭВМ «Конструктор логических
моделей/схем противоаварийной автоматики».
Приложение № 2 к Конкурсной
(максимальной) цены Договора.
документации
-
Обоснование
начальной
4
1. Извещение о проведении конкурса в электронной форме
1.
2.
Способ закупки
Предмет закупки
3.
Наименование
Заказчика
(Организатора
конкурса)
Место
нахождения
Заказчика
(Организатора
конкурса)
Почтовый
адрес
Заказчика
(Организатора
конкурса)
Адрес
электронной
почты
Заказчика
(Организатора
конкурса)
Номер
контактного
телефона
Заказчика
(Организатора
конкурса)
Предмет Договора
4.
5.
6.
7.
8.
Конкурс в электронной форме (далее – конкурс)
Право заключения договора на выполнение
работ по модификации программы для ЭВМ
«Конструктор
логических
моделей/схем
противоаварийной автоматики» (далее −
Договор)
Акционерное общество «Системный оператор
Единой
энергетической
системы»
(АО «СО ЕЭС»)
109012, г. Москва, Китайгородский проезд, д. 7,
стр. 3
109012, г. Москва, Китайгородский проезд, д. 7,
стр. 3
ntk@so-ups.ru
+ 7 (495) 627-94-13
Исполнитель обязуется на основании
утвержденных Заказчиком заявок (далее –
утвержденные Заявки) в соответствии с
Техническими требованиями (Приложение № 1 к
Договору) выполнять работы (далее – Работы) по
модификации
Программы
для
ЭВМ
«Конструктор
логических
моделей/схем
противоаварийной автоматики» (далее –
Программа для ЭВМ):
 актуализировать эскизный проект на
Программу для ЭВМ (далее – эскизный проект);
 осуществлять модификацию Программы
для ЭВМ, включая разработку и актуализацию
документации
на
модифицированную
Программу для ЭВМ;
 проводить предварительные испытания
работоспособности
модифицированной
5
9.
Состав,
объем
выполняемых Работ
10. Сроки
выполнения
Работ по Договору
11. Место
выполнения
Работ
12. Сведения о начальной
(максимальной) цене
Договора
Программы для ЭВМ;
 выполнять работы, необходимые для
осуществления внедрения модифицированной
Программы для ЭВМ,
и передавать Заказчику результаты Работ
по Договору, а Заказчик обязуется принимать
результаты Работ по Договору и оплачивать их.
Требования
приведены
в
Технических
требованиях (Приложение № 1 к Конкурсной
документации).
Сроки выполнения Работ по Договору:
– дата начала выполнения Работ: дата
заключения Сторонами Договора;
– дата окончания выполнения Работ: не позднее
«31» августа 2027 года.
(Участник конкурса вправе предложить иной,
более короткий срок окончания выполнения
Работ по Договору, но не ранее 01.08.2027)
109012, г. Москва, Китайгородский проезд, д. 7,
стр. 3
Начальная (максимальная) цена Договора,
заключаемого
по
результатам
конкурса,
составляет 19 864 550 (Девятнадцать миллионов
восемьсот шестьдесят четыре тысячи пятьсот
пятьдесят) рублей 00 копеек без учета НДС.
13. Сведения о порядке Конкурс проводится путем открытой закупочной
проведения конкурса
процедуры в электронной форме в соответствии
с правилами и с использованием функционала
электронной площадки B2B-Center (далее –
Электронная площадка).
Для участия в конкурсе юридическое лицо или
индивидуальный предприниматель должны быть
аккредитованы на Электронной площадке в
порядке,
установленном
оператором
Электронной площадки.
14. Адрес
электронной www.b2b-center.ru
площадки
в
информационнотелекоммуникационной
сети «Интернет»
15. Срок, место и порядок Конкурсная документация находится в открытом
предоставления
доступе, начиная с даты официальной
Конкурсной
публикации на Электронной площадке и в
6
документации
16. Порядок
подачи
Конкурсных заявок на
участие в конкурсе
17. Дата начала, дата и
время окончания срока
подачи
Конкурсных
заявок
Единой информационной системе. Порядок
получения Конкурсной документации на
Электронной площадке определяется правилами
данной Электронной площадки.
Конкурсная документация предоставляется без
взимания платы в форме электронного
документа.
Для участия в конкурсе необходимо подать
Конкурсную заявку, подготовленную в порядке,
оговоренном в Конкурсной документации, в
электронном виде через Электронную площадку.
Дата начала подачи Участниками Конкурсных
заявок: 06.10.2026.
Дата и время окончания подачи Участниками
Конкурсных заявок: до 09 часов 00 минут
22.10.2026.
18. Закупочная
Заказчика
комиссия Постоянно
действующая
Центральная
закупочная комиссия АО «СО ЕЭС», созданная
приказом АО «СО ЕЭС» от 07.10.2019 № 299.
19. Порядок
подведения Подведение итогов конкурса проводится
итогов конкурса
Центральной
закупочной
комиссией
АО «СО ЕЭС» не позднее 09 часов 00 минут
29.10.2026 по адресу: 119297, г. Москва, вн.тер.г.
муниципальный округ Солнцево, ул. Петра
Непорожнего, д. 7 стр. 1.
20. Участник конкурса
Любое юридическое лицо или несколько
юридических лиц, выступающих на стороне
одного участника конкурса, независимо от
организационно-правовой
формы,
формы
собственности, места нахождения и места
происхождения капитала, за исключением
юридического лица, являющегося иностранным
агентом в соответствии с Федеральным законом
от 14 июля 2022 года № 255-ФЗ «О контроле за
деятельностью
лиц,
находящихся
под
иностранным
влиянием»,
либо
любое
физическое лицо или несколько физических лиц,
выступающих на стороне одного участника
конкурса, в том числе индивидуальный
предприниматель
или
несколько
индивидуальных
предпринимателей,
выступающих на стороне одного участника
конкурса, за исключением физического лица,
7
являющегося
иностранным
агентом
в
соответствии с Федеральным законом от 14 июля
2022 года № 255-ФЗ «О контроле за
деятельностью
лиц,
находящихся
под
иностранным влиянием»
21. Требования
к Претендовать на победу в конкурсе могут
Участникам конкурса
Участники конкурса, предложившие лучшие
условия для исполнения Договора и отвечающие
следующим требованиям:
а) соответствие
Участника
конкурса
требованиям, устанавливаемым в соответствии с
законодательством Российской Федерации к
лицам,
осуществляющим
исполнение
обязательств, являющихся предметом Договора;
б) непроведение ликвидации Участника
конкурса – юридического лица и отсутствие
решения арбитражного суда о признании
Участника конкурса – юридического лица,
индивидуального предпринимателя банкротом и
об открытии конкурсного производства;
в) неприостановление
деятельности
Участника
конкурса
в
порядке,
предусмотренном
Кодексом
Российской
Федерации
об
административных
правонарушениях, на день подачи Конкурсной
заявки;
г) представление
предусмотренных
п. 5.1.4
документации;
сведений,
Конкурсной
д) отсутствие у Участника конкурса
недоимки по налогам, сборам, задолженности по
иным обязательным платежам в бюджеты
бюджетной системы Российской Федерации (за
исключением сумм, на которые предоставлены
отсрочка,
рассрочка,
инвестиционный
налоговый
кредит
в
соответствии
с
законодательством Российской Федерации о
налогах и сборах, которые реструктурированы в
соответствии с законодательством Российской
Федерации, по которым имеется вступившее в
законную силу решение суда о признании
обязанности заявителя по уплате этих сумм
8
исполненной
или
которые
признаны
безнадежными к взысканию в соответствии с
законодательством Российской Федерации о
налогах и сборах) за прошедший календарный
год, размер которых превышает 25 % (Двадцать
пять процентов) балансовой стоимости активов
Участника конкурса, по данным бухгалтерской
отчетности за последний отчетный период.
Участник конкурса считается соответствующим
установленному требованию в случае, если им в
установленном порядке подано заявление об
обжаловании
указанных
недоимки,
задолженности и решение по такому заявлению
на дату рассмотрения заявки на участие в
определении
поставщика
(подрядчика,
исполнителя) не принято;
е) отсутствие сведений об Участнике
конкурса
в
реестре
недобросовестных
поставщиков, предусмотренном статьей 5
Федерального закона от 18.07.2011 № 223-ФЗ «О
закупках товаров, работ, услуг отдельными
видами юридических лиц» и (или) в реестре
недобросовестных
поставщиков,
предусмотренном Федеральным законом от
05.04.2013 № 44-ФЗ «О контрактной системе в
сфере закупок товаров, работ, услуг для
обеспечения государственных и муниципальных
нужд»;
ж)
отсутствие у Участника конкурса –
физического лица либо у руководителя, членов
коллегиального исполнительного органа или
главного бухгалтера юридического лица –
Участника конкурса судимости за преступления
в сфере экономики и (или) преступления,
предусмотренные статьями 289, 290, 291, 291.1
Уголовного кодекса Российской Федерации (за
исключением лиц, у которых такая судимость
погашена или снята), а также неприменение в
отношении
указанных
физических
лиц
наказания в виде лишения права занимать
определенные должности или заниматься
определенной деятельностью, которые связаны с
поставкой товара, выполнением работы,
9
оказанием услуги, являющихся предметом
осуществляемой закупки, и административного
наказания в виде дисквалификации;
з) отсутствие фактов привлечения в
течение 2 (Двух) лет до момента подачи заявки
Участника конкурса – юридического лица к
административной
ответственности
за
совершение
административного
правонарушения, предусмотренного статьей
19.28 Кодекса Российской Федерации об
административных правонарушениях;
и) отсутствие сведений об Участнике
конкурса в реестре иностранных агентов,
предусмотренном Федеральным законом от
14.07.2022
№ 255-ФЗ
«О
контроле
за
деятельностью
лиц,
находящихся
под
иностранным влиянием».
22. Обеспечение
Обязательства Участников конкурса, связанные
Участником конкурса с подачей Конкурсных заявок, обеспечиваются
обязательств,
денежными средствами в размере 3 % (Трех
связанных с подачей процентов) от начальной (максимальной) цены
Конкурсной заявки
Договора, что составляет 595 936 (Пятьсот
(размер, порядок и срок девяносто пять тысяч девятьсот тридцать шесть)
предоставления
рублей 50 копеек.
обеспечения)
Участник
вправе
вместо
денежного
обеспечения
предоставить
Организатору
конкурса независимую гарантию в целях
обеспечения
исполнения
обязательств,
связанных с подачей Конкурсной заявки, в
размере 3 % (Трех процентов) от начальной
(максимальной) цены Договора, что составляет
595 936
(Пятьсот девяносто пять тысяч
девятьсот тридцать шесть) рублей 50 копеек, на
условиях, предусмотренных разделом 7
Конкурсной документации.
Если Участник является субъектом малого и
среднего предпринимательства, то размер
обеспечения составляет 2 % (Два процента) от
начальной (максимальной) цены Договора, что
составляет 397 291 (Триста девяносто семь
тысяч двести девяносто один) рубль 00 копеек.
Порядок и срок предоставления обеспечения
10
Участником конкурса обязательств, связанных с
подачей Конкурсной заявки, устанавливаются
разделом 7 Конкурсной документации.
23. Обеспечение
исполнения
обязательств
по
Договору
(размер, порядок, срок
предоставления
обязательства
исполнения Договора,
основное
обязательство,
исполнение которого
обеспечивается и срок
его исполнения)
24. Запрет или ограничение
закупок товаров (в том
числе
поставляемых
при
выполнении
закупаемых
работ),
происходящих
из
иностранных
государств,
работ,
выполняемых
иностранными лицами,
преимущество
в
отношении
товаров
российского
происхождения (в том
числе
поставляемых
при
выполнении
закупаемых
работ),
работ,
выполняемых
российскими лицами
25. Срок
и
форма
заключения Договора
Не требуется
Не установлено
Договор по результатам конкурса между
Заказчиком
и
Победителем
конкурса
заключается не ранее чем через 10 (Десять) дней
и не позднее чем через 20 (Двадцать) дней с даты
размещения в единой информационной системе
итогового
протокола,
составленного
по
результатам конкурса.
Договор заключается в письменной форме путем
составления одного документа, подписанного
11
сторонами.
26. Победитель конкурса, Участник
конкурса,
Конкурсная
заявка
Победитель
(окончательное
предложение)
которого
соответствует требованиям, установленным
настоящей Конкурсной документацией, и
Конкурсная заявка (окончательное предложение)
которого
по
результатам
сопоставления
Конкурсных
заявок
(окончательных
предложений) на основании указанных в
Конкурсной документации критериев оценки
содержит лучшие условия исполнения Договора.
27. Единая
Единая информационная система в сфере
информационная
закупок
в
информационносистема
телекоммуникационной сети «Интернет» по
адресу www.zakupki.gov.ru.
28. Участниками закупки Нет
могут быть только
субъекты малого и
среднего
предпринимательства
12
2. Общие положения
2.1.
Общие сведения о конкурсе
2.1.1. Организатор конкурса приглашает лиц, указанных в п. 20 Извещения
о проведении конкурса, к участию в открытой закупочной процедуре – конкурсе
в электронной форме на право заключения договора на выполнение работ по
модификации программы для ЭВМ «Конструктор логических моделей/схем
противоаварийной автоматики» (далее − конкурс).
2.1.2. Текст Извещения о проведении конкурса в электронной форме (далее
– Извещение о проведении конкурса) приведен в разделе 1 Конкурсной
документации (здесь и далее ссылки относятся к настоящей Конкурсной
документации, если по тексту не установлено иное). Извещение о проведении
конкурса опубликовано в Единой информационной системе и на Электронной
площадке.
2.1.3. Конкурс проводится в электронной форме на Электронной
площадке. Рассмотрение, оценка и сопоставление Конкурсных заявок,
определение Победителя конкурса, уведомление Участников об итогах
конкурса, иные необходимые действия Организатора конкурса совершаются
Центральной закупочной комиссией.
2.1.4. Для справок обращаться:
а)
по организационным вопросам по тел. (495) 627-94-13, электронный
адрес: ntk@so-ups.ru;
б)
вопросы технического характера направляются Участником
конкурса через Электронную площадку.
2.1.5. Подробные требования к выполняемым Работам изложены в
Технических требованиях (Приложение № 1 к Конкурсной документации).
Проект Договора, который заключается по результатам конкурса, приведен в
разделе 4. Требования к Участникам конкурса, порядок подтверждения
соответствия предъявляемым требованиям приведены в разделе 5. Порядок
проведения конкурса и участия в нем, а также инструкции по подготовке
Конкурсных заявок приведены в разделе 6. Обеспечение исполнения
обязательств Участника конкурса – в разделе 7. Образцы форм документов,
включаемых в Конкурсную заявку, приведены в разделе 8.
2.2.
Начальная (максимальная) цена Договора
2.2.1. Начальная (максимальная) цена Договора, заключаемого по
результатам конкурса, составляет 19 864 550 (Девятнадцать миллионов
восемьсот шестьдесят четыре тысячи пятьсот пятьдесят) рублей 00 копеек без
учета НДС.
2.2.2. Начальная (максимальная) цена Договора определена в соответствии
с утвержденными в АО «СО ЕЭС» Методическими указаниями (размещены в
Единой
информационной
системе,
ссылка
на
место
13
размещения:https://zakupki.gov.ru/epz/orderclause/card/documents.html?
reestrNumber=1120001227 ).
Обоснование начальной (максимальной) цены Договора содержится в
Приложении № 2 к Конкурсной документации.
2.3.
Разъяснение Конкурсной документации
Участник конкурса вправе направить Организатору конкурса через
функционал Электронной площадки запрос о разъяснении положений
Извещения о проведении конкурса и (или) Конкурсной документации. В течение
3 (Трех) рабочих дней с даты поступления запроса, Организатор конкурса
осуществляет разъяснение положений Извещения о проведении конкурса и (или)
Конкурсной документации через функционал Электронной площадки и
размещает их в Единой информационной системе с указанием предмета запроса,
но без указания Участника конкурса, от которого поступил указанный запрос.
При этом Организатор конкурса вправе не осуществлять такое разъяснение в
случае, если указанный запрос о разъяснении положений Извещения о
проведении конкурса и (или) Конкурсной документации поступил позднее чем
за 3 (Три) рабочих дня до даты окончания срока подачи заявок на участие в
конкурсе.
2.4.
Внесение изменений в Конкурсную документацию
2.4.1. До истечения срока окончания подачи Конкурсных заявок
Организатор конкурса может внести изменения в Извещение о проведении
конкурса и (или) Конкурсную документацию, в том числе продлить срок подачи
Конкурсных заявок на участие в конкурсе. Указанные изменения размещаются
на Электронной площадке и в Единой информационной системе. В случае
внесения изменений в Извещение о проведении конкурса, Конкурсную
документацию срок подачи Конкурсных заявок на участие в конкурсе должен
быть продлен таким образом, чтобы с даты размещения таких изменений до даты
окончания срока подачи Конкурсных заявок на участие в конкурсе оставалось не
менее половины срока подачи заявок на участие в конкурсе.
2.4.2. Все
претенденты,
официально
получившие
Конкурсную
документацию на Электронной площадке, извещаются оператором Электронной
площадки в электронной форме о внесенных Организатором конкурса
изменениях и/или о продлении срока подачи Конкурсных заявок на участие в
конкурсе.
2.4.3. Участники конкурса самостоятельно отслеживают возможные
изменения, внесенные в Извещение о проведении конкурса и (или) Конкурсную
документацию, размещенные на Электронной площадке и в Единой
информационной системе. Организатор конкурса не несет ответственности в
случае, если Участник конкурса не ознакомился с изменениями, внесенными в
Извещение о проведении конкурса и (или) Конкурсную документацию,
размещенными и опубликованными надлежащим образом.
14
2.5.
Правовой статус документов
2.5.1. Извещение о проведении конкурса, опубликованное в соответствии с
п. 2.1.2, Конкурсная документация являются приглашением делать оферты и
должны рассматриваться Участниками конкурса в соответствии с этим.
2.5.2. Конкурсная заявка Участника конкурса имеет правовой статус
оферты и в соответствии с этим рассматривается Организатором конкурса.
2.5.3. Протокол о результатах конкурса, подписанный Организатором
конкурса и Победителем конкурса, имеет силу договора, определяющего
обязанность Организатора конкурса и Победителя конкурса заключить Договор
на условиях, установленных Извещением о проведении конкурса, Конкурсной
документацией и Конкурсной заявкой Победителя конкурса в части, не
противоречащей Извещению о проведении конкурса и Конкурсной
документации.
2.5.4. При определении условий Договора с Победителем конкурса
используются следующие документы с соблюдением указанной иерархии:
а) Проект Договора, приведенный в разделе 4 Конкурсной документации;
б) Протокол о результатах конкурса;
в) Извещение о проведении конкурса и Конкурсная документация со
всеми дополнениями и разъяснениями (за исключением раздела 4 Конкурсной
документации);
г) Конкурсная заявка Победителя конкурса со всеми дополнениями и
разъяснениями.
Иные документы Организатора конкурса, Участников конкурса не
определяют их права и обязанности в связи с данным конкурсом.
2.5.5. Во всем, что не урегулировано Извещением о проведении конкурса и
Конкурсной документацией, Организатор конкурса, Участники конкурса
руководствуются Положением о порядке проведения регламентированных
закупок товаров, работ, услуг для нужд акционерного общества «Системный
оператор Единой энергетической системы» (размещено на сайте Заказчика
(http://so-ups.ru/)), Федеральным законом от 18.07.2011 № 223-ФЗ «О закупках
товаров, работ, услуг отдельными видами юридических лиц», Гражданским
кодексом Российской Федерации.
2.6.
Обжалование
2.6.1. Участник конкурса, который не согласен с действиями
Центральной закупочной комиссии, имеет право подать заявление о
рассмотрении разногласий, связанных с проведением конкурса (далее –
разногласия).
2.6.2. До заключения Договора разногласия направляются в Центральный
закупочный орган АО «СО ЕЭС» (далее – ЦЗО Общества). О получении
15
заявления о рассмотрении разногласий ответственный секретарь ЦЗО Общества
незамедлительно уведомляет руководителя Центральной закупочной комиссии и
подразделение,
ответственное
за
профилактику
коррупционных
правонарушений и реализацию антикоррупционных мер в АО «СО ЕЭС».
2.6.3. Если разногласия не разрешены по взаимному согласию
представившего их Участника конкурса и лиц, производивших закупку, ЦЗО
Общества в течение 30 (Тридцати) дней со дня получения таких разногласий
выносит и направляет заявителю письменное решение, которое должно
содержать:
1) обоснование мотивов принятия решения;
2) меры, направленные на удовлетворение изложенных требований, в
случае полного или частичного разрешения разногласий.
2.6.4. ЦЗО Общества вправе принять одно или несколько из следующих
решений:
1) полностью или частично отменить решение Центральной закупочной
комиссии и принять собственное решение, а при необходимости разрешить
вопрос о возмещении убытков, понесенных Участником в результате
отмененного или измененного решения;
2) признать заявление Участника необоснованным;
3) оставить разногласия без рассмотрения, в случае если до принятия по
ним решения заявитель обратился с жалобой в антимонопольный орган.
2.6.5. Разногласия, неурегулированные в вышеуказанном порядке,
подлежат разрешению в Арбитражном суде г. Москвы.
2.7.
Прочие положения
2.7.1. Участник конкурса самостоятельно несет все расходы, связанные с
подготовкой и подачей Конкурсной заявки, а Организатор конкурса по этим
расходам не отвечает и не имеет обязательств, независимо от хода и результатов
конкурса, за исключением случаев, прямо предусмотренных действующим
законодательством Российской Федерации.
2.7.2. Организатор конкурса обеспечивает разумную конфиденциальность
относительно всех полученных от Участников конкурса сведений, в том числе
содержащихся в Конкурсных заявках. Предоставление этой информации другим
Участникам конкурса или третьим лицам возможно только в случаях, прямо
предусмотренных действующим законодательством Российской Федерации или
настоящей Конкурсной документацией.
2.7.3. Организатор конкурса вправе отклонить Конкурсную заявку
Участника конкурса на любом этапе конкурса, если он установит, что:
− Участник конкурса прямо или косвенно дал, согласился дать или
предложил работнику Организатора конкурса вознаграждение в любой форме:
работу, услугу, какую-либо ценность, предоставил имущественные права в
качестве стимула, который может повлиять на принятие Центральной
16
закупочной комиссией решения об определении Победителя конкурса;
− Участники конкурса заключили между собой какое-либо соглашение с
целью повлиять на определение Победителя конкурса.
2.7.4. В случае если обстоятельства, указанные в п. 2.7.3, установлены
после определения Победителя конкурса или заключения Договора, Организатор
конкурса вправе оспорить результаты конкурса в судебном порядке в
соответствии с действующим законодательством Российской Федерации.
2.7.5. В соответствии с Извещением о проведении конкурса, Организатор
конкурса имеет право отменить конкурс в любое время до наступления срока
окончания подачи Конкурсных заявок на участие в конкурсе, указанного в п. 17
Извещения о проведении конкурса, не неся никакой ответственности перед
Участниками конкурса или третьими лицами, которым такое действие может
принести убытки. Отмена проведения конкурса оформляется на Электронной
площадке и в Единой информационной системе.
2.7.6. Все документы, входящие в состав Конкурсной заявки, должны быть
составлены на русском языке. Подача документов, входящих в состав
Конкурсной заявки на иностранном языке, должна сопровождаться
предоставлением надлежащим образом заверенного перевода на русский язык. В
случае противоречия оригинала и перевода преимущество будет иметь перевод.
2.7.7. Все суммы денежных средств ценовых предложений Участников,
должны быть выражены в российских рублях. Выражение денежных сумм в
других валютах может быть расценено как несоответствие Конкурсной заявки
требованиям Конкурсной документации.
17
3. Технические требования
Исполнитель должен выполнить работы по модификации программы для
ЭВМ «Конструктор логических моделей/схем противоаварийной автоматики» в
соответствии с Техническими требованиями на выполнение работ по
модификации программы для ЭВМ «Конструктор логических моделей/схем
противоаварийной автоматики» (Приложение № 1 к Конкурсной документации).
18
4. Проект Договора
Договор № ________
г. Москва
«___» __________ 2026 года
Акционерное общество «Системный оператор Единой энергетической
системы» (сокращенное наименование АО «СО ЕЭС»), именуемое в дальнейшем
«Заказчик», в лице _________________ (указать должность и Ф.И.О. лица,
уполномоченного на подписание договора), действующего на основании
доверенности от ___№ ___, с одной стороны, и
_________________ (указать полное наименование контрагента с
расшифровкой организационно-правовой формы и его сокращенное
наименование в соответствии с учредительными документами), именуемое в
дальнейшем «Исполнитель», в лице _________________ (указать должность и
Ф.И.О. лица, уполномоченного на подписание договора), действующего на
основании _________________ (Устава, либо доверенности (с реквизитами),
либо свидетельства о регистрации физического лица в качестве
индивидуального предпринимателя (с реквизитами) / индивидуальный
предприниматель _____________________ (указать фамилию, имя и отчество
контрагента без сокращений), именуемый в дальнейшем «Исполнитель»,
зарегистрированный в ЕГРИП за номером _______________ (указать номер
регистрации индивидуального предпринимателя в ЕГРИП), действующий на
основании свидетельства о регистрации физического лица в качестве
индивидуального
предпринимателя
_____________________
(указать
реквизиты свидетельства) (условие, выделенное курсивом, включается в
Договор, если индивидуальный предприниматель зарегистрирован до
31.12.2016), с другой стороны,
при совместном упоминании именуемые «Стороны», а по отдельности –
«Сторона», заключили настоящий договор (далее – Договор) о нижеследующем:
1. ПРЕДМЕТ ДОГОВОРА
1.1. Исполнитель обязуется на основании утвержденных Заказчиком
заявок (далее – утвержденные Заявки) в соответствии с Техническими
требованиями (Приложение № 1 к Договору) выполнять работы (далее – Работы)
по модификации программы для ЭВМ «Конструктор логических моделей/схем
противоаварийной автоматики» (далее – Программа для ЭВМ):
 актуализировать эскизный проект на Программу для ЭВМ (далее –
эскизный проект);
 осуществлять модификацию Программы для ЭВМ, включая разработку
и актуализацию документации на модифицированную Программу для ЭВМ;
 проводить
предварительные
испытания
работоспособности
модифицированной Программы для ЭВМ;
 выполнять работы, необходимые для осуществления внедрения
модифицированной Программы для ЭВМ,
19
и передавать Заказчику результаты Работ по Договору, а Заказчик
обязуется принимать результаты Работ по Договору и оплачивать их.
1.2. Договор в соответствии со ст. 429.1 Гражданского кодекса
Российской Федерации является рамочным и определяет общие условия
обязательственных взаимоотношений Сторон, которые конкретизируются
Сторонами в утвержденных Заявках.
1.3. В утвержденных Заявках определяются: требования Заказчика к
способам и результатам выполнения Работ, цели выполнения Работ,
наименование, содержание и объемы выполнения Работ, сроки их выполнения,
стоимость Работ в соответствии с согласованной Сторонами Оценкой
трудозатрат, а также иные сведения, указанные в п. 7.1.1 Технических
требований (Приложение № 1 к Договору). Работы выполняются иждивением
Исполнителя – его силами и средствами.
1.4. Срок выполнения Работ по Договору:
– дата начала выполнения Работ: дата заключения Сторонами Договора;
– дата окончания выполнения Работ: «__» ________ 2027 года.
(Указывается дата окончания выполнения Работ в соответствии с
Конкурсной заявкой Победителя конкурса, но не ранее 01.08.2027 и не позднее
31.08.2027)
Сроки выполнения Работ по каждой утвержденной Заявке устанавливаются
в соответствующей утвержденной Заявке. Независимо от окончания срока
выполнения Работ по Договору, Работы должны быть выполнены Исполнителем
по всем утвержденным в течение действия Договора Заявкам.
1.5. Результатами Работ по Договору является модифицированная в
соответствии с утвержденными Заявками Программа для ЭВМ, успешно
прошедшая внедрение у Заказчика.
2. ПОРЯДОК СОГЛАСОВАНИЯ ЗАЯВОК К ДОГОВОРУ
2.1. В течение срока выполнения Работ по Договору, предусмотренного
пунктом 1.4 Договора, Заказчик направляет Исполнителю заявки способом,
указанным в п. 16.4 Договора (далее – заявка(и)). В заявке должны быть указаны
Работы, подлежащие выполнению Исполнителем, требования к способам и
результатам выполнения Работ, цели выполнения Работ, оценка трудозатрат на
выполнение Работ по заявке и ориентировочные сроки выполнения Работ по
заявке.
2.2. Не позднее 7 (Семи) рабочих дней с даты направления Заказчиком
заявки Исполнитель дорабатывает заявку с учетом п. 7.1.1 Технических
требований (Приложение № 1 к Договору) и предоставляет Заказчику на
утверждение подписанную со своей стороны заявку, включающую оценку
трудозатрат на выполнение Работ по заявке (далее – Оценка трудозатрат).
Оценка трудозатрат должна быть составлена по форме Приложения № 3 к
Договору с использованием стоимости по ставкам оплаты труда специалистов в
час, указанной в Соглашении о тарифах (Приложение № 2 к Договору).
20
Заказчик утверждает заявку не позднее 5 (Пяти) рабочих дней с момента
получения ее от Исполнителя или в те же сроки направляет Исполнителю отказ
от согласования документа с указанием причин отказа.
В случае отказа Заказчика от утверждения заявки Исполнитель обязан
доработать заявку и повторно представить Заказчику на утверждение не позднее
2 (Двух) рабочих дней после получения отказа Заказчика.
Утверждение представленной Исполнителем заявки после ее доработки по
замечаниям Заказчика производится Заказчиком в сроки, предусмотренные
настоящим пунктом Договора.
С момента утверждения заявки Заказчиком утвержденная Заявка становится
неотъемлемой частью Договора.
3. ЦЕНА ДОГОВОРА И ПОРЯДОК РАСЧЕТОВ
3.1.
Цена Договора (общая стоимость Работ) не может превышать
_________ (указать сумму прописью) рублей ____ копеек, кроме того НДС (22
%) в размере ______ (указать сумму прописью) рублей __ копеек. Всего цена
Договора (общая стоимость Работ) с учетом НДС (22 %) не может превышать
_____ (указать сумму прописью) рублей __ копеек.
(В случае, если Исполнитель применяет упрощенную систему
налогообложения и освобождается от исполнения обязанностей
налогоплательщика НДС в соответствии с пунктом 1 статьи 145 НК РФ,
включается условие: «без НДС в связи с освобождением от уплаты НДС
Исполнителя, применяющего упрощенную систему налогообложения, согласно
пункта 1 статьи 145 НК РФ»)
(При этом стоимость Работ не должна превышать: в 2026 году –
4 864 550 (Четыре миллиона восемьсот шестьдесят четыре тысячи пятьсот
пятьдесят) рублей 00 копеек, кроме того НДС (22 %), в 2027 году – 15 000 000
(Пятнадцать миллионов) рублей 00 копеек, кроме того НДС (22 %).)
Цена Договора определяется как сумма стоимости Работ по всем
утвержденным Заявкам в течение действия Договора.
Стоимость Работ, выполняемых Исполнителем по каждой утвержденной
Заявке, определяется в каждой утвержденной Заявке на основе фактических
трудозатрат – количества человеко-часов, исходя из стоимости по ставкам
оплаты труда специалистов в час, указанной в Соглашении о тарифах
(Приложение № 2 к Договору).
Стоимость по ставкам оплаты труда специалистов в час, указанная в
Соглашении о тарифах (Приложение № 2 к Договору), является твердой, не
подлежит изменению в течение действия Договора, включает все расходы
Исполнителя, связанные с исполнением обязательств по Договору, стоимость
Работ, учитывает стоимость Работ, прямо не упомянутых в Договоре, но
необходимых для завершения выполнения Работ по Договору, а также
причитающееся Исполнителю вознаграждение.
3.2. Оплата выполненных Работ по каждой утвержденной Заявке
производится Заказчиком в течение 7 (Семи) рабочих дней со дня подписания
21
Сторонами Универсального передаточного документа (далее – УПД) или Акта о
приемке выполненных работ (по форме Приложения № 4 к Договору) (далее –
Акт о приемке выполненных работ) по соответствующей утвержденной Заявке
при условии выставления Исполнителем Заказчику счета на оплату и счетафактуры, оформленного в соответствии с требованиями действующего
законодательства Российской Федерации (в случае, если
Исполнитель
применяет упрощенную систему налогообложения и освобождается от
исполнения обязанностей налогоплательщика НДС в соответствии с пунктом 1
статьи 145 НК РФ, условие о счете-фактуре в Договор не включается).
3.3.
Оплата производится путем перечисления Заказчиком денежных
средств на расчетный счет Исполнителя.
3.4.
Моментом оплаты считается дата списания денежных средств с
расчетного счета Заказчика.
3.5.
Предоставляемые Исполнителем первичные учетные документы
должны быть оформлены в соответствии с требованиями Федерального закона
от 06.12.2011 № 402-ФЗ «О бухгалтерском учете».
4. ПРАВА И ОБЯЗАННОСТИ СТОРОН
4.1. Исполнитель обязан:
4.1.1. Выполнить Работы в полном объеме в течение срока,
предусмотренного в пункте 1.4 Договора.
4.1.2. Выполнить Работы в порядке и на условиях, предусмотренных
Договором, в том числе в соответствии с Техническими требованиями
(Приложение № 1 к Договору), утвержденными Заявками, эскизным проектом,
актуализированным Исполнителем по Договору и утвержденным Заказчиком,
требованиями действующих нормативных правовых актов Российской
Федерации, нормативных документов федеральных органов исполнительной
власти Российской Федерации (в том числе технических норм, правил,
стандартов), локальными нормативными актами Заказчика, иными исходными
данными, переданными Заказчиком.
4.1.3. В ходе выполнения Работ по каждой утвержденной Заявке,
необходимых для осуществления внедрения модифицированной Программы для
ЭВМ, Исполнитель обязан:
1) принимать участие в установке и настройке, тестировании
модифицированной Программы для ЭВМ на испытательных стендах Заказчика
(удаленно средствами защищенного удаленного доступа):
– в рамках проведения установки и настройки, тестирования
модифицированной Программы для ЭВМ в проверке соответствия
характеристик модифицированной Программы для ЭВМ требованиям
Технических требований (Приложение № 1 к Договору), утвержденной Заявке,
эскизному проекту, актуализированному Исполнителем по Договору и
утвержденному Заказчиком, в том числе проверке полноты и качества
выполнения модифицированной Программой для ЭВМ функций во всех
режимах функционирования модифицированной Программы для ЭВМ, проверке
22
надежности и устойчивости функционирования модифицированной Программы
для ЭВМ, проверке реакции модифицированной Программы для ЭВМ на
некорректную информацию, ошибки пользователя и аварийные ситуации,
проверке полноты сообщений, команд, запросов, доступных пользователю
модифицированной Программы для ЭВМ и их достаточности для эксплуатации
модифицированной Программы для ЭВМ;
– в проверке разработанной и актуализированной документации на
модифицированную Программу для ЭВМ, указанной в Технических
требованиях (Приложение № 1 к Договору), на соответствие утвержденной
Заявке, в том числе проверке наличия в документации рекомендаций по
восстановлению работоспособности модифицированной Программы для ЭВМ
после отказов и полноты их описания;
– в интеграции модифицированной Программы для ЭВМ в
информационную среду Заказчика, в том числе корректировке параметров
настройки модифицированной Программы для ЭВМ с учетом взаимодействия
модифицированной Программы для ЭВМ с другими автоматизированными
системами, входящими в состав ИТ-инфраструктуры Заказчика, настройке
параметров работы модифицированной Программы для ЭВМ, отладке работы
модифицированной Программы для ЭВМ на аппаратных средствах Заказчика,
анализе результатов выполнения сценариев интеграции модифицированной
Программы
для
ЭВМ,
выполнении
корректировки
параметров
модифицированной Программы для ЭВМ с учетом текущих изменений в объекте
автоматизации;
2) выполнять анализ и оперативное исправление ошибок, выявленных в
работе модифицированной Программы для ЭВМ по результатам установки,
настройки, тестирования модифицированной Программы для ЭВМ и устранять
причины, влекущие возникновение ошибок, для обеспечения правильной работы
функций модифицированной Программы для ЭВМ;
3) проводить консультирование специалистов Заказчика по работе с
модифицированной Программой для ЭВМ с целью обеспечения их
самостоятельной работы с модифицированной Программой для ЭВМ и ее
обновления;
4) проводить иные мероприятия, предусмотренные Техническими
требованиями (Приложение № 1 к Договору).
Техническим средством взаимодействия между Исполнителем и
Заказчиком в ходе выполнения Исполнителем Работ по второй и последующим
утвержденным Заявкам, в ходе приемки Заказчиком результатов Работ по второй
и последующим утвержденным Заявкам, в течение гарантийного срока на
результат Работ по второй и последующим утвержденным Заявкам (п. 6.1
Договора) является Автоматизированная система учета заявок Заказчика (далее –
АСУЗ). Заказчик предоставляет Исполнителю удаленный доступ к АСУЗ в
соответствии с условиями Договора.
4.1.4. В ходе работ по первой утвержденной Заявке актуализировать и
предоставить на утверждение Заказчику актуализированный эскизный проект. В
23
случае отказа Заказчика от утверждения актуализированного эскизного проекта
доработать документ и повторно представить его Заказчику на утверждение не
позднее 5 (Пяти) рабочих дней со дня получения отказа Заказчика.
Модификацию Программы для ЭВМ осуществлять на основании утвержденного
Заказчиком актуализированного эскизного проекта.
4.1.5. В ходе выполнения Работ по второй и последующим утвержденным
Заявкам проводить предварительные испытания модифицированной Программы
для ЭВМ, по результатам предварительных испытаний подготовить протокол
предварительных испытаний модифицированной Программы для ЭВМ, а также
подготовить и утвердить акт готовности модифицированной Программы для
ЭВМ к процедуре внедрения в АО «СО ЕЭС».
4.1.6. Не позднее 5 (Пяти) рабочих дней до начала проведения
предварительных испытаний модифицированной Программы для ЭВМ по
второй утвержденной Заявке представить Заказчику на согласование
разработанную программу и методику испытаний модифицированной
Программы для ЭВМ (п. 7.1.4 Технических требований (Приложение № 1 к
Договору)), а также на рассмотрение и согласование разработанную и
актуализированную документацию на модифицированную Программу для ЭВМ
по второй утвержденной Заявке (п.п. 7.1.3, 7.1.5 Технических требований
(Приложение № 1 к Договору)).
Не позднее 5 (Пяти) рабочих дней до начала проведения предварительных
испытаний модифицированной Программы для ЭВМ по последующим
утвержденным
Заявкам
представлять
Заказчику
на
согласование
актуализированную программу и методику испытаний модифицированной
Программы для ЭВМ (п. 7.1.4 Технических требований (Приложение № 1 к
Договору)), а также на рассмотрение и согласование разработанную и
актуализированную документацию на модифицированную Программу для ЭВМ
по последующим утвержденным Заявкам (п.п. 7.1.3, 7.1.5 Технических
требований (Приложение № 1 к Договору)).
В случае отказа Заказчика от согласования (рассмотрения)
соответствующего документа доработать документ и повторно представить
Заказчику на согласование (рассмотрение) не позднее 3 (Трех) рабочих дней
после получения отказа Заказчика.
4.1.7. В ходе выполнения Работ по второй и последующим утвержденным
Заявкам создавать дистрибутивы модифицированной Программы для ЭВМ
путем компиляции и сборки в автоматизированной информационной системе
«Фонд программ и алгоритмов» (далее – АИС «ФПА») Заказчика из
предоставленного Исполнителем исходного текста (кода) в соответствии с п.
4.3.9.1 Технических требований (Приложение № 1 к Договору).
4.1.8. После успешного окончания предварительных испытаний
модифицированной Программы для ЭВМ в соответствии с п.п. 4.3.9.1, 5.1
Технических требований (Приложение № 1 к Договору) по второй и
последующим утвержденным Заявкам передать Заказчику модифицированную
Программу для ЭВМ (дистрибутив (включая инсталляционный пакет), исходный
24
текст (код) и прочие файлы, необходимые для создания дистрибутива (сторонние
библиотеки, скрипты и т.д.) модифицированной Программы для ЭВМ), а также
разработанную и актуализированную документацию на модифицированную
Программу для ЭВМ согласно п.п. 7.1.3-7.1.5 Технических требований
(Приложение № 1 к Договору) в электронном виде в АИС «ФПА» Заказчика с
учетом требований к формату документации, установленных пунктом 7.2
Технических требований (Приложение № 1 к Договору).
4.1.9. За свой счет и в сроки, установленные Заказчиком, устранять
недостатки, выявленные в ходе выполнения Исполнителем Работ по
соответствующей утвержденной Заявке, при приемке Заказчиком результата
Работ по соответствующей утвержденной Заявке, а также в течение
гарантийного срока на результат Работ по второй и последующим утвержденным
Заявкам (пункт 6.1 Договора).
Факт устранения недостатков, выявленных в ходе выполнения Работ по
второй и последующим утвержденным Заявкам, при приемке Заказчиком
результата Работ по соответствующей утвержденной Заявке, а также в течение
гарантийного срока на результат Работ по второй и последующим утвержденным
Заявкам (п. 6.1 Договора) фиксируется Сторонами в АСУЗ.
В срок, установленный Заказчиком для устранения недостатков по второй
и последующим утвержденным Заявкам, Исполнитель обязан передавать
Заказчику дистрибутив (включая инсталляционный пакет), исходный текст (код)
и прочие файлы, необходимые для создания дистрибутива (сторонние
библиотеки, скрипты и т.д.) модифицированной Программы для ЭВМ,
разработанную и актуализированную документацию на модифицированную
Программу для ЭВМ (п.п. 7.1.3-7.1.5 Технических требований (Приложение № 1
к Договору)) с внесенными в ходе устранения недостатков изменениями.
Устранение недостатков модифицированной Программы для ЭВМ не является
ее последующей модификацией.
4.1.10.
Исполнять полученные в ходе выполнения Работ указания
Заказчика, если такие указания не противоречат условиям Договора и не
представляют собой вмешательства в деятельность Исполнителя.
4.1.11.
Незамедлительно известить Заказчика и до получения от него
указаний приостановить Работы при обнаружении:

возможных неблагоприятных для Заказчика последствий
исполнения его указаний о выполнении Работ;

иных не зависящих от Исполнителя обстоятельств, угрожающих
качеству результатам Работ или могущих повлечь изменение сроков или объема
выполнения Работ.
4.1.12.
Выставлять Заказчику счета-фактуры в соответствии с
действующим законодательством Российской Федерации. В случае если
Исполнитель не выставил в срок счет-фактуру либо выставил счет-фактуру,
содержание которого не соответствует требованиям действующего
законодательства Российской Федерации, Заказчик вправе взыскать с
Исполнителя штраф в сумме налога на добавленную стоимость, которая могла
25
бы быть предъявлена Заказчиком к вычету или возмещению из бюджета при
условии надлежащего оформления и предоставления счета-фактуры
Исполнителем. Стороны признают, что для взыскания штрафа,
предусмотренного настоящим пунктом Договора, Заказчик не обязан
доказывать факт отказа налоговых органов в предоставлении Заказчику
указанных выше вычетов или возмещения налога на добавленную стоимость из
бюджета.
(Условие о счете-фактуре не включается в Договор в случае, если
Исполнитель применяет упрощенную систему налогообложения и
освобождается от исполнения обязанностей налогоплательщика НДС в
соответствии с пунктом 1 статьи 145 НК РФ)
4.1.13.
Согласовать с Заказчиком способами, указанными в п. 16.4
Договора, необходимость использования в результатах Работ по каждой
утвержденной Заявке охраняемых результатов интеллектуальной деятельности,
принадлежащих третьим лицам, и правовые основания приобретения прав на их
использование. Права на результаты интеллектуальной деятельности третьих
лиц должны быть переданы Исполнителем Заказчику в счет цены Договора на
срок действия исключительного права на такие результаты интеллектуальной
деятельности, если иной срок использования письменно способами, указанными
в п. 16.4 Договора, не согласован между Заказчиком и Исполнителем. Права на
результаты интеллектуальной деятельности третьих лиц должны быть переданы
Заказчику в объеме, согласованном Сторонами. Все права третьих лиц на
результаты интеллектуальной деятельности, используемые в составе
результатов Работ по соответствующей утвержденной Заявке, должны быть
прямо указаны в разработанной и актуализированной документации на
модифицированную Программу для ЭВМ по соответствующей утвержденной
Заявке.
4.1.14.
Не нарушать в ходе исполнения своих обязательств по
Договору права третьих лиц на результаты интеллектуальной деятельности.
Передать Заказчику полученные по Договору результаты Работ, не нарушая
исключительных прав третьих лиц.
4.1.15.
Самостоятельно урегулировать все вопросы выплаты
вознаграждения авторам модифицированной Программы для ЭВМ в
соответствии с абзацем 3 пункта 2 статьи 1295 Гражданского кодекса Российской
Федерации. Исполнитель гарантирует, что авторы модифицированной по
Договору Программы для ЭВМ не будут иметь каких бы то ни было требований
и претензий в отношении прав Заказчика на модифицированную Программу для
ЭВМ, предусмотренных Договором.
4.1.16.
Использовать Технические требования (Приложение № 1 к
Договору) и утвержденные Заявки только для выполнения своих обязательств по
Договору. Исполнитель осведомлен о том, что Технические требования
(Приложение № 1 к Договору) и утвержденные Заявки являются
подготовительным материалом для модификации Программы для ЭВМ,
охраняемым авторским правом в соответствии со статьей 1261 Гражданского
26
кодекса Российской Федерации, и при их использовании по Договору обязуется
не нарушать охраняемые в соответствии с действующим законодательством
Российской Федерации права Заказчика и третьих лиц.
4.1.17.
Представлять Заказчику сведения о ходе выполнения Работ в
течение 3 (Трех) рабочих дней со дня получения от Заказчика соответствующего
запроса.
4.1.18.
Выполнить Работы лично (без привлечения третьих лиц).
4.1.19.
В течение 3 (Трех) рабочих дней со дня окончания выполнения
Работ по Договору или расторжения / прекращения Договора по любым
основаниям возвратить Заказчику все материальные носители, содержащие
переданные Заказчиком для выполнения Работ исходный текст (код),
дистрибутив, эксплуатационную документацию на Программу для ЭВМ, а также
уничтожить все копии экземпляров Программы для ЭВМ и прочих связанных с
Программой для ЭВМ файлов и материалов, записанные в память ЭВМ
Исполнителя. Возврат Исполнителем материальных носителей, содержащих
переданные Заказчиком для выполнения Работ по Договору исходный текст
(код), дистрибутив, эксплуатационную документацию на Программу для ЭВМ, а
также экземпляры Программы для ЭВМ и прочие связанные с Программой для
ЭВМ файлы и материалы оформляется передаточным актом.
4.1.20.
Для технической возможности предоставления защищенного
удаленного доступа (далее – ЗУД) Исполнитель обязан:
– предоставить отчуждаемые носители ключевой информации в
удостоверяющий центр Заказчика вместе с заявлением на регистрацию субъекта
информационного обмена и заявлением на получение ключа и сертификата
ключа проверки электронной подписи в соответствии с «Соглашением об
использовании субъектом информационного обмена электронной подписи при
информационном обмене с АО «СО ЕЭС» (с юридическим лицом)»,
заключенным с Заказчиком по форме, утвержденной Заказчиком;
– иметь установленное клиентское программное обеспечение,
предназначенное для создания защищенного соединения с корпоративной
информационной системой Заказчика. Клиентское программное обеспечение
Исполнителя должно быть совместимо с эксплуатируемыми у Заказчика
средствами криптографической защиты информации, используемыми для
организации ЗУД;
– незамедлительно предоставлять по требованию Заказчика материалы и
объяснения, связанные с выявленной подозрительной активностью в отношении
корпоративных ресурсов Заказчика и/или Системы, исходящей из
информационной инфраструктуры или от специалистов Исполнителя.
4.1.21. Выполнить Работы силами квалифицированных специалистов в
количестве _______________ специалистов (указывается в соответствии с
Конкурсной заявкой Победителя конкурса, но не менее 7 (Семи) специалистов),
имеющих документы, подтверждающие квалификацию, указанные в п. 4.1.
Технических требований (Приложение № 1 к Договору), в том числе
___________ специалиста (-ов), имеющего (-их) документы о повышении
27
квалификации (обучении) в области администрирования операционной системы
Astra Linux (указывается в соответствии с Конкурсной заявкой Победителя
конкурса, но не менее 1 (Одного) специалиста). Также для выполнения работ
необходимо привлечь специалиста, обладающего подтвержденным опытом
работы в области UX/UI-дизайна в соответствии с п. 4.1. Технических
требований (Приложение № 1 к Договору).
4.1.22. В процессе исполнения обязательств по Договору и по их
завершении соблюдать права Заказчика на Программу для ЭВМ, включая ее
отдельные элементы, конфигурации, модули, исправления, обновления, любые
иные результаты интеллектуальной деятельности, включая подготовительные
материалы; не передавать третьим лицам и не использовать самостоятельно
Программу для ЭВМ, ее отдельные элементы, конфигурации, модули,
исправления, обновления, любые иные результаты интеллектуальной
деятельности, включая подготовительные материалы, в целях не связанных с
исполнением Договора.
4.1.23.
Выполнить иные обязанности, предусмотренные Договором и
действующим законодательством Российской Федерации.
4.2. Заказчик обязан:
4.2.1. Предоставить Исполнителю всю информацию и документы,
имеющиеся у Заказчика и необходимые Исполнителю для исполнения
обязательств по Договору, в том числе локальные нормативные акты Заказчика,
исходный текст (код), дистрибутив, эксплуатационную документацию на
Программу для ЭВМ. Исходный текст (код), дистрибутив, эксплуатационная
документация на Программу для ЭВМ передаются Исполнителю в электронном
виде на материальном носителе (компакт-диске CD или ином электронном
носителе). Передача Исполнителю исходного текста (кода), дистрибутива,
эксплуатационной документации на Программу для ЭВМ оформляется
передаточным актом.
4.2.2. Принять и оплатить результаты Работ по утвержденным Заявкам,
выполненных Исполнителем с надлежащим качеством и в соответствии с
условиями Договора.
4.2.3. Утвердить актуализированный Исполнителем эскизный проект на
Программу для ЭВМ или направить Исполнителю отказ от утверждения
актуализированного эскизного проекта не позднее 15 (Пятнадцати) рабочих дней
с момента получения его от Исполнителя.
Утверждение представленного Исполнителем актуализированного
эскизного проекта после его доработки по замечаниям Заказчика производится
Заказчиком в сроки, предусмотренные настоящим пунктом Договора.
4.2.4. Согласовывать представленные Исполнителем по второй и
последующим утвержденным Заявкам разработанную или актуализированную
программу и методику испытаний модифицированной Программы для ЭВМ
(п. 7.1.4 Технических требований (Приложение № 1 к Договору)), рассматривать
и согласовывать разработанную и актуализированную документацию на
модифицированную Программу для ЭВМ (п.п. 7.1.3, 7.1.5 Технических
28
требований (Приложение № 1 к Договору)) или направить Исполнителю отказ от
согласования соответствующего документа не позднее 5 (Пяти) рабочих дней с
момента получения их от Исполнителя.
Согласование представленных Исполнителем документов после их
доработки по замечаниям Заказчика производится Заказчиком в сроки,
предусмотренные настоящим пунктом Договора.
4.2.5. С даты подписания Сторонами УПД или Акта о приемке
выполненных работ по первой утвержденной Заявке до окончания гарантийного
срока на результат работ по второй и последующим утвержденным Заявкам
(пункт 6.1 Договора) предоставить Исполнителю удаленный доступ к АСУЗ
Заказчика в целях взаимодействия между Исполнителем и Заказчиком в ходе
выполнения Исполнителем Работ по второй и последующим утвержденным
Заявкам, в ходе приемки Заказчиком результатов Работ по второй и
последующим утвержденным Заявкам и в течение гарантийного срока на
результат Работ по второй и последующим утвержденным Заявкам (п. 6.1
Договора).
4.2.6. С даты подписания Сторонами УПД или Акта о приемке
выполненных работ по первой утвержденной Заявке предоставить Исполнителю
ЗУД к своим корпоративным ресурсам в соответствии с установленной
процедурой Заказчика.
Заказчик вправе осуществлять мониторинг, контроль, запись действий
Исполнителя (процессов, запускаемых от имени Исполнителя), осуществляемых
через ЗУД.
4.2.7. Выполнить иные обязанности, предусмотренные Договором и
действующим законодательством Российской Федерации.
4.3. Исполнитель вправе:
4.3.1. Требовать полной и своевременной оплаты результатов Работ по
утвержденным Заявкам, выполненных Исполнителем с надлежащим качеством и
в соответствии с условиями Договора.
4.3.2. Досрочно с письменного разрешения Заказчика, направленного
способами, указанными в п. 16.4 Договора, выполнять Работы по утвержденным
Заявкам, передавать их результаты Заказчику без изменения цены по
соответствующим утвержденным Заявкам.
4.3.3. Требовать от Заказчика предоставления имеющихся у него
информации и документов, в том числе локальных нормативных актов
Заказчика, необходимых для выполнения Работ.
4.4. Исполнитель не вправе:
4.4.1. Использовать при выполнении Работ технические средства защиты
авторских прав, которыми согласно статье 1299 Гражданского кодекса
Российской Федерации признаются любые технологии, технические устройства
или их компоненты, контролирующие доступ к модифицированной Программе
для ЭВМ, предотвращающие либо ограничивающие осуществление Заказчиком
каких-либо действий в отношении модифицированной Программы для ЭВМ.
29
4.4.2. Использовать результаты Работ по Договору, разработанную и/или
актуализированную документацию по Договору, а также любые
подготовительные и промежуточные материалы, созданные или полученные в
ходе выполнения Работ по Договору, для собственных нужд.
4.5. Заказчик вправе:
4.5.1. В любое время проверять ход и качество Работ, выполняемых
Исполнителем, в том числе получать от Исполнителя информацию о ходе
выполнения Работ, знакомиться с промежуточными результатами Работ,
требовать от Исполнителя представления пояснений о ходе выполнения Работ по
форме, установленной Заказчиком.
4.5.2. В течение действия Договора обращаться к Исполнителю с устными
и письменными запросами с целью разъяснения (конкретизации) выводов,
положений, содержащихся в результате или промежуточном результате Работ.
4.5.3. Назначать Исполнителю разумный срок для устранения недостатков,
выявленных в ходе выполнения Исполнителем Работ по соответствующей
утвержденной Заявке, при приемке Заказчиком результата Работ по
соответствующей утвержденной Заявке, а также в течение гарантийного срока на
результат Работ по второй и последующим утвержденным Заявкам (п. 6.1
Договора).
Заказчик сообщает о недостатках по второй и последующим
утвержденным Заявкам специалисту Группы технического сопровождения
Исполнителя путем регистрации в АСУЗ обращения. Порядок подачи
обращений в АСУЗ установлен в Приложении № 6 к Договору.
4.5.4. Давать указания о способе выполнения Работ, если такие указания не
противоречат условиям Договора и не представляют собой вмешательства в
деятельность Исполнителя.
4.5.5. В любое время отказаться от исполнения Договора в одностороннем
внесудебном порядке полностью или в части при отсутствии нарушения
Исполнителем условий Договора, уплатив Исполнителю только часть стоимости
Работ пропорционально Работам, выполненным до расторжения Договора. При
этом обязанность Заказчика по возмещению Исполнителю понесенных им
убытков, связанных с отказом Заказчика от исполнения Договора,
ограничивается реальным ущербом в размере не более 5 % (Пяти процентов) от
цены Договора.
4.5.6. Привлекать третьих лиц для устранения недостатков, выявленных в
ходе выполнения Работ по второй и последующим утвержденным Заявкам и
(или) в ходе приемки Заказчиком результата Работ по второй и последующим
утвержденным Заявкам, в течение гарантийного срока на результат Работ по
второй и последующим утвержденным Заявкам (п. 6.1 Договора) в случае, если
Исполнитель в течение времени, установленного пунктом 1.8 Порядка подачи
обращений в АСУЗ (Приложение № 6 к Договору) для принятия Исполнителем
обращения Заказчика о недостатках (далее – обращение) в работу, не принял в
работу обращение или отказался от устранения недостатков или уклонился от
устранения недостатков в соответствии с пунктом 1.9 Порядка подачи
30
обращений в АСУЗ (Приложение № 6 к Договору) или не устранил такие
недостатки в установленный Заказчиком срок.
Расходы, связанные с исправлением недостатков, производятся за счет
Исполнителя, а порядок привлечения Заказчиком третьих лиц носит
односторонний уведомительный характер и не требует согласия Исполнителя,
при этом Исполнитель обязан возместить расходы Заказчика в течение 8
(Восьми) рабочих дней с момента получения Исполнителем требования
Заказчика и документов, подтверждающих расходы Заказчика.
5. ПОРЯДОК СДАЧИ-ПРИЕМКИ РЕЗУЛЬТАТА РАБОТ
5.1.
Приемка результата Работ по второй и последующим
утвержденным Заявкам осуществляется Заказчиком только при положительном
результате проведенных предварительных испытаний работоспособности
модифицированной Программы для ЭВМ, установки и настройки, тестирования
модифицированной Программы для ЭВМ, а также при условии надлежащего
оформления представленных документов (п.п. 5.2, 5.3 Договора).
5.2.
В дату окончания Работ по первой утвержденной Заявке
Исполнитель направляет Заказчику способами, указанными в п. 16.4 Договора,
письменное уведомление о готовности результата выполненных Работ по первой
утвержденной Заявке к сдаче, а также документы в составе:
– утвержденный Заказчиком актуализированный эскизный проект на
модифицированную Программу для ЭВМ;
– надлежащим образом оформленный и подписанный со своей стороны
УПД или Акт о приемке выполненных работ по соответствующей утвержденной
Заявке;
– счет на оплату и счет-фактуру, оформленный в соответствии с
требованиями действующего законодательства Российской Федерации (В
случае, если Исполнитель применяет упрощенную систему налогообложения и
освобождается от исполнения обязанностей налогоплательщика НДС в
соответствии с пунктом 1 статьи 145 НК РФ, условия о счете-фактуре в
Договор не включается).
5.3.
В дату окончания Работ по второй и последующим утвержденным
Заявкам Исполнитель направляет Заказчику способами, указанными в п. 16.4
Договора, письменное уведомление о готовности результата выполненных Работ
по соответствующей утвержденной Заявке к сдаче, результат Работ по
соответствующей утвержденной Заявке, а также документы в составе:
– модифицированная Программа для ЭВМ (дистрибутив (включая
инсталляционный пакет) и исходный текст (код) и прочие файлы, необходимые
для создания дистрибутива (сторонние библиотеки, скрипты и т.д.)
модифицированной Программы для ЭВМ);
–
разработанная
и
актуализированная
документация
на
модифицированную Программу для ЭВМ согласно пунктам 7.1.3-7.1.5
Технических требований (Приложение № 1 к Договору), согласованная с
Заказчиком,
31
– надлежащим образом оформленный и подписанный со своей стороны
УПД или Акт о приемке выполненных работ по соответствующей утвержденной
Заявке;
– счет на оплату и счет-фактуру, оформленный в соответствии с
требованиями действующего законодательства Российской Федерации (В
случае, если Исполнитель применяет упрощенную систему налогообложения и
освобождается от исполнения обязанностей налогоплательщика НДС в
соответствии с пунктом 1 статьи 145 НК РФ, условия о счете-фактуре в
Договор не включается).
5.4.
Заказчик подписывает УПД или Акт о приемке выполненных
работ по соответствующей утвержденной Заявке в течение 15 (Пятнадцати)
рабочих дней со дня представления Исполнителем результата Работ по
соответствующей утвержденной Заявке и всех документов, указанных в пунктах
5.2 или 5.3 Договора, при условии надлежащего выполнения Работ по
соответствующей утвержденной Заявке, а также при надлежащем оформлении
представленных документов либо в этот же срок направляет Исполнителю
письменный отказ от подписания УПД или Акта о приемке выполненных работ
по соответствующей утвержденной Заявке с указанием причин отказа.
При этом, Заказчик также сообщает о недостатках в результате Работ по
второй и последующим утвержденным Заявкам специалисту Группы
технического сопровождения Исполнителя путем регистрации в АСУЗ
обращения в соответствии с Порядком подачи обращений в АСУЗ (Приложение
№ 6 к Договору).
5.5.
В случае отказа Заказчика от подписания УПД или Акта о приемке
выполненных работ по соответствующей утвержденной Заявке Исполнитель
обязан устранить выявленные Заказчиком недостатки в результате Работ по
соответствующей утвержденной Заявке за свой счет в сроки, установленные
Заказчиком.
5.6.
После устранения Исполнителем всех недостатков в результате
Работ по соответствующей утвержденной Заявке Исполнитель осуществляет
сдачу, а Заказчик приемку результата Работ по соответствующей утвержденной
Заявке в порядке и сроки, установленные настоящим разделом Договора. Факт
устранения недостатков в результате Работ по второй и последующим
утвержденным Заявкам фиксируется Сторонами в АСУЗ.
5.7.
После подписания Заказчиком всех УПД или Актов о приемке
выполненных работ по всем утвержденным Заявкам Исполнитель направляет
Заказчику 2 (Два) экземпляра подписанного со своей стороны Технического акта
об установлении гарантийного срока по форме Приложения № 5 к Договору,
который подписывается Заказчиком в течение 3 (Трех) рабочих дней.
5.8.
Досрочная сдача Исполнителем результатов Работ по
утвержденным Заявкам допускается с письменного разрешения Заказчика,
направленного способами, указанными в п. 16.4 Договора, без изменения цены
по соответствующим утвержденным Заявкам.
5.9.
До подписания Сторонами УПД или Акта о приемке выполненных
32
работ по соответствующей утвержденной Заявке риск случайной гибели или
случайного повреждения (утраты) результата Работ по соответствующей
утвержденной Заявке несет Исполнитель.
5.10.
При возникновении между Заказчиком и Исполнителем спора по
поводу недостатков результатов Работ по соответствующей утвержденной
Заявке или их причин по требованию любой из Сторон должна быть назначена
экспертиза. Расходы на экспертизу несет Исполнитель, за исключением случаев,
когда экспертизой установлено отсутствие нарушений Исполнителем Договора
или причинной связи между действиями Исполнителя и обнаруженными
недостатками. В указанных случаях расходы на экспертизу несет Сторона,
потребовавшая назначения экспертизы, а если она назначена по соглашению
между Сторонами, обе Стороны поровну.
6. ГАРАНТИЙНЫЕ ОБЯЗАТЕЛЬСТВА
6.1. На результат Работ по второй и последующим утвержденным
Заявкам, включая разработанную и актуализированную документацию на
модифицированную Программу для ЭВМ (п.п. 7.1.3-7.1.5 Технических
требований (Приложение № 1 к Договору)), устанавливается гарантийный срок.
Дата начала гарантийного срока на результат Работ по второй и
последующим утвержденным Заявкам: дата подписания Сторонами УПД или
Акта о приемке выполненных работ по соответствующей утвержденной Заявке.
Дата окончания гарантийного срока на результат Работ по второй и
последующим утвержденным Заявкам: дата окончания периода, равного ___
(_________) месяцам (указывается гарантийный срок в соответствии с
Конкурсной заявкой Победителя конкурса, но не менее 12 (Двенадцати)
месяцев), исчисляемого с даты подписания Сторонами Технического акта об
установлении гарантийного срока по форме Приложения № 5 к Договору.
6.2. Техническим средством взаимодействия в ходе гарантийного
обслуживания результата Работ по второй и последующим утвержденным
Заявкам между Исполнителем и Заказчиком является АСУЗ. В целях
гарантийного обслуживания результата Работ по второй и последующим
утвержденным Заявкам Заказчик предоставляет Исполнителю удаленный доступ
к АСУЗ в соответствии с условиями Договора.
6.3. Если в течение гарантийного срока обнаружатся недостатки в
результате Работ по второй и последующим утвержденным Заявкам, Заказчик
сообщает об этом специалисту Группы технического сопровождения
Исполнителя путем регистрации в АСУЗ обращения в соответствии с Порядком
подачи обращений в АСУЗ (Приложение № 6 к Договору).
6.4. В случае отказа Исполнителя от исправления недостатков или
уклонения от устранения недостатков в порядке указанном в п. 1.9 Порядка
подачи обращений в АСУЗ (Приложение № 6 к Договору) наличие недостатков,
указанных в пункте 6.3 Договора, фиксируется актом о недостатках,
составляемым Заказчиком и Исполнителем, а при отказе или уклонении
Исполнителя от составления данного акта – Заказчиком с возможным
33
привлечением незаинтересованных третьих лиц с последующим возмещением
Заказчику понесенных им расходов на привлечение таких лиц. Уклонением
Исполнителя от составления акта о недостатках считается неподписание
Исполнителем данного акта в течение 5 (Пяти) рабочих дней с момента
получения уведомления Заказчика об обнаружении недостатков в результате
Работ по соответствующей утвержденной Заявке. Составленный Заказчиком акт
о недостатках в одностороннем порядке или с привлечением третьих лиц имеет
для Исполнителя юридическую силу и является основанием для привлечения к
ответственности.
6.5. Исполнитель устраняет недостатки результата Работ по второй и
последующим утвержденным Заявкам за свой счет в установленные Заказчиком
сроки. Факт устранения недостатков в результате Работ по второй и
последующим утвержденным Заявкам фиксируется Сторонами в АСУЗ.
В срок, установленный Заказчиком для устранения недостатков
Исполнитель
обязан
передавать
Заказчику
дистрибутив
(включая
инсталляционный пакет), исходный текст (код) модифицированной Программы
для ЭВМ и прочие файлы (сторонние библиотеки, скрипты и т.д.), необходимые
для создания дистрибутива модифицированной Программы для ЭВМ,
разработанную и актуализированную документацию на модифицированную
Программу для ЭВМ (пункты 7.1.3_- 7.1.5 Технических требований
(Приложение № 1 к Договору)) с внесенными в ходе устранения недостатков
изменениями. Устранение недостатков модифицированной Программы для
ЭВМ не является ее последующей модификацией.
6.6. Гарантийный срок на результат Работ по второй и последующим
утвержденным Заявкам продлевается на период устранения недостатков.
7. ОТВЕТСТВЕННОСТЬ СТОРОН
7.1.
За неисполнение или ненадлежащее исполнение принятых по
Договору обязательств Стороны несут ответственность в соответствии с
действующим законодательством Российской Федерации и положениями
Договора.
7.2.
В случае нарушения установленного Договором срока оплаты
выполненных Работ по соответствующей утвержденной Заявке Заказчик обязан
уплатить Исполнителю по требованию последнего пени в размере 0,02 % (Ноль
целых две сотых процента) на сумму просроченных к оплате денежных средств
по соответствующей утвержденной Заявке за каждый день просрочки
исполнения и/или ненадлежащего исполнения обязательств до момента их
надлежащего исполнения или дня прекращения Договора.
7.3.
В случае нарушения установленного в соответствующей
утвержденной Заявке срока начала или окончания выполнения Работ по
соответствующей утвержденной Заявке, установленного Заказчиком срока
устранения недостатков, выявленных в ходе выполнения Исполнителем Работ по
соответствующей утвержденной Заявке, при приемке Заказчиком результата
Работ по соответствующей утвержденной Заявке, включая нарушение срока
34
устранения недостатков вследствие не передачи Заказчику дистрибутива
модифицированной Программы для ЭВМ (включая инсталляционный пакет),
исходного текста (кода) и прочих файлов, необходимых для создания
дистрибутива (сторонние библиотеки, скрипты и т.д.) модифицированной
Программы для ЭВМ, разработанной и актуализированной документации на
модифицированную Программу для ЭВМ (п.п. 7.1.3-7.1.5 Технических
требований (Приложение № 1 к Договору)) с внесенными в ходе устранения
недостатков изменениями, Исполнитель обязан уплатить Заказчику по
требованию последнего за каждый факт нарушения Договора пени в размере
0,02 % (Ноль целых две сотых процента) от стоимости Работ по
соответствующей утвержденной Заявке, за каждый день просрочки исполнения
и/или ненадлежащего исполнения обязательств до дня их надлежащего
исполнения или дня прекращения Договора.
7.4.
В случае нарушения Исполнителем установленного Заказчиком
срока устранения недостатков в результате Работ по второй и последующим
утвержденным Заявкам в период гарантийного срока (пункт 6.1 Договора),
включая нарушение срока устранения недостатков вследствие не передачи
Заказчику дистрибутива модифицированной Программы для ЭВМ (включая
инсталляционный пакет), исходного текста (кода) и прочих файлов,
необходимых для создания дистрибутива (сторонние библиотеки, скрипты и т.д.)
модифицированной Программы для ЭВМ, документации на модифицированную
Программу для ЭВМ (п.п. 7.1.3-7.1.5 Технических требований (Приложение № 1
к Договору)) с внесенными в ходе устранения недостатков изменениями,
Исполнитель по требованию Заказчика выплачивает последнему пени в размере
0,02 % (Ноль целых две сотых процента) от цены Договора (пункт 3.1 Договора)
за каждый день просрочки исполнения и/или ненадлежащего исполнения
обязательств до дня их надлежащего исполнения или дня прекращения
Договора.
7.5.
В случае обнаружения в процессе выполнения Работ,
необходимых для внедрения модифицированной Программы для ЭВМ по
соответствующей утвержденной Заявке, недостатков модифицированной
Программы для ЭВМ, которые не указаны в протоколах предварительных
испытаний модифицированной Программы для ЭВМ, оформленных по
результатам предварительных испытаний по соответствующей утвержденной
Заявке, и которые не могли быть выявлены Заказчиком при приемке результата
Работ по соответствующей утвержденной Заявке, в том числе такие, которые
были умышленно скрыты Исполнителем, Исполнитель обязан уплатить
Заказчику по требованию последнего за каждый факт нарушения Договора
штраф в размере 0,1 % (Ноль целых одна десятая процента) от стоимости Работ
по соответствующей утвержденной Заявке.
7.6.
В случае использования в составе результата Работ по
соответствующей утвержденной Заявке результатов интеллектуальной
деятельности, права на которые принадлежат третьим лицам, при отсутствии
согласования Заказчика и/или указания на их использование в разработанной и
35
актуализированной документации на модифицированную Программу для ЭВМ
по соответствующей утвержденной Заявке Исполнитель обязан уплатить
Заказчику по требованию последнего штраф в размере 100 000 (Сто тысяч)
рублей за каждый объект прав, независимо от наличия или отсутствия претензий
третьих лиц. Уплата указанного штрафа не освобождает Исполнителя от
возмещения убытков, связанных с претензиями правообладателей – третьих лиц,
в полном объеме сверх суммы штрафа.
7.7.
В случае разглашения конфиденциальной информации Заказчика
Исполнитель обязан уплатить Заказчику по требованию последнего штраф в
размере 100 000 (Сто тысяч) рублей за каждый случай разглашения
конфиденциальной информации, а также возместить убытки в полном объеме
сверх суммы штрафа.
7.8.
В случае неисполнения или ненадлежащего исполнения
Исполнителем обязательств по Договору, если за такое неисполнение или
ненадлежащее исполнение конкретный вид санкции не установлен Договором,
Исполнитель обязан уплатить Заказчику по требованию последнего за каждый
факт нарушения Договора штраф в размере 0,1 % (Ноль целых одна десятая
процента) от цены Договора (пункт 3.1 Договора).
В случае если указанное в настоящем пункте Договора неисполнение
(ненадлежащее исполнение) обязательств Исполнителя носит длящийся
характер, Исполнитель обязан уплатить Заказчику по требованию последнего за
каждый факт нарушения Договора пени в размере 0,05% (Ноль целых пять сотых
процента) от цены Договора (пункт 3.1 Договора), за каждый день просрочки
исполнения и/или ненадлежащего исполнения обязательств до момента их
надлежащего исполнения или дня прекращения Договора.
7.9.
Определение суммы неустойки возможно в досудебном порядке
при признании суммы неустойки Стороной, нарушившей обязательства, и
уведомлении об этом другой Стороны. После получения Стороной способами,
указанными в п. 16.4 Договора, надлежаще оформленного уведомления о
признании Стороной, нарушившей обязательства, суммы неустойки Сторона
выставляет счет на оплату, который подлежит оплате в течение 8 (Восьми)
рабочих дней.
В случае непризнания Стороной, нарушившей обязательства, или
признания, но неоплаты суммы неустойки, указанной в уведомлении,
окончательная (общая) сумма неустойки определяется на основании решения
суда.
7.10. Уплата неустойки не освобождает Сторону от исполнения
обязательств по Договору.
7.11. В случае нарушения Исполнителем условий соглашения о
соблюдении требований по информационной безопасности, заключенного
между Сторонами, Исполнитель обязан уплатить Заказчику по требованию
последнего штраф в размере 100 000 (Сто тысяч) рублей за каждый выявленный
факт нарушения, в том числе независимо от наличия или отсутствия претензий
третьих лиц. Уплата указанного штрафа не освобождает Исполнителя от
36
возмещения убытков, понесенных Заказчиком и (или) связанных с претензиями
третьих лиц, в полном объеме сверх суммы штрафа.
7.12. В случае предъявления Заказчику иска, связанного с нарушением
прав третьих лиц, в том числе с нарушением их интеллектуальных прав,
Исполнитель обязан возместить Заказчику понесенные в связи с этим убытки в
полном объеме.
7.13. В случае нарушения Исполнителем обязательств, установленных
пунктом 4.1.22 Договора, Исполнитель обязан уплатить Заказчику по
требованию последнего штраф в размере 100 000 (Сто тысяч) рублей за каждый
выявленный факт нарушения обязательства. Уплата указанного штрафа не
освобождает Исполнителя от возмещения убытков, понесенных Заказчиком в
полном объеме сверх суммы штрафа.
7.14. Суммарные выплаты Стороны за неисполнение или ненадлежащее
исполнение принятых по Договору обязательств (за исключением возмещения
Исполнителем убытков, связанных с претензиями правообладателей – третьих
лиц по пунктам 7.6, 7.12, 7.13 Договора, которые возмещаются в полном объеме)
не должны превышать цену Договора. Суммы возмещения убытков по
пунктам 7.6, 7.12, 7.13 Договора не учитываются в целях расчета суммарных
выплат Исполнителя за неисполнение или ненадлежащее исполнение принятых
по Договору обязательств в соответствии с настоящим пунктом Договора.
7.15. Исполнитель несет ответственность за актуализацию эскизного
проекта, включая недостатки, обнаруженные впоследствии в ходе модификации
или эксплуатации модифицированной на основе указанной документации
Программы для ЭВМ. При обнаружении недостатков Исполнитель по
требованию Заказчика обязан переделать актуализированный эскизный проект и
модифицированную Программу для ЭВМ, включая документацию на нее, а
также возместить Заказчику причиненные убытки.
7.16. Исполнитель обязуется возместить Заказчику убытки, понесенные
им в связи с неисполнением или ненадлежащим исполнением обязательств
Исполнителем, в полном объеме сверх неустойки.
7.17. Исполнитель в соответствии со ст. 431.2 ГК РФ заверяет Заказчика
о том, что:
- основной целью заключения Договора, совершения операций по
Договору не являются неуплата (неполная уплата) или зачет (возврат) суммы
налога;
- располагает организационными, производственными, материальными,
финансовыми, кадровыми и иными ресурсами, необходимыми для исполнения
договора;
- обязательства и операции по Договору исполняются Исполнителем или
лицом, которому обязательство передано по Договору или закону. Исполнитель
не привлекает для исполнения обязательств и операций по договору физических
лиц, отношения с которыми не оформлены надлежащим образом;
- документы, составленные при заключении и исполнении Договора, не
содержат искажения сведений о фактах хозяйственной жизни. Все операции по
37
Договору Исполнитель надлежащим образом отражает в налоговом и
бухгалтерском учете;
- руководствуется в своей деятельности принципом добросовестности и
надлежащим образом в соответствии с требованиями Налогового кодекса
Российской Федерации исполняет свои права и обязанности по исчислению и
уплате налогов и сборов, предусмотренных законодательством Российской
Федерации.
7.18. Исполнитель обязуется возместить Заказчику в полном объеме
убытки, возникшие у Заказчика вследствие недостоверности заверений, данных
Исполнителем в пункте 7.17 Договора, руководствуясь ст. 431.2 Гражданского
кодекса РФ, и имущественные потери в соответствии со ст. 406.1 ГК РФ,
возникшие в случае наступления одного из следующих обстоятельств:
- предъявление налоговым органом требования об уплате задолженности,
пени, штрафа в связи с отказом в применении налогового вычета по НДС по
работам (товарам, услугам, имущественным правам), которые являются
предметом Договора, а равно в связи с исключением затрат на приобретение этих
работ (товаров, услуг, имущественных прав) из расходов по налогу на прибыль
организаций;
- указание в акте налоговой проверки или ином аналогичном документе
на необоснованность получения Заказчиком налоговой выгоды, а равно на
нарушение положений ст. 54.1 НК РФ при осуществлении прав по исчислению
налоговой базы и (или) суммы НДС, налога на прибыль организаций по
причинам, связанным с Исполнителем.
Имущественные потери возмещаются Исполнителем в размере сумм,
подлежащих уплате Заказчиком на основании акта, решения, требования или
иного аналогичного документа налогового органа.
Исполнитель обязуется возместить Заказчику имущественные потери и
все убытки, предусмотренные настоящим пунктом Договора, в течение 30
(Тридцати) календарных дней со дня получения от Заказчика соответствующего
требования.
8. ОБСТОЯТЕЛЬСТВА НЕПРЕОДОЛИМОЙ СИЛЫ
8.1.
Стороны освобождаются от ответственности за неисполнение или
ненадлежащее исполнение своих обязательств по Договору, если надлежащее
исполнение оказалось невозможным вследствие непреодолимой силы, т.е.
чрезвычайных и непредотвратимых при данных условиях обстоятельств,
которые возникли после заключения Договора, в том числе пожар, наводнение,
землетрясение, прочие стихийные бедствия и иные обстоятельства
чрезвычайного характера, повлекшие за собой невозможность выполнения
Сторонами своих обязательств по Договору.
8.2.
В случае возникновения обстоятельств непреодолимой силы
Сторона, ссылающаяся на действие обстоятельств непреодолимой силы, как на
основание освобождения ее от ответственности за неисполнение или
ненадлежащее исполнение обязательств по Договору, обязана:
38
8.2.1. Немедленно в письменной форме способом, указанным в п. 16.4
Договора, известить о наступлении и о предполагаемом сроке действия
обстоятельств непреодолимой силы другую Сторону и в разумный срок
предоставить необходимые подтверждения.
8.2.2. Предпринять необходимые действия для уменьшения последствий
действия обстоятельств непреодолимой силы, устранения препятствий к
выполнению обязательства и возобновления выполнения своих обязательств в
полном объеме в соответствии с Договором.
8.2.3. Уведомить другую Сторону способом, указанным в п. 16.4
Договора, о возобновлении выполнения своих обязательств согласно Договору.
8.3.
Отсутствие уведомления или несвоевременное уведомление
лишает Сторону права ссылаться на обстоятельства непреодолимой силы как на
основание, освобождающее ее от ответственности за неисполнение обязательств
по Договору.
8.4.
При наличии обстоятельств непреодолимой силы сроки
выполнения Сторонами обязательств по Договору продлеваются на время, в
течение которого действуют обстоятельства непреодолимой силы либо на время,
необходимое для устранения Сторонами последствий действия таких
обстоятельств непреодолимой силы. В случае если обстоятельства
непреодолимой силы продолжаются свыше 1 (Одного) месяца либо сроки,
требующиеся для устранения Сторонами последствий действия таких
обстоятельств непреодолимой силы, превышают 1 (Один) месяц, то любая из
Сторон вправе отказаться от исполнения Договора в одностороннем
внесудебном порядке, при этом Стороны производят взаиморасчеты.
9. УСЛОВИЯ КОНФИДЕНЦИАЛЬНОСТИ
9.1. Сохранность конфиденциальной информации, обладателем которой
является Заказчик, регулируется соглашением об охране конфиденциальности
информации от «__» _______ 20__года. Указанное соглашение действует в
течение действия Договора, а также после прекращения действия Договора в
соответствии с условиями данного соглашения.
9.2. Исполнитель обязан обеспечить конфиденциальность информации,
содержащейся в разработанных Исполнителем подготовительных материалах
для модификации Программы для ЭВМ по каждой утвержденной Заявке,
модифицированной Программе для ЭВМ по каждой утвержденной Заявке,
актуализированном Исполнителем и утвержденном Заказчиком эскизном
проекте,
разработанной
и
актуализированной
документации
на
модифицированную Программу для ЭВМ по каждой утвержденной Заявке,
Программе для ЭВМ и эксплуатационной документации на нее, переданных
Заказчиком, а также иной конфиденциальной информации Заказчика в
соответствии с соглашением об охране конфиденциальности информации от
___.___.20___.
10. ПОРЯДОК РАСКРЫТИЯ ИНФОРМАЦИИ
39
10.1.Исполнитель обязан уведомлять Заказчика:
– об изменении состава участников (учредителей) Исполнителя, состава
органов управления Исполнителя (единоличного, коллегиального, иных органов
управления), а также состава акционеров, владеющих более чем 5 (Пятью)
процентами акций Исполнителя;
– о передаче полномочий единоличного исполнительного органа
Исполнителя управляющей организации или управляющему и прекращении их
полномочий.
10.2.В случае если участником (учредителем) Исполнителя, членом
органа управления Исполнителя, акционером, владеющим более чем 5 (Пятью)
процентами акций Исполнителя, и (или) лицом, которому переданы функции
единоличного исполнительного органа Исполнителя, является юридическое
лицо Исполнитель обязан уведомлять Заказчика об изменениях, указанных в
пункте 10.1 Договора, в отношении данного юридического лица. Обязанность
Исполнителя, предусмотренная настоящим пунктом Договора, распространяется
также в отношении всех физических лиц, указанных в пункте 10.1 Договора,
выступающих в качестве конечных бенефициаров Исполнителя.
10.3. Исполнитель обязан направлять Заказчику уведомление об
изменениях, указанных в пунктах 10.1, 10.2 Договора, по форме, размещенной на
сайте Заказчика в разделе «Закупки/Информация о заключенных договорах» по
адресу
http://so-ups.ru/index.php?id=procurement_conclud
(файл
«Форма
справки.xls.»), в течение 5 (Пяти) рабочих дней со дня соответствующих
изменений посредством направления информации на адрес электронной почты
bfinfo@so-ups.ru.
10.4.В случае ненаправления (отказа от направления) Исполнителем
Заказчику в установленный Договором срок уведомления об изменениях,
указанных в пунктах 10.1, 10.2 Договора, а равно в случае выявления Заказчиком
в результате указанных изменений факта участия работников руководящего
состава Заказчика (Председатель Правления, Первый заместитель
Председателя Правления, главный бухгалтер, директор по направлению,
заместитель директора по направлению, руководитель самостоятельного
структурного
подразделения,
руководитель
филиала,
заместитель
руководителя филиала) и (или) их близких родственников (супруг (супруга),
совершеннолетние и несовершеннолетние дети, родители, полнородные и
неполнородные братья и сестры) в деятельности Исполнителя в формах,
указанных в пунктах 10.1, 10.2 Договора, Заказчик вправе в одностороннем
внесудебном порядке отказаться от исполнения Договора, направив
Исполнителю уведомление об отказе от исполнения Договора. По истечении 30
(Тридцати) дней со дня получения Исполнителем уведомления Заказчика об
отказе от исполнения Договора Договор считается расторгнутым.
11.РАЗРЕШЕНИЕ СПОРОВ
11.1. Все споры и разногласия, возникающие из Договора или в связи с
ним, в том числе касающиеся его заключения, действия, исполнения, изменения,
40
дополнения, прекращения или действительности, подлежат разрешению в
Арбитражном суде города Москвы в соответствии с действующим
законодательством Российской Федерации.
12.ПРАВА СТОРОН НА РЕЗУЛЬТАТ РАБОТ
12.1. В соответствии со статьей 1296 Гражданского кодекса Российской
Федерации исключительное право на актуализированный эскизный проект и
модифицированную в результате выполнения Работ по второй и последующим
утвержденным Заявкам Программу для ЭВМ, в том числе на исходный текст
(код), дистрибутив модифицированной Программы для ЭВМ, разработанную и
актуализированную документацию на модифицированную Программу для ЭВМ
по каждой утвержденной Заявке согласно п.п. 7.1.3-7.1.5 Техническим
требованиям (Приложение № 1 к Договору), принадлежит Заказчику.
13.ПОРЯДОК РАСТОРЖЕНИЯ ДОГОВОРА
13.1. В случае существенного нарушения Договора Исполнителем
Заказчик имеет право в одностороннем внесудебном порядке отказаться от
исполнения Договора и потребовать от Исполнителя возмещения убытков в
полном объеме. В указанном случае Договор расторгается Заказчиком
посредством направления способами, указанными в п. 16.4 Договора,
уведомления Исполнителю об отказе от исполнения Договора с указанием того,
какие существенные нарушения Договора допущены Исполнителем. Со дня
получения Исполнителем уведомления Заказчика об отказе от исполнения
Договора или с более позднего дня, указанного в уведомлении как момент
расторжения Договора, Договор считается расторгнутым, а обязательства
Сторон – прекратившимися, за исключением обязательств, касающихся
возмещения убытков в порядке, предусмотренном далее в настоящем пункте
Договора, и обязательств, предусмотренных пунктом 4.1.19 Договора. При
наличии у Заказчика убытков, причиненных Исполнителем Заказчику
неисполнением или ненадлежащим исполнением обязательств по Договору,
Заказчик направляет Исполнителю требование о возмещении убытков с
приложением расчета суммы убытков. Исполнитель обязан оплатить Заказчику
убытки не позднее 15 (Пятнадцати) календарных дней с момента получения
расчета суммы убытков от Заказчика. В случае, если Исполнитель не оплатил
убытки в течение установленного настоящим пунктом Договора срока, Заказчик
вправе обратиться в суд за взысканием убытков в установленном
законодательством Российской Федерации порядке.
13.2.
Существенным нарушением условий Договора Исполнителем
являются:

нарушение срока начала или окончания выполнения Работ по
соответствующей утвержденной Заявке более чем на 30 (Тридцать) календарных
дней по причинам, не зависящим от Заказчика;

неустранение выявленных Заказчиком недостатков Работ по
соответствующей утвержденной Заявке в сроки, установленные Заказчиком, а
41
равно не устранение недостатков, для которых срок их устранения не установлен
Заказчиком, – в течение 30 (Тридцати) календарных дней с момента получения
Исполнителем требования Заказчика об устранении недостатков;

привлечение Исполнителем к выполнению Работ третьих лиц в
нарушение условий пункта 4.1.18 Договора;

нарушение Исполнителем требований пункта 4.1.21 Договора;

нарушение Исполнителем любого из обязательств, указанных в
пункте 4.1.13 и (или) 4.1.14, и (или) 4.1.15, и (или) 4.1.16, и (или) 4.1.22, и (или)
4.4.2 Договора;

непредоставление сведений о ходе выполнения Работ в течение 10
(Десяти) рабочих дней со дня получения от Заказчика соответствующего
запроса;
–
если в ходе исполнения Договора установлено, что Исполнитель не
соответствует установленным документацией о закупке требованиям к
участникам закупки или предоставил недостоверную информацию о своем
соответствии таким требованиям, что позволило ему стать победителем
определения Исполнителя.
Заказчик вправе в одностороннем внесудебном порядке отказаться от
исполнения Договора в случае объявления Исполнителя банкротом и открытия в
отношении него конкурсного производства, наложения ареста на имущество
Исполнителя.
Заказчик также вправе в одностороннем внесудебном порядке отказаться
от исполнения Договора и в иных случаях, предусмотренных действующим
законодательством Российской Федерации.
13.3.
При отказе Заказчика от исполнения Договора полностью или в
части в соответствии с пунктом 4.5.5 Договора:
13.3.1. Заказчик:
13.3.1.1. направляет Исполнителю письменное уведомление способом,
указанным в п. 16.4 Договора, об отказе от исполнения Договора полностью или
в части. При этом в день получения Исполнителем такого уведомления или с
более позднего дня, указанного в уведомлении как момент расторжения
Договора полностью или в части, Договор считается расторгнутым полностью
или в части, а обязательства Сторон – прекратившимися, за исключением
обязательств, касающихся взаиморасчетов, порядок которых предусмотрен
далее в настоящем пункте Договора, и обязательств, предусмотренных пунктом
4.1.19 Договора;
13.3.1.2. в течение 15 (Пятнадцати) календарных дней с момента
получения от Исполнителя документов, указанных в пункте 13.3.2.2 Договора,
Заказчик производит оценку представленных документов и, при отсутствии
недостатков в результате выполненных Работ и при надлежащем оформлении
Исполнителем представленных документов, подписывает представленный
Исполнителем УПД или Акт о приемке выполненных работ;
13.3.1.3. в течение 7 (Семи) рабочих дней с даты подписания Сторонами
УПД или Акта о приемке выполненных работ производит оплату.
42
13.3.2.
Исполнитель:
13.3.2.1. в день получения уведомления Заказчика об отказе от
исполнения Договора полностью или в части или в более поздний день,
указанный Заказчиком в уведомлении как день расторжения Договора
полностью или в части, прекращает выполнение Работ полностью или в части и в
этот же день письменно способами, указанными в п. 16.4 Договора, уведомляет
об этом Заказчика. Работы, выполненные Исполнителем позже дня расторжения
Договора, оплате не подлежат;
13.3.2.2. в течение 10 (Десяти) календарных дней с момента расторжения
Договора полностью или в части Исполнитель представляет Заказчику
письменный отчет о выполненных Работах на момент расторжения Договора,
результаты Работ, выполненных на момент расторжения Договора, документы,
оформленные до момента расторжения Договора согласно условиям Договора,
включая Технические требования (Приложение № 1 к Договору),
утвержденной(-ым) Заявки(-ам), до момента расторжения Договора, Оценку
трудозатрат по выполненным Работам до момента расторжения Договора, УПД
или Акт о приемке выполненных работ, Технический акт об установлении
гарантийного срока по форме Приложения № 5 к Договору, счет на оплату и
счет-фактуру, оформленный в соответствии с требованиями действующего
законодательства Российской Федерации (В случае, если Исполнитель
применяет упрощенную систему налогообложения и освобождается от
исполнения обязанностей налогоплательщика НДС в соответствии с пунктом 1
статьи 145 НК РФ, условие о счете-фактуре в Договор не включается).
Невыполнение или несвоевременное выполнение условий настоящего
пункта Договора является безусловным подтверждением выполнения
Исполнителем Работ после расторжения Договора. Работы, выполненные
Исполнителем после расторжения Договора, оплате Заказчиком не подлежат.
14.АНТИКОРРУПЦИОННЫЕ УСЛОВИЯ
14.1. Исполнителю известно о том, что Заказчик ведет
антикоррупционную деятельность и развивает не допускающую коррупционных
проявлений культуру.
14.2. Исполнитель настоящим подтверждает, что он ознакомился с
Антикоррупционной политикой АО «СО ЕЭС» (далее – Политика),
размещенной на официальном сайте Заказчика по адресу http://so-ups.ru/,
удостоверяет, что он полностью принимает положения Политики и обязуется
обеспечить соблюдение требований Политики.
14.3. В целях противодействия коррупции, исключения случаев
конфликта интересов и иных злоупотреблений:
14.3.1. В случае возникновения у одной из Сторон подозрений, что
произошло или может произойти нарушение каких-либо положений Политики
другой Стороной, Сторона, у которой возникли такие подозрения, направляет
другой Стороне письменное уведомление с требованием представить
разъяснения. Письменное уведомление должно содержать ссылку на факты и
43
материалы, достоверно подтверждающие или дающие основание предполагать,
что произошло или может произойти нарушение каких-либо положений
Политики другой Стороной. Сторона, получившая уведомление, обязана
незамедлительно представить другой Стороне письменные разъяснения.
14.3.2. Каждая из Сторон не выплачивает, не предлагает выплатить и не
обещает выплату каких-либо денежных средств, а также не осуществляет
передачу ценных бумаг, иного имущества, оказание услуг имущественного
характера, предоставление имущественных прав, прямо или косвенно, любым
лицам для оказания влияния на действия (бездействие) другой Стороны с целью
получения каких-либо неправомерных преимуществ или для достижения иных
неправомерных целей.
14.3.3. При исполнении своих обязательств по Договору Стороны не
осуществляют по отношению друг к другу действия, квалифицируемые
применимым законодательством как коррупционные, а также действия,
нарушающие требования применимого законодательства и международных
актов о противодействии легализации (отмыванию) доходов, полученных
преступным путем.
14.3.4. В случае если Заказчику станет известно о факте совершения
Исполнителем административного правонарушения по ст. 19.28 «Незаконное
вознаграждение от имени юридического лица» Кодекса Российской Федерации
об административных правонарушениях и/или о факте судимости лица,
выполняющего управленческие функции у Исполнителя (единоличного
исполнительного органа, члена совета директоров или иного коллегиального
исполнительного органа и/или лица, постоянно, временно либо по специальному
полномочию
выполняющего
организационно-распорядительные
или
административно-хозяйственные функции у Исполнителя) за преступления по
какой-либо из следующих статей Уголовного кодекса Российской Федерации:
204 «Коммерческий подкуп», 290 «Получение взятки», 291 «Дача взятки», 291.1
«Посредничество во взяточничестве», 201 «Злоупотребление полномочиями»,
285 «Злоупотребление должностными полномочиями», 159 «Мошенничество»,
Заказчик вправе в одностороннем внесудебном порядке отказаться от
исполнения Договора. С момента получения Исполнителем уведомления
Заказчика об отказе от исполнения Договора Договор считается расторгнутым.
При этом факт совершения административного правонарушения или
преступления указанными в настоящем пункте лицами должен быть
подтвержден вступившим в законную силу постановлением по делу об
административном правонарушении или приговором суда соответственно.
14.3.5. Стороны гарантируют полную конфиденциальность при
исполнении настоящего раздела Договора.
15.ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ
15.1. Обеспечение Исполнителем информационной безопасности при
исполнении обязательств по Договору, связанных с информационными
ресурсами и (или) при предоставлении защищенного удаленного доступа к
44
информационным ресурсам, обладателем которых является Заказчик,
регулируется соглашением о соблюдении требований по информационной
безопасности от «__» _______ 20__года № __. Указанное соглашение действует в
течение действия Договора, а также после прекращения действия Договора в
соответствии с условиями данного соглашения.
15.2. Исполнитель обязан исполнять условия соглашения о соблюдении
требований по информационной безопасности от «__» _______ 20__года №__.
16.ПРОЧИЕ ПОЛОЖЕНИЯ
15.1.
Договор вступает в силу с момента его подписания Сторонами и
действует до момента исполнения Сторонами принятых на себя обязательств.
Работы должны быть выполнены Исполнителем и оплачены Заказчиком по всем
Заявкам, утвержденным Заказчиком в течение действия Договора.
15.2.
Во всем, что не предусмотрено Договором, Стороны
руководствуются действующим законодательством Российской Федерации.
15.3.
В случае изменения адреса и/или реквизитов Сторона, у которой
произошли данные изменения, обязуется своевременно уведомить об этом
другую Сторону. До получения уведомления об изменениях Сторона,
исполнившая свои обязательства по Договору с использованием старых адресов
и/или реквизитов другой Стороны, считается исполнившей обязательства
надлежащим образом. Уведомление об изменении адресов или реквизитов
Стороны вступает в силу для другой Стороны с момента его получения.
15.4. Стороны определили следующие способы обмена документами
и/или юридически значимыми и иными сообщениями (далее – Документ
(Документы)):
1)
Нарочно (доставка курьером Стороны-отправителя): Документ
считается доставленным Стороне-получателю в день приема Документа
Стороной-получателем у курьера с отметкой этой Стороны о получении;
2)
Заказным
почтовым
отправлением:
Документ
считается
доставленным Стороне-получателю в день вручения почтового отправления
либо в день истечения срока хранения при неполучении адресатом отправления в
отделении связи;
3)
В электронной форме с использованием информационнотелекоммуникационной сети посредством электронной почты Стороны с
применением усиленной квалифицированной электронной подписи (далее –
КЭП). Данный способ обмена Документами не применяется в случае, если:
- осуществляется
обмен
счетами-фактурами
(в
том
числе
исправленными и корректировочными), первичными учетными документами,
счетами на оплату и иными документами, подтверждающими исполнение
обязательств Сторон по Договору;
- Документ подлежит подписанию исключительно собственноручной
подписью на бумажном носителе либо в иной форме (например, посредством
45
АСУЗ) в соответствии с законодательством Российской Федерации, локальными
нормативными актами Стороны или по соглашению Сторон;
- в Документе содержатся сведения, составляющие государственную
тайну, или информация конфиденциального характера (в том числе
коммерческая или иная охраняемая законом тайна; информация для служебного
пользования; персональные данные, за исключением фамилии, имени, отчества);
- Документ подлежит направлению в адрес иностранных лиц и
международных организаций.
Юридически значимыми сообщениями в соответствии с Договором
признаются заявления, уведомления, извещения, требования и иные сообщения,
если они влекут или могут повлечь для одной или обеих сторон гражданскоправовые последствия в силу закона или сделки (в том числе требования,
претензии, заявления, жалобы или иные документы, направленные с целью
соблюдение досудебного порядка урегулирования спора; односторонние сделки
(например, заявление о зачете встречных однородных требований, уведомления
об одностороннем отказе от исполнения договора и прочее); сообщения,
связанные с нарушением одной из Сторон обязательств по Договору; сообщения,
связанные с изменением обязательств (условий) Договора), а также иные письма,
уведомления, сообщения.
16.4.1. Электронный документ и приложения к нему, обмен которыми
осуществляется посредством электронной почты, должны соответствовать
Требованиям к электронным документам, размещенным на официальном сайте
Заказчика в сети Интернет: https://www.so-ups.ru/contacts/edocs/requirements/.
Изменения данных требований вступают в силу с момента их опубликования на
указанном сайте.
Адрес электронной почты АО «СО ЕЭС» для получения Документов:
secr@so-ups.ru;
Адрес
электронной
почты
Исполнителя
для
получения
Документов:__________________________.
(указать общий адрес электронной почты Исполнителя для получения
входящей корреспонденции (адрес канцелярии или секретариата))
В случае изменения адреса электронной почты соответствующая Сторона
обязана уведомить об этом другую Сторону и обеспечить беспрерывное
осуществление обмена электронными документами. При этом вносить
изменения в Договор не требуется.
Документ считается доставленным в момент отправки такого сообщения
одной Стороной в адрес другой Стороны при условии, что размер вложений в
электронное письмо не превышает 20 Мегабайт. В случае если размер вложения,
планируемого к отправке, превышает 20 Мегабайт, то документ направляется
путем отправки получателю ссылки на облачное файловое хранилище, проходя
по которой получатель может загрузить файлы Документа и файл (-ы)
электронной (-ых) подписи (-ей). При направлении ссылки на облачное файловое
хранилище Документ считается доставленным с момента отправки такой ссылки
одной Стороной в адрес другой Стороны.
46
Полученные в соответствии с настоящими правилами Документы
признаются равнозначными документам на бумажном носителе, подписанным
собственноручной подписью уполномоченных лиц и заверенным печатью (при
использовании Стороной печати).
16.4.2. Документы, доставляемые нарочно или заказным почтовым
отправлением, направляются Стороне-получателю по адресу ее места
нахождения, указанному в разделе Договора «МЕСТО НАХОЖДЕНИЯ,
АДРЕСА, РЕКВИЗИТЫ И ПОДПИСИ СТОРОН», или уведомлении Стороны об
изменении адреса. В случае, если в указанном разделе предусмотрен почтовый
адрес (адрес для направления корреспонденции) направляются на почтовый
адрес (адрес для направления корреспонденции).
15.5. Стороны вправе осуществлять обмен счетами-фактурами (в том
числе исправленными и корректировочными), первичными учетными
документами, счетами на оплату и иными документами, подтверждающими
исполнение обязательств Сторон по Договору, в электронной форме по
телекоммуникационным каналам связи с применением КЭП через операторов
электронного документооборота (далее – Оператор ЭДО) при условии
заключения между Сторонами соглашения об электронном документообороте
через Оператора ЭДО.
15.6. В случаях, когда в соответствии с законодательством Российской
Федерации обмен счетами-фактурами (в том числе исправленными и
корректировочными) и иными документами должен осуществляться
исключительно в электронной форме с применением КЭП через Операторов
ЭДО, заключение вышеуказанного соглашения не требуется, но оно может быть
оформлено по желанию Сторон.
15.7. Договор составлен в электронной форме и подписан усиленной
квалифицированной электронной подписью уполномоченных лиц обеих Сторон
посредством электронного документооборота через оператора электронного
документооборота.
или
Договор составлен в 2 (Двух) экземплярах на бумажном носителе, имеющих
одинаковую юридическую силу, по 1 (Одному) экземпляру для каждой из Сторон.
(Форма заключения Договора определяется Сторонами на этапе
подписания Договора)
15.8. Лица, подписавшие от имени Сторон Договор, подтверждают свои
полномочия на подписание Договора, включая все приложения к нему, а также
свидетельствуют о соблюдении Сторонами всех корпоративных процедур,
необходимых для заключения Договора.
15.9. Исполнитель подтверждает, что на момент заключения Договора
Исполнитель является/не является (нужное подчеркнуть) субъектом
малого/среднего (нужное подчеркнуть) предпринимательства.
Если Исполнитель является субъектом малого или среднего
предпринимательства, он вправе заключать с третьими лицами (финансовыми
агентами) договоры финансирования под уступку денежного требования
47
(факторинга), в соответствии с которыми финансовый агент передает или
обязуется передать Исполнителю денежные средства в счет денежного
требования Исполнителя к Заказчику, вытекающего из выполнения
Исполнителем Работ по Договору, а Исполнитель уступает или обязуется
уступить финансовому агенту это денежное требование.
Исполнитель обязан уведомить Заказчика способами, указанными в пункте
16.4 Договора, о заключении им договора финансирования под уступку
денежного требования (факторинга) в срок не позднее 2 (Двух) календарных
дней с момента заключения указанного договора.
15.10. Под рабочими днями в Договоре понимаются рабочие дни, исходя из
пятидневной рабочей недели (все дни недели, кроме субботы и воскресенья), не
являющиеся в соответствии с действующим законодательством Российской
Федерации праздничными нерабочими днями и днями, на которые перенесены
выходные дни, а также выходные дни (суббота и воскресенье), которые в
соответствии с действующим законодательством Российской Федерации
являются рабочими днями.
15.11. К Договору прилагаются в качестве его неотъемлемой части:

Приложение № 1 «Технические требования»;

Приложение № 2 «Соглашение о тарифах»;

Приложение № 3 «Форма Оценки трудозатрат»;

Приложение № 4 «Форма Акта о приемке выполненных работ»;

Приложение № 5 «Форма Технического акта об установлении
гарантийного срока»;

Приложение № 6 «Порядок подачи обращений в АСУЗ».
17.МЕСТО НАХОЖДЕНИЯ, АДРЕСА, РЕКВИЗИТЫ И ПОДПИСИ
СТОРОН
17.1. ЗАКАЗЧИК:
17.2. ИСПОЛНИТЕЛЬ:
АО «СО ЕЭС»
место нахождения и адрес:
109012, г. Москва, Китайгородский
проезд, д. 7, стр. 3.
почтовый адрес: 109012, г. Москва,
Китайгородский проезд, д. 7, стр. 3.
ИНН / КПП: 7705454461 / 770501001
р/с 40702810515000004034
в Филиале «Центральный»
Банка ВТБ (ПАО) г. Москва
к/с 30101810145250000411
БИК 044525411
Должность
______________ / ____________ /
М.П.
Должность
______________/ ________/
М.П.
48
Приложение № 1
к Договору №____________
от «___» ______________ 2026 года
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
на выполнение работ по модификации программы для ЭВМ
«Конструктор логических моделей/схем противоаварийной автоматики»
(формируются в соответствии с требованиями Технических требований
(Приложение № 1 к Конкурсной документации))
От Заказчика:
___________________/
М.П.
/
От Исполнителя:
________________ /
М.П.
/
49
Приложение № 2
к Договору №____________
от «___» ______________ 2026 года
СОГЛАШЕНИЕ О ТАРИФАХ
(формируется в соответствии с Конкурсной заявкой Победителя
конкурса)
Стоимость Работ, выполняемых Исполнителем по каждой утвержденной
Заказчиком Заявке, определяется на основе фактических трудозатрат –
количества человеко-часов, исходя из стоимости по следующим ставкам оплаты
труда специалистов в час:
№
Категория
специалиста
Трудозат
раты
(чел.часов)
Стоимость по
ставке оплата
труда
специалистов
в час*, руб. без
НДС
Стоимость, руб.
без НДС
НДС
с учетом
НДС
1.
ИТОГО:
*Стоимость по ставкам оплаты труда специалистов в час включает все расходы Исполнителя,
связанные с исполнением обязательств по Договору, стоимость Работ, учитывает стоимость
Работ, прямо не упомянутых в Договоре, но необходимых для завершения выполнения Работ по
Договору, а также причитающееся Исполнителю вознаграждение, является твердой и не
подлежит изменению в течение действия Договора.
(При этом стоимость Работ не должна превышать: в 2026 году –
4 864 550 (Четыре миллиона восемьсот шестьдесят четыре тысячи пятьсот
пятьдесят) рублей 00 копеек, кроме того НДС (22 %), в 2027 году – 15 000 000
(Пятнадцать миллионов) рублей 00 копеек, кроме того НДС (22 %).)
(В случае, если Исполнитель применяет упрощенную систему
налогообложения и освобождается от исполнения обязанностей
налогоплательщика НДС в соответствии с пунктом 1 статьи 145 НК РФ,
включается условие: «без НДС в связи с освобождением от уплаты НДС
Исполнителя, применяющего упрощенную систему налогообложения, согласно
пункта 1 статьи 145 НК РФ»)
Под 1 (Одним) человеко-часом понимается выполнение работ 1 (Одним)
специалистом Исполнителя, в течение 1 (Одного) часа при продолжительности
50
рабочего дня не более 8 (Восьми) часов в день. Под рабочими днями понимаются
рабочие дни исходя из пятидневной рабочей недели (все дни недели, кроме
субботы и воскресенья), не являющиеся в соответствии с действующим
законодательством Российской Федерации праздничными нерабочими днями и
днями, на которые перенесены выходные дни, а также выходные дни (суббота и
воскресенье), которые в соответствии с действующим законодательством
Российской Федерации являются рабочими днями.
В случае если выполнение работ специалистом Исполнителя требует
большей загрузки, нежели 8 (Восемь) часов в течение 1 (Одного) рабочего дня
(«Сверхурочные работы»), то такие работы, а также работы в выходные и
нерабочие праздничные дни оплачиваются по стоимости по ставкам оплаты
труда специалистов в час, указанной выше.
От Заказчика:
___________________/
М.П.
/
От Исполнителя:
________________ /
М.П.
/
51
Приложение № 3
к Договору №____________
от «___» ______________ 2026 года
ФОРМА ОЦЕНКИ ТРУДОЗАТРАТ
начало формы
Наименование Категория
работ
специалиста
Почасовая
Трудозатраты Общая
ставка,
, часов/Общее стоимость,
руб.
включая кол-во часов руб.
включая
НДС 22%
НДС 22%
<Номер Заявки> <Краткое описание Заявки, сроки>
<Вид работ 1> Специалист 1
Специалист 2
<Вид работ 2> Специалист 2
…
…
ИТОГО (включая НДС 22%)
конец формы
От Заказчика:
___________________/
М.П.
/
От Исполнителя:
________________ /
М.П.
/
52
Приложение № 4
к Договору №____________
от «___» ______________ 2026 года
«Форма Акта о приемке выполненных работ»
начало формы
Акт о приемке выполненных работ № ____
к Договору от ____ 202__ года № ____
г. Москва
__________202_ года.
Акционерное общество «Системный оператор Единой энергетической системы»
(АО «СО ЕЭС»), именуемое в дальнейшем «Заказчик», в лице _________________
(указать должность и Ф.И.О. лица, уполномоченного на подписание договора),
действующего на основании доверенности от ___.____.20___ №____, с одной
стороны, и
_________________ (указать полное наименование контрагента с
расшифровкой организационно-правовой формы либо его сокращенное наименование
в соответствии с учредительными документами), именуемое в дальнейшем
«Исполнитель», в лице _________________ (указать должность и Ф.И.О. лица,
уполномоченного на подписание договора), действующего на основании
_________________ (Устава, либо доверенности (с реквизитами) / индивидуальный
предприниматель _____________________(указать фамилию, имя и отчество
контрагента без сокращений), именуемый в дальнейшем «Исполнитель»,
зарегистрированный в ЕГРИП за номером _______________ (указать номер
регистрации индивидуального предпринимателя в ЕГРИП), действующий на
основании свидетельства о регистрации физического лица в качестве
индивидуального предпринимателя _____________________(указать реквизиты
свидетельства) (условие, выделенное курсивом, включается в Договор, если
индивидуальный предприниматель зарегистрирован до 31.12.2016), с другой
стороны,,
далее при совместном упоминании именуемые «Стороны», составили и
подписали настоящий Акт о нижеследующем:
1.
Исполнитель завершил выполнение Работ по утвержденной(ным)
Заказчиком Заявке(ам) (далее-утвержденная(ые) Заявка(и)):
____________________________________________________________________
____________________________________________________________________
2.
Исполнитель передал,
утвержденной(ыми) Заявкой(ами):
а
Заказчик
принял
в
соответствии
с
53
– актуализированный эскизный проект на Программу для ЭВМ;
или
– модифицированную программу для ЭВМ «Конструктор логических
моделей/схем противоаварийной автоматики» (кумулятивный дистрибутив (включая
инсталляционный пакет), исходный текст (код) в электронном виде с использованием
АИС «ФПА» Заказчика и прочие файлы, необходимые для создания дистрибутива
(сторонние библиотеки, скрипты и т.д.) модифицированной Программы для ЭВМ
«Конструктор логических моделей/схем противоаварийной автоматики»);
– разработанную и актуализированную документацию по утвержденной(ым)
Заявке(ам) согласно пунктам 7.1.3-7.1.5 Технических требований (Приложение № 1 к
Договору), согласованную с Заказчиком.
3.
Стоимость выполненных Работ по утвержденной(ым) Заявке(ам)
составляет: __________ (указать сумму прописью) рублей ____ копеек, в том числе
НДС (22%) в размере ______ (указать сумму прописью) рублей __ копеек.
4. Подлежит оплате за выполненные Работы по утвержденной(ым) Заявке(ам)
_________ (указать сумму прописью) рублей ____ копеек, в том числе НДС (22 %) в
размере ______ (указать сумму прописью) рублей __ копеек.
5. Работы выполнены Исполнителем согласно условиям Договора,
утвержденной(ым) Заявке(ам). Стороны претензий друг к другу не имеют.
6. Настоящий Акт составлен в двух экземплярах, имеющих одинаковую
юридическую силу, по одному для каждой из Сторон.
От Заказчика:
___________________/
М.П.
/
От Исполнителя:
________________ /
М.П.
/
конец формы
От Заказчика:
___________________/
М.П.
/
От Исполнителя:
________________ /
М.П.
/
54
Приложение № 5
к Договору №____________
от «___» ______________ 2026 года
«Форма Технического акта об установлении гарантийного срока»
начало формы
Технический акт об установлении гарантийного срока
к Договору от ____ 202__ года № ____
г. Москва
__________202_ года.
Акционерное общество «Системный оператор Единой энергетической системы»
(АО «СО ЕЭС»), именуемое в дальнейшем «Заказчик», в лице _________________
(указать должность и Ф.И.О. лица, уполномоченного на подписание договора),
действующего на основании доверенности от ___.____.20___ №____, с одной
стороны, и
_________________ (указать полное наименование контрагента с
расшифровкой организационно-правовой формы либо его сокращенное наименование
в соответствии с учредительными документами), именуемое в дальнейшем
«Исполнитель», в лице _________________ (указать должность и Ф.И.О. лица,
уполномоченного на подписание договора), действующего на основании
_________________
(Устава,
либо
доверенности
(с
реквизитами)
/
индивидуальный предприниматель _____________________(указать фамилию, имя
и отчество контрагента без сокращений), именуемый в дальнейшем
«Исполнитель», зарегистрированный в ЕГРИП за номером _______________
(указать номер регистрации индивидуального предпринимателя в ЕГРИП),
действующий на основании свидетельства о регистрации физического лица в
качестве индивидуального предпринимателя _____________________(указать
реквизиты свидетельства) (условие, выделенное курсивом, включается в Договор,
если индивидуальный предприниматель зарегистрирован до 31.12.2016), с другой
стороны,
далее при совместном упоминании именуемые «Стороны», составили и
подписали настоящий Акт о нижеследующем:
1.
В настоящем Акте устанавливается дата окончания гарантийного срока
на результат Работ по второй и последующим утвержденным Заказчиком Заявкам,
Работы по которым выполнены Исполнителем и приняты Заказчиком по УПД или
Актам о приемке выполненных работ, а именно:
_________________________________________________________________________
_______________________________________________________________
55
2.
Дата окончания гарантийного срока на результат Работ по второй и
последующим утвержденным Заказчиком Заявкам, указанным в п. 1 настоящего
Акта: дата окончания периода, равного ___ (_________) месяцам (указывается
гарантийный срок в соответствии с Конкурсной заявкой Победителя конкурса, но не
менее 12 (Двенадцати) месяцев), исчисляемого с даты подписания Сторонами
настоящего Акта.
3.
Настоящий Акт составлен в двух экземплярах, имеющих одинаковую
юридическую силу, по одному для каждой из Сторон.
От Заказчика:
___________________/
М.П.
/
От Исполнителя:
________________ /
М.П.
/
конец формы
От Заказчика:
___________________/
М.П.
/
От Исполнителя:
________________ /
М.П.
/
56
Приложение № 6
к Договору №____________
от «___» ______________ 2026 года
Порядок подачи обращений в АСУЗ
1.1.
Если во время выполнения Работ по второй и последующим
утвержденным Заявкам, или в ходе приемки Заказчиком результатов Работ по второй
и последующим утвержденным Заявкам, или в течение гарантийного срока на
результаты Работ по второй и последующим утвержденным Заявкам (п. 6.1 Договора)
обнаружатся недостатки в Работах или результатах Работ, Заказчик сообщает об этом
специалисту Группы технического сопровождения Исполнителя путем
формирования обращения о недостатках в Работах или в результатах Работ в АСУЗ.
Сформированные Заказчиком в АСУЗ обращения автоматически направляются по
электронной почте на адрес Исполнителя _______@_______. Исполнитель вправе
изменить свои контактные данные в порядке, установленном п. 16.4 Договора.
1.2.
При формировании обращений о недостатках в Работах или
результатах Работ в АСУЗ Заказчик указывает информацию, необходимую для
взаимодействия Исполнителя и Заказчика:
Договор (номер, дата)
Информация о Заказчике:

Название организации

ФИО контактного лица Заказчика

Контактные телефоны контактного лица Заказчика
Информация о модифицированной Программе для ЭВМ:

наименование модифицированной Программы для ЭВМ

номер версии модифицированной Программы для ЭВМ
Если при работе модифицированной Программы для ЭВМ получены сообщения об
ошибках – копии таких сообщений
Описание проблемы

Как возникает ошибка/проблема

Какая диагностика при этом появляется

После каких действий/настроек ошибка/проблема появилась впервые
Срок устранения недостатков *
Дата отправки обращения
* Срок устранения недостатков в Работах по утвержденным Заявкам или результатах Работ
по утвержденным Заявкам по обращению Заказчика о недостатках в Работах или результатах Работ
(далее – обращение/обращение о недостатках) определяется Заказчиком на основании анализа
выявленных недостатков по соответствующей утвержденной Заявке.
Обращение должно содержать информацию по одному вопросу или проблеме.
1.3.
В случае невозможности подачи обращения средствами АСУЗ
57
Заказчик уведомляет Исполнителя об обнаруженных недостатках в Работах или
результатах Работ по адресу электронной почты Исполнителя, указанному в пункте
1.1 настоящего Приложения.
1.4.
С даты подписания Сторонами УПД или Акта о приемке выполненных
работ по первой утвержденной Заявке Заказчик обеспечивает Исполнителю
удаленный доступ к АСУЗ в целях взаимодействия между Исполнителем и
Заказчиком в ходе выполнения Исполнителем Работ по второй и последующим
утвержденным Заявкам, в ходе приемки Заказчиком результатов Работ по второй и
последующим утвержденным Заявкам, в течение гарантийного срока на результаты
Работ по второй и последующим утвержденным Заявкам (п. 6.1 Договора).
1.5.
Исполнитель обеспечивает прием обращений о недостатках с
электронного адреса Заказчика: sd@so-ups.ru.
1.6.
В ходе выполнения Исполнителем Работ по второй и последующим
утвержденным Заявкам, в ходе приемки Заказчиком результатов Работ по второй и
последующим утвержденным Заявкам, в течение гарантийного срока на результаты
Работ по второй и последующим утвержденным Заявкам специалисты Исполнителя
вправе запросить у Заказчика дополнительную информацию по обращению о
недостатках средствами АСУЗ.
1.7.
В момент регистрации обращения о недостатках АСУЗ автоматически
отправляет электронное письмо с уведомлением в адрес Исполнителя.
1.8.
Началом выполнения обращения о недостатках в Работах или в
результатах Работ, а также о запросе информации признается время принятия в
работу Исполнителем обращения в АСУЗ. Подтверждением принятия обращения в
работу Исполнителем является изменение статуса обращения в АСУЗ на
«Выполняется». Исполнитель обязан принять в работу обращение или отказаться от
его исполнения в сроки, указанные в таблице «Время принятия Исполнителем
обращения в АСУЗ в работу», с момента регистрации обращения в АСУЗ. Для
обращений, зарегистрированных в АСУЗ во внерабочее время, начало принятия
обращения в работу Исполнителем исчисляется со времени начала следующего
рабочего дня. Под рабочим временем при подаче обращений в АСУЗ понимается
период с 08:30 до 17:30 мск по рабочим дням.
Критичное обращение – обращение, содержащее описание недостатка в работе
Программы для ЭВМ, не позволяющего перейти к следующим этапам испытаний
Программы для ЭВМ или нарушающего штатное функционирование Программы для
ЭВМ до момента его устранения.
Приоритет обращения определяется Заказчиком.
Таблица «Время принятия Исполнителем обращения в АСУЗ в работу»
Тип обращения
Приоритет обращения
Время
принятия
обращения в работу
Недостатки в Работах или Критичный
результатах Работ
2
часа
с
момента
регистрации обращения в
АСУЗ
Недостатки в Работах или Некритичный
4
часа
с
момента
58
результатах Работ
регистрации обращения в
АСУЗ
Запрос информации
4
часа
с
момента
регистрации обращения в
АСУЗ
1.9.
Отказом от устранения недостатков в Работах или результатах Работ
считается изменение статуса обращения в АСУЗ на «Решен» с указанием причины
отказа. Уклонением от устранения недостатков в Работах или результатах Работ
является неизменение статуса обращения в АСУЗ на «Выполняется» в течение
времени, указанного в пункте 1.8 настоящего Приложения, для принятия
Исполнителем обращения в работу.
1.10.
В ходе выполнения Исполнителем Работ по второй и последующим
утвержденным Заявкам, в ходе приемки Заказчиком результатов Работ по второй и
последующим утвержденным Заявкам, в течение гарантийного срока на результаты
Работ по второй и последующим утвержденным Заявкам Исполнитель обязан
отражать статус выполнения обращения и взаимодействия с Заказчиком в АСУЗ.
1.11.
Факт устранения недостатков в Работах по второй и последующим
утвержденным Заявкам или результатах Работ по второй и последующим
утвержденным Заявкам фиксируется Сторонами в АСУЗ. Исполнитель по факту
устранения недостатков в Работах или результатах Работ выставляет обращению в
АСУЗ статус «Решен». АСУЗ будет отправлено соответствующее уведомление в
адрес Заказчика.
1.12.
Заказчик по факту проверки устранения недостатков в Работах или
результатах Работ выставляет обращению в АСУЗ статус «Закрыт», в случае наличия
замечаний Заказчик возвращает обращение в работу путем выставления в АСУЗ для
обращения статуса «Назначен».
1.13.
Обращение Заказчика считается выполненным надлежащим образом
после присвоения Исполнителем обращению статуса «Решен», но только в том
случае, когда после этого Заказчиком обращению был присвоен статус «Закрыт».
1.14.
В случае несоблюдения сроков выполнения обращения АСУЗ будет
направлено соответствующее уведомление в адрес Заказчика и Исполнителя.
1.15.
Контроль за соблюдением сроков выполнения обращения
осуществляет Заказчик путем формирования отчетов средствами АСУЗ.
От Заказчика:
___________________/
М.П.
/
От Исполнителя:
________________ /
М.П.
/
59
Соглашение
об охране конфиденциальности информации
г. ________
« ___ » ________ 20 __ года.
Акционерное общество «Системный оператор Единой энергетической
системы» (АО «СО ЕЭС») в лице _______________, действующего на основании
________ (Устава или доверенности от «__» _____20____ г.), и
_____________________ (полное наименование юридического лица) в лице
(должность, фамилия, имя, отчество), действующего на основании _________
(Устава или доверенности от «__» _____20_ г.) (далее совместно именуемые
«Стороны», а по отдельности – «Сторона»), заключили настоящее соглашение об
охране каждой из Сторон конфиденциальности информации другой Стороны (далее –
Соглашение) о нижеследующем.
1. Термины и определения
Передающая сторона – Сторона настоящего Соглашения, предоставляющая
другой Стороне доступ к Конфиденциальной информации, обладателем которой она
является, в том числе путем передачи Конфиденциальной информации на
материальном носителе, и (или) предъявляющая требование к другой Стороне о
соблюдении конфиденциальности информации, содержащейся в материалах,
разрабатываемых другой Стороной в ходе исполнения договора, заключенного
Сторонами.
Принимающая сторона – Сторона настоящего Соглашения, получающая от
другой Стороны доступ к Конфиденциальной информации, обладателем которой
является другая Сторона, в том числе путем приема материальных носителей с
Конфиденциальной информацией, и (или) разрабатывающая материалы в ходе
исполнения договора, заключенного Сторонами, содержащие информацию, в
отношении которой другая Сторона предъявляет требование о соблюдении ее
конфиденциальности.
Конфиденциальная информация – информация Передающей стороны,
признаваемая конфиденциальной в соответствии с законодательством Российской
Федерации, локальными нормативными актами Передающей стороны, с которыми
ознакомлена Принимающая сторона, иная информация, в отношении которой
Передающей стороной заявлено требование о соблюдении ее конфиденциальности, в
том числе информация, указанная в качестве конфиденциальной в договорах между
Сторонами, включая информацию, составляющую коммерческую тайну;
информацию для служебного пользования; информацию, относящуюся к
персональным данным; инсайдерскую информацию.
Конфиденциальность информации – обязательное для выполнения
Принимающей стороной, получившей доступ к Конфиденциальной информации
Передающей стороны, требование не раскрывать и не передавать Конфиденциальную
60
информацию Передающей стороны третьим лицам без согласия Передающей
стороны.
Информация – сведения (сообщения, данные) независимо от формы их
представления.
Информация, составляющая коммерческую тайну, – сведения любого
характера (производственные, технические, экономические, организационные и др.),
в том числе о результатах интеллектуальной деятельности в научно-технической
сфере, а также сведения о способах осуществления профессиональной деятельности,
которые имеют действительную или потенциальную коммерческую ценность в силу
неизвестности их третьим лицам, к которым у третьих лиц нет свободного доступа на
законном основании и в отношении которых Передающей стороной и (или) третьим
лицом,
перед
которым
Передающая
сторона
обязалась
соблюдать
конфиденциальность информации, введен режим коммерческой тайны.
Информация для служебного пользования – сведения, содержащиеся в
документах и на других материальных носителях с грифом «Для служебного
пользования», получаемых Передающей стороной от органа государственной власти,
иного
государственного
органа,
органа
местного
самоуправления,
подведомственного указанным органам предприятия, учреждения, организации, и
включаемые в документы, подготавливаемые работниками Передающей стороны.
Обладатель Конфиденциальной информации – лицо, которое владеет
Конфиденциальной информацией на законном основании, ограничило доступ к
Конфиденциальной информации и установило в отношении нее режим
конфиденциальности.
Информационные ресурсы – отдельные документы и отдельные массивы
документов, документы и массивы документов в информационных системах
(библиотеках, архивах, фондах, банках данных, других информационных системах).
Доступ к Конфиденциальной информации – ознакомление Принимающей
стороны с Конфиденциальной информацией Передающей стороны и (или) третьих
лиц с согласия Передающей стороны, а также согласия иных лиц (если получение их
согласия предусмотрено настоящим Соглашением) или на ином законном основании
при условии сохранения конфиденциальности этой информации, в том числе путем
передачи Конфиденциальной информации Принимающей стороне.
Передача Конфиденциальной информации – передача Конфиденциальной
информации, зафиксированной на материальном носителе, Передающей стороной
Принимающей стороне или Принимающей стороной третьим лицам с согласия
Передающей стороны, а также с согласия иных лиц (если получение их согласия
предусмотрено настоящим Соглашением) или на ином законном основании при
условии сохранения конфиденциальности информации.
Представление
Конфиденциальной
информации
–
передача
Конфиденциальной информации, зафиксированной на материальном носителе,
органам государственной власти, иным государственным органам, органам местного
самоуправления,
подведомственным
указанным
органам
предприятиям,
учреждениям, организациям в целях выполнения их функций.
Разглашение Конфиденциальной информации – действие или бездействие, в
результате которого Конфиденциальная информация в любой возможной форме
61
(устной, письменной, иной форме, в том числе с использованием технических
средств) становится известной третьим лицам без согласия Передающей стороны, а
также согласия иных лиц (если получение их согласия предусмотрено настоящим
Соглашением).
2. Предмет Соглашения
Принимающая сторона обязуется соблюдать конфиденциальность в отношении
Конфиденциальной информации Передающей стороны, в том числе не допускать ее
разглашения и не использовать во вред Передающей стороне, и обеспечивать
специальные меры охраны и использования Конфиденциальной информации
Передающей стороны, при этом уровень охраны Конфиденциальной информации
Передающей стороны не должен быть ниже, чем для охраны собственной
конфиденциальной информации Принимающей стороны.
3. Обеспечение конфиденциальности
3.1. Принимающая сторона вправе предоставлять доступ своим работникам к
Конфиденциальной информации Передающей стороны только при условии наличия в
трудовых договорах с соответствующими работниками обязательства работников о
неразглашении Конфиденциальной информации Передающей стороны. Передающая
сторона вправе запросить у Принимающей стороны список работников
Принимающей стороны, которым будет предоставляться или был предоставлен
доступ к Конфиденциальной информации Передающей стороны.
3.2. Положения
настоящего
Соглашения
распространяются
на
Конфиденциальную информацию Передающей стороны независимо от вида
носителя, на котором она зафиксирована.
3.3. Информация, передаваемая в письменной, печатной или иной
материальной форме на любых материальных носителях (бумажных, электронных и
т.д.), будет считаться Конфиденциальной информацией только в том случае, если
такая информация имеет гриф ограничения доступа «Коммерческая тайна», «Для
служебного
пользования»
либо
пометку
«Персональные
данные»,
«Конфиденциально» (в зависимости от вида информации).
3.4. Информация, передаваемая в устной форме, будет считаться
Конфиденциальной информацией только в том случае, если в момент передачи будет
обозначена как конфиденциальная информация либо обозначена в зависимости от
вида информации как коммерческая тайна, информация для служебного пользования,
персональные данные, а позднее зафиксирована на материальном носителе с грифом
ограничения доступа «Коммерческая тайна», «Для служебного пользования» либо с
пометкой «Персональные данные», «Конфиденциально» (в зависимости от вида
информации).
3.5. Информация, доступ к которой предоставляется Принимающей стороне без
передачи материального носителя, информация, содержащаяся в информационных
ресурсах, доступ к которым предоставляется Принимающей стороне без передачи
материального носителя, а также информация, разрабатываемая в ходе выполнения
договора, заключенного Сторонами, будет считаться Конфиденциальной
информацией Передающей стороны, если требования об охране ее
62
конфиденциальности содержатся в нормах законодательства Российской Федерации,
локальных нормативных актах Передающей стороны, с которыми ознакомлена
Принимающая сторона, или условиях заключенного Сторонами договора либо в
отношении которой Передающей стороной заявлено требование о сохранении ее
конфиденциальности.
3.6. По каналам связи доступ к Конфиденциальной информации Передающей
стороны производится при условии наличия у Принимающей стороны защищенных
каналов передачи информации.
3.7. Информация для служебного пользования, полученная Передающей
стороной от органа государственной власти, иного государственного органа, органа
местного самоуправления, подведомственных указанным органам предприятия,
учреждения, организации, передается Принимающей стороне только по письменному
решению соответствующего органа государственной власти, иного государственного
органа, органа местного самоуправления, подведомственных указанным органам
предприятия, учреждения, организации, которые приняли решение об отнесении
документа или материального носителя к категории информации для служебного
пользования. Передача Конфиденциальной информации для служебного пользования
Принимающей стороной третьим лицам возможна при условии получения
письменного согласия Передающей стороны и органа государственной власти, иного
государственного органа, органа местного самоуправления, подведомственных
указанным органам предприятия, учреждения, организации, которые приняли
решение об отнесении документа или материального носителя к категории
информации для служебного пользования.
3.8. Перечень сведений, составляющих Конфиденциальную информацию
АО «СО ЕЭС», порядок обращения с Конфиденциальной информацией и контроля за
соблюдением такого порядка в отношении Конфиденциальной информации
АО «СО ЕЭС» устанавливаются следующими локальными нормативными актами
АО «СО ЕЭС», с которыми __________ (указать наименование контрагента)
ознакомилось до подписания настоящего Соглашения:
№
п/п
1
2
Наименование локального
нормативного акта
Регламент работы с информацией,
составляющей коммерческую тайну,
и информацией для служебного
пользования в АО «СО ЕЭС»
Перечень
конфиденциальной
информации АО «СО ЕЭС»
Утверждающий документ
Приказ ОАО «СО ЕЭС»
от 09.10.2015
№ 330
Приказ АО «СО ЕЭС» от
21.03.2023 № 85
Дата ввода в
действие
30.10.2015
21.03.2023
Примечание. Условие пункта 3.9 включается в соглашение в случае
ознакомления АО «СО ЕЭС» по требованию контрагента с локальными
нормативными актами контрагента, устанавливающими перечень сведений,
содержащих Конфиденциальную информацию, и (или) порядок обращения с
Конфиденциальной информацией контрагента и контроля за соблюдением такого
порядка.
3.9. Перечень сведений, составляющих Конфиденциальную информацию
__________ (указать наименование контрагента), порядок обращения с
63
Конфиденциальной информацией и контроля за соблюдением такого порядка в
отношении Конфиденциальной информации __________ (указать наименование
контрагента) устанавливаются следующими локальными нормативными актами
__________
(указать
наименование
контрагента),
с
которыми
АО «СО ЕЭС» ознакомилось до подписания настоящего Соглашения:
№
п/
п
Наименование локального
нормативного акта
Утверждающий
документ
Дата
ввода в
действие
1
2
4. Права Передающей стороны
4.1. Передающая сторона вправе:
4.1.1. Относить информацию к Конфиденциальной информации Передающей
стороны, определять перечень и состав Конфиденциальной информации.
4.1.2. Использовать Конфиденциальную информацию Передающей стороны
для собственных нужд в порядке, не противоречащем законодательству Российской
Федерации.
4.1.3. Разрешать или запрещать доступ к Конфиденциальной информации
Передающей стороны своим работникам и (или) третьим лицам, определять порядок
и условия доступа к ней.
4.1.4. Без согласования с Принимающей стороной, но с последующим
уведомлением устанавливать, изменять и отменять в письменной форме режим
конфиденциальности информации.
4.1.5. Требовать от Принимающей стороны и ее работников, получивших
доступ к Конфиденциальной информации Передающей стороны, соблюдения
обязанностей по охране ее конфиденциальности.
4.1.6. Требовать от работников Принимающей стороны, получивших доступ к
Конфиденциальной информации Передающей стороны в результате действий,
совершенных случайно или по ошибке, охраны конфиденциальности этой
информации.
4.1.7. Защищать в установленном законом порядке свои права в случае
разглашения, незаконного получения или незаконного использования третьими
лицами Конфиденциальной информации Передающей стороны, в том числе
требовать возмещения убытков, причиненных в связи с нарушением ее прав.
5. Права Принимающей стороны
5.1. Принимающая сторона вправе:
5.1.1. В соответствии с законодательством Российской Федерации
самостоятельно определять способы защиты Конфиденциальной информации
Передающей стороны. Однако при этом должны быть обеспечены:
исключение доступа к Конфиденциальной информации Передающей
стороны любых лиц без согласия Принимающей стороны;
64
возможность
использования
Конфиденциальной
информации
Передающей стороны работниками Принимающей стороны без нарушения режима
конфиденциальности информации;
возможность доступа к Конфиденциальной информации Передающей
стороны третьих лиц только при условии получения согласия Передающей стороны, а
также иных лиц (если получение их согласия предусмотрено настоящим
Соглашением) и письменного обязательства о соблюдении третьими лицами,
которым предоставляется доступ к Конфиденциальной информации Передающей
стороны, условий конфиденциальности, аналогичных условиям, установленным
настоящим Соглашением.
5.1.2. Представлять органам государственной власти, иным государственным
органам, органам местного самоуправления, подведомственным указанным органам
предприятиям, учреждениям, организациям по их мотивированному требованию
Конфиденциальную информацию Передающей стороны без согласия Передающей
стороны только в случаях, когда представление информации обязательно в
соответствии с законодательством Российской Федерации.
6. Обязанности Принимающей стороны
6.1. Принимающая сторона обязана:
6.1.1. Ограничивать доступ к Конфиденциальной информации Передающей
стороны путем установления порядка обращения с Конфиденциальной информацией
и контроля за соблюдением такого порядка.
6.1.2. Не использовать Конфиденциальную информацию Передающей стороны
в целях, не связанных с исполнением обязательств по договору, заключенному
Сторонами, или в иных целях, для которых к Конфиденциальной информации
Передающей стороной предоставлен доступ Принимающей стороне.
6.1.3. Вести учет лиц, получивших доступ к Конфиденциальной информации
Передающей стороны, и по запросу Передающей стороны незамедлительно
представлять ей сведения о таких лицах.
6.1.4. Урегулировать отношения со своими работниками, которые получают
доступ
к
Конфиденциальной
информации
Передающей
стороны.
В этих целях Принимающая сторона обязана:
а)
ознакомить
под
роспись
работника,
доступ
которого
к
Конфиденциальной информации Передающей стороны необходим для выполнения
им своих трудовых обязанностей, с перечнем информации конфиденциального
характера, утверждаемого Передающей стороной, а также с установленным
Принимающей стороной режимом конфиденциальности и мерами ответственности за
его нарушение;
б)
создать работнику необходимые условия для соблюдения им
установленного Принимающей стороной режима конфиденциальности информации.
6.1.5. Исключать доступ лиц, право доступа которых к Конфиденциальной
информации не установлено, к Конфиденциальной информации Передающей
стороны без согласия Передающей стороны.
При необходимости предоставить доступ к Конфиденциальной информации
Передающей стороны третьим лицам Принимающая сторона обязана уведомить об
65
этом Передающую сторону в письменной форме и получить письменное согласие на
предоставление доступа к Конфиденциальной информации Передающей стороны
третьему лицу по каждому отдельному случаю.
6.1.6. В случае представления Конфиденциальной информации Передающей
стороны органам государственной власти, иным государственным органам, органам
местного самоуправления, подведомственным указанным органам предприятиям,
учреждениям, организациям, когда такое представление Конфиденциальной
информации обязательно в соответствии с законодательством Российской
Федерации, незамедлительно письменно уведомить об этом Передающую сторону,
если иное не установлено нормами законодательства Российской Федерации.
6.1.7. Незамедлительно сообщить Передающей стороне о допущенном
Принимающей стороной либо ставшем ей известном факте разглашения или угрозе
разглашения, незаконном получении или незаконном использовании третьими
лицами Конфиденциальной информации Передающей стороны, принимать
необходимые меры по восстановлению конфиденциальности информации, не
допускать дальнейшего несанкционированного использования или разглашения
Конфиденциальной информации Передающей стороны.
7. Ответственность Принимающей стороны
Принимающая сторона в случае причинения Передающей стороне убытков
вследствие неисполнения или ненадлежащего исполнения условий настоящего
Соглашения, в том числе причиненных действиями (бездействием) третьих лиц,
которым Принимающей стороной предоставлен доступ к Конфиденциальной
информации Передающей стороны, обязана возместить причиненные убытки в
полном объеме в соответствии с законодательством Российской Федерации.
8. Срок действия Соглашения
8.1. Настоящее Соглашение заключается на неопределенный срок и вступает в
силу с момента его подписания Сторонами.
Настоящее Соглашение может быть расторгнуто по соглашению Сторон при
отсутствии заключенных Сторонами договоров, по которым передача
Конфиденциальной информации регулируется настоящим Соглашением.
8.2. Расторжение настоящего Соглашения не освобождает Принимающую
сторону от исполнения обязательств, принятых по настоящему Соглашению в период
его действия, в отношении Конфиденциальной информации Передающей стороны,
переданной Принимающей стороне до прекращения действия настоящего
Соглашения, а также не освобождает от ответственности, установленной
законодательством Российской Федерации и настоящим Соглашением.
8.3. Обязательства Принимающей стороны в отношении Конфиденциальной
информации Передающей стороны остаются в силе в течение срока действия режима
конфиденциальности Конфиденциальной информации Передающей стороны, в том
числе после прекращения действия настоящего Соглашения. Срок действия режима
конфиденциальности Конфиденциальной информации Передающей стороны
устанавливается законодательством Российской Федерации и (или) локальными
нормативными актами Передающей стороны, а если такой срок не установлен – в
66
течение действия заключенного Сторонами договора, в ходе выполнения которого
осуществлялся доступ Принимающей стороны к Конфиденциальной информации
Передающей стороны, и пяти лет после его прекращения.
Соглашением между Сторонами может быть установлен иной срок действия
режима конфиденциальности Конфиденциальной информации Передающей
стороны.
9. Прочие условия
9.1. Настоящее Соглашение составлено в двух экземплярах – по одному для
каждой Стороны. Оба экземпляра имеют равную юридическую силу.
9.2. Требования настоящего Соглашения обязательны для исполнения
Сторонами, их законными представителями и правопреемниками.
9.3. Все споры, разногласия и требования, возникающие из настоящего
Соглашения или в связи с ним, в том числе связанные с его заключением, изменением,
исполнением, нарушением, расторжением, прекращением или действительностью,
подлежат разрешению в суде.
9.4. Изменения и дополнения к настоящему Соглашению согласовываются
Сторонами и оформляются путем подписания дополнительных соглашений.
10. Реквизиты и подписи Сторон
АО «СО ЕЭС»
Адрес, ИНН, ОГРН
Наименование
с
указанием
организационно-правовой формы
Адрес, ИНН, ОГРН
Подписи Сторон:
Должность
Должность
_____________________ Инициалы, фамилия
М.П.
_____________________ Инициалы, фамилия
М.П.
67
Соглашение
о соблюдении требований по информационной безопасности №__
г. Москва
«___» _____________ 20__ года
Акционерное общество «Системный оператор Единой энергетической
системы» (АО «СО ЕЭС») в лице _______________, действующего на основании
________ (Устава или доверенности от «__» _____20____ г.) (далее - Заказчик), и
_____________________ (полное наименование юридического лица) в лице
(должность, фамилия, имя, отчество), действующего на основании _________
(Устава или доверенности от «__» _____20_ г.) (далее - Субъект информационного
обмена, Субъект) (далее совместно именуемые «Стороны», а по отдельности –
«Сторона»), заключили настоящее соглашение о соблюдении требований по
информационной безопасности (далее – Соглашение) о нижеследующем.
1. Термины и определения
Заказчик – сторона Соглашения, выступающая по Договору с Субъектом
информационного
обмена
Заказчиком
(Покупателем,
Лицензиатом/Сублицензиатом).
ЗУД – защищенный удаленный доступ – доступ к внутренним ресурсам
Заказчика специалистами Субъекта из информационно-телекоммуникационной сети
«Интернет» через демилитаризованную зону Заказчика, осуществляемый с
использованием средств криптографической защиты информации, путем выпуска
удостоверяющим центром Заказчика и передачи Субъекту информационного обмена
ключа и сертификата ключа проверки электронной подписи.
ИБ – информационная безопасность.
Инструктаж по ИБ – доведение Заказчиком до Субъекта сведений о правилах
и политике информационной безопасности Заказчика, которое может осуществляться
в любом удобном виде (прохождение курса, ознакомление с памяткой, методичкой
или локальными нормативными актами Заказчика и др.) в соответствии с
программой, разработанной Заказчиком.
Инцидент ИБ – появление одного или нескольких нежелательных или
неожиданных состояний информационной системы, сервиса или информационнотелекоммуникационной сети Заказчика и/или Субъекта, указывающих на нарушение
требований по ИБ или отказ технических средств Заказчика и/или Субъекта,
обеспечивающих ИБ, или возникновение ситуации, которая может иметь отношение
к ИБ, и которые нарушили или с значительной вероятностью могут нарушить
функционирование деловых процессов и создать угрозы ИБ Заказчика и/или
Субъекта.
Информация – сведения (сообщения, данные) независимо от формы их
представления.
Информационный ресурс Заказчика – это информация, зафиксированная на
материальном носителе и/или находящаяся в информационных (информационноуправляющих) системах.
68
Договор – любой действующий между Заказчиком и Субъектом договор.
Признаки инцидента ИБ - к признакам инцидента ИБ относятся:
‒ нетиповая загрузка ресурсов оборудования (центрального процессора,
оперативного запоминающего устройства, жесткого диска или SSD;
‒ сетевая активность (увеличение сетевого трафика, нехарактерная
рассылка запросов, сканирование портов и т. д.);
‒ множественные неудачные попытки аутентификации и авторизации в
системе Заказчика;
‒ наличие незнакомых или подозрительных файлов на диске компьютера
Заказчика/ Субъекта;
‒ некорректное поведение браузера на компьютере Субъекта,
перенаправление на подозрительные сайты;
‒ нештатное отключение антивируса на серверах и компьютерах Субъекта;
‒ сообщения антивируса о наличии не вредоносной, но потенциально
опасной программы.
Событие ИБ - идентифицированное возникновение состояния системы,
сервиса или сети Заказчика и/или Субъекта, указывающее на возможное нарушение
политики информационной безопасности, отказ защитных мер, а также
возникновение ранее неизвестной ситуации, которая может быть связана с
безопасностью.
Субъект информационного обмена (Субъект) - Сторона Соглашения,
выступающая по Договору с Заказчиком Поставщиком (Исполнителем/Подрядчиком,
Лицензиаром/Лицензиатом).
Сменный носитель информации – материальный носитель, подключаемый к
компьютерному оборудованию (usb-носители, флэш-память, оптические или
магнитооптические диски и др.) с зафиксированной на нем информацией.
УЗ – учетная(-ые) запись(-и) Субъекта в инфраструктуре Заказчика, в том числе
используемая для подключения к внутренним ресурсам Заказчика с помощью ЗУД.
2. Предмет Соглашения
Субъект информационного обмена обязуется соблюдать установленные
Соглашением требования по информационной безопасности, в том числе при
предоставлении Субъекту и использовании Субъектом ЗУД к корпоративной
информационной системе Заказчика.
3. Права и обязанности Сторон
3.1. Субъект обязан:
3.1.1. Соблюдать требования действующего законодательства Российской
Федерации в области защиты информации.
3.1.2.При выполнении работ/оказании услуг средствами ЗУД незамедлительно
информировать Заказчика по электронному адресу omsib@odusv.so-ups.ru и телефону
8 (846) 279-71-98 об обнаружении признаков Инцидента ИБ в информационных
системах Субъекта.
69
3.1.3. В целях нейтрализации угроз безопасности, соблюдать все указания
Службы информационной безопасности Заказчика при работе с информационными
ресурсами Заказчика.
3.1.4. Предоставлять по запросу Заказчика любую информацию, связанную с
инцидентом / событием ИБ, возникшим в информационных системах Субъекта в ходе
выполнения Субъектом работ / оказания услуг на информационных ресурсах
Заказчика, посредством ЗУД.
3.1.5. В случае возникновения инцидента / события ИБ – обеспечить
специалистам Заказчика беспрепятственный доступ к программному и аппаратному
обеспечению, предоставить необходимую информацию, техническую и
эксплуатационную документацию на имеющиеся у Субъекта информационные
ресурсы, которые используются в рамках выполнения работ на информационных
ресурсах Заказчика, возможность провести копирование и пересылку Информации,
оказать содействие в сборе необходимой информации и иное содействие в рамках
реагирования (расследования) инцидентов.
3.1.6. В зависимости от предмета обязательств по Договору, Субъект обязан:
3.1.6.1. обеспечить отсутствие в передаваемой в рамках исполнения обязательств
по Договору Информации файлов, содержащих вредоносное ПО (в случае
предоставления Заказчику информации в электронном виде (например, с
использованием сменных носителей информации или путем направления ссылки на
электронный ресурс).
3.1.6.2. в случае необходимости осуществления доступа к информационным
ресурсам Заказчика посредством ЗУД, для принятия Заказчиком решения о допуске
специалистов Субъекта к выполнению работ на информационных ресурсах Заказчика
посредством ЗУД выполнять следующие требования по соблюдению
информационной безопасности:
- предоставить заполненную анкету по форме, согласно Приложению №1 к
Соглашению в срок не более 3 (Трех) рабочих дней с даты заключения
соответствующего Договора с Заказчиком;
- обеспечить выполнение основных требований по ИБ, предъявляемых к
Субъекту, согласно Приложению № 2 к Соглашению;
- исполнить обязанности Субъекта при выполнении работ / оказании услуг на
информационных ресурсах посредством ЗУД, согласно Приложению № 4 к
Соглашению;
- предоставить отчет об антивирусной проверке оборудования Субъекта,
используемого для целей ЗУД (далее – оборудование Субъекта) в срок не более 3
(Трех) рабочих дней с даты заключения соответствующего Договора с Заказчиком;
- обеспечить отсутствие вредоносного ПО на ЭВМ, подключаемых к
информационным ресурсам Заказчика.
3.1.6.3. В случае выполнения работ / оказания услуг на объекте Заказчика
выполнять следующие требования по соблюдению информационной безопасности:
- обеспечить выполнение обязанностей Субъекта при выполнении работ /
оказании услуг непосредственно на территории Заказчика, согласно
Приложению № 5 к Соглашению.
3.1.7. Подписывая Соглашение, Субъект дает право Заказчику на проведение в
70
случае необходимости, определяемой по решению Заказчика, оценки защищенности
в соответствии с Программой и методикой, описанной в Приложении № 3 к
Соглашению. Заказчик уведомляет Субъект о своем решении на проведение оценки
защищенности не позднее чем за 3 (Три) рабочих дня до проведения указанной
оценки.
3.1.8. По требованию Заказчика обеспечить прохождение специалистами
Субъекта Инструктажа по ИБ, организуемого Заказчиком.
3.2. Субъект вправе:
3.2.1. Получать консультации специалистов Заказчика о порядке
предоставления и использования ЗУД.
3.2.2. Получать консультации относительно требований по ИБ и порядка их
выполнения.
3.3. Заказчик обязан:
3.3.1. Принять решение о предоставлении/отказе в предоставлении Субъекту
допуска к выполнению работ на территории Заказчика или посредством ЗУД к
информационным ресурсам Заказчика, на основании документов и по результатам
мероприятий, указанных в пунктах 3.1.6.2 и (или) 3.1.6.3, а также в пункте 3.1.7
Соглашения.
3.3.2. Ознакомить Субъекта с требованиями по ИБ необходимыми при
выполнении конкретного вида работ / оказания услуг (если данные требования не
содержатся в Соглашении).
3.4. Заказчик вправе:
3.4.1. Проводить проверки соблюдения Субъектом требований по ИБ, в том
числе проверку состава программного и аппаратного обеспечения оборудования
Субъекта, подключаемого к информационным ресурсам Заказчика.
3.4.2. Заказчик вправе осуществлять мониторинг, контроль, запись действий
Субъекта (процессов, запускаемых от имени Субъекта), в том числе осуществляемых
через ЗУД.
3.4.3. При фиксации Заказчиком события(-ий) (инцидента(-ов)) ИБ в рамках
выполнения работ Субъектом, организовать и участвовать в реагировании и
расследовании события(-ий) (инцидента(-ов)) ИБ.
3.4.4. В рамках реагирования и расследования события(-ий) (инцидента(-ов))
ИБ Заказчик вправе запрашивать у Субъекта любую Информацию, относящуюся к
данному событию (инциденту), а также проводить оценку защищенности в
соответствии с Программой и методикой, описанной в Приложении № 3 к
Соглашению.
3.4.5. При фиксации Заказчиком события(-ий) (инцидента(-ов)) ИБ в рамках
выполнения работ /оказания услуг Субъектом, Заказчик вправе приостановить
выполнение работ / оказание услуг сотрудниками Субъекта непосредственно на
информационных ресурсах Заказчика до окончания проведения расследования
соответствующего события (инцидента) ИБ и завершения мероприятий по оценке
защищенности, при этом указанная приостановка выполнения работ / оказания услуг
Заказчиком не влечет изменения сроков выполнения работ / оказания услуг
Субъектом по Договору.
71
3.4.6. При несоблюдении Субъектом требований ИБ, Заказчик вправе
приостановить выполнение работ / оказание услуг специалистами Субъекта
непосредственно на информационных ресурсах Заказчика до момента
предоставления Субъектом подтверждения устранения нарушений требований ИБ.
4. Ответственность Субъекта,
обязательства по возмещению потерь Заказчика
4.1. Субъект информационного обмена несет ответственность за просрочку
выполнения обязательств по Договору, в том числе за период приостановки
выполнения работ / оказания услуг, и возмещает Заказчику в полном объеме убытки,
возникшие вследствие события (инцидента) ИБ, если по результатам расследования
события (инцидента) ИБ установлено, что событие (инцидент) ИБ произошло
вследствие действий (бездействия) Субъекта и (или) лиц, указанных в п. 4.2
Соглашения.
4.2. Субъект информационного обмена несет ответственность за действия
(бездействие) лиц, на которых возложено непосредственное исполнение обязательств
по Договору, в том числе, которым Субъектом или по инициативе Субъекта
предоставлен доступ к системам, сервисам или сети Заказчика и/или Субъекта,
ключевым носителям информации и/или паролям УЗ.
4.3. В случаях, не предусмотренных п. 4.1 и п. 4.2 Соглашения, Субъект
информационного обмена обязан возместить Заказчику все имущественные потери,
вызванные наступлением события (инцидента) ИБ, если по результатам
расследования события (инцидента) ИБ установлено, что событие (инцидент) ИБ
произошло в информационной системе, сервисе или информационнотелекоммуникационной сети Субъекта.
5. Прочие условия
5.1. Соглашение заключается на неопределенный срок и вступает в силу с
момента его подписания Сторонами.
5.2. Прекращение действия Соглашения не освобождает Субъекта от
ответственности, установленной законодательством Российской Федерации и
Соглашением.
5.3. Соглашение составлено в двух экземплярах – по одному для каждой
Стороны. Оба экземпляра имеют равную юридическую силу (в случае подписания
Соглашения собственноручной подписью на бумажном носителе).
ИЛИ
Соглашение составлено в электронной форме и подписано усиленной
квалифицированной электронной подписью уполномоченных лиц обеих Сторон
посредством электронного документооборота через оператора электронного
документооборота (в случае подписания Соглашения в электронной форме с
использованием усиленной квалифицированной электронной подписи).
5.4. Требования Соглашения обязательны для исполнения Сторонами, их
законными представителями и правопреемниками.
5.5. Все споры, разногласия и требования, возникающие из Соглашения или в
72
связи с ним, в том числе связанные с его заключением, изменением, исполнением,
нарушением, расторжением, прекращением или действительностью, подлежат
разрешению в суде.
5.6. Изменения и дополнения к Соглашению согласовываются Сторонами и
оформляются путем подписания дополнительных соглашений.
5.7. Условия Соглашения применяются ко всем Договорам, заключенным
между Заказчиком и Субъектом информационного обмена.
Соглашение может быть расторгнуто по соглашению Сторон при отсутствии
заключенных между Сторонами Договоров.
Расторжение Соглашения не освобождает Субъекта информационного обмена
от исполнения обязательств, принятых по Соглашению в период его действия, до
прекращения действия Соглашения, а также не освобождает от ответственности,
установленной законодательством Российской Федерации и Соглашением.
5.8. К Соглашению прилагаются в качестве его неотъемлемой части:
Приложение № 1 – Форма анкеты для Субъекта по вопросам
информационной безопасности;
Приложение № 2 – Основные требования по ИБ, предъявляемые к
Субъекту;
Приложение № 3 – Программа и методика проведения контроля
защищенности.
Приложение № 4 – Обязанности субъекта при выполнении работ /
оказании услуг на информационных ресурсах посредством ЗУД
Приложение № 5 – Обязанности Субъекта при выполнении работ /
оказании услуг непосредственно на территории Заказчика
АО «СО ЕЭС»
Адрес, ИНН, ОГРН
6. Реквизиты и подписи Сторон
Наименование
с
указанием
организационно-правовой формы
Адрес, ИНН, ОГРН
Подписи Сторон:
Должность
Должность
________________ /_________/
М.П.
________________ /_________/
М.П.
73
Приложение №1
к Соглашению о соблюдении требований по
информационной безопасности от __.__. ___ № __
ФОРМА
Анкета для Субъекта
по вопросам информационной безопасности
Наименование Субъекта:
Дата заполнения:
С целью обеспечения необходимого уровня ИБ и оперативного
реагирования на возможные угрозы ИБ обеспечить предоставление следующих
сведений на адреса:
omsib@odusv.so-ups.ru, ia-sib-dev@so-ups.ru
№
п/п
1
2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
3
4
5
Вопрос
Контакты (ФИО, электронная почта и телефон)
представителя Субъекта, с которым можно
взаимодействовать по вопросам обеспечения ИБ и
удаленного доступа к ресурсам АО «СО ЕЭС».
Какие приняты меры по реализации рекомендаций
НКЦКИ: https://safe-surf.ru/specialists/news/677262/?
sphrase_id=46031
Какие инвентаризационные мероприятия проводятся
в организации?
Осуществляется ли управление доступом к
информационным ресурсам через сеть Интернет?
Как организована защита веб-приложений?
Какие методы и средства защиты используются для
службы электронной почты?
Какие методы и средства защиты используются для
служб DNS?
Какие установлены требования к парольной защите?
Какие методы и средства защиты используются для
информационно-телекоммуникационной
сети
организации? Каким образом в организации
реализована защита периметра корпоративной сети?
Как организован контроль ИБ? В т.ч. в части
управления уязвимостями?
Проводился ли в организации внешний анализ
защищенности (пентест)? Если проводился, то когда?
Обеспечивается ли сообщение ответственному лицу
АО «СО ЕЭС» о фактах увольнения сотрудников
организации, которым ранее был предоставлен
удаленный доступ к ресурсам АО «СО ЕЭС»?
Используются ли для удаленного доступа к ресурсам
АО «СО ЕЭС» личные устройства сотрудников
организации?
Ответ
74
№
п/п
Вопрос
Ответ
Какой используется антивирус и как часто
обновляются антивирусные базы на рабочих местах
6
организации, c которых осуществляется удаленный
доступ к ресурсам АО «СО ЕЭС»?
Какие
еще
средства
защиты
информации
применяются в организации?
В рамках ответа на данный вопрос необходимо
указать класс (категорию) средства защиты
7
информации, используемого в организации в
формате: класс (категорию), наименование, версия.
Например, Межсетевой экран - UserGate E3000;
средство криптографической защиты информации ViPNet HW 1000; Антириус – Dr.Web
Перечень доменов и IP-адресов, доступных из сети
8
Интернет (необходимы для проведения контроля
защищенности, см. Приложение 3)
Перечень доменов и IP-адресов, которые нельзя
подвергать контролю защищенности, к примеру
9
высокого риска нарушения доступности или
принадлежность/использование третьей стороной
(см. Приложение 3)
Временные промежутки, в которые нельзя проводить
контроль защищенности (см. Приложение 3). При
10
этом, продолжительность временного промежутка не
должна быть равна полному рабочему дню
Контактные данные ответственного, с которым
11
необходимо контактировать при проведении
контроля защищённости (см. Приложение 3)
Примечание: порядок заполнения анкеты и предоставления данных по настоящей
Анкете согласовывается предварительно с Заказчиком.
По согласованию с Субъектом Заказчик с помощью технических средств
может проводить проверку сведений, указанных в анкете, в части контроля
реализации мер защиты и анализа защищенности.
Подписи Сторон:
от Заказчика:
Должность
от Субъекта информационного обмена:
Должность
________________ /_________/
М.П.
________________ /_________/
М.П.
75
Приложение № 2
к Соглашению о соблюдении требований по
информационной безопасности от __.__. ___ № __
Основные требования по ИБ, предъявляемые к Субъекту
1. Требования к оборудованию Субъекта
1.1. При осуществлении подключения к информационным ресурсам
Заказчика посредством не принадлежащего Заказчику оборудования –
оборудования Субъекта (компьютер или иное средство вычислительной техники
(ноутбук, мобильное устройство), такое оборудование должно соответствовать
следующим требованиям:

на оборудовании Субъекта должны быть установлены последние
обновления для общесистемного программного обеспечения, включая
обновления безопасности;

на оборудовании Субъекта должно быть установлено и
функционировать отечественное средство антивирусной защиты с актуальными
антивирусными базами;

предоставлен отчет о полной проверке средством антивирусной
защиты текущего состояния оборудования Субъекта (отчет должен быть не
старше 7 (Семи) дней), не содержащий события выявления вредоносного
программного обеспечения или иных событий ИБ.
2. Требования к парольной защите учетных записей в
инфраструктуре Заказчика
2.1. Субъект обязан соблюдать следующие требования к организации
парольной защиты УЗ:
 УЗ создается и закрепляется за каждым специалистом Субъекта;
 УЗ должна быть уникальной для каждого специалиста Субъекта
информационного обмена;
 длина пароля пользовательских УЗ Субъекта должна составлять не менее
12 символов, длина пароля административных УЗ Субъекта должна быть не
менее 14 символов, длина пароля сервисных УЗ Субъекта должна быть не
менее 25 символов, за исключением случаев, если информационно
управляющая система (ИУС) не поддерживает длину пароля в 25 символов
и более, то устанавливается пароль с максимально поддерживаемой ИУС
длиной;
 в качестве пароля УЗ должна выбираться последовательность символов,
обеспечивающая малую вероятность ее подбора и состоящая из букв
латинского алфавита в верхнем и нижнем регистре (A-a), цифр и
специальных символов (~ ! @ # $ % & и т.п.), за исключением случаев, когда
специальные символы не могут использоваться в качестве элемента пароля
(требования отдельных информационных систем);
 для создания пароля рекомендуется следовать инструкциям, указанным в
пункте 3 данного приложения;
76
 запрещается использовать в качестве пароля: «пустой» пароль, имя
пользователя (за исключением случаев, когда это предусмотрено
эксплуатационной документацией информационного ресурса), простые
пароли типа «123», «111», «qwerty» и им подобные, а также имена, даты
рождения, клички домашних животных, номера автомобилей, телефонов и
другие пароли, которые можно подобрать, основываясь на информации о
специалисте, или которые могут быть подобраны по словарям;
 запрещается использование стандартных паролей, предусмотренных
производителем оборудования или программного обеспечения для его
первоначальной настройки, после завершения таковой;
 срок действия пароля пользовательской и административной УЗ должен
составлять не более 90 (Девяноста) дней, срок действия паролей сервисных
УЗ не более 3 (Трех) лет;
 в случае компрометации пароля (подсматривание пароля кем-либо,
разглашение пароля и т.д.) специалист Субъекта обязан немедленно
изменить свой пароль с учетом требований, изложенных выше.
Подписи Сторон:
от Заказчика:
Должность
от Субъекта информационного обмена:
Должность
________________ /_________/
М.П.
________________ /_________/
М.П.
77
Приложение № 3
к Соглашению о соблюдении требований по
информационной безопасности от __.__. ___ № __
Программа и методика проведения контроля защищенности
1. Предмет и техническое описание:
Целью проведения контроля защищенности является контроль защищенности
конфиденциальной информации от несанкционированного доступа в средствах и
системах
информатизации
Субъекта
путем
моделирования
действий
высококвалифицированных злоумышленников, проводящих целенаправленные
атаки на объекты информационной инфраструктуры.
Для этого специалисты Заказчика разрабатывают и моделируют различные
сценарии угроз, имитируя действия потенциального злоумышленника.
Имитация действий потенциального злоумышленника должна включать в себя
следующие этапы развития атаки:
 поиск векторов компрометации сервисов и систем, доступных из сети
Интернет, а также проверка возможности получения несанкционированного
доступа к критичной информации;
 получение первоначального доступа во внутреннюю сеть Субъекта;
 повышение привилегий в системе Субъекта;
 закрепление во внутренней сети Субъекта;
 горизонтальное продвижение во внутренней сети Субъекта;
 извлечение данных Субъекта.
В ходе работ могут быть смоделированы следующие типы угроз:
 Внешний злоумышленник: попытка получения доступа во внутреннюю сеть
Субъекта путем проникновения через внешние сервисы, доступные из сети
Интернет.
 Внутренний злоумышленник: попытка повышения привилегий и получения
доступа к системам Субъекта из внутренней сети Субъекта.
Для этого будут проводиться следующие виды атак, которые могут включать в
себя:
 сбор информации об объекте тестирования;
 тестирование на проникновение и поиск векторов компрометации сервисов
Субъекта, доступных из сети Интернет:
 идентификация уязвимостей данных сервисов и систем;
 поиск возможности обхода существующих средств защиты;
 применение инструментов автоматизированного анализа защищенности.
 Обеспечение устойчивости и развитие атаки во внутреннюю сеть Субъекта:
 анализ обнаруженных уязвимостей рабочих станций пользователей,
компонентов информационных систем, сетевого оборудования и сетевых
средств защиты;
78

моделирование атак на уровне приложений, сетевых сервисов и
операционных систем, с использованием специализированных средств, а
также сведений об известных уязвимостях и ошибках конфигурации в
отношении выявленных систем;
 попытка эскалации привилегий пользователей системы - проверка
возможности получения пользователем прав администратора;
 попытка не регламентного повышения привилегий в ИТ-сервисах
авторизованными пользователями и возможности получения доступа к
закрытой информации;
 попытка компрометации сервисов Субъекта c целью получения доступа к
конфиденциальной информации или информации ограниченного круга;
 попытка получения доступа к контроллеру домена.
2. Место проведения:
Удаленно на территории Российской Федерации.
3. Область:
Для начала проведения контроля защищенности Субъект предоставляет
Заказчику заполненную анкету (по форме Приложения № 1 к Соглашению).
Заказчик обязуется согласовывать с Субъектом атаки, которые потенциально
могут привести к неработоспособности ресурса/сервиса.
4. Отчетные документы:
Специалисты Заказчика готовят экспертное заключение по итогам контроля
защищенности, в котором описывают результаты проведенных мероприятий и
принятое решение о возможности (невозможности) предоставления ЗУД.
Данное экспертное заключение предоставляется Субъекту в электронной
форме по указанным им в анкете (по форме Приложения № 1 к Соглашению)
контактным данным.
Подписи Сторон:
от Заказчика:
Должность
от Субъекта информационного обмена:
Должность
________________ /_________/
М.П.
________________ /_________/
М.П.
79
Приложение № 4
к Соглашению о соблюдении требований по
информационной безопасности от __.__. ___ № __
Обязанности Субъекта при выполнении работ / оказании услуг на
информационных ресурсах посредством ЗУД
1. Для технической возможности предоставления ЗУД - обратиться в
удостоверяющий центр Заказчика в целях получения сертификата ключа проверки
электронной подписи в соответствии с Регламентом удостоверяющего центра (далее
– УЦ) АО «СО ЕЭС» (Регламент УЦ АО «СО ЕЭС» размещен для ознакомления на
официальном сайте АО «СО ЕЭС» по адресу: https://www.so-ups.ru/about/udc/) и
«Соглашением об использовании субъектом информационного обмена электронной
подписи при информационном обмене с АО «СО ЕЭС» (с юридическим лицом)»,
заключенным с Заказчиком по форме, утвержденной Заказчиком.
2. При организации ЗУД обеспечить криптографическую защиту канала связи, в
том числе с использованием сертифицированных средств криптографической защиты
информации в случаях, установленных законодательством Российской Федерации.
3. При настройке ЗУД обеспечить параметры безопасности устройств
(персональных компьютеров, ноутбуков, планшетов, смартфонов и т.п.), с которых
осуществляется ЗУД, в соответствии с Регламентом УЦ АО «СО ЕЭС» (размещен для
ознакомления
на
официальном
сайте
АО
«СО ЕЭС»
по
адресу:
https://www.so-ups.ru/about/udc/) и/или Инструкцией пользователя подсистемы
защищенного удаленного доступа системы защиты периметра Исполнительного
аппарата АО «СО ЕЭС» (передается при получении криптографических ключей).
4.
Иметь
установленное
клиентское
программное
обеспечение,
предназначенное для создания защищенного соединения с корпоративной
информационной системой Заказчика. Клиентское программное обеспечение
Субъекта должно быть совместимо с эксплуатируемыми у Заказчика средствами
криптографической защиты информации, используемыми для организации ЗУД.
5. Аннулирование ЗУД для специалиста(-ов) Субъекта осуществляется в
следующих случаях:
5.1. расторжения (истечения срока действия) Договора;
5.2. прекращения правоотношений между Субъектом и его специалистом или
отстранение последнего от производства работ / оказания услуг по Договору;
5.3. оповещения об утрате (потере, хищении) ключевых документов
(носителей) специалистом Субъекта – для соответствующего специалиста Субъекта;
5.4. неоднократных (два и более раза) нарушений специалистом(-ами) Субъекта
требований ИБ при использовании ЗУД;
5.5. в случае отказа (уклонения) Субъекта от выполнения требований Заказчика
по ИБ, установленных Соглашением, локальных нормативных актов Заказчика, а
также требований законодательства Российской Федерации в части ИБ.
6. В случае аннулирования ЗУД для специалиста(-ов) Субъекта по основаниям,
указанным в пунктах 5.3, 5.4, 5.5 настоящего Приложения № 4 к Соглашению,
80
выполнение работ / оказание услуг непосредственно на территории Заказчика
возможно только специалистами Субъекта, соответствующими требованиям
статьи 10 Федерального закона от 21.07.2011 № 256-ФЗ «О безопасности объектов
топливно-энергетического комплекса» после предоставления всех необходимых
документов и их проверки в соответствии с требованиями указанной статьи.
7. Непредоставление или приостановление ЗУД для специалистов Субъекта
осуществляется в следующих случаях:
 выявления признака инцидента ИБ, фиксация событий ИБ в системах
мониторинга ИБ;
 при выявлении несоответствия сведений, указанных в анкете для Субъекта по
вопросам ИБ при использовании ЗУД (Приложение № 1 к Соглашению);
 при наличии признаков непосредственной угрозы несанкционированного
доступа к информационным ресурсам Заказчика;
 при отказе Субъекта в предоставлении информации или неполном
предоставлении сведений, в соответствии с п. 3.1.6 Соглашения или
несоблюдении иных требований, изложенных в п. 3.1.6 Соглашения;
 фиксация небезопасных сервисов в сети Интернет, имеющих отношение к
Субъекту информационного обмена;
 несоответствии Субъекта требованиям, изложенным в Соглашении.
8. Решение о возобновлении предоставления ЗУД принимается Заказчиком по
результатам устранения Субъектом обстоятельств, указанных в п. 7 настоящего
Приложения.
Подписи Сторон:
от Заказчика:
Должность
от Субъекта информационного обмена:
Должность
________________ /_________/
М.П.
________________ /_________/
М.П.
81
Приложение № 5
к Соглашению о соблюдении требований по
информационной безопасности от __.__. ___ № __
Обязанности Субъекта при выполнении работ / оказании услуг
непосредственно на территории Заказчика
1. Выполнение работ / оказание услуг непосредственно на территории
Заказчика возможно только специалистами Субъекта, соответствующими
требованиям статьи 10 Федерального закона от 21.07.2011 № 256-ФЗ «О
безопасности
объектов
топливно-энергетического
комплекса»
после
предоставления всех необходимых документов и их проверки в соответствии с
требованиями указанной статьи.
2. Субъект обязан:
 до начала выполнения работ / оказания услуг непосредственно на
информационных ресурсах Заказчика, ознакомить всех специалистов,
принимающих участие в работах / оказании услуг, с требованиями по ИБ,
изложенными в Соглашении, а также иными требованиями ИБ по
указанию Заказчика;
 соблюдать правила режима и внутреннего распорядка на территории
Заказчика, включая правила доступа в серверные помещения;
 использовать только согласованное с Заказчиком программное
обеспечение и технические средства;
 обеспечить проверку съемных машинных носителей на наличие
вредоносного программного обеспечения перед подключением к
информационным ресурсам Заказчика;
 вести журналы действий (логи) при работе с ресурсами Заказчика и
предоставлять их по запросу;
 после завершения работ по требованию Заказчика полностью удалить все
данные, полученные в ходе работ, с устройств Субъекта.
Подписи Сторон:
от Заказчика:
Должность
от Субъекта информационного обмена:
Должность
________________ /_________/
М.П.
________________ /_________/
М.П.
82
5. Требования к Участникам конкурса. Подтверждение соответствия
предъявляемым требованиям
5.1.
Требования к Участникам конкурса
5.1.1. Соответствие Участника конкурса требованиям, устанавливаемым
в соответствии с законодательством Российской Федерации к лицам,
осуществляющим исполнение обязательств, являющихся предметом Договора.
5.1.2. Непроведение ликвидации Участника конкурса – юридического
лица и отсутствие решения арбитражного суда о признании Участника конкурса
– юридического лица, индивидуального предпринимателя банкротом и об
открытии конкурсного производства.
5.1.3. Неприостановление деятельности Участника конкурса в порядке,
предусмотренном Кодексом Российской Федерации об административных
правонарушениях, на день подачи Конкурсной заявки.
5.1.4. В целях обеспечения прозрачности финансово-хозяйственной
деятельности, в том числе исключения случаев конфликта интересов или
злоупотреблений работников Заказчика, связанных с занимаемой должностью,
Участники обязаны представить сведения об участниках, единоличном
исполнительном органе, членах коллегиального исполнительного органа или
иного коллегиального органа управления Участника (совет директоров,
наблюдательный совет), а также владельцах более 5 % (Пяти процентов) акций
Участника, а в случае если функции исполнительного органа переданы
юридическому лицу или юридическое лицо является владельцем доли любого
размера в уставном капитале Участника или владельцем более 5 % (Пяти
процентов) акций Участника, должны быть представлены аналогичные
сведения по указанному юридическому лицу и так далее вплоть до конечного
руководителя, собственника (участника, акционера) или выгодоприобретателя
(бенефициара). Указанные сведения представляются отдельным документом по
форме, размещенной на сайте Организатора в разделе «Закупки / Информация о
заключенных
договорах»
по
адресу
http://www.so-ups.ru/index.php?
id=procurement_conclud (файл «Форма справки.xls.»), с указанием ИНН, ОГРН,
наименования (ФИО), адреса регистрации, серии и номера документа,
удостоверяющего личность, отношения к Участнику, в том числе через иных
лиц, а также наименования и реквизитов документа, подтверждающего такое
отношение. Для нерезидентов указывается аналогичная или сопоставимая
информация. Непредставление Участником указанных сведений является
основанием для отказа в допуске к участию в конкурсе.
5.1.5. Отсутствие у Участника конкурса недоимки по налогам, сборам,
задолженности по иным обязательным платежам в бюджеты бюджетной
системы Российской Федерации (за исключением сумм, на которые
предоставлены отсрочка, рассрочка, инвестиционный налоговый кредит в
соответствии с законодательством Российской Федерации о налогах и сборах,
83
которые реструктурированы в соответствии с законодательством Российской
Федерации, по которым имеется вступившее в законную силу решение суда о
признании обязанности заявителя по уплате этих сумм исполненной или
которые признаны безнадежными к взысканию в соответствии с
законодательством Российской Федерации о налогах и сборах) за прошедший
календарный год, размер которых превышает 25 % (Двадцать пять процентов)
балансовой стоимости активов Участника конкурса, по данным бухгалтерской
отчетности за последний отчетный период. Участник конкурса считается
соответствующим установленному требованию в случае, если им в
установленном порядке подано заявление об обжаловании указанных
недоимки, задолженности и решение по такому заявлению на дату
рассмотрения заявки на участие в определении поставщика (подрядчика,
исполнителя) не принято.
5.1.6. Отсутствие сведений об Участнике конкурса в реестре
недобросовестных поставщиков, предусмотренном статьей 5 Федерального
закона от 18.07.2011 № 223-ФЗ «О закупках товаров, работ, услуг отдельными
видами юридических лиц» и (или) в реестре недобросовестных поставщиков,
предусмотренном Федеральным законом от 05.04.2013 № 44-ФЗ «О
контрактной системе в сфере закупок товаров, работ, услуг для обеспечения
государственных и муниципальных нужд».
5.1.7. Отсутствие у Участника конкурса – физического лица либо у
руководителя, членов коллегиального исполнительного органа или главного
бухгалтера юридического лица – Участника конкурса судимости за
преступления в сфере экономики и (или) преступления, предусмотренные
статьями 289, 290, 291, 291.1 Уголовного кодекса Российской Федерации (за
исключением лиц, у которых такая судимость погашена или снята), а также
неприменение в отношении указанных физических лиц наказания в виде
лишения права занимать определенные должности или заниматься
определенной деятельностью, которые связаны с поставкой товара,
выполнением работы, оказанием услуги, являющихся предметом
осуществляемой закупки, и административного наказания в виде
дисквалификации.
5.1.8. Отсутствие фактов привлечения в течение 2 (Двух) лет до момента
подачи заявки Участника конкурса – юридического лица к административной
ответственности за совершение административного правонарушения,
предусмотренного статьей 19.28 Кодекса Российской Федерации об
административных правонарушениях.
5.1.9. Отсутствие сведений об Участнике конкурса в реестре
иностранных агентов, предусмотренном Федеральным законом от 14.07.2022
№ 255-ФЗ «О контроле за деятельностью лиц, находящихся под иностранным
влиянием».
5.2.
Подтверждение соответствия Участников конкурса
84
установленным требованиям
5%1%.2.1. Участник конкурса представляет в составе Конкурсной заявки
следующие документы для подтверждения его соответствия требованиям,
установленным к Участникам конкурса:
№
Вид документа
Примечания
№
Организационные и правоустанавливающие документы:
1
2
3
4
5
6
Решение
об
юридического лица
учреждении
Устав
(учредительный
товариществ)
Предоставляется копия с оригинала, выданного
договор
для регистрирующим органом, в действующей
редакции либо документ в электронном виде,
подписанный усиленной квалифицированной
подписью налогового органа.
Решение о внесении изменений к Предоставляется копия с оригинала, выданного
Уставу (учредительному договору регистрирующим органом, в действующей
для товариществ), текст изменений редакции, с отметкой регистрирующего органа,
либо
документ
в
электронном
виде,
подписанный усиленной квалифицированной
подписью налогового органа.
Решение о назначении (избрании)
директора (руководителя) – лица,
имеющего право без доверенности
действовать от имени юридического
лица (согласно Выписке из ЕГРЮЛ)
Решение об одобрении совершения Если цена планируемого договора превышает
крупной сделки (протокол общего установленную законом или учредительными
собрания участников или иного документами для данного юридического лица
органа управления, имеющего
право принимать решения о
совершении крупной сделки)
Решение об одобрении совершения Если договор не является сделкой с
сделки с заинтересованностью (если заинтересованностью,
соответствующая
договор,
заключаемый
по оговорка делается в оферте
результатам конкурса, является для
данного Участника сделкой с
заинтересованностью
в
соответствии с законодательством
Российской Федерации)
Другие документы:
7
8
Документ,
подтверждающий Представляется
в
случае
подписания
полномочия лица, подписавшего документов по доверенности
Конкурсную заявку
Сведения,
предусмотренные По форме, размещенной на сайте Организатора
п. 5.1.4. Конкурсной документации в
разделе
«Закупки / Информация
о
85
№
Вид документа
Примечания
№
заключенных
договорах»
по
http://www.so-ups.ru/index.php?
id=procurement_conclud
(файл
справки.xls.»)
9
10
адресу
«Форма
Документы,
подтверждающие В соответствии с перечнем документов,
представленные
сведения, размещенном на сайте Организатора в разделе
предусмотренные
п. 5.1.4. «Закупки / Информация
о
заключенных
Конкурсной документации
договорах» по адресу: http://so-ups.ru/index.php?
id=procurement_conclud
(файл
«Перечень
документов, подтверждающих информацию о
цепочке
собственников
(бенефициаров)
контрагента,
и
предъявляемые
к
ним
требования.pdf»)
Справка ФНС России о состоянии
расчетов по налогам, сборам, пеням,
штрафам, процентам организаций и
индивидуальных
предпринимателей,
выданная
Участнику
Справка
ФНС
России
представляется
Участником только в случае наличия у
Участника задолженности по начисленным
налогам, сборам и иным обязательным платежам
в бюджеты любого уровня (за исключением: а)
сумм задолженности, на которые предоставлены
отсрочка,
рассрочка,
инвестиционный
налоговый
кредит
в
соответствии
с
законодательством Российской Федерации о
налогах и сборах; б) сумм задолженности,
которые реструктурированы в соответствии с
законодательством Российской Федерации; в)
сумм задолженности, по которым имеется
вступившее в законную силу решение суда о
признании обязанности Участника по уплате
этих сумм исполненной или которые признаны
безнадежными к взысканию в соответствии с
законодательством Российской Федерации о
налогах и сборах; г) сумм задолженности,
оспариваемых Участником в судебном порядке,
и по которым на момент проведения конкурса
соответствующее судебное решение не принято)
за прошедший календарный год, размер которой
превышает 25 % балансовой стоимости активов
по данным бухгалтерской отчетности за
последний завершенный отчетный период.
Справка ФНС России о состоянии расчетов по
налогам, сборам, пеням, штрафам, процентам
организаций
и
индивидуальных
предпринимателей, выданная Участнику должна
быть оформлена по правилам, установленным
приказом ФНС России
86
№
Вид документа
Примечания
Платежное поручение с отметкой
банка об оплате обеспечения
Конкурсной заявки (квитанция в
случае наличной формы оплаты,
выписка из банка в случае внесения
соответствующих
денежных
средств при помощи системы
«Банк-Клиент») или независимая
гарантия;
копии доверенностей,
совершенных в письменной форме
на
бумажном
носителе
(в
соответствии с пунктом 7.11
Конкурсной документации) или
машиночитаемые доверенности (в
соответствии с п. 7.12 Конкурсной
документации)
Условия независимой гарантии должны
соответствовать условиям, содержащимся в
форме независимой гарантии, приведенной в
Конкурсной документации (форма № 6).
№
11
В случае выдачи независимой гарантии в
письменной форме на бумажном носителе
оригинал такой гарантии направляется в
отдельном
конверте
с
нарочным
или
посредством
курьерской
доставки
в
Центральную
закупочную
комиссию
АО «СО ЕЭС» по адресу: 119297, г. Москва,
вн.тер.г. муниципальный округ Солнцево,
ул. Петра Непорожнего, д. 7, стр. 1. Конверт
должен быть доставлен не позднее времени
окончания подачи Участниками Конкурсных
заявок.
5.2.2. Участник конкурса представляет в составе Конкурсной заявки
следующие документы, необходимые для сопоставления и оценки Конкурсных
заявок (отсутствие указанных документов не является основанием для
отклонения Конкурсных заявок Участников конкурса):
№
Вид документа
Примечания
№
Финансово-экономические документы:
(на последнюю отчетную дату с отметкой или электронным подтверждением
территориального органа ФНС России)
Бухгалтерский баланс (форма 1)
1
2
Отчет о финансовых результатах
(форма 2)
3
Отчет об
(форма 3)
4
Отчет о движении денежных средств При наличии
(форма 4)
5
Приложения
к
бухгалтерскому При наличии
балансу и пояснительные записки
изменениях
Аудиторское заключение
6
7
капитала При наличии
Только для юридических лиц, подлежащих
обязательному аудиту
При упрощенной системе налогообложения:
87
№
Вид документа
Примечания
№
а)
б)
Упрощенный бухгалтерский баланс
по итогам последнего отчетного
периода, налоговая декларация (для
индивидуального предпринимателя)
Свидетельство (уведомление) о
переводе на упрощенную систему
налогообложения
Другие документы:
Анкета Участника конкурса
По форме 3
8
9
10
Справка о перечне и годовых По форме 4
объемах выполнения аналогичных
договоров (с приложением копий
договоров,
актов
о
приемке
выполненных работ/ актов об
оказании услуг, УПД и иных
документов (отчетов об оказании
услуг, регламентов оказания услуг,
технических
заданий
и
др.),
содержащих описание аналогичных
работ/ услуг, назначение и основные
функции программ для ЭВМ) (при
наличии)
Справка о кадровых ресурсах
По форме 5
В справке следует указать (при
1. Копии документов предоставляются в
наличии)
количество
квалифицированных специалистов, отношении каждого специалиста Участника,
планируемых для привлечения к привлекаемого к выполнению Работ по
выполнению Работ по Договору (не Договору.
менее чем 7 (Семь) специалистов 2.
с К Справке прикладываются копии документов,
высшим образованием в области подтверждающих наличие трудовых и/или
информационных технологий и (или) гражданско-правовых
отношений
между
электроэнергетики
и(или) Участником
и
привлекаемыми
им
к
математики) в том числе не менее 1 выполнению
Работ
по
Договору
(Одного) специалиста, имеющего специалистами: штатного расписания, приказа
документы
о
повышении о назначении на должность и (или) трудовой
квалификации (обучении) в области книжки, и (или) трудового договора
администрирования операционной (допускается предоставление выписок из
системы Astra Linux в соответствии с указанных документов) и/или договоров
требованиями, указанными в пункте гражданско-правового
характера
с
2.3 Приложения № 2 к Техническим привлекаемыми
к
выполнению
Работ
требованиям (Приложение № 1 к специалистами.
Конкурсной
документации)
и
приложить копии документов (при
наличии):

дипломов
о
высшем
88
№
Вид документа
Примечания
№
образовании
в
области
информационных технологий и(или)
электроэнергетики
и(или)
математики (на не менее чем 7 (Семь)
специалистов);

документов о повышении
квалификации (обучении) в области
администрирования операционной
системы Astra Linux (на не менее, чем
1 (Одного) специалиста);

резюме
на
каждого
специалиста с указанием опыта
участия в аналогичных договорах
(проектах).
11
Иные документы, которые, по
мнению Участника, подтверждают
его соответствие установленным
требованиям, с соответствующими
комментариями,
разъясняющими
цель
предоставления
этих
документов
(отзывы,
благодарственные
и
рекомендательные
письма,
сертификаты ИСО и т.д.)
При наличии
5.2.3. Документы, указанные в пунктах 5.2.1,
Участником конкурса к Письму о подаче оферты.
5.2.2.
прилагаются
89
6. Порядок проведения конкурса. Инструкции по подготовке Конкурсных
заявок
6.1.
Общий порядок проведения конкурса
6.1.1. С учетом положений Конкурсной документации конкурс проводится
в следующем порядке и в следующие сроки:
№
п/п
1.
2.
3.
Наименование процедуры
Сроки
Начало
Публикация на Электронной
площадке
Извещения
о
проведении конкурса
Разъяснение
Организатором
положений
Конкурсной
документации по запросам
Участников конкурса
Подготовка
и
подача
Участниками
конкурса
Конкурсных заявок (загрузка
файлов Конкурсной заявки на
Электронную площадку)
Окончание
06.10.2026
06.10.2026
16.10.2026
06.10.2026
22.10.2026
09:00
4.
Рассмотрение
Конкурсных
заявок Участников конкурса
не позднее 28.10.2026
09:00
5.
Подведение итогов конкурса
не позднее 29.10.2026
09:00
6.
Заключение Договора
6.2.
Не ранее чем через
10 (Десять) дней с
даты размещения в
Единой
информационной
системе итогового
протокола,
составленного по
результатам
конкурса
Не позднее чем
через 20 (Двадцать)
дней с даты
размещения в
Единой
информационной
системе итогового
протокола,
составленного по
результатам
конкурса
Порядок подачи Конкурсной заявки
6.2.1. Конкурсные заявки подаются в электронной форме. Для участия в
конкурсе Участник конкурса должен быть аккредитован на Электронной
площадке. Аккредитация осуществляется в соответствии с регламентом
Электронной площадки.
90
6.2.2. Участник конкурса подает Конкурсную заявку на Электронную
площадку через Личный кабинет с использованием реализованных на
Электронной площадке средств защиты информации.
6.2.3. Конкурсная заявка должна быть заверена электронной подписью
уполномоченного представителя Участника конкурса. Включенные в состав
Конкурсной заявки документы, подтверждающие соответствие Участника
установленным Конкурсной документацией требованиям, а также документы,
необходимые для сопоставления и оценки Конкурсных заявок, должны быть
представлены в виде копий с оригиналов. При невозможности прочтения какойлибо части текста документа (под невозможностью прочтения понимается
объективная невозможность открыть документ офисными средствами чтения и
обработки файлов) такой документ считается не поданным в составе Конкурсной
заявки и не принимается к рассмотрению Центральной закупочной комиссией.
Анкета Участника конкурса (по форме 3) предоставляется Участником конкурса
также и в формате Microsoft Excel. Имя файла и (или) его описание на
Электронной площадке должно соответствовать его содержанию.
6.2.4. Конкурсная заявка содержит:
а)
Письмо о подаче оферты (с приложениями) по форме 1;
б)
Документы, подтверждающие соответствие Участника конкурса
требованиям Конкурсной документации (п. 5.2.1);
в)
Документы, подтверждающие соответствие Конкурсной заявки
требованиям, установленным для сопоставления и оценки Конкурсных заявок
(п. 5.2.2);
г)
Ценовое предложение Участника. Подача ценовых предложений
осуществляется
с
использованием
программно-аппаратных
средств
Электронной площадки.
6.2.5. Участник конкурса имеет право подать только 1 (Одну) Конкурсную
заявку. В случае нарушения этого требования Организатор конкурса отказывает
в допуске такому Участнику конкурса к участию в конкурсе.
6.2.6. Письмо о подаче оферты подписывается лицом, имеющим право в
соответствии с законодательством Российской Федерации действовать от лица
Участника конкурса без доверенности, или надлежащим образом
уполномоченным им лицом на основании доверенности (далее —
уполномоченное лицо). Применение факсимильной подписи (факсимиле) не
допускается.
6.2.7. Организатор конкурса вправе запросить у Участника конкурса
предоставление оригиналов или нотариально удостоверенных копий, поданных
в составе Конкурсной заявки копий документов как в ходе проведения
закупочной процедуры, так и после подведения ее итогов до подписания
Договора.
6.2.8. Срок окончания подачи Участниками конкурса Конкурсных заявок
91
установлен п. 6.1.1.
6.2.9. В случае если по окончании срока подачи Конкурсных заявок,
установленного п. 6.1.1, не подано ни одной Конкурсной заявки, Центральная
закупочная комиссия принимает решение о признании конкурса
несостоявшимся.
6.3.
Срок действия Конкурсной заявки
Конкурсная заявка действительна в течение 90 (Девяноста) календарных
дней со дня, следующего за днем окончания подачи Конкурсных заявок (п. 6.1.1).
6.4.
Продление срока окончания подачи Конкурсных заявок
Организатор конкурса вправе продлить срок подачи Конкурсных заявок на
участие в конкурсе в порядке, установленном п. 2.4.1. Конкурсной
документации.
6.5.
Порядок изменения Конкурсных заявок
Участник конкурса вправе с использованием функционала Электронной
площадки изменять или дополнять Конкурсную заявку в любое время вплоть до
наступления срока окончания подачи Конкурсных заявок.
6.6.
Порядок отзыва поданных Конкурсных заявок
6.6.1. Участник конкурса вправе отозвать Конкурсную заявку и
отказаться от участия в конкурсе.
6.6.2. Участник конкурса, отозвавший Конкурсную заявку, вправе подать
новую Конкурсную заявку с использованием функционала Электронной
площадки.
6.7.
Порядок вскрытия Конкурсных заявок
6.7.1. Вскрытие Конкурсных заявок, то есть открытие доступа к
Конкурсным заявкам, на Электронной площадке происходит в указанную дату и
время автоматически с соблюдением конфиденциальности: немедленно после
вскрытия Конкурсных заявок информация о всех поступивших Конкурсных
заявках на данный конкурс становится доступной для уполномоченных
пользователей Личного кабинета Организатора конкурса, а также для
ознакомления другими Участниками конкурса. При этом информация о
Конкурсных заявках недоступна пользователям других участников Электронной
площадки, не являющихся Участниками данного конкурса.
6.7.2. По результатам процедуры вскрытия Конкурсных заявок
Центральная закупочная комиссия составляет протокол открытия доступа к
заявкам, который размещается на Электронной площадке и в Единой
информационной системе.
92
6.8.
Рассмотрение, оценка и сопоставление Конкурсных заявок
6.8.1. Общие положения
6.8.1.1.
Рассмотрение, оценка и сопоставление Конкурсных заявок
осуществляется Центральной закупочной комиссией.
6.8.1.2.
Для подготовки предложений по рассмотрению, оценке и
сопоставлению Конкурсных заявок Центральная закупочная комиссия вправе
привлекать экспертов.
6.8.1.3.
Рассмотрение, оценка и сопоставление Конкурсных заявок
включает отборочную стадию (п. 6.8.2) и оценочную стадию (п. 6.8.3).
6.8.2. Рассмотрение Конкурсных заявок (отборочная стадия)
6.8.2.1.
В рамках отборочной стадии Центральная закупочная
комиссия рассматривает:
а) соответствие Участников
документации (п. 5.1);
конкурса
требованиям
Конкурсной
б) соответствие содержания и формы заявки Участника требованиям
Конкурсной документации.
6.8.2.2. В рамках отборочной стадии Центральная закупочная комиссия
вправе запросить у Участников конкурса разъяснения или дополнения их
Конкурсных заявок, в том числе представление отсутствующих документов. При
этом Центральная закупочная комиссия не вправе запрашивать разъяснения или
требовать документы, меняющие суть Конкурсной заявки.
6.8.2.3. При проверке правильности оформления Конкурсной заявки
Центральная закупочная комиссия вправе не обращать внимания на мелкие
недочеты и погрешности, которые не влияют на существо Конкурсной заявки.
6.8.2.4. При рассмотрении Конкурсной заявки Центральная закупочная
комиссия отказывает в допуске к участию в конкурсе Участникам конкурса в
случае:
93
а) непредставления документов, перечень которых определен пунктом 5.2.1.
Конкурсной документации, либо наличия в документах, предусмотренных
пунктами 5.2.1., 5.2.2. Конкурсной документации, недостоверных
сведений об Участнике конкурса или Работах, либо существенного
нарушения по форме предоставления документов. Выявление
недостоверных сведений и отклонение заявки Участника конкурса по
данному основанию возможно на любом этапе конкурса;
б) несоответствия Участника конкурса требованиям, установленным в
Конкурсной документации;
в) несоответствия
Конкурсной
заявки
требованиям
Конкурсной
документации, в том числе в части предмета конкурса, превышения цены,
указанной в Конкурсной заявке, над начальной (максимальной) ценой,
указанной в Конкурсной документации, ухудшения для Заказчика условий
исполнения Договора по срокам выполнения Работ по Договору, форме,
срокам и порядку оплаты, гарантийному сроку или иным условиям;
г) подачи Участником заявки, которая не может быть признана офертой, так
как содержит недостаточно определенное предложение о заключении
договора (п. 1 ст. 435 ГК РФ) или поступления от одного Участника более
одной заявки в рамках одной закупочной процедуры (одного лота), а равно
подачи Участником конкурса заявки, которая содержит очевидную
ошибку в ценовом предложении, приводящую к невозможности
заключения и исполнения Договора в связи с явным несоответствием
необходимых для исполнения Договора затрат и предложенной
Участником конкурса цены Договора;
д) в связи с возможным наличием конфликта интересов или злоупотреблений
работников руководящего состава Заказчика (Председатель Правления,
Первый
заместитель
Председателя
Правления,
заместитель
Председателя Правления, главный бухгалтер, директор по направлению,
заместитель
директора
по
направлению,
руководитель
самостоятельного структурного подразделения, руководитель филиала,
заместитель руководителя филиала), связанных с занимаемой
должностью и их участием или участием их близких родственников
(супруг, дети, родители, полнородные и неполнородные братья и сестры)
в деятельности Участника в формах, указанных в п. 5.1.4 Конкурсной
документации;
е) в иных случаях, предусмотренных Конкурсной документацией.
6.8.2.5. В исключительных случаях при несущественном отклонении
Конкурсной заявки от требований Конкурсной документации Центральная
закупочная комиссия вправе принять решение о допуске Участника конкурса к
участию в конкурсе, при этом основания для такого решения должны в равной
степени применяться ко всем Участникам этого конкурса.
6.8.2.6. На основании результатов рассмотрения Конкурсных заявок
94
Участников конкурса Центральная закупочная комиссия принимает решение о
допуске Участника конкурса к участию в конкурсе либо об отказе в допуске
Участника конкурса к участию в конкурсе.
6.8.2.7. В случае если на основании результатов рассмотрения Конкурсных
заявок Центральной закупочной комиссией принято решение о допуске к
участию в конкурсе не более одного Участника конкурса, Центральная
закупочная комиссия принимает решение о признании конкурса
несостоявшимся. Договор с единственным Участником конкурса заключается в
порядке, предусмотренном пунктом 6.11 Конкурсной документации, при
отсутствии к тому объективных препятствий (отпадение потребности в товарах,
работах, услугах на условиях, указанных в Конкурсной документации).
6.8.2.8. В случае если на основании результатов рассмотрения Конкурсных
заявок Центральной закупочной комиссией принято решение об отказе в допуске
к участию в конкурсе всех Участников конкурса, Центральная закупочная
комиссия принимает решение о признании конкурса несостоявшимся.
6.8.2.9. По результатам рассмотрения Конкурсных заявок (отборочная
стадия) Центральная закупочная комиссия составляет протокол рассмотрения
заявок, который размещается на Электронной площадке и в Единой
информационной системе.
6.8.3. Оценка и сопоставление Конкурсных заявок (оценочная стадия)
6.8.3.1. Для определения лучших условий исполнения Договора
Центральная закупочная комиссия оценивает и сопоставляет Конкурсные заявки
по степени выгодности для Заказчика, исходя из следующих критериев:
№
п/п
Наименование критерия
Обозначение
выставленного по
критерию
балла
/суммы
баллов
Значимость
критерия
Обозначение
значимости
критерия
1.
Цена Договора
КЦi
30%
ВЦi
2.
Качество Работ и квалификация ККРi
Участника конкурса, в том числе:
35%
ВКРi
2.1.
Опыт
выполнения
договоров
аналогичных K2.1
44%
P2.1
Количество
квалифицированных
специалистов Участника конкурса,
К2.2
привлекаемых для выполнения Работ
по Договору
30%
Р2.2
2.2.
95
2.3.
Деловая репутация
К2.3
26%
Р2.3
10%
Всгi
3.
Срок предоставления гарантии Ксгi
качества на результат выполненных
Работ по второй и последующим
утвержденным Заявкам, включая
разработанную
и
актуализированную документацию
25%
Вфхi
4.
Функциональные характеристики Кфхi
(описание вариантов математической и
графической реализации типовых
блоков
фиксации
отключения
оборудования
и
контроля
предшествующего режима, включая
логику работы указанных типовых
блоков, их возможные параметры и
передвижение на схеме в соответствии
с буллитом 3 пункта 4.2.1 Технических
требований (Приложение № 1 к
Конкурсной документации) и пунктом
9.1 Эскизного проекта (Приложение
№ 1 к Техническим требованиям
(Приложение № 1 к Конкурсной
документации))
6.8.3.2.
Центральная закупочная комиссия оценивает и сопоставляет
Конкурсные заявки в соответствии с критериями, указанными в пп. 6.8.3.1, в
следующем порядке:
6.8.3.2.1. Оценка по критерию 1 «Цена Договора» осуществляется по
формуле:
КЦi
где:
КЦi – балльная оценка ценового предложения для i-го Участника;
Ni – цена предложения i-го Участника;
Nmin– лучшая (минимальная) цена среди всех предложений;
Бmax– максимальный балл (равен 5).
6.8.3.2.2. Присвоение баллов Конкурсным заявкам по критерию 2
«Качество Работ и квалификация Участника конкурса» осуществляется на
основании суммы баллов по подкритериям с учетом их значимости,
определяемой по формуле:
К
где:
КРi
= К2.1 х Р2.1 + К2.2 х Р2.2 + К2.3 х Р2.3
96
ККРi – сумма баллов (с учетом значимости) по подкритериям критерия 2
«Качество Работ и квалификация Участника конкурса»;
K2.1 – K2.3 – балл (сумма баллов) по соответствующим подкритериям
критерия 2 «Качество Работ и квалификация Участника
конкурса»;
P2.1 – P2.3 − значимость каждого подкритерия критерия 2 «Качество Работ
и квалификация Участника конкурса».
6.8.3.2.2.1. Присвоение баллов Конкурсным заявкам по подкритерию
2.1 «Опыт выполнения аналогичных договоров» осуществляется на основании
документов, предоставленных Участниками конкурса о выполнении
аналогичных договоров за последние 3 (Три) года до срока окончания подачи
Участниками Конкурсных заявок в зависимости от интервала отклонения от
начальной (максимальной) цены Договора, установленной в п. 2.2.1 Конкурсной
документации:

«5» баллов присваивается Участнику конкурса, у которого
суммарная стоимость выполнения аналогичных договоров больше или равна
100 % от начальной (максимальной) цены Договора, указанной в п. 2.2.1
Конкурсной документации;

«4» балла присваивается Участнику конкурса, у которого суммарная
стоимость выполнения аналогичных договоров больше или равна 75%, но
меньше 100 % от начальной (максимальной) цены Договора, указанной в п. 2.2.1
Конкурсной документации;

«3» балла присваивается Участнику конкурса, у которого суммарная
стоимость выполнения аналогичных договоров больше или равна 50%, но
меньше 75 % от начальной (максимальной) цены Договора, указанной в п. 2.2.1
Конкурсной документации;

«2» балла присваивается Участнику конкурса, у которого суммарная
стоимость выполнения аналогичных договоров больше или равна 25%, но
меньше 50 % от начальной (максимальной) цены Договора, указанной в п. 2.2.1
Конкурсной документации;

«1» балл присваивается Участнику конкурса, у которого суммарная
стоимость выполнения аналогичных договоров меньше 25 % от начальной
(максимальной) цены Договора, указанной в п. 2.2.1 Конкурсной документации;

«0» баллов присваивается Участнику конкурса, не предоставившему
документы, подтверждающие опыт выполнения аналогичных договоров.
При расчете оценки по подкритерию 2.1. «Опыт выполнения
аналогичных договоров» учитывается только подтвержденный опыт
выполнения аналогичных договоров копиями документов, указанных в
подпункте 9 таблицы пункта 5.2.2 Конкурсной документации.
6.8.3.2.2.2.При
оценке
по
подкритерию 2.2
«Количество
квалифицированных специалистов Участника конкурса, привлекаемых для
выполнения Работ по Договору» учитывается количество специалистов в штате
Участника конкурса и/или находящихся с ним в гражданско-правовых
97
отношениях, привлекаемых для выполнения Работ по Договору, квалификация
которых подтверждена копиями дипломов о высшем образовании в области
информационных технологий и(или) электроэнергетики и(или) математики,
копиями документов о повышении квалификации (обучении) в области
администрирования операционной системы Astra Linux, резюме с указанием
опыта участия в аналогичных договорах (проектах):
– «5» баллов присваивается Участнику конкурса, который подтвердил
наличие 7 (Семи) и более специалистов, имеющих дипломы о высшем
образовании в области информационных технологий и (или) информационной
безопасности и (или) электроэнергетики и(или) математики, в том числе не менее
1 (Одного) специалиста, имеющего документы о повышении квалификации
(обучении) в области администрирования операционной системы Astra Linux, и
предоставил резюме на всех данных 7 (Семь) и более специалистов с указанием
опыта участия в аналогичных договорах (проектах);
–
«3» балла присваивается Участнику конкурса, который подтвердил
наличие 7 (Семи) и более специалистов, имеющих дипломы о высшем
образовании в области информационных технологий и (или) электроэнергетики
и(или) математики, в том числе подтвердил наличие не менее 1 (Одного)
специалиста, имеющего документы о повышении квалификации (обучении) в
области администрирования операционной системы Astra Linux, и предоставил
резюме на данных специалистов в количестве не менее 4 (Четырех), но не более 6
(Шести) резюме с указанием опыта участия в аналогичных договорах (проектах);

«1» балл присваивается Участнику конкурса, который подтвердил
наличие 7 (Семи) и более специалистов, имеющих дипломы о высшем
образовании в области информационных технологий и (или) электроэнергетики
и(или) математики, в том числе подтвердил наличие не менее 1 (Одного)
специалиста, имеющего документы о повышении квалификации (обучении) в
области администрирования операционной системы Astra Linux, и предоставил
резюме на данных специалистов в количестве менее 4 (Четырех) специалистов с
указанием опыта участия в аналогичных договорах (проектах) либо не
предоставил ни одного резюме на специалистов с указанием опыта участия в
аналогичных договорах (проектах);

«0» баллов присваивается Участнику конкурса, который подтвердил
наличие 7 (Семи) и более специалистов, имеющих дипломы о высшем
образовании в области информационных технологий и (или) электроэнергетики
и(или) математики, при этом не подтвердил наличие не менее 1 (Одного)
специалиста, имеющего документы о повышении квалификации (обучении) в
области администрирования операционной системы Astra Linux, предоставил на
данных специалистов, либо не предоставил резюме на специалистов с указанием
опыта участия в аналогичных договорах (проектах);
либо

«0» баллов присваивается Участнику конкурса, который не
подтвердил наличие 7 (Семи) специалистов, имеющих дипломы о высшем
образовании в области информационных технологий и (или) электроэнергетики
98
и(или) математики, подтвердил или не подтвердил наличие не менее 1 (Одного)
специалиста, имеющего документы о повышении квалификации (обучении) в
области администрирования операционной системы Astra Linux, предоставил на
данных специалистов (часть специалистов), либо не предоставил ни одного
резюме на специалистов с указанием опыта участия в аналогичных договорах
(проектах);
или в иных случаях, не подпадающих под критерии оценки на «5»
баллов, «3» балла, «1» балл.
6.8.3.2.2.3. Оценка по подкритерию 2.3 «Деловая репутация»
проводится в соответствии с утвержденным в АО «СО ЕЭС» Алгоритмом
(размещен на интернет-сайте АО «СО ЕЭС», ссылка на место размещения:
https://www.so-ups.ru/fileadmin/files/company/tenders/tenders_low/
assessment_business_reputation_2022.pdf).
6.8.3.2.3. Присвоение баллов Конкурсным заявкам по критерию 3 «Срок
предоставления гарантии качества на результат выполненных Работ по второй и
последующим
утвержденным
Заявкам,
включая
разработанную
и
актуализированную документацию» осуществляется по следующей формуле:
Ксгi
где:
Ксгi – балльная оценка по критерию для i-го Участника.
W – минимальный срок предоставления гарантии качества на результат
выполненных Работ по второй и последующим утвержденным Заявкам,
включая
разработанную
и
актуализированную
документацию,
установленный Конкурсной документацией.
Wi – срок предоставления гарантии качества на результат выполненных
Работ по второй и последующим утвержденным Заявкам, включая
разработанную и актуализированную документацию, предлагаемый
Участником в Конкурсной заявке. Если такой срок превышает
установленный в Конкурсной документации более чем на 50% (Wi >1.5W),
для расчета оценки по настоящему критерию принимается Wi =1.5W, а
Договор заключается на предложенных условиях.
Бmax – максимальный балл (равен 5).
6.8.3.2.4. Оценка по критерию 4 «Функциональные характеристики
(описание вариантов математической и графической реализации типовых блоков
фиксации отключения оборудования и контроля предшествующего режима,
включая логику работы указанных типовых блоков, их возможные параметры и
передвижение на схеме в соответствии с буллитом 3 пункта 4.2.1 Технических
требований (Приложение № 1 к Конкурсной документации) и пунктом 9.1
99
Эскизного проекта (Приложение № 1 к Техническим требованиям (Приложение
№ 1 к Конкурсной документации))» осуществляется следующим путем:
– «5» баллов присваивается Участнику конкурса, который предоставил
подробное (полное) описание вариантов математической и графической
реализации типовых блоков фиксации отключения оборудования и контроля
предшествующего режима, включая логику работы указанных типовых блоков,
их возможные параметры и передвижение на схеме в соответствии с буллитом 3
пункта 4.2.1 Технических требований (Приложение № 1 к Конкурсной
документации) и пунктом 9.1 Эскизного проекта (№ 1 к Техническим
требованиям (Приложение № 1 к Конкурсной документации));
– «3» балла присваивается Участнику конкурса, который предоставил
частичное (неполное) описание вариантов математической и графической
реализации типовых блоков фиксации отключения оборудования и контроля
предшествующего режима, включая логику работы указанных типовых блоков,
их возможные параметры и передвижение на схеме в соответствии с буллитом 3
пункта 4.2.1 Технических требований (Приложение № 1 к Конкурсной
документации) и пунктом 9.1 Эскизного проекта (Приложение № 1 к
Техническим требованиям (Приложение № 1 к Конкурсной документации));
– «0» баллов присваивается Участнику конкурса, который не предоставил
описание вариантов математической и графической реализации типовых блоков
фиксации отключения оборудования и контроля предшествующего режима,
включая логику работы указанных типовых блоков, их возможные параметры и
передвижение на схеме в соответствии с буллитом 3 пункта 4.2.1 Технических
требований (Приложение № 1 к Конкурсной документации) и пунктом 9.1
Эскизного проекта (Приложение № 1 к Техническим требованиям (Приложение
№ 1 к Конкурсной документации)).
6.8.3.2.5. Итоговое значение Конкурсных заявок (сумма баллов)
рассчитывается после суммирования баллов, набранных Конкурсными заявками
по каждому из критериев с учетом их значимости, по следующей формуле:
ИСБ= КЦi·ВЦi + ККРi·ВКРi + КСГi·ВСГi + КФХi·ВФХi
где:
– итоговая сумма баллов Конкурсной заявки;
КЦi – набранный Конкурсной заявкой балл по критерию «Цена Договора»;
ВЦi – значимость критерия «Цена Договора»;
ККРi – набранный Конкурсной заявкой балл по критерию «Качество Работ и
квалификация Участника конкурса»;
ВКРi – значимость критерия «Качество Работ и квалификация Участника
конкурса»;
КСГi – набранный Конкурсной заявкой балл по критерию «Срок
предоставления гарантии качества на результат выполненных Работ
100
по второй и последующим утвержденным Заявкам, включая
разработанную и актуализированную документацию»;
ВСГi – значимость критерия «Срок предоставления гарантии качества на
результат выполненных Работ по второй и последующим
утвержденным
Заявкам,
включая
разработанную
и
актуализированную документацию»;
ФХi
К
– набранный Конкурсной заявкой балл по критерию «Функциональные
характеристики
(описание
вариантов
математической
и
графической реализации типовых блоков фиксации отключения
оборудования и контроля предшествующего режима, включая
логику работы указанных типовых блоков, их возможные
параметры и передвижение на схеме в соответствии с буллитом 3
пункта 4.2.1 Технических требований (Приложение № 1 к
Конкурсной документации) и пунктом 9.1 Эскизного проекта
(Приложение № 1 к Техническим требованиям (Приложение № 1 к
Конкурсной документации))»;
ВФХi – значимость критерия «Функциональные характеристики (описание
вариантов математической и графической реализации типовых
блоков фиксации отключения оборудования и контроля
предшествующего режима, включая логику работы указанных
типовых блоков, их возможные параметры и передвижение на
схеме в соответствии с буллитом 3 пункта 4.2.1 Технических
требований (Приложение № 1 к Конкурсной документации) и
пунктом 9.1 Эскизного проекта (Приложение № 1 к Техническим
требованиям (Приложение № 1 к Конкурсной документации))».
6.8.3.3.
На основании результатов оценки Конкурсных заявок
Центральной закупочной комиссией каждой Конкурсной заявке относительно
других по мере уменьшения итогового значения присваивается порядковый
номер. Первый номер присваивается Конкурсной заявке, набравшей по
результатам оценки максимальное количество баллов. Такая Конкурсная заявка
считается содержащей лучшие условия исполнения Договора. В случае если в
нескольких Конкурсных заявках содержатся одинаковые условия исполнения
Договора и такие Конкурсные заявки получили одинаковые итоговые значения,
меньший порядковый номер присваивается Конкурсной заявке, которая
поступила ранее других Конкурсных заявок, содержащих такие условия.
6.8.3.4.
Результаты оценки и сопоставления Конкурсных заявок
(оценочная стадия) указываются Центральной закупочной комиссией в итоговом
протоколе.
6.8.3.5.
В случае проведения переторжки (подраздел 6.8.4) оценка и
сопоставление Конкурсных заявок Участников конкурса являются
предварительными. По окончании переторжки Центральная закупочная
комиссия производит окончательную оценку и сопоставление Конкурсных
заявок в соответствии с ранее объявленными критериями и учетом цен,
101
полученных в ходе переторжки. Конкурсные заявки Участников конкурса,
приглашенных на переторжку, но в ней не участвовавших, учитываются при
окончательной оценке и сопоставлении Конкурсных заявок.
6.8.4. Переторжка (окончательные предложения)
6.8.4.1. Организатор конкурса объявляет о том, что он может
предоставить Участникам конкурса, допущенным к оценочной стадии,
возможность добровольно повысить предпочтительность их Конкурсных заявок
путем снижения первоначальной цены (далее – переторжка), при условии
сохранения остальных положений Конкурсной заявки без изменений. Решение о
проведении переторжки принимает Центральная закупочная комиссия.
Переторжка проводится только по одному параметру – по цене.
6.8.4.2.
в конкурсе.
Организатор конкурса обладает правом проведения переторжки
6.8.4.3.
Проведение переторжки осуществляется по правилам и с
использованием программно-аппаратных средств Электронной площадки.
6.9.
Порядок подведения итогов конкурса
6.9.1. Победителем конкурса признается Участник конкурса, Конкурсная
заявка (окончательное предложение) которого соответствует требованиям,
установленным настоящей Конкурсной документацией, и Конкурсная заявка
(окончательное предложение) которого по результатам сопоставления
Конкурсных заявок (окончательных предложений) на основании указанных в
Конкурсной документации критериев оценки содержит лучшие условия
исполнения Договора.
6.9.2. По результатам конкурса Центральной закупочной комиссией
составляется итоговый протокол, который размещается на Электронной
площадке и в Единой информационной системе.
6.9.3. Организатор конкурса направляет Победителю конкурса на
подписание Протокол о результатах конкурса в соответствии с требованиями
статьи 448 Гражданского кодекса Российской Федерации.
6.10. Подписание Протокола о результатах конкурса
В Протоколе о результатах конкурса должны быть указаны существенные
условия Договора, его стороны, срок, в течение которого такой Договор должен
быть заключен. Протокол о результатах конкурса подписывается
уполномоченными лицами и скрепляется печатями Организатора конкурса и
Победителя конкурса (при наличии у Победителя конкурса печати). Протокол о
результатах конкурса составляется в 2 (Двух) экземплярах, по одному
экземпляру для каждой из сторон.
6.11. Заключение Договора
102
6.11.1.
Договор по результатам конкурса между Заказчиком и
Победителем конкурса заключается не ранее чем через 10 (Десять) дней и не
позднее чем через 20 (Двадцать) дней с даты размещения в Единой
информационной системе итогового протокола, составленного по результатам
конкурса.
В случае обжалования в антимонопольном органе действий (бездействия)
Заказчика, Центральной закупочной комиссии, Электронной площадки договор
с Победителем конкурса должен быть заключен не позднее чем через 5 (Пять)
дней с даты вынесения решения антимонопольного органа по результатам
рассмотрения жалобы.
6.11.2. Договор заключается в письменной форме путем составления
одного документа, подписанного Сторонами.
6.11.3.
Условия Договора определяются
требованиями Организатора конкурса и п. 2.5.4.
в
соответствии
с
6.11.4. Обеспечение обязательств, связанных с исполнением Договора
(размер, порядок, срок предоставления обязательства исполнения Договора,
основное обязательство, исполнение которого обеспечивается и срок его
исполнения): не требуется.
6.11.5.
В случае если Победитель конкурса в срок, предусмотренный
п. 6.11.1, не заключит Договор на условиях, определенных Конкурсной
документацией, Центральная закупочная комиссия признает Победителя
конкурса уклонившимся от заключения Договора.
6.11.6.
В случае признания Победителя конкурса уклонившимся или
отказавшимся от заключения Договора (п. 6.11.5), Заказчик вправе заключить
Договор с Участником конкурса, Конкурсной заявке которого присвоен второй
номер, если срок действия Конкурсной заявки такого Участника конкурса не
истек, либо объявить о проведении повторного конкурса. При этом Организатор
конкурса вправе изменить условия конкурса.
6.12. Антидемпинговые меры
6.12.1. При предложении Участником конкурса цены Договора, которая
на 25 % (Двадцать пять процентов) и более ниже начальной (максимальной)
цены Договора, указанной в п. 2.2.1. Конкурсной документации (далее –
демпинговая цена Договора), Договор с Участником конкурса, предложившим
демпинговую цену Договора, заключается только после предоставления таким
Участником информации, подтверждающей его добросовестность в
соответствии с пунктом 6.12.2. Конкурсной документации. Демпинговой ценой
будет считаться ценовое предложение Участника в размере 14 898 412
(Четырнадцать миллионов восемьсот девяносто восемь тысяч четыреста
двенадцать) рублей 50 копеек без учета НДС (включительно) и менее.
6.12.2. К информации, подтверждающей добросовестность Участника
конкурса, относится информация, содержащаяся в реестре договоров,
103
заключенных заказчиками по результатам закупки, и (или) в реестре контрактов,
заключенных заказчиками, размещенных в Единой информационной системе, и
подтверждающая исполнение таким Участником конкурса в течение 3 (Трех) лет
до даты подачи Конкурсной заявки на участие в конкурсе 3 (Трех) договоров и
(или) контрактов (с учетом правопреемства), исполненных без применения к
такому Участнику конкурса неустоек (штрафов, пеней). При этом цена одного из
таких договоров и (или) контрактов должна составлять не менее чем 20 %
(Двадцать процентов) начальной (максимальной) цены Договора (контракта),
указанной в Извещении о проведении конкурса и Конкурсной документации.
6.12.3. Информация, предусмотренная пунктом 6.12.2 Конкурсной
документации, предоставляется Участником конкурса при направлении
Заказчику подписанного проекта Договора. При невыполнении таким
Участником конкурса, признанным Победителем конкурса данного требования
или
признании
Центральной
закупочной
комиссией
информации,
предусмотренной пунктом 6.12.2. Конкурсной документации, недостоверной
Договор с таким Участником конкурса не заключается, и он признается
уклонившимся от заключения Договора. В этом случае решение Центральной
закупочной комиссии оформляется протоколом, который размещается
Заказчиком в Единой информационной системе не позднее рабочего дня,
следующего за днем подписания указанного протокола.
6.13. Уведомление Участников конкурса о результатах конкурса
6.13.1. Информация о результатах проведенного конкурса автоматически
публикуется на Электронной площадке непосредственно в момент рассылки
уведомлений об определении Победителя конкурса.
6.13.2. На основании письменного запроса Участника конкурса, Конкурсная
заявка которого отклонена или не заняла первое место, Организатор конкурса
направляет Участнику конкурса краткие разъяснения соответствующего
решения Центральной закупочной комиссии.
7.
104
7. Обеспечение исполнения обязательств Участника конкурса
7.1. Участники, подающие Конкурсные заявки (в том числе участники,
на стороне которых выступают несколько юридических или физических лиц),
вносят денежные средства в размере 3 % (Трех процентов) от начальной
(максимальной) цены Договора, что составляет 595 936 (Пятьсот девяносто пять
тысяч девятьсот тридцать шесть) рублей 50 копеек, в качестве обеспечения
Конкурсных заявок на расчетный счет Организатора конкурса по следующим
реквизитам:
Получатель
Банк получателя
Назначение платежа
АО «СО ЕЭС»
ИНН 7705454461 КПП 770501001
Филиал «Центральный» Банка ВТБ (ПАО)
г. Москва
Р/с № 40702810515000004034
БИК 044525411
К/с № 30101810145250000411
«Обеспечение Конкурсной заявки на участие
в конкурсе №______ (НДС не облагается)»
Участник конкурса, являющийся субъектом малого и среднего
предпринимательства и подающий Конкурсную заявку, вносит денежные
средства на расчетный счет Организатора конкурса по указанным в настоящем
пункте Конкурсной документации реквизитам в размере 2 % (Два процента) от
начальной (максимальной) цены Договора, что составляет 397 291 (Триста
девяносто семь тысяч двести девяносто один) рубль 00 копеек.
7.2.
Денежные средства, внесенные Участником конкурса в
соответствии с п. 7.1, обеспечивают исполнение обязательства Участника
конкурса заключить Договор в установленном Конкурсной документацией
порядке в случае признания Участника конкурса Победителем конкурса.
7.3. Факт внесения Участником конкурса денежных средств в качестве
обеспечения Конкурсной заявки подтверждается платежным поручением
(квитанцией в случае наличной оплаты) с отметкой банка об оплате.
7.4. В том случае, если перевод денежных средств в качестве
обеспечения Конкурсной заявки осуществляется Участником при помощи
системы «Банк-Клиент», факт внесения денежных средств в обеспечение
Конкурсной заявки подтверждается выпиской из банка, подтверждающей
перевод денежных средств.
7.5.
Соответствующее платежное поручение с отметкой банка об оплате
(квитанция в случае наличной формы оплаты, выписка из банка в случае
внесения соответствующих денежных средств при помощи системы «БанкКлиент») должно быть представлено Участником конкурса в составе
документов, входящих в Конкурсную заявку на участие в конкурсе.
7.6. Обеспечение Конкурсной заявки должно быть зачислено в сумме и
по реквизитам Организатора конкурса, указанным в п. 7.1, до срока окончания
105
подачи Конкурсных заявок. В противном случае обеспечение Конкурсной заявки
считается невнесенным, и Центральная закупочная комиссия отказывает в
допуске к участию в конкурсе такому Участнику.
7.7. Организатор конкурса возвращает Участникам конкурса денежные
средства, внесенные в качестве обеспечения Конкурсной заявки путем
перечисления денежных средств на счет, реквизиты которого указаны в
Конкурсной заявке, поданной соответствующим Участником конкурса в
следующих случаях и в следующие сроки:
7.7.1. В течение 7 (Семи) рабочих дней со дня принятия Организатором
конкурса решения об отказе от проведения конкурса;
7.7.2. В течение 7 (Семи) рабочих дней со дня поступления Организатору
конкурса уведомления об отзыве Участником конкурса Конкурсной заявки –
Участнику конкурса, подавшему Организатору конкурса уведомление об отзыве
Конкурсной заявки по внутрисистемной почте;
7.7.3. В течение 7 (Семи) рабочих дней со дня вскрытия конвертов с
Конкурсными заявками – Участникам конкурса, обеспечение Конкурсных
заявок которых поступило в адрес Организатора конкурса, а доступ к
размещению Конкурсных заявок Организатора конкурса был прекращен
Электронной площадкой в связи с истечением времени подачи Конкурсных
заявок;
7.7.4. В течение 7 (Семи) рабочих дней с момента принятия решения об
отказе в допуске – Участникам конкурса, которым отказано в допуске к участию
в конкурсе;
7.7.5. В течение 7 (Семи) рабочих дней с момента определения Победителя
конкурса – Участникам конкурса, которые участвовали в конкурсе, но не стали
Победителями конкурса, за исключением Участника конкурса, Конкурсной
заявке которого присвоен второй номер;
7.7.6. Участнику конкурса, Конкурсной заявке которого присвоен
второй номер – в течение 7 (Семи) рабочих дней со дня заключения Договора с
Победителем конкурса или с таким Участником конкурса;
7.7.7. Победителю или единственному Участнику конкурса в течение 7
(Семи) рабочих дней со дня заключения с ним Договора;
7.7.8. В течение 7 (Семи) рабочих дней со дня признания конкурса
несостоявшимся, за исключением единственного Участника конкурса в случае
заключения с ним Договора.
7.8.
Организатор вправе не возвращать Победителю денежные средства,
внесенные в качестве обеспечения Конкурсной заявки (или предъявить в размере
обеспечения заявки требование об уплате денежной суммы по независимой
гарантии) в случае уклонения или отказа Победителя конкурса или Участника
конкурса, Конкурсной заявке которого присвоен второй номер, от заключения
Договора.
7.9.
Участник вправе предоставить независимую гарантию вместо
денежного обеспечения, указанного в п. 7.1, в соответствии со следующими
требованиями:
106
7.9.1. обязательства Участников, связанные с подачей Конкурсных заявок,
обеспечиваются независимой гарантией в размере 3 % (Трех процентов) от
начальной (максимальной) цены Договора, что составляет 595 936 (Пятьсот
девяносто пять тысяч девятьсот тридцать шесть) рублей 50 копеек;
если Участник конкурса является субъектом малого и среднего
предпринимательства, то обязательства, связанные с подачей Конкурсной
заявки, обеспечиваются независимой гарантией в размере 2 % (Два процента) от
начальной (максимальной) цены Договора, что составляет 397 291 (Триста
девяносто семь тысяч двести девяносто один) рубль 00 копеек;
7.9.2. гарант должен соответствовать требованиям, указанным в
постановлении Правительства Российской Федерации от 20.12.2021 № 2369 «О
требованиях к банкам и фондам содействия кредитованию (гарантийным
фондам, фондам поручительств) для целей осуществления закупок товаров
(работ, услуг) для обеспечения государственных и муниципальных нужд, об
изменении и признании утратившими силу некоторых актов и отдельных
положений некоторых актов Правительства Российской Федерации»;
7.9.3. независимой гарантией обеспечивается обязательство Участника
конкурса заключить Договор в установленном Конкурсной документацией
порядке в случае признания его Победителем конкурса (требование по
независимой гарантии предъявляется в случае уклонения или отказа Победителя
конкурса от заключения Договора с Заказчиком по результатам проведения
конкурса);
7.9.4. независимая гарантия должна быть выдана в письменной форме на
бумажном носителе или в форме электронного документа, подписанного
усиленной квалифицированной электронной подписью лица, имеющего право
действовать от имени гаранта (далее – УКЭП). Независимая гарантия не должна
быть оформлена в виде электронного образа документа (электронная копия
независимой гарантии, изготовленной на бумажном носителе, заверенная
УКЭП);
7.9.5. условия независимой гарантии должны соответствовать условиям,
содержащимся в форме, приведенной в Конкурсной документации (форма № 6);
7.9.6. валюта гарантии должна совпадать с валютой Договора;
7.9.7. срок действия гарантии должен быть равен или превышать срок
действия Конкурсной заявки;
7.9.8. независимая гарантия не должна содержать условия или требования,
противоречащие условиям формы независимой гарантии, приведенной в
Конкурсной документации (форма № 6), или делающих их неисполнимыми.
7.10. В случае неисполнения Участником конкурса обязательства,
исполнение которого обеспечено независимой гарантией, Организатор конкурса
вправе выставить гаранту требование об уплате денежной суммы,
предусмотренной независимой гарантией, по указанным в этом требовании
реквизитам.
7.11. В случае выдачи гарантом независимой гарантии в письменной форме
на бумажном носителе Участник конкурса обязан представить Заказчику
107
оригинал независимой гарантии, выданной гарантом в письменной форме на
бумажном носителе. Гарантия должна быть подписана лицом, имеющим право
действовать от имени гаранта.
Оригинал независимой гарантии направляется в отдельном конверте с
нарочным или посредством курьерской доставки в Центральную закупочную
комиссию АО «СО ЕЭС» по адресу: 119297, г. Москва, вн.тер.г. муниципальный
округ Солнцево, ул. Петра Непорожнего, д. 7, стр. 1. Конверт должен быть
доставлен не позднее времени окончания подачи Участниками конкурса
Конкурсных заявок.
В случае если независимая гарантия, выданная в письменной форме на
бумажном носителе, от имени гаранта подписана представителем, действующим
на основании доверенности, одновременно с независимой гарантией, Участник
конкурса обязан представить удостоверенную гарантом в установленном
порядке копию доверенности, совершенную в письменной форме на бумажном
носителе,
уполномочивающую
представителя
гаранта
подписывать
соответствующие гарантии. В случае, если доверенность в письменной форме на
бумажном
носителе
представителя
гаранта
выдана
в
порядке
передоверия/последующего передоверия, Участник конкурса обязан также
одновременно с гарантией представить удостоверенные гарантом в
установленном порядке копии доверенностей, выданных в письменной форме на
бумажном носителе, в отношении всех лиц, участвовавших в передаче в порядке
передоверия/последующего передоверия полномочий, представителю гаранта,
подписавшему независимую гарантию.
7.12. При выдаче гарантом независимой гарантии в форме электронного
документа Участник конкурса представляет в составе конкурсной заявки
независимую гарантию в форме электронного документа, подписанную УКЭП.
В случае если независимая гарантия в форме электронного документа от
имени гаранта подписана УКЭП представителя гаранта, действующим на
основании доверенности, Участник конкурса одновременно с такой независимой
гарантией представляет в составе конкурсной заявки доверенность, выданную
представителю гаранта в электронной форме в машиночитаемом виде (далее –
машиночитаемая доверенность), уполномочивающую представителя гаранта
подписывать соответствующие гарантии. В случае, если машиночитаемая
доверенность
представителя
гаранта
выдана
в
порядке
передоверия/последующего передоверия, Участник конкурса обязан также
одновременно с независимой гарантией в форме электронного документа
представить машиночитаемые доверенности всех лиц, участвовавших в передаче
в порядке передоверия/последующего передоверия полномочий, представителю
гаранта, подписавшему независимую гарантию.
Машиночитаемые доверенности представляются Участником конкурса в
составе конкурсной заявки в формате XML, подписанные усиленными
квалифицированными
электронными
подписями
лиц,
выдавших
машиночитаемые доверенности, или нотариусов в соответствии с
108
п.п. 1, 2 ч. 2 ст. 17.2 Федерального закона от 06.04.2011 № 63-ФЗ
«Об электронной подписи».
7.13. В случае выбора Участником конкурса способа обеспечения
исполнения обязательства, связанного с подачей Конкурсной заявки, в форме
независимой гарантии, Центральная закупочная комиссия отказывает такому
Участнику конкурса в допуске к участию в конкурсе если:
а) Участник конкурса не представил: независимую гарантию в соответствии
с п.п. 7.11, 7.12 Конкурсной документации; копии доверенностей в письменной
форме на бумажном носителе, в случае оформления независимой гарантии в
письменной форме на бумажном носителе в соответствии с п. 7.11 Конкурсной
документации; машиночитаемые доверенности в соответствии с п. 7.12
Конкурсной документации, в случае оформления независимой гарантии в форме
электронного документа;
б) независимая гарантия не соответствует требованиям п. 7.9 Конкурсной
документации;
в) независимая гарантия подписана неуполномоченным лицом;
г) усиленная квалифицированная электронная подпись, которой подписана
независимая гарантия, по результатам ее проверки в государственной
информационной системе уполномоченного федерального органа в сфере
использования электронной подписи, является недействительной;
д) машиночитаемая доверенность не размещена в одной из
информационных систем, предусмотренной Организационно-техническими
требованиями к порядку хранения, использования и отмены указанных в статьях
17.2 и 17.3 Федерального закона «Об электронной подписи» доверенностей,
утвержденными постановлением Правительства РФ от 21.02.2022 № 223 и/или в
машиночитаемой доверенности отсутствуют идентифицирующие сведения об
информационной системе, которая предоставляет техническую возможность
получения информации о досрочном прекращении действия машиночитаемой
доверенности.
109
8.
Образцы форм документов, включаемых в Конкурсную заявку
8.1.
Письмо о подаче оферты (форма 1)
8.1.1. Форма Письма о подаче оферты
начало формы
«_____»_______________ года
№______________________
Уважаемые господа!
Изучив Извещение о проведении конкурса, размещенное на Электронной
площадке B2B-Center, и Конкурсную документацию на право заключения
договора на выполнение работ по модификации программы для ЭВМ
«Конструктор логических моделей/схем противоаварийной автоматики»,
включая установленный претензионный порядок обжалования,
_____________________________________________________________,
(полное наименование Участника конкурса с указанием организационно-правовой формы)
зарегистрированное по адресу:
_____________________________________________________________,
(место нахождения и адрес Участника конкурса)
предлагает заключить договор на выполнение работ по модификации
программы для ЭВМ «Конструктор логических моделей/схем противоаварийной
автоматики» на условиях Проекта Договора (раздел 4 Конкурсной
документации) и в соответствии с Техническим предложением, являющимся
неотъемлемым приложением к настоящему письму и составляющим вместе с
настоящим письмом Конкурсную заявку.
Форма, сроки и порядок оплаты: в соответствии с условиями проекта
Договора (раздел 4 Конкурсной документации).
Сроки выполнения Работ по Договору:
– дата начала выполнения Работ: дата заключения Сторонами Договора;
– дата окончания выполнения Работ: «__» _____ 2027 года.
(Указывается дата окончания выполнения Работ не ранее 01.08.2027 и не
позднее 31.08.2027)
Срок предоставления гарантии качества на результат выполненных Работ
по второй и последующим утвержденным Заявкам, включая разработанную и
актуализированную документацию:
На результат Работ по второй и последующим утвержденным Заявкам,
включая
разработанную
и
актуализированную
документацию
на
модифицированную Программу для ЭВМ (п.п. 7.1.3-7.1.5 Технических
требований (Приложение № 1 к Договору)), устанавливается гарантийный срок:
дата начала гарантийного срока на результат Работ по второй и
110
последующим утвержденным Заявкам: дата подписания Сторонами УПД или
Акта о приемке выполненных работ по соответствующей утвержденной Заявке;
дата окончания гарантийного срока на результат Работ по второй и
последующим утвержденным Заявкам: дата окончания периода, равного ___
(_________) месяцам (указывается гарантийный срок не менее 12 (Двенадцати)
месяцев), исчисляемого с даты подписания Сторонами Технического акта об
установлении гарантийного срока по форме Приложения № 5 к Договору.
Сообщаем, что _______________________________________________:
(сокращенное наименование Участника конкурса)
− не находится в процессе ликвидации, на имущество не наложен арест,
отсутствует решение арбитражного суда о признании банкротом;
− не приостановлена деятельность в порядке, предусмотренном Кодексом
Российской Федерации об административных правонарушениях на дату подачи
Конкурсной заявки;
− отсутствует
в
реестре
недобросовестных
поставщиков,
предусмотренном статьей 5 Федерального закона от 18.07.2011 № 223-ФЗ «О
закупках товаров, работ, услуг отдельными видами юридических лиц» и (или) в
реестре недобросовестных поставщиков, предусмотренном Федеральным
законом от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок
товаров, работ, услуг для обеспечения государственных и муниципальных
нужд»;
− отсутствует в реестре иностранных агентов, предусмотренном
Федеральным законом от 14.07.2022 № 255-ФЗ «О контроле за деятельностью
лиц, находящихся под иностранным влиянием».
(Наименование Участника конкурса) настоящим подтверждает, что
работники руководящего состава Заказчика (Председатель Правления, Первый
заместитель Председателя Правления, заместитель Председателя Правления,
главный бухгалтер, директор по направлению, заместитель директора по
направлению, руководитель самостоятельного структурного подразделения,
руководитель филиала, заместитель руководителя филиала), а также их
ближайшие родственники (супруг, дети, родители, полнородные и
неполнородные братья и сестры) не являются акционерами (не владеют долями в
уставном капитале) (Наименование Участника конкурса), не входят в состав
его органов управления, не находятся с ним в трудовых или гражданскоправовых отношениях либо каким-либо иным образом не являются
выгодоприобретателями (бенефициарами) от деятельности участника.
(Или необходимо указать таких лиц и форму их участия в деятельности.)
(Наименование Участника конкурса) настоящим подтверждает, что
договор, заключаемый по результатам конкурса, не является для
(Наименование Участника конкурса) сделкой с заинтересованностью.
111
(Или указывает, что договор, заключаемый по результатам конкурса,
является для (Наименование Участника конкурса) сделкой с
заинтересованностью.)
(Наименование Участника конкурса) подтверждает отсутствие у
Участника - физического лица либо у руководителя, членов коллегиального
исполнительного органа или главного бухгалтера юридического лица Участника судимости за преступления в сфере экономики и (или) преступления,
предусмотренные статьями 289, 290, 291, 291.1 Уголовного кодекса Российской
Федерации (за исключением лиц, у которых такая судимость погашена или
снята), а также неприменение в отношении указанных физических лиц наказания
в виде лишения права занимать определенные должности или заниматься
определенной деятельностью, которые связаны с поставкой товара,
выполнением
работы,
оказанием
услуги,
являющихся
предметом
осуществляемой закупки, и административного наказания в виде
дисквалификации.
(Наименование Участника конкурса) настоящим подтверждает
отсутствие фактов привлечения в течение 2 (Двух) лет до момента подачи заявки
Участника конкурса – юридического лица к административной ответственности
за совершение административного правонарушения, предусмотренного статьей
19.28 Кодекса Российской Федерации об административных правонарушениях.
(Наименование Участника конкурса) настоящим подтверждает, что не
имеет задолженности по начисленным налогам, сборам (за исключением: а) сумм
задолженности, на которые предоставлены отсрочка, рассрочка,
инвестиционный налоговый кредит в соответствии с законодательством
Российской Федерации о налогах и сборах; б) сумм задолженности, которые
реструктурированы в соответствии с законодательством Российской
Федерации; в) сумм задолженности, по которым имеется вступившее в
законную силу решение суда о признании обязанности Участника по уплате
этих сумм исполненной или которые признаны безнадежными к взысканию в
соответствии с законодательством Российской Федерации о налогах и сборах;
г) сумм задолженности, оспариваемых Участником в судебном порядке, и по
которым на момент проведения конкурса соответствующее судебное решение
не принято) за прошедший календарный год, размер которой превышает 25 %
(Двадцать пять процентов) балансовой стоимости активов (Наименование
Участника конкурса) по данным бухгалтерской отчетности за последний
завершенный отчетный период.
(Или указывает наличие и размер задолженности по начисленным налогам,
сборам и иным обязательным платежам в бюджеты любого уровня (за
исключением: а) сумм задолженности, на которые предоставлены отсрочка,
рассрочка, инвестиционный налоговый кредит в соответствии с
законодательством Российской Федерации о налогах и сборах; б) сумм
112
задолженности, которые реструктурированы в соответствии с
законодательством Российской Федерации; в) сумм задолженности, по
которым имеется вступившее в законную силу решение суда о признании
обязанности Участника по уплате этих сумм исполненной или которые
признаны безнадежными к взысканию в соответствии с законодательством
Российской Федерации о налогах и сборах; г) сумм задолженности,
оспариваемых Участником в судебном порядке, и по которым на момент
проведения конкурса соответствующее судебное решение не принято) за
прошедший календарный год, размер которой превышает 25 % (Двадцать пять
процентов) балансовой стоимости активов (Наименование Участника
конкурса) по данным бухгалтерской отчетности за последний завершенный
отчетный период, с приложением к письму о подаче оферты справки ФНС
России о состоянии расчетов по налогам, сборам, пеням, штрафам, процентам
организаций и индивидуальных предпринимателей.)
(Наименование Участника конкурса) соглашается с тем, что
предоставление недостоверной информации в настоящей оферте или
прилагаемых к ней документах является достаточным основанием для
отклонения заявки.
(Наименование Участника конкурса) соглашается с тем, что при
предложении Участником конкурса цены Договора, которая на 25 % (Двадцать
пять процентов) и более ниже начальной (максимальной) цены Договора,
указанной в п. 2.2.1 Конкурсной документации, применяются антидемпинговые
меры в соответствии с пунктом 6.12. Конкурсной документации.
(Наименование Участника конкурса) подтверждает, что критерии
оценки и сопоставления Конкурсных заявок Участником конкурса изучены и
понятны, и Участник конкурса согласен с ними.
Настоящая Конкурсная заявка имеет правовой статус оферты и действует в
течение срока, установленного Конкурсной документацией.
(Наименование Участника конкурса) подтверждает, что обязательства,
связанные с подачей Конкурсных заявок, обеспечиваются денежными
средствами ИЛИ независимой гарантией (указать).
К настоящему Письму о подаче оферты прилагаются в качестве его
неотъемлемых частей приложения:
1. Техническое предложение (форма 2) на ____ л.
2. Анкета Участника конкурса (форма 3) на ____ л.
3. Справка о перечне и годовых объемах выполнения аналогичных
договоров (форма 4) на ____ л.
4. Справка о кадровых ресурсах (форма 5) на ____ л.
113
5. Документы, подтверждающие соответствие Участника конкурса и
Конкурсной заявки установленным требованиям на ____ л.
____________________________________
(подпись, М.П.)
____________________________________
(фамилия, имя, отчество подписавшего, должность)
конец формы
114
8.1.2. Инструкции по заполнению Письма о подаче оферты
8.1.2.1. Письмо о подаче оферты (далее – Письмо) оформляется на
официальном бланке Участника конкурса. Участник конкурса присваивает
Письму дату и номер в соответствии с принятыми у него правилами
документооборота.
8.1.2.2. Участник конкурса указывает свое полное фирменное
наименование (с указанием организационно-правовой формы) и место
нахождения.
8.1.2.3. Участник конкурса перечисляет и указывает объем каждого из
прилагаемых к Письму документов.
8.1.2.4. Письмо должно содержать только одну оферту. В случае
нарушения Участником конкурса указанного требования, Центральная
закупочная комиссия отказывает в допуске такого Участника конкурса к
участию в конкурсе.
8.1.2.5. Письмо должно быть подписано уполномоченным лицом и
скреплено печатью Участника конкурса при наличии у Участника конкурса
печати.
8.2.
115
8.2. Техническое предложение (форма 2)
8.2.1. Форма Технического предложения
начало формы
Приложение 1 к Письму о подаче оферты
от «____»_____________ года №__________
Техническое предложение
Наименование Участника конкурса: ______________________________
(здесь Участник конкурса выражает согласие на выполнение Работ по
Договору в соответствии с Техническими требованиями (Приложение № 1 к
Конкурсной документации).
В целях повышения предпочтительности Конкурсной заявки Участник
вправе предоставить в Техническом предложении описание вариантов
математической и графической реализации типовых блоков фиксации
отключения оборудования и контроля предшествующего режима, включая
логику работы указанных типовых блоков и их возможные параметры и
передвижение на схеме в соответствии с буллитом 3 пункта 4.2.1 Технических
требований (Приложение № 1 к Конкурсной документации) и пунктом 9.1
Эскизного проекта (Приложение № 1 к Техническим требованиям (Приложение
№ 1 к Конкурсной документации).
____________________________________
(подпись, М.П.)
____________________________________
(фамилия, имя, отчество подписавшего, должность)
конец формы
116
8.2.2.
Инструкции по заполнению Технического предложения
8.2.2.1. Участник конкурса указывает дату и номер Письма, приложением к
которому является данное Техническое предложение.
8.2.2.2. Участник конкурса указывает свое полное
наименование (в том числе организационно-правовую форму).
фирменное
8.2.2.3. В Техническом предложении Участник конкурса выражает
согласие на выполнение Работ по Договору в соответствии с Техническими
требованиями (Приложение № 1 к Конкурсной документации). Все дополнения
и изменения к Техническим требованиям (Приложение № 1 к Конкурсной
документации), предлагаемые Участником конкурса в составе Технического
предложения, указываются отдельно. При этом такие изменения и дополнения не
должны ухудшать для Заказчика условия исполнения Договора, заключаемого
по результатам конкурса.
8.2.2.4. В соответствии с требованиями буллита 3 пункта 4.2.1 Технических
требований (Приложение № 1 к Конкурсной документации) и пунктом 9.1
Эскизного проекта (Приложение № 1 к Техническим требованиям (Приложение
№ 1 к Конкурсной документации) Участник конкурса в Техническом
предложении может предоставить описание вариантов математической и
графической реализации типовых блоков фиксации отключения оборудования и
контроля предшествующего режима, включая логику работы указанных типовых
блоков и их возможные параметры и передвижение на схеме.
8.2.2.5. Техническое
предложение
должно
быть
подписано
уполномоченным лицом и скреплено печатью Участника конкурса при наличии
у Участника конкурса печати.
117
8.3.
Анкета Участника конкурса (форма 3)
8.3.1. Форма Анкеты Участника конкурса
начало формы
Приложение 2 к Письму о подаче оферты
от «____»_____________ года №__________
Анкета Участника конкурса
Наименование Участника конкурса: _____________
№
п/п
Наименование
1
2
Организационно-правовая форма и полное
фирменное наименование Участника конкурса
ОГРН
3
ИНН/КПП Участника конкурса
4
Резидент/Нерезидент
5
ОКПО
6
Банковские реквизиты
7
Место нахождения, адрес
8
Фактический адрес
9
Почтовый адрес (для переписки)
10
Телефоны Участника конкурса (в т.ч. код
города)
Факс Участника конкурса (в т.ч. код города)
11
12
13
14
Сведения об Участнике конкурса
(заполняется Участником конкурса)
номер
расчетного
счета
наименование банка
адрес банка
прочие банковские реквизиты
Адрес электронной почты Участника конкурса,
сайт Участника конкурса (при наличии)
Лицо, имеющее право действовать от имени Ф.И.О.
Участника без доверенности
должность
телефон
Ответственное лицо Участника конкурса по Ф.И.О.
вопросам, связанным с проведением конкурса
должность
телефон
____________________________________
118
(подпись, М.П.)
____________________________________
(фамилия, имя, отчество подписавшего, должность)
конец формы
119
8.3.2. Инструкции по заполнению Анкеты Участника конкурса
8.3.2.1. Анкета Участника конкурса (далее – Анкета) заполняется по всем
позициям, пустые графы Анкеты оставлять не следует. В случае отсутствия
каких-либо данных или неприменимости вопроса к Участнику конкурса в
соответствующих графах таблиц Анкеты указываются слова «нет данных» или
«неприменимо» соответственно.
Анкета предоставляется Участником конкурса в формате PDF, а также в
формате Microsoft Excel. В формате Microsoft Excel Анкета заполняется на
основании «Шаблона Анкеты участника», размещенного на интернет-сайте
Заказчика, ссылка на место размещения: «О компании / Закупки / Информация о
заключенных
договорах»,
адрес
http://www.so-ups.ru/index.php?
id=procurement_conclud (файл «Шаблон Анкеты участника.xls.»).
8.3.2.2. Анкета должна быть подписана уполномоченным лицом и
скреплена печатью Участника конкурса при наличии у Участника конкурса
печати.
120
8.4. Справка о перечне и годовых объемах выполнения
аналогичных договоров (форма 4)
8.4.1. Форма Справки о перечне и годовых объемах выполнения
аналогичных договоров
начало формы
Приложение 3 к Письму о подаче оферты
от «____»_____________ года №__________
Справка о перечне и годовых объемах выполнения
аналогичных договоров
Наименование Участника конкурса: __________________
Заказчик
Предмет Назначение и
№
(наименование,
аналогично
основные
п/п
адрес,
контактное
лицо с
указанием
должности,
контактного
телефона)
го
договора
Договор
функции
программы
для ЭВМ
№
дата
Х
Х
сумма, тыс.
руб.
Документы,
подтверждающие
исполнение
обязательств по
договору (акты, УПД)
№
дата сумма,
тыс.
руб.
1.
2.
…
ИТОГО, руб.:
____________________________________
(подпись, М.П.)
____________________________________
(фамилия, имя, отчество подписавшего, должность)
конец формы
Х
Х
121
8.4.2. Инструкции по заполнению Справки о перечне и годовых
объемах выполнения аналогичных договоров
8.4.2.1. Участник конкурса указывает дату и номер Письма, приложением к
которому является данная Справка.
8.4.2.2. В Справке Участник конкурса указывает свое полное фирменное
наименование (в том числе организационно-правовую форму).
8.4.2.3. В Справке Участник конкурса указывает перечень и годовые
объемы выполнения аналогичных договоров за последние 3 (Три) года до срока
окончания подачи Участниками Конкурсных заявок (при наличии).
В целях оценки и сопоставления Конкурсных заявок учитывается опыт
выполнения аналогичных договоров оказания услуг по техническому
обслуживанию (сопровождению) и (или) на выполнение работ по созданию
(разработке) и(или) модификации программ для ЭВМ, применяемых в
электроэнергетике в области моделирования схем устройств и/или каналов
передачи сигналов противоаварийной автоматики.
К Справке прилагаются копии договоров, актов о приемке выполненных
работ/ актов об оказании услуг, УПД и иных документов (отчетов об оказании
услуг, регламентов оказания услуг, технических заданий и др.), содержащих
описание аналогичных работ/ услуг, назначение и основные функции программ
для ЭВМ. Участник может самостоятельно выбрать договоры, которые, по его
мнению, наилучшим образом характеризуют его опыт.
8.4.2.4. Справка должна быть подписана уполномоченным лицом и
скреплена печатью Участника конкурса при наличии у Участника конкурса
печати.
122
8.5.
Справка о кадровых ресурсах (форма 5)
8.5.1. Форма Справки о кадровых ресурсах
начало формы
Приложение 4 к Письму о подаче оферты
от «____»_____________ года №__________
Справка о кадровых ресурсах
Наименование Участника конкурса: ______________________
Таблица 1. Кадровые ресурсы, планируемые для привлечения к
исполнению Договора
№
п/п
Фамилия, имя, отчество
специалиста
Образование
(какое
учебное
заведение
окончил, год окончания,
полученная
специальность)
(при наличии)
Документы о повышении
квалификации (обучении)
в
области
администрирования
операционной
системы
Astra Linux
(при наличии)
Специалисты
1.
2.
…
____________________________________
(подпись, М.П.)
___________________________________
(фамилия, имя, отчество подписавшего, должность)
конец формы
123
8.5.2. Инструкции по заполнению Справки о кадровых ресурсах
8.5.2.1. Участник конкурса указывает дату и номер Письма, приложением к
которому является данная Справка.
8.5.2.2. Участник конкурса указывает свое полное фирменное
наименование (в том числе организационно-правовую форму).
8.5.2.3. В таблице 1 данной Справки перечисляются только те специалисты
(при наличии), которые будут непосредственно привлечены Участником
конкурса в ходе выполнения Договора (не менее 7 (Семи) специалистов с
высшим образованием в области информационных технологий и (или)
электроэнергетики и(или) математики, в том числе не менее 1 (Одного)
специалиста, имеющего документы о повышении квалификации (обучении) в
области администрирования операционной системы Astra Linux).
Квалификация специалистов в соответствии требованиями п. 2.3
Приложения № 2 к Техническим требованиям (Приложение № 1 к Конкурсной
документации) подтверждается копиями документов (при наличии):
 дипломов о высшем образовании в области информационных
технологий и(или) электроэнергетики и(или) математики (на не
менее чем 7 (Семь) специалистов);
 документов о повышении квалификации (обучении) в области
администрирования операционной системы Astra Linux (на не менее,
чем 1 (Одного) специалиста);
 резюме на каждого специалиста с указанием опыта участия в
аналогичных договорах (проектах).
К Справке прикладываются копии документов, подтверждающих наличие
трудовых и/или гражданско-правовых отношений между Участником и
привлекаемыми им к выполнению Работ по Договору специалистами: штатного
расписания, приказа о назначении на должность и (или) трудовой книжки, и
(или) трудового договора (допускается предоставление выписок из указанных
документов) и/или договоров гражданско-правового характера с привлекаемыми
к выполнению Работ специалистами.
8.5.2.4. Справка должна быть подписана уполномоченным лицом и
скреплена печатью Участника конкурса при наличии у Участника конкурса
печати.
124
8.6.
Независимая гарантия (форма 6)
8.6.1. Форма независимой гарантии
начало формы
Форма гарантии исполнения обязательств,
связанных с участием в конкурсе и подачей Конкурсной заявки
В АО «СО ЕЭС»
НЕЗАВИСИМАЯ ГАРАНТИЯ № _________
г. ________
«___»_______20__ года.
Мы информированы о том, что ________________________ (указать
полное наименование юридического лица или ФИО индивидуального
предпринимателя) (адрес места нахождения юридического лица или места
регистрации индивидуального предпринимателя: ___________, ОГРН
_____________), именуемое(ый) в дальнейшем «Принципал», намерен(о)
участвовать в конкурсе в электронной форме на право заключения договора на
выполнение работ по модификации программы для ЭВМ «Конструктор
логических моделей/схем противоаварийной автоматики» (далее – Договор),
проводимом Акционерным обществом «Системный оператор Единой
энергетической системы» (адрес места нахождения: г. Москва, Китайгородский
проезд, д. 7, стр. 3, ОГРН 1027700201352), именуемым в дальнейшем
«Бенефициар». В соответствии с условиями Конкурсной документации
Принципал обязан предоставить Бенефициару финансовое обеспечение
исполнения своих обязательств, связанных с подачей Конкурсной заявки
Принципала на участие в конкурсе в электронной форме на право заключения
договора на выполнение работ по модификации программы для ЭВМ
«Конструктор логических моделей/схем противоаварийной автоматики», на
денежную сумму в размере _______ (указать сумму цифрами и прописью)
рублей __ копеек (указывается размер обеспечения в соответствии с
требованиями раздела 7 Конкурсной документации).
Учитывая
вышеизложенное,
по
просьбе
Принципала
мы,
_________________________________ (наименование, адрес и иные реквизиты
гаранта, реквизиты лицензии, выданной Банком России, ОГРН ________, БИК
____________), в лице _____________, действующего на основании
_____________, именуемый в дальнейшем «Гарант», настоящим принимаем на
себя безотзывное и безусловное обязательство выплатить в течение 5 (Пяти)
рабочих дней со дня следующего за днем получения письменного требования
125
Бенефициара любую сумму, не превышающую _______ (указать сумму
цифрами и прописью) рублей __ копеек (указывается размер обеспечения в
соответствии с требованиями раздела 7 Конкурсной документации), без споров
и возражений с нашей стороны, не требуя от Бенефициара обоснований суммы
требования по настоящей Гарантии, а также доказательств факта неисполнения
или ненадлежащего исполнения Принципалом своих обязательств, связанных с
подачей Конкурсной заявки.
Настоящая Гарантия обеспечивает надлежащее исполнение Принципалом
следующего его обязательства перед Бенефициаром, связанного с подачей
Конкурсной заявки:

исполнение Принципалом обязанности заключить Договор в
порядке, установленном Конкурсной документацией, в случае признания
Принципала Победителем конкурса (требование по Гарантии предъявляется в
случае уклонения или отказа Принципала от заключения Договора с
Бенефициаром по результатам проведения конкурса).
Письменное требование Бенефициара должно содержать указание на то,
что Принципал не исполнил обязательства, связанные с подачей Конкурсной
заявки, сумму требования, все необходимые и достаточные для перечисления
суммы по Гарантии платежные реквизиты Бенефициара и должно быть
подписано Бенефициаром.
Предусмотренные настоящей Гарантией обязательства Гаранта считаются
исполненными с момента списания денежных средств с корреспондентского
счета Гаранта в пользу Бенефициара, в соответствии с реквизитами, указанными
в требовании Бенефициара.
Ответственность Гаранта перед Бенефициаром за невыполнение или
ненадлежащее выполнение Гарантом обязательства по настоящей Гарантии не
ограничивается суммой, на которую выдана Гарантия.
Настоящая Гарантия вступает в силу с «____» _________20___года и
действует по «____»_________20__ (включительно). (Срок действия
независимой гарантии должен быть равен или превышать срок действия
Конкурсной заявки) Требование по настоящей Гарантии должно быть
направлено Бенефициаром Гаранту по адресу: ____________________________.
Настоящая Гарантия регулируется законодательством Российской
Федерации.
Права и обязанности по настоящей Гарантии не могут быть переданы
иным лицам без соответствующего соглашения Гаранта и Бенефициара.
Гарант согласен, что никакие изменения или дополнения Конкурсной
документации или Конкурсной заявки Принципала никоим образом не
освобождают Гаранта от обязательств по настоящей Гарантии, и не требуется
уведомлять Гаранта о любых таких изменениях и дополнениях.
Любое изменение, внесенное Гарантом в условия Гарантии, будет
действительно для Бенефициара только при условии получения Гарантом
письменного уведомления Бенефициара о согласии на такое изменение.
126
Все споры, возникающие в связи с действительностью, толкованием или
исполнением настоящей Гарантии, подлежат рассмотрению в Арбитражном суде
г. Москвы.
Подписи уполномоченных лиц.
конец формы
127
8.6.2. Инструкции по заполнению независимой гарантии
8.6.2.1. Требования к независимой гарантии
8.6.2.1.1. Независимая гарантия должна соответствовать форме 6.
8.6.2.1.2. В тексте независимой гарантии:
а)
Валюта гарантии должна совпадать с валютой Договора.
б)
Срок действия гарантии должен быть равен или превышать срок
действия Конкурсной заявки.
8.6.2.1.3. В независимой гарантии не должно быть условий или
требований, противоречащих положениям формы независимой гарантии,
приведенной в Конкурсной документации, или делающих их неисполнимыми.
8.6.2.2. Требования, предъявляемые Организатором конкурса к
гарантам
Гаранты должны соответствовать требованиям, указанным в
постановлении Правительства Российской Федерации от 20.12.2021 № 2369 «О
требованиях к банкам и фондам содействия кредитованию (гарантийным
фондам, фондам поручительств) для целей осуществления закупок товаров
(работ, услуг) для обеспечения государственных и муниципальных нужд, об
изменении и признании утратившими силу некоторых актов и отдельных
положений некоторых актов Правительства Российской Федерации».

=== ФАЙЛ: Приложение 1 к КД_ТТ Модификация КПА(38958291_256_06_10_2026).docx | docs/32616441078/Приложение 1 к КД_ТТ Модификация КПА(38958291_256_06_10_2026).pdf
Приложение № 1
к Конкурсной документации по конкурсу в
электронной форме на право
заключения договора на выполнение работ по
модификации программы для ЭВМ
«Конструктор логических моделей/схем
противоаварийной автоматики»
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
на выполнение работ по модификации программы для ЭВМ
«Конструктор логических моделей/схем противоаварийной
автоматики»
Москва 2026
2
СОДЕРЖАНИЕ
1.
ОБЩИЕ ПОЛОЖЕНИЯ...................................................................................................5
1.1.
Полное наименование программы для ЭВМ и её условное обозначение...............5
1.2.
Сведения об организации Заказчика и Исполнителя.................................................5
1.3.
Основание для модификации Системы.........................................................................5
1.4.
Основные понятия, определения и сокращения..........................................................6
2.
НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ...................................................7
2.1.
Назначение Системы.........................................................................................................7
2.2.
Цели модификации Системы..........................................................................................7
2.3. Перечень диспетчерских центров АО «СО ЕЭС», в которых предполагается
использовать Систему................................................................................................................. 7
3.
ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ............................................8
4.
ТРЕБОВАНИЯ К СИСТЕМЕ.......................................................................................... 9
4.1.
Требования к обеспечению кадровыми ресурсами Исполнителя............................9
4.2.
Функциональные требования к модифицированной Системе...............................31
4.2.1.
Общие требования к модифицированной Системе..............................................31
4.2.2.
Требования к визуализации......................................................................................31
4.3.
Нефункциональные требования к Системе................................................................32
4.3.1.
Общие требования.......................................................................................................32
4.3.2.
Требования к архитектуре.........................................................................................33
4.3.3.
Требования к режиму функционированию Системы..........................................33
4.3.4.
Требования к надежности..........................................................................................34
4.3.5.
Требования к категорийности Системы.................................................................34
4.3.6.
Требования к безопасности....................................................................................... 34
4.3.6.1.
Общие требования.................................................................................................. 34
4.3.6.2.
Требования к паролям Системы.........................................................................35
4.3.6.3.
Требования к совместимости с антивирусным ПО.........................................35
4.3.6.4.
Требования по взаимодействию с ПАК «СОКИБ»..........................................35
4.3.6.5.
Требования по взаимодействию с подсистемой управления уязвимостями
35
4.3.7.
Требования к масштабированию.............................................................................35
4.3.8.
Требования к API Системы.......................................................................................36
4.3.9.
Требования к видам обеспечения.............................................................................36
4.3.9.1.
Требования к программному обеспечению.......................................................36
4.3.9.2.
Требования к техническому обеспечению.........................................................39
4.3.9.2.1.
Требования к видам технических средств.........................................................39
4.3.9.2.2.
Требования к сетям связи при информационном обмене Системы.............40
4.3.9.3.
Требования к совместимости с пакетом офисных приложений...................40
3
4.3.9.4.
Требования к интеграции со Службой каталогов............................................40
4.3.9.5.
Требования по взаимодействию с системой резервного копирования........41
4.3.9.6.
Требования по взаимодействию с системой электронной почты.................42
4.3.9.7.
Требования по интеграции с сервисом точного времени...............................42
4.3.10. Требования к проведению нагрузочного тестирования......................................42
4.3.11. Требования к журналированию...............................................................................42
4.3.11.1.
Общие требования.................................................................................................. 42
4.3.11.2.
Требования к хранению и форматам сообщений.............................................43
5.
СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО МОДИФИКАЦИИ СИСТЕМЫ..........45
5.1.
Общие положения............................................................................................................45
5.2.
Обязанности Заказчика и Исполнителя...................................................................... 45
5.2.1.
Обязанности Заказчика..............................................................................................45
5.2.2.
Обязанности Исполнителя........................................................................................ 46
5.3.
Демонстрация промежуточных результатов работы................................................48
6.
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ................................................49
6.1.
Виды, состав, объем и методы испытаний Системы и её составных частей.......49
6.1.1.
Виды испытаний..........................................................................................................49
6.1.2.
Состав, объем и методы испытаний........................................................................49
6.1.2.1.
Предварительные испытания..............................................................................49
6.1.2.2.
Установка и настройка..........................................................................................50
6.1.2.3.
Тестирование........................................................................................................... 50
6.1.3.
Регистрация и устранение замечаний.....................................................................51
7.
ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ............................................................52
7.1.
Перечень подлежащих разработке и актуализации документов............................52
7.1.1.
Заявки............................................................................................................................ 52
7.1.2.
Актуализированный эскизный проект...................................................................53
7.1.3.
Актуализированная эксплуатационная документация на Систему.................54
7.1.3.1.
Общее описание Системы..................................................................................... 54
7.1.3.2.
Руководство пользователя.................................................................................... 54
7.1.3.3.
Руководство администратора...............................................................................54
7.1.3.4.
Руководство системного администратора.........................................................55
7.1.4.
Программа и методика испытаний......................................................................... 55
7.1.5.
Комплект документов при передаче дистрибутива..............................................56
7.1.5.1.
Протокол предварительных испытаний............................................................56
7.1.5.2.
Акт готовности Системы к процедуре внедрения в АО «СО ЕЭС».............56
7.1.5.3.
Инструкция по установке и настройке Системы.............................................56
7.1.5.4.
Перечень внесенных изменений..........................................................................57
7.1.5.5.
Матрица доступа.....................................................................................................57
4
7.2.
Формат документации.................................................................................................... 57
7.3.
Исходный текст (код)...................................................................................................... 58
8.
НОРМАТИВНЫЕ ДОКУМЕНТЫ, РЕГУЛИРУЮЩИЕ ВЫПОЛНЕНИЕ
РАБОТ ПО МОДИФИКАЦИИ СИСТЕМЫ.........................................................................59
9.
ПРИЛОЖЕНИЕ……………………………………………………..……………………60
5
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1.
Полное наименование программы для ЭВМ и её условное обозначение
Наименование программы для ЭВМ: Конструктор логических моделей/схем
противоаварийной автоматики.
Условное обозначение программы для ЭВМ – КПА, Система.
1.2.
Сведения об организации Заказчика и Исполнителя
Заказчик: Акционерное общество «Системный оператор Единой
энергетической системы» (АО «СО ЕЭС») – специализированная организация,
единолично осуществляющая централизованное оперативно-диспетчерское
управление в Единой энергетической системе России.
Исполнитель: организация, выигравшая конкурсные торги.
1.3.
Основание для модификации Системы
Основанием для модификации Системы является:
− Сводный годовой план развития АСДУ АО «СО ЕЭС» на 2026 год.
6
1.4.
Основные понятия, определения и сокращения
API
Application Programming Interface (Интерфейс программирования
приложений) – набор готовых классов, процедур, функций, структур и
констант, предоставляемых приложением (библиотекой, сервисом)
для использования во внешних программных продуктах. Используется
программистами для написания приложений
HTTPS
HyperText Transfer Protocol Secure (Расширение протокола HTTP для
поддержки шифрования в целях повышения безопасности)
АИС «ФПА»
Автоматизированная информационная система «Фонд программ и
алгоритмов»
АО «СО ЕЭС»,
Заказчик
Акционерное общество «Системный оператор Единой энергетической
системы»
АСДУ
Автоматизированные системы диспетчерского управления
АСУЗ
Автоматизированная система учета заявок Заказчика
БД
База данных
ЗУД
Защищенный удаленный доступ
ИА
Исполнительный аппарат АО «СО ЕЭС»
ИБ
Информационная безопасность
ИК
Исходный текст (код)
ИТ
Информационные технологии
ИУС
Информационно-управляющая система
Микросервисная
архитектура
Вариант сервис-ориентированной архитектуры программного
обеспечения, направленный на взаимодействие насколько это
возможно небольших, слабо связанных и легко изменяемых модулей
НСИ
Нормативно-справочная информация
ОДУ
Филиал АО «СО ЕЭС» объединенное диспетчерское управление
ОС
Операционная система
ПА
Противоаварийная автоматика
ПАК
Программно-аппаратный комплекс
ПАК «ЕСМ»
ПАК «Единая система мониторинга ИТ-инфраструктуры
исполнительного аппарата АО "СО ЕЭС»
ПАК «СОКИБ»,
СОКИБ
Программно-аппаратный комплекс «Система оперативного контроля
информационной безопасности»
ПО
Программное обеспечение
РДУ
Филиал АО «СО ЕЭС» региональное диспетчерское управление
ТТ
Технические требования
7
2. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
2.1.
Назначение Системы
Назначением Системы является автоматизация процесса создания,
редактирования и проверки корректности разработанных моделей устройств
(функций) ПА.
2.2.
Цели модификации Системы
Целями модификации Системы по настоящим ТТ являются:
− актуализация Эскизного проекта на создание программы для ЭВМ
«Универсальный конструктор моделей устройств (функций)
противоаварийной автоматики» (Приложение № 1 к настоящим ТТ),
разработанного по договору от 05.05.2023 № 273-14-8Н-23;
− интеграция Системы в существующую ИТ-инфраструктуру
АО «СО ЕЭС» в соответствии с актуализированным Эскизным
проектом;
− реализация типовых блоков следующих устройств автоматики в том
числе их графического отображения;
 предотвращения нарушения устойчивости;
 ликвидации асинхронного режима;
 ограничения снижения частоты;
 ограничения повышения частоты;
 ограничения снижения напряжения;
 ограничения повышения напряжения;
 ограничения перегрузки оборудования.
2.3.
Перечень диспетчерских центров АО «СО ЕЭС»,
предполагается использовать Систему
в
которых
Система модифицируется для использования в диспетчерских центрах
Заказчика - ИА, ОДУ, РДУ.
8
3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
Конструктор логических моделей/схем противоаварийной автоматики
разработан с целью автоматизации процесса создания, редактирования и
проверки корректности разработанных моделей устройств (функций) ПА.
Система позволяет технологам формировать схемы, используя типовые
блоки различных классов, каждый из которых имеет свой набор параметров,
позволяющих реализовать функцию и логику противоаварийной автоматики в
контексте логического представления реального оборудования.
В Системе реализованы следующие функции:
− управление схемами: создание, редактирование параметров,
открытие на чтение, открытие для редактирования, переключение
режимов открытой схемы (редактирование или проверка),
перемещение между функциями ПА, удаление;
− формирование схем (наполнение схем объектами): добавление
типовых объектов на схему, изменение параметров объектов на
схеме, связывание объектов, удаление объектов, управление
укрупненными блоками на схеме (создание, редактирование,
удаление), копирование и/или вставка объектов и укрупненных
блоков, копирование объектов из других схем;
− проверка схем (проверка прохождения тестового сигнала по схеме):
управление объектами привязки (привязкой объекта на схеме к
объектам энергосистемы), управление параметрами тестового
сигнала, просмотр результатов проверки схемы.
9
4. ТРЕБОВАНИЯ К СИСТЕМЕ
4.1.
Требования к обеспечению кадровыми ресурсами Исполнителя
Все специалисты, привлекаемые Исполнителем для выполнения работ по
модификации Системы, должны быть в штате Исполнителя и/или находиться с
ним в гражданско-правовых отношениях.
Специалисты, в количестве не менее, чем в указанном в таблице 1
настоящих ТТ, и привлекаемые Исполнителем для выполнения работ по
модификации Системы, должны иметь высшее образование в области
информационных технологий и (или) электроэнергетики и (или) математики
(подтверждается копиями дипломов о высшем образовании).
Таблица 1
Минимальные требования к численности специалистов Исполнителя
Роль в проекте
Руководитель проекта
Бизнес-аналитик
Backend-разработчик
Frontend-разработчик
UX/UI-дизайнер
Специалист по функциональному тестированию
Численность специалистов:
Количество
специалистов
Исполнителя
1
1
2
1
1
2
8
Планируемое количество трудозатрат для выполнения работ по
модификации Системы должно быть не менее 4 760 человеко-часов.
При выполнении работ специалисты, привлекаемые Исполнителем для
выполнения работ по модификации Системы, должны обладать необходимой
квалификацией и предпочтительно подтвержденным опытом работы в
соответствии с требованиями, указанными в таблице 2 настоящих ТТ.
26
Таблица 2
Минимальные требования к квалификации специалистов команды Исполнителя
Роль в проекте
Подтвержденный опыт и
квалификация
- дополнительное образование
Руководитель проекта
по управлению проектами;
- опыт управления проектами
по разработке программного
обеспечения с численностью
команды не менее 10 человек;
- опыт
работы
с
информационными
системами
управления
проектами;
- управления требованиями.
Выполняемые работы в проекте
- взаимодействие с представителями Заказчика,
согласование
финансовых,
юридических,
организационных и иных условий с Заказчиком;
- формирование объема и бюджета проекта в целом,
согласование приоритетов, стоимости и сроков
реализации задач;
- контроль и адаптация общепроектного процесса
для повышения качества модифицируемой
Системы;
- планирование, организация, координирование и
контроль хода выполнения Работ;
- интервьюирование и формирование команды;
- мониторинг всех показателей и метрик проекта,
принятие мер по их улучшению;
- ведение и управление процессом модификации,
тестирования
и
внедрения
Системы,
ответственность за соблюдение практик и
методологии;
- организация
и
проведение
совещаний,
демонстраций;
- выявление и решение проблем в процессе работы
команды Исполнителя;
Дополнительный опыт и
навыки
- знание
и
опыт
применения
традиционных и гибких
методологий управления
проектами и разработки
программного
обеспечения;
- базовые
знания
процессов производства
и
передачи
электроэнергии.
27
Роль в проекте
Подтвержденный опыт и
квалификация
Выполняемые работы в проекте
- повышение
- опыт работы на аналогичных
Backend-разработчик
позициях более 5 лет;
- опыт
разработки
программного
кода
с
использованием
СУБД
«Postgres»;
- опыт
оптимизации
производительности
на
уровне БД;
- опыт проектирования и
разработки клиент-серверных
систем;
- опыт
разработки
автоматизированных систем
для электроэнергетической
отрасли;
- опыт
разработки клиентсерверных систем;
- опыт
планирования
и
проведения
нагрузочного
Дополнительный опыт и
навыки
эффективности работы команды
Исполнителя, стремление к достижению целей
членами команды Исполнителя;
- подготовка статус-отчетов по выполняемым
Работам.
- контроль за архитектурной целостностью и - опыт
разработки
оптимальностью архитектуры;
архитектур для решений
класса клиент-сервер и
- проработка архитектурных решений;
- внутреннее рецензирование и согласование заявок отчетных систем;
на модификацию Системы, кода на соответствие - опыт участия в проектах
по
разработке
ПО,
проработанному архитектурному решению;
управляемых
с
- согласование архитектуры и технических
использованием гибких
требований по заявке на модификацию Системы;
- системный анализ требований, оценка влияния методологий;
- знание
методик
требований на архитектуру на уровне БД;
декомпозиции работ и
- проектирование и доработка БД;
оценке
трудоемкости
- оптимизация работы системы на уровне БД для задач по разработке.
повышения
отказоустойчивости
и
производительности;
- разработка соответствующих разделов рабочей
документации;
- разработка кода в соответствии с согласованными
Заказчиком требованиями;
- ревизия кода и фиксирование ошибок;
- участие в процессе передаче исходного текста
(кода) Заказчику;
- разработка методик нагрузочного тестирования;
28
Роль в проекте
Frontend-разработчик
Бизнес-аналитик
Подтвержденный опыт и
Выполняемые работы в проекте
квалификация
тестирования
систем
с - подготовка
и
проведение
нагрузочного
использованием ПО JMeter
тестирования;
или аналогичного.
- анализ результатов нагрузочного тестирования,
локализация возникших проблем;
- презентация
результатов
нагрузочного
тестирования Заказчику.
- опыт работы на аналогичных - разработка кода в соответствии с согласованными
позициях более 5 лет;
Заказчиком требованиями;
- опыт верстки, реализации - организация и отладка программного кода, и
функциональности
по
фиксирование ошибок;
макетам
графического - работа с HTML и CSS и дизайн-макетами;
интерфейса.
- верстка веб-интерфейса Системы;
- настройка всех блоков страниц (кнопок, вкладок и
остальных элементов Системы);
- тестирование, устранение багов.
- опыт работы в качестве - общее планирование работ в ходе аналитики
бизнес-аналитика не менее 3
(формирование требований и экспертиза);
лет, в т.ч. в проектах по - взаимодействие с представителями Заказчика в
созданию
рамках сбора и согласования требований;
автоматизированных систем - управление процессом доработки и согласования
для электроэнергетической
заявок;
отрасли не менее 1 года;
- участие в функциональном тестировании;
- опыт разработки требований
- системный анализ требований на реализуемость,
и
проектирования
оценка влияния требований на архитектуру или на
автоматизированных систем
условия работ по проекту;
для электроэнергетической
согласование
архитектуры
и
технических
отрасли;
требований с командой разработки;
- опыт
согласования
Дополнительный опыт и
навыки
- опыт участия в проектах
по
разработке
ПО,
управляемых
с
использованием гибких
методологий;
- знание
методик
декомпозиции работ и
оценке
трудоемкости
задач по разработке.
- базовые
знания
принципов
функционирования
устройств
релейной
защиты и автоматики;
- базовые
знания
процессов производства
и
передачи
электроэнергии.
29
Роль в проекте
Специалист по
функциональному
тестированию
UX/UI-дизайнер
Подтвержденный опыт и
Дополнительный опыт и
Выполняемые работы в проекте
квалификация
навыки
архитектурных решений к - согласование
функциональных
и
интеграционным задачам;
нефункциональных требований с Заказчиком;
- опыт разработки требований - консультирование разработчиков и тестировщиков
и оценки аналитических
по документации;
работ.
- разработка и актуализация документации.
- опыт
тестирования - участие в подготовке программы и методики
программного обеспечения
испытаний;
для
автоматизированных - подготовка тестовых данных/ настройка тестовой
систем от 3-х лет;
среды
- опыт разработки тестовых - выполнение
тестирования
(включая
сценарий
(включая
регрессионное) в процессе разработки;
автоматизированные);
- сбор, анализ и оформление результатов
тестирования и испытаний;
- опыт планирования и оценки - поддержка пользовательского тестирования;
трудозатрат
работ
по - оценка целесообразности применения различных
тестированию.
методов
применения/оптимизации
автоматизированного тестирования;
- оценка эффективности тестирования, рисков
автоматизации;
- разработка
скриптов
и
средств
автоматизированного тестирования (эмуляторов,
утилит генерации тестовых данных).
- опыт работы на аналогичной - разработка информационной архитектуры;
должности от 3-х лет;
- владение основами типографики и композиции;
- опыт
проектирования - понимание принципов usability и адаптивности
различных
вариантов
веб-интерфейсов;
пользовательского
опыта, - создание визуального дизайна графического
30
Роль в проекте
Подтвержденный опыт и
квалификация
проработки
пользовательских сценариев.
Выполняемые работы в проекте
интерфейса пользователя;
- понимание технологий frontend-разработки.
Дополнительный опыт и
навыки
31
4.2.
Функциональные требования к модифицированной Системе
4.2.1. Общие требования к модифицированной Системе
В ходе модификации Системы должны быть выполнены, как минимум,
следующие требования:
1.
Актуализация Эскизного проекта на создание программы для ЭВМ
«Универсальный конструктор моделей устройств (функций) противоаварийной
автоматики».
2.
Выполнить работы по модификации Системы в соответствии с
актуализированным Эскизным проектом в части инфраструктурных требований:
- перевести Систему на функционирование под управлением СУБД
Tantor;
- обеспечить логирование в соответствии с п. 4.3.11 (требования к составу
логируемой информации могут быть уточнены в ходе актуализации
Эскизного проекта (далее также – ЭП);
- реализовать интеграцию со Службой каталогов.
3.
Выполнить работы по реализации типовых блоков следующих устройств
автоматики:
 предотвращения нарушения устойчивости;
 ликвидации асинхронного режима;
 ограничения снижения частоты;
 ограничения повышения частоты;
 ограничения снижения напряжения;
 ограничения повышения напряжения;
 ограничения перегрузки оборудования.
Состав блоков определяется в ходе актуализации ЭП.
Функции Системы, не модифицируемые в рамках настоящих ТТ, должны
остаться без изменения.
Модификацию Системы необходимо осуществлять с учетом результатов
работ по договорам от 19.04.2023 № 261-14-5Н-23 с АО «НТЦ ЕЭС», от
05.05.2023 № 273-14-8Н-23 с АО «НТЦ ЕЭС».
4.2.2. Требования к визуализации
При разработке пользовательского интерфейса Системы должно быть
обеспечено:
1) Интерфейс должен быть выдержан в едином стиле для всех разделов.
Все формы отображения должны иметь единообразную компоновку и не
противоречащие друг другу правила работы. Для обеспечения этого
соответствия все формы отображения и свойства выводимых значений (формат,
шрифт) должны быть основаны на единых библиотеках стилей.
2) Интерфейс должен позволять решать задачи пользователя наиболее
быстрым и простым способом: доступ к любой функции должен осуществляться
посредством минимально возможного количества команд.
32
3) Доступ к основным функциям должен осуществляться с активной
(текущей) формы.
4) Интерфейс должен обеспечивать сохранение индивидуальных настроек
представления форм отображения для каждого пользователя. Для ускорения и
упрощения работы в интерфейсе должны быть реализованы:
 возможность использования сочетания клавиш, для выполнения
действий на форме отображения;
 возможность отмены последних правок данных, выполненных на
форме отображения;
 возможность вызова функций из контекстного меню, вызываемого
нажатием правой кнопки мыши на объекте;
 возможность
выбора
подлежащих
вводу
данных
из
предопределенного списка;
 проверка введенных данных на корректность.
5) Интерфейс должен масштабироваться при изменении разрешения
экрана, используемого в операционной системе (все элементы управления
должны быть доступны пользователю).
6) Элементы управления на всех формах отображения должны быть
сгруппированы согласно выполняемым функциям.
7) Отображение элементов управления в активированном состоянии
должно визуально отличаться от их отображения в не активированном
состоянии.
8) В случае невозможности размещения информации в пределах экрана на
форме отображения необходимо реализовать полосы горизонтальной или
вертикальной прокрутки.
9) Пользователь должен получать информацию как об успешном
завершении операций, так и о возникновении сбоев в ходе их выполнения или
невозможности выполнения.
10) Должна быть предусмотрена настройка для отличия полигонного и
основного экземпляра Системы.
11) Исполнитель должен разработать и предоставить на согласование
Заказчику прототипы экранных форм отображения Системы. Состав форм
отображения должен быть согласован с Заказчиком до начала выполнения работ
по прототипированию.
12) Окончательный вид, состав и функциональность форм отображения
Системы должны быть согласованы с Заказчиком.
4.3.
Нефункциональные требования к Системе
4.3.1. Общие требования
При модификации Системы должны остаться неизменными:
- требования к техническому обеспечению, необходимому для
функционирования Системы;
- требования к программному обеспечению (в том числе требования к
дистрибутиву модифицированной Системы);
33
- требования к категорийности;
- требования к производительности;
- требования к режиму функционированию Системы;
- требования к надежности;
- требования к пропускной способности ЛВС и межфилиальных каналов
связи;
- требования к взаимодействию с инфраструктурными системами
(Служба каталогов, система резервного копирования);
- требования к информационной безопасности.
Система
должна
быть
модифицирована
в
соответствии
с
актуализированным ЭП.
4.3.2. Требования к архитектуре
Система должна иметь централизованную архитектуру с расположением
серверов на уровне ИА.
Архитектура Системы должна быть реализована с использованием
модульного подхода к разработке программного обеспечения, основанного на
использовании распределённых, слабо связанных, заменяемых компонентов,
оснащённых стандартизированными интерфейсами для взаимодействия по
стандартизированным протоколам.
Архитектура Системы должна учитывать раздельное размещение
серверных ресурсов на разных площадках, включая географически
распределенные площадки и аппаратные залы, для организации
отказоустойчивости и высокой доступности.
Система должна быть реализована на основе многозвенной
(многоуровневой) архитектуры: клиент – сервер приложений – сервер БД.
Для пользователей должен быть реализован доступ к Системе через вебинтерфейс в корпоративной сети АО «СО ЕЭС».
Веб-браузеры, используемые для доступа к веб-интерфейсу, должны
соответствовать корпоративной технической политике Заказчика, быть
стандартным продуктом и не модифицироваться Исполнителем.
4.3.3. Требования к режиму функционированию Системы
Должно быть обеспечено функционирование Системы в следующих
режимах:
− Штатный режим;
− Автономный режим;
− Режим обновления;
− Режим технического обслуживания (для проведения обслуживания,
реконфигурации и замены компонент, тестирования и диагностики).
4.3.4. Требования к надежности
Мероприятия по обеспечению надёжности должны планироваться и
осуществляться в соответствии с положениями стандарта ГОСТ 24.701-86
34
"Надёжность автоматизированных систем управления". Согласно п. 1.4. данного
стандарта уровень надёжности Системы зависит от надёжности и других свойств
технического обеспечения (комплекса технических средств), программного
обеспечения и персонала, участвующего в функционировании Системы.
Выход из строя любой составной части (модуля) Системы или нарушение
внешних интерфейсов не должны приводить к прекращению функционирования
Системы в целом, при этом должна обеспечиваться возможность выполнения
функций всех оставшихся частей Системы в нормальном или автономном
режиме.
Повышение надежности Системы в части ошибочных действий
пользователей следует обеспечивать необходимым уровнем защиты от
несанкционированного доступа к информации, а также разграничением
полномочий доступа и прав пользователей.
Если авария или неустранимая ошибка произошла, то Система после
устранения причин аварии должна восстанавливать работоспособность при
повторном перезапуске компонентов Системы.
Все сообщения пользователю о сбоях Системы должны быть дополнены
описанием возможных действий для диагностики и устранения сбоя.
4.3.5. Требования к категорийности Системы
В соответствии с Положением об организации обслуживания
информационно-управляющих систем, инфраструктурных программноаппаратных комплексов и технических средств, обеспечивающих их
функционирование, утвержденным приказом АО «СО ЕЭС» от 20.05.2022
№ 178, Система относится к третьей категории оперативного обслуживания.
4.3.6. Требования к безопасности
4.3.6.1. Общие требования
Система должна обеспечивать:
− защиту от несанкционированного доступа к информации, хранящейся в
базе данных Системы;
− аутентификацию и авторизацию пользователей с использованием
учетных записей корпоративной Службы каталогов;
− разграничение полномочий доступа пользователей к информации на
уровне задач в соответствии с назначенной в Системе ролью;
− контроль доступа пользователей Системы к защищаемым
информационным ресурсам в соответствии с назначенной в Системе ролью;
− ведение журнала всех действий пользователя в Системе, в том числе с
возможностью сохранения истории изменённых пользователем данных;
− события, связанные с ИБ (авторизация, смена пароля, неверный ввод
пароля и т.д.) должны записываться в syslog в формате CEF (Common Event
Format);
− в случае разработки API для внешних систем или пользователей все
функции должны использоваться в рамках ролевой модели Системы, при этом
35
должны быть исключены или при невозможности исключения, должны быть
минимизированы функции доступные для неавторизованного пользователя и
доступ по API должен осуществляться по протоколу TLS 1.2 или выше.
4.3.6.2. Требования к паролям Системы
Пароли в Системе (в конфигурационных файлах, в БД) не должны
храниться в любом виде. В случае невозможности исключения хранения
паролей, допускается хранить пароли в зашифрованном виде. Вместе с тем
допускается хранение хэшей паролей, сгенерированных с уникальными
модификаторами (солью) для каждого сгенерированного хэша (модификатор
«соль» допускается хранить вместе с хэшем в базе данных).
Система должна обеспечивать передачу паролей пользователей,
специализированных и сервисных учетных записей в зашифрованном виде или в
рамках используемого протокола с шифрованием.
4.3.6.3. Требования к совместимости с антивирусным ПО
Необходимо обеспечить совместимость Системы с эксплуатируемыми в
АО «СО ЕЭС» средствами антивирусной защиты (установка и
функционирование Системы не должны приводить к необходимости изменения
настроек антивирусного программного обеспечения).
4.3.6.4. Требования по взаимодействию с ПАК «СОКИБ»
Компоненты Системы должны быть подключены в качестве источников
событий ИБ к Системе оперативного контроля событий ИБ АО «СО ЕЭС».
4.3.6.5. Требования
уязвимостями
по
взаимодействию
с
подсистемой
управления
Перед установкой Системы на сервера промышленной эксплуатации и/или
перед вводом Системы в промышленную эксплуатацию, может быть проведен
анализ исходного текста (кода) и сканирование Системы на наличие уязвимостей
с использованием эксплуатируемых у Заказчика средств анализа уязвимостей.
Уязвимости, актуальные для Заказчика, обнаруженные в процессе сканирования
и анализа исходного текста (кода), должны быть устранены Исполнителем перед
установкой Системы на сервера промышленной эксплуатации.
4.3.7. Требования к масштабированию
В части масштабирования Система должна обеспечивать:
− Отсутствие принципиальных ограничений на число одновременно
работающих в Системе конечных пользователей (ограничения только по составу
и характеристикам технических средств, сетевого и каналообразующего
оборудования).
− База данных Системы должна быть способна выдерживать, по крайней
мере, двукратное увеличение объема относительно объема при первоначальном
развертывании, не требуя восстановления, перекомпиляции или любой другой
обработки.
36
− Должна быть предусмотрена возможность масштабирования функций
Системы на произвольное количество серверов. Масштабирование должно
выполняться как по «горизонтали» (в рамках одного ДЦ), так и по «вертикали» (в
рамках иерархии ДУ).
4.3.8. Требования к API Системы
В Системе отсутствует программный интерфейс API.
При возникновении необходимости в его реализации программный
интерфейс API должен быть реализован в соответствии со стандартами
IEC 61968-1 и IEC 61968-100.
API Системы должен обеспечивать по запросу выдачу внешним АСДУ
любой технологической информации, хранящейся в БД Системы.
Для внешних пользователей, обладающих доступом к API Системы,
должна быть предусмотрена возможность назначения отдельной роли для
доступа к API в интерфейсе администратора Системы.
4.3.9. Требования к видам обеспечения
4.3.9.1. Требования к программному обеспечению
В случае использования при модификации Системы сторонних шаблонов
для программных платформ (framework) и/или программных библиотек должны
использоваться актуальные версии, не содержащие на момент модификации
известных уязвимостей программного кода.
При использовании сторонних компонентов, необходимо отдавать
предпочтение отечественным компонентам, включенным в Единый реестр
отечественного программного обеспечения. Система не должна содержать
платные импортные сторонние компоненты и должна быть модифицирована с
учетом рекомендаций АНО «ЦКИТ»1 . Состав бесплатных компонентов,
используемых в Системе, должен быть согласован с Заказчиком на этапе
актуализации Эскизного проекта. Список бесплатных компонентов системного и
связующего программного обеспечения должен соответствовать требованиям
актуальной версии Технологического стека программного обеспечения,
утвержденного в АО «СО ЕЭС». При выборе версии компонентов необходимо
обеспечить использование поддерживаемых версий с долгой технической
поддержкой разработчика (LTS, Long-term support).
Операционная система, под управлением которой работает Система,
должна быть стандартным продуктом и не должна модифицироваться
Исполнителем.
Системное и связующее программное обеспечение должно быть
стандартным продуктом и не должно модифицироваться Исполнителем.
Клиентские рабочие места пользователей должны функционировать под
управлением операционных систем, массово используемых в информационной
инфраструктуре Заказчика.
1
Методические рекомендации АНО "ЦКИТ" по подготовке заявок на включение ПО в Единый реестр (https://ruikt.ru/metodic#!/tab/595058081-1);
37
Там, где это возможно с точки зрения обеспечения необходимой
производительности и гибкости развёртывания Системы, должна быть
обеспечена возможность работы в виртуальной среде Заказчика с динамически
перераспределяемой вычислительной мощностью и ёмкостью для хранения
данных.
Используемые методы сбора данных о состоянии Системы должны
обеспечивать возможность работы через штатное агентское ПО,
устанавливаемое на серверы и работающее по защищенному протоколу с
инициацией соединения от агента, а также через внешний опрос по протоколу
SNMP с поддержкой версий SNMPv2C и SNMPv3.
При подготовке дистрибутива Системы, работающей под управлением
операционной системы семейства Linux, должны быть учтены следующие
требования:
1.
Дистрибутив Системы должен содержать только прикладное
программное обеспечение, в том числе необходимые для работы Системы файлы
конфигурации;
2.
При использовании в составе Системы компонентов, имеющихся в
репозитории производителя операционной системы, следует использовать их
доступные в репозитории версии.
3.
В части установки системного программного обеспечения должен
быть представлен полный список компонентов системного и связующего
программного обеспечения (включая зависимости от иных компонентов,
требующих предварительной установки и настройки). В случае использования
параметров установки системного программного обеспечения, отличных от
заданных по умолчанию, в руководстве системного администратора Системы
должен быть подробно описан процесс их установки и настройки, а также для
каждого компонента должен быть разработан и приложен пример конфигурации,
содержащий необходимые изменения в файле конфигурации «по умолчанию» с
комментариями по назначению и установленному значению для каждого
параметра;
4.
В случае необходимости для работы Системы системного ПО,
отсутствующего у Заказчика и в репозиториях ОС Astra Linux, дистрибутивы
такого ПО в формате deb пакетов должны быть предоставлены Исполнителем
для помещения в корпоративный репозиторий Заказчика, и устанавливаться
оттуда. Не допускается установка любых компонентов Системы из сети
интернет;
5.
Не допускается использование технологий контейнеризации для
системного и связующего программного обеспечения;
6.
Прикладное программное обеспечение в составе дистрибутива
Системы должно быть разработано с учетом требований актуальной версии
Технологического стека программного обеспечения, утвержденного в
АО «СО ЕЭС» (актуальная редакция Технологического стека предоставляется
Заказчиком Исполнителю);
38
7.
При модификации Системы следует разделять права системного и
прикладного администратора Системы в соответствии с актуальной версией
«Требований по разграничению прав доступа на ОС Linux», утвержденных в
АО «СО ЕЭС» (актуальная редакция Требований предоставляется Заказчиком
Исполнителю). Использование матрицы доступа обязательно начиная с момента
предварительных испытаний Системы.
8.
Дистрибутив Системы должен предоставляться в виде стандартного
инсталляционного deb пакета (пакетов, в случае необходимости разделения по
функциональному назначению) для операционной системы Astra Linux. При
подготовке инсталляционного пакета (-ов) должно быть выполнено следующее:
сформирован файл манифеста, как минимум содержащий:
i.
имя пакета;
ii.
версия пакета;
iii. зависимости от необходимых для работы прикладного
программного обеспечения пакетов (за исключением системного программного
обеспечения);
iv.
пакеты, вызывающие конфликты (программное обеспечение,
которое не должно быть установлено, в т.ч. системное);
v.
описание пакета;
vi.
описание архитектуры системы, в которой можно установить пакет;
все
необходимые
настройки
компонентов
программного
обеспечения должны выполняться скриптами установки (preinst, postinst, prerm,
postrm);
в скриптах установки Системы не допускается использование
систем управления конфигурациями SCM (Ansible, Puppet, Chef и т.д.).
9.
В случае использования для запуска прикладного программного
обеспечения Системы технологий контейнеризации (Docker) в ходе
планирования и подготовки дистрибутива должно быть выполнено следующее:
базовый
образ,
используемый
в
контейнерах,
должен
соответствовать требованиям настоящих ТТ (должен быть подготовлен на
основании разрешенной в АО «СО ЕЭС» к использованию версии ОС Linux);
образы используемых в Системе контейнеров должны собираться в
АИС «ФПА» Заказчика на основании переданных Исполнителем файлов с
инструкциями (Docker файлов) с последующим размещением собранных
образов в корпоративном репозитории Заказчика;
операции по скачиванию, обновлению образа контейнера, запуска
контейнера на выполнение должны выполняться в рамках исполнения скриптов
в составе инсталляционного deb пакета (-ов);
обновление образа контейнера должно выполняться путем
скачивания образа из корпоративного репозитория Заказчика;
10. Прикладное программное обеспечение Системы, передаваемое в
составе дистрибутива, должно создаваться путем компиляции и сборки в АИС
«ФПА» Заказчика из переданного Исполнителем Заказчику исходного текста
(кода) Системы;
39
11. В случае наличия ограничений в использовании АИС «ФПА» для
компиляции и сборки прикладного программного обеспечения дистрибутива
допускается создание дистрибутива средствами Исполнителя. При этом,
Исполнитель должен предоставить дистрибутив и исходный текст (код)
прикладного программного обеспечения на электронном носителе.
12. Детальные требования и состав дистрибутивов прикладного
программного обеспечения Системы должны быть согласованы с Заказчиком.
В случае развертывания компонентов Системы (веб-сервер / сервер
приложений / сервер БД) на отдельных серверах в состав дистрибутива Системы
должны входить инсталляционные пакеты для каждого из компонентов.
При подготовке дистрибутива Системы должна быть предусмотрена
возможность деинсталляции Системы (компонентов Системы) с учетом
технических особенностей используемой операционной системы.
При выполнении обновления Системы (компонентов Системы) должна
быть обеспечена возможность возврата к предыдущей версии Системы, а также
повторного выполнения процедуры обновления.
4.3.9.2. Требования к техническому обеспечению2
4.3.9.2.1.
Требования к видам технических средств
Исполнитель должен предоставить и согласовать с Заказчиком типовой
перечень и характеристики оборудования, необходимого для функционирования
Системы.
На этапе актуализации эскизного проекта Исполнитель должен уточнить
техническую спецификацию аппаратного обеспечения (требования к
аппаратному обеспечению), которая должна определять:
- количественный состав и характеристики серверного оборудования
для работы программного обеспечения Системы;
- требования к сетевым интерфейсам на серверном оборудовании
Системы для:
- обеспечения внутренних соединений между серверами Системы;
- интеграции с корпоративной информационной системой Заказчика;
- обеспечения требуемых характеристик по производительности;
- характеристики оборудования клиентских рабочих мест для
различных категорий пользователей.
Весь состав технических средств должен быть выбран исходя из
требований по работе Системы в виртуальной среде Заказчика. При работе
Система не должна избыточно потреблять вычислительные ресурсы в отсутствие
выполняемых задач, в особенности vCPU.
Необходимость использования физических серверов или выделенных
серверов виртуализации для размещения Системы должна быть согласована с
Заказчиком на этапе эскизного проекта.
2
Обязательный раздел (требуется для согласования со СПАК), содержание определяется исходя из
функциональных особенностей внедряемой Системы.
40
Техническая спецификация аппаратного обеспечения подлежит
согласованию с Заказчиком и может быть изменена по согласованию сторон
вплоть до завершения комплексных испытаний. Инициативу внесения
изменений может проявить как Исполнитель, так и Заказчик.
Кроме типовой части для каждого уровня диспетчерского управления
техническая спецификация аппаратного обеспечения должна включать разделы,
учитывающие особенности каждого места установки.
Требования к аппаратному обеспечению, отраженные в разработанной
технической спецификации, должны подтверждаться расчётами потребления
ресурсов и необходимого быстродействия Системы. Требования могут быть
уточнены по результатам нагрузочных испытаний.
4.3.9.2.2. Требования к сетям связи при информационном обмене
Системы
Уточнение
пропускной
способности
сети,
необходимой
для
функционирования Системы должны быть выполнены на этапе актуализации
эскизного проекта и согласованы с Заказчиком.
Пропускная способность, необходимая для функционирования Системы
не должна превышать пропускной способности локальных вычислительных
сетей и межфилиальных каналов связи Заказчика. Исполнитель при разработке
спецификации оборудования должен учитывать использование существующей
структурированной кабельной сети.
4.3.9.3. Требования к совместимости с пакетом офисных приложений
В Системе отсутствует интеграция с пакетом офисных приложений «Р7офис».
4.3.9.4. Требования к интеграции со Службой каталогов
Для Систем, размещаемых в ЛВС Заказчика, пользователями которых
будут пользователи Заказчика, рекомендуется использовать Службу каталогов
Заказчика как единый источник информации о учётных записях пользователей
Системы. При использовании Службы каталогов необходимо использовать
следующий подход для предоставления доступа к Системе:
− Пользователь входит в одну или более группы Службы каталогов;
− Группе Службы каталогов, в которой состоит пользователь,
сопоставлена роль Системы;
− Учетная запись пользователя Службы каталогов в поле «Организация»
содержит информацию о диспетчерском центре Системы, к которому
принадлежит пользователь.
Членство в группах должно считываться на момент входа пользователя в
Систему, не требуя рестарта служб Системы или иных действий для применения
изменений в членстве групп.
Для систем под управлением Linux рекомендуется использовать
аутентификацию Kerberos. Допускается использовать аутентификацию при
41
помощи LDAP bind, с использованием SSL LDAP. Клиентская часть системы или
клиентский браузер для систем с веб-интерфейсом должны передавать текущие
учётные данные Службы каталогов пользовательской сессии при помощи
технологии единого входа (Single Sign-on, SSO) прозрачно для пользователя, не
требуя ввода отдельного логина и пароля, для внутренних пользователей
Системы.
При выполнении аутентификации необходимо использовать ближайшие к
серверам Системы с точки зрения топологии сети сервера Службы каталога,
используя для обнаружения механизм сайтов Службы каталога. Допускается
ручная настройка серверов службы каталога в интерфейсе и(или) файлах
настроек Системы, при этом необходимо иметь возможность указать не менее
трёх серверов. В случае недоступности выбранного сервера Службы каталога
должно выполняться автоматическое прозрачное для работы Системы
переключение на следующий доступный.
При использовании Службы каталогов необходимо предусмотреть
автоматический выбор пользователей из всех имеющихся пространств имён
(доменов) Заказчика, либо использование сервиса глобального каталога,
содержащего подмножество атрибутов пользователей всех доменов (при
наличии).
4.3.9.5. Требования по взаимодействию с системой резервного копирования
Система должна поддерживать резервное копирование при помощи
имеющихся у Заказчика средств резервного копирования, архивирования и
восстановления, как для программного обеспечения, так и для настроек и
данных, в том числе БД, Системы. Не допускается использование скриптов
резервного копирования, выполняемых по расписанию планировщика ОС.
Система должна поддерживать создания моментального снимка
виртуальной машины, а также поддерживать резервное копирование с помощью
агента резервного копирования, внутри ОС виртуальной машины.
При использовании агента резервного копирования, Система должна
поддерживать копирование каталогов, файлов, конфигураций, БД, состояния ОС
и прочих данных.
Восстановление Системы должно быть возможным как в режиме
восстановления из моментального снимка виртуальной машины, так и в режиме
агента резервного копирования, путем восстановления агентом каталогов,
файлов, конфигураций, БД, состояния ОС и прочих данных.
Документация Системы должна предусматривать описание типового:
− списка резервируемых объектов – серверов, каталогов, файлов, БД и
т.п.;
− времени и периодичности резервного копирования;
− длительности хранения резервных копий
для учёта в Регламенте резервного копирования Системы.
42
Система должна сохранять работоспособность во время резервного
копирования и не требовать своей остановки для создания консистентной
резервной копии, данные в которой взаимно согласованы на момент
копирования.
Система должна поддерживать резервное копирование на удалённую
площадку при наличии таковой в инфраструктуре резервного копирования
Заказчика.
4.3.9.6. Требования по взаимодействию с системой электронной почты
В Системе отсутствует интеграция с системой электронной почты.
4.3.9.7. Требования по интеграции с сервисом точного времени
В Системе отсутствует интеграция с серверами точного времени.
4.3.10.
Требования к проведению нагрузочного тестирования
Нагрузочное тестирование систем, имеющих веб-интерфейс, проводится с
использованием специализированного ПО «Apache JMeter».
Для проведения тестирования Исполнителю необходимо предоставить
Заказчику следующую информацию:
− параметры, подлежащие проверке (производительность базы данных,
устойчивость к пиковым нагрузкам и т.д.);
− ключевые метрики успеха тестирования (время отклика, количество
обработанных запросов в секунду, использование ресурсов CPU/RAM,
соотношение успешных/неудачных запросов);
− разработать скрипты JMeter, которые будут использоваться для
симуляции нагрузки тестируемых сервисов.
Сценарии нагрузки (запросы) должны включать в себя типичные действия
пользователей при работе с сервисом, моделирование пиковых нагрузок
(одновременное выполнение множества однотипных операций), тестирование
аномалий (ошибки ввода данных).
Параметры тестирования:
−
−
−
−
4.3.11.
количество виртуальных пользователей;
длительность теста;
интервал между запросами;
параллельность выполнения запросов.
Требования к журналированию
4.3.11.1.Общие требования
Система должна обеспечивать формирование событий в подсистеме
журналирования при каждом изменении состояния в соответствии с
необходимым уровнем детализации передаваемой информации по каждому из
регистрируемых событий.
43
В системе должна быть обеспечена возможность журналирования всех
типов возникающих в Системе и ее подсистемах значимых событий, а также
действий пользователей, в соответствии с требуемой настройкой уровня
детализацией журнала Системы, определяемой уровнем серьезности
регистрируемого события – INFO, DEBUG и т.д.
В системе должна быть реализована возможность переключения уровней
детализации журналов Системы и ее подсистем без необходимости вывода из
работы Системы полностью либо ее отдельных подсистем (в том числе без
ручного перезапуска Системы и ее подсистем).
Формирование журналов Системы, вне зависимости от степени их
детализации и уровня серьезности сообщений в их составе, не должно приводить
к деградации производительности Системы.
4.3.11.2.Требования к хранению и форматам сообщений
Предпочтительный формат хранения журналов Системы и ее подсистем –
текстовый файл (файл формата *. json, при необходимости). Допускается
использовать краткие идентификаторы Системы и ее подсистем в именах файлов
журналов Системы с опциональным добавлением иных меток (дата, числовой
идентификатор номера файла при ограничении на его размер в рамках
выбранной модели ротации и т.д.).
Система должна предусматривать ведение журналов для каждой из
подсистем с учетом общих требований к хранению и форматам сообщений. При
использовании в Системе решений по контейнеризации, журналы сообщений
должны формироваться для каждого из контейнеров с последующим их
сохранением на сервере.
В Системе должны быть предусмотрены механизмы ротации журналов
Системы, определяющие размер, период хранения, а также глубину хранения
информации в файлах журнала (допускается использование стандартных
программ по работе с архивами, а также средств, реализующих ротацию
текстовых файлов, доступных в рамках стандартного программного обеспечения
для ОС).
В общем случае журнал Системы должен включать, как минимум, но не
ограничиваясь, следующие поля:
 дата и метка времени события;
 уровень серьезности сообщения (INFO, DEBUG, ERROR и т.д.);
 сообщение, определяющие событие, которое было зарегистрировано;
 опциональные поля, значимые в рамках выбранной Системы
(идентификатор события, идентификатор пользователя, детальный
контекст события, утилизация ресурсов, идентификаторы зависимых
подсистем и т.д.).
Размещение файлов логов должно производиться в директории,
определяемой конфигурацией приложения. Запрещается запись прикладных
журналов Системы:
44
 в системные журналы операционной системы (/var/log системного
уровня, такие как syslog, daemon.log);
 на системный диск (раздел, на котором установлена ОС), если в
составе сервера предусмотрен отдельный диск (раздел) для
размещения прикладного ПО и данных. В этом случае логи должны
размещаться на выделенном несистемном разделе.
45
5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО МОДИФИКАЦИИ СИСТЕМЫ
5.1.
Общие положения
Состав требований к способам и результатам Работ по модификации
Системы определяется Заказчиком, посредством направления Исполнителю и
утверждения доработанных Исполнителем заявок.
Работы по модификации Системы должны быть выполнены в соответствии
с п. 5.2.2 настоящих ТТ и на основании утвержденных Заявок.
По второй и последующим утвержденным Заявкам на модификацию
Системы Исполнитель должен предоставить Заказчику соответствующий
требованиям п. 4.3.9.1 настоящих ТТ кумулятивный дистрибутив
модифицированной Системы (включая инсталляционный пакет, файлы
необходимые для создания дистрибутива (сторонние библиотеки, скрипты и
т.д.), содержащий все изменения, в т.ч. по ранее принятым Заказчиком
результатам Работ по модификации Системы по утвержденным Заявкам,
прошедший предварительные испытания, исходный текст (код) и полный
комплект документации согласно пп. 7.1.3-7.1.5 настоящих ТТ. Указанный
кумулятивный дистрибутив модифицированной Системы также должен быть
создан Исполнителем в АИС «ФПА» Заказчика.
5.2.
Обязанности Заказчика и Исполнителя
5.2.1. Обязанности Заказчика
1. Предоставление Исполнителю заявок на модификацию Системы;
2. Утверждение доработанных Исполнителем заявок, включая Оценку
трудозатрат;
3. Утверждение
актуализированного
Исполнителем
ЭП
на
модифицированную Систему по первой утвержденной Заявке в соответствии
разделом 7 настоящих ТТ;
4. Рассмотрение и согласование разработанной и актуализированной
Исполнителем документации (за исключением ЭП) на модифицированную
Систему по второй и последующим утвержденным Заявкам в соответствии
разделом 7 настоящих ТТ;
5. Предоставление информации, при необходимости документации,
подробных описаний интерфейсов взаимодействия модифицированной Системы
с другими системами, находящимися в составе ИТ-инфраструктуры Заказчика;
6. Фиксирование замечаний к модифицированной Системе, выявленных в
ходе внедрения, информирование о них Исполнителя и контроль устранения
выявленных замечаний;
7. Контроль соблюдения Исполнителем сроков выполнения работ по
каждой утвержденной Заявке;
8. Консультирование Исполнителя по настройке процессов компиляции,
сборки Системы в АИС «ФПА»;
46
9. Предоставление Исполнителю защищенного удаленного доступа
(далее – ЗУД) к своим корпоративным ресурсам в соответствии с установленной
процедурой Заказчика.
Заказчик вправе осуществлять мониторинг, контроль, запись действий
Исполнителя (процессов, запускаемых от имени Исполнителя), осуществляемых
через ЗУД.
В случае выявления подозрительной активности со стороны Исполнителя
Заказчик вправе приостановить доступ Исполнителя к своим корпоративным
ресурсам и/или Системе, до выяснения причин и нейтрализации факторов
подозрительной активности.
5.2.2. Обязанности Исполнителя
1. Актуализация и предоставление на утверждение Заказчику
актуализированного ЭП;
2. Анализ состава и объема работ, содержащегося в заявках на
модификацию Системы, полученных от Заказчика;
3. Доработка и предоставление Заказчику на утверждение заявок, включая
Оценку трудозатрат, подготовленную по форме Приложения № 3 к Договору, и
сроки выполнения работ по каждой утвержденной Заявке;
4. Планирование, организация, координирование и контроль хода
выполнения работ специалистами Исполнителя по каждой утвержденной Заявке;
5. Разработка, актуализация и предоставление на рассмотрение и
согласование Заказчику разработанной и актуализированной Исполнителем
документации (за исключением ЭП) на модифицированную Систему по второй и
последующим утвержденным Заявкам в соответствии с разделом 7 настоящих
ТТ;
6. Выполнение необходимых работ по модификации Системы:
 модификация Системы в соответствии с утвержденными Заявками;
 проведение регулярного инспектирования кода;
 организация
регулярных
промежуточных
демонстраций
функционально законченных частей модифицированной Системы с
целью контроля Заказчиком правильности выбранного решения;
 устранение
замечаний
Заказчика
к
документации
и
модифицированной Системе в рамках работ по модификации
Системы;
7. Разработка и предоставление на согласование Заказчику прототипов
экранных форм отображения Системы.
8. Устранение замечаний к документации и модифицированной Системе,
выявленных Заказчиком в рамках предварительных испытаний, выполнения
работ, необходимых для осуществления внедрения модифицированной
Системы, и в течение гарантийного срока в соответствии с условиями Договора.
9. Использование при выполнении работ специализированных средств:
 управления проектами разработки ПО;
 хранения и контроля версий кода;
47




рецензирования кода;
ведения проектной документации;
нагрузочного тестирования;
нефункционального тестирования.
10. Проведение испытаний компонентов, подсистем, предварительных
испытаний модифицированной Системы и обеспечение присутствия на них
представителей Заказчика.
11. Предоставление по требованию Заказчика и в согласованные с ним
сроки информации по выполняемым работам по каждой утвержденной Заявке.
12. Предоставление Заказчику по второй и последующим утвержденным
Заявкам соответствующего требованиям пп. 4.3.9.1, 5.1 настоящих ТТ
дистрибутива (включая инсталляционный пакет), исходного текста (кода) и
прочих файлов, необходимых для создания дистрибутива (сторонние
библиотеки, скрипты и т.д.) модифицированной по утвержденной Заявке
Системы, с комплектом документов, указанных в пп. 7.1.3-7.1.5 настоящих ТТ.
13. Настройка процесса компиляции и сборки дистрибутива
модифицированной Системы с использованием АИС «ФПА».
14. Создание дистрибутива модифицированной Системы путём
компиляции и сборки в АИС «ФПА» Заказчика.
15. Для технической возможности предоставления ЗУД Исполнитель
обязан:
 Предоставить отчуждаемые носители ключевой информации в
удостоверяющий центр Заказчика вместе с заявлением на
регистрацию субъекта информационного обмена и заявлением на
получение ключа и сертификата ключа проверки электронной
подписи в соответствии с «Соглашением об использовании
субъектом информационного обмена электронной подписи при
информационном обмене с АО «СО ЕЭС» (с юридическим лицом)»,
заключенным с Заказчиком по форме, утвержденной Заказчиком;
 Иметь установленное клиентское программное обеспечение,
предназначенное для создания защищенного соединения с
корпоративной информационной системой Заказчика. Клиентское
программное обеспечение Исполнителя должно быть совместимо с
эксплуатируемыми у Заказчика средствами криптографической
защиты информации, используемыми для организации ЗУД;
 Незамедлительно предоставлять по требованию Заказчика
материалы и объяснения, связанные с выявленной подозрительной
активностью в отношении корпоративных ресурсов Заказчика и/или
Системы, исходящей из информационной инфраструктуры или от
работников Исполнителя.
16. Выполнение работ, необходимых для осуществления внедрения
модифицированной Системы, на испытательных стендах Заказчика (удаленно
средствами ЗУД), в том числе: участие в установке и настройке, проведении
тестирования модифицированной Системы, оперативное исправление ошибок,
48
выявленных по результатам тестирования, и в случае необходимости проведение
повторных предварительных испытаний и участие в повторном тестировании
модифицированной Системы на испытательных стендах Заказчика.
17. Работы, необходимые для внедрения модифицированной Системы,
выполняются в соответствии с Положением о вводе в эксплуатацию и выводе из
эксплуатации информационно-управляющих систем и инфраструктурных
программно-аппаратных комплексов в АО «СО ЕЭС», утвержденным приказом
АО «СО ЕЭС» от 02.10.2019 № 291.
18. Консультирование персонала Заказчика на всех этапах внедрения
модифицированной Системы по вопросам использования модифицированных
компонентов Системы. В ходе консультации должны быть даны ответы на все
вопросы Заказчика относительно работы с модифицированной Системой.
19. Обеспечение соответствия требованиям функциональности и
безопасности работы в среде Системы интегрируемого программного
обеспечения, разработанного третьей стороной, или стандартного программного
обеспечения, предоставляемого Исполнителем.
20. Согласование с Заказчиком необходимости использования при
модификации
Системы
охраняемых
результатов
интеллектуальной
деятельности, принадлежащих третьим лицам, и правовые основания
приобретения прав на их использование.
21. Выполнение требований к обеспечению кадровыми ресурсами,
указанными в п. 4.1 настоящих ТТ.
5.3.
Демонстрация промежуточных результатов работ
В ходе модификации основной функциональности должны проводиться
регулярные демонстрации реализованного функционала и разработанной и
актуализированной документации Заказчику.
Частота демонстраций согласовывается с Заказчиком, но не реже 1 раза в
месяц.
По запросу Заказчика на демонстрации Исполнитель должен представить
отчеты по выполняемым работам.
Сценарий демонстрации, список и состав отчетов согласовывается с
Заказчиком заблаговременно.
49
6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ
6.1.
Виды, состав, объем и методы испытаний Системы и её составных
частей
6.1.1. Виды испытаний
Внедрение Системы должно осуществляться в соответствии с
требованиями Договора и Положения о вводе в эксплуатацию и выводе из
эксплуатации информационно-управляющих систем и инфраструктурных
программно-аппаратных комплексов в АО «СО ЕЭС», утвержденного приказом
АО «СО ЕЭС» от 02.10.2019 № 291.
По итогам выполнения работ по второй и последующим утвержденным
Заявкам должны проводиться следующие виды испытаний:
- предварительные испытания модифицированной Системы на
испытательных стендах Исполнителя или Заказчика;
- тестирование модифицированной Системы на испытательных стендах
Заказчика.
6.1.2. Состав, объем и методы испытаний
Состав, объем и методы испытаний модифицированной Системы должны
быть установлены исходя из цели подтверждения соответствия
модифицированной Системы требованиям настоящих ТТ.
6.1.2.1. Предварительные испытания
Предварительные испытания служат для проверки корректности
функционирования Системы перед проведением тестирования у Заказчика.
Предварительные испытания должны проводиться на испытательных
стендах Исполнителя и при необходимости на испытательных стендах
Заказчика.
Предварительные испытания по второй и последующим утвержденным
Заявкам должны проводиться в соответствии с программой и методикой
испытаний. Во время предварительных испытаний должны быть проведены
тесты, разработанные Исполнителем, которые интенсивно используют все
функции и компоненты модифицированной Системы как индивидуально, так и
совместно, при этом должна проверяться правильность функционирования
модифицированной Системы.
Исполнитель не позднее, чем за две недели уведомляет Заказчика о сроках
проведения предварительных испытаний и обеспечивает участие в
предварительных испытаниях представителей Заказчика.
Заказчик вправе потребовать демонстрацию предварительных испытаний
на испытательных стендах Исполнителя или Заказчика с использованием ЗУД.
В
ходе
предварительных
испытаний
оформляется
протокол
предварительных испытаний, в который должны быть включены следующие
позиции:
- версия модифицированной Системы, проходившая испытания;
50
- дата проведения испытаний;
- место проведения испытаний;
- участники испытаний;
- результаты испытаний:
- характеристики и функции, проходившие испытания;
- фактические результаты испытаний.
- общий итог испытаний, выводы.
Протокол предварительных испытаний должен быть подписан
Исполнителем и представителями Заказчика, если они участвовали в
предварительных испытаниях.
При положительном окончании предварительных испытаний должен быть
подписан акт готовности модифицированной Системы к процедуре внедрения в
АО «СО ЕЭС».
В акте готовности модифицированной Системы к процедуре внедрения в
АО «СО ЕЭС» указываются результаты предварительных испытаний, версия
модифицированной Системы, проходившая испытания и степень готовности
Системы к внедрению в АО «СО ЕЭС».
Акт готовности модифицированной Системы к процедуре внедрения в
АО «СО ЕЭС» утверждается Исполнителем.
Заказчик имеет право в любой момент приостановить предварительные
испытания, если сочтет, что количество или серьезность замечаний оправдывают
такую приостановку. В этом случае предварительные испытания должны быть
остановлены, должна быть проведена работа по устранению замечаний, после
чего предварительные испытания должны быть проведены повторно. Повторные
предварительные испытания должны быть запланированы на срок,
согласованный Исполнителем и Заказчиком.
Предварительные испытания проводятся повторно с оформлением
соответствующих документов после создания в АИС «ФПА» Заказчика
дистрибутивов модифицированной Системы, в т.ч. обновлений, содержащих
исправление ошибок.
6.1.2.2. Установка и настройка
Установка и настройка модифицированной Системы, выполненные
ответственными представителями Заказчика с участием Исполнителя, должны
считаться законченными, если они осуществились в соответствии с
документацией по установке и настройке, предоставляемой Исполнителем.
6.1.2.3. Тестирование
Тестирование модифицированной Системы должно проводиться с целью
определения
правильности
функционирования
всех
компонентов
модифицированной Системы.
Тестирование по второй и последующим утвержденным Заявкам должно
проводиться на испытательных стендах Заказчика в соответствии с
согласованной Заказчиком программой и методикой испытаний.
51
В ходе тестирования необходимо обеспечить проверку выполнения всех
функций модифицированной Системы во всех режимах функционирования.
Скрипты, предоставляемые Исполнителем для проведения нагрузочного
тестирования, должны быть реализованы с помощью согласованного с
Заказчиком средства автоматизации.
Объем и детальность тестирования, выполняемого с помощью скриптов,
должны быть уточнены в процессе модификации Системы.
По результатам тестирования модифицированной Системы Заказчик
оформляет Протокол тестирования, который содержит заключение о готовности
модифицированной Системы к внедрению у Заказчика или о выявленных
замечаниях. При выявлении замечаний, препятствующих внедрению,
Исполнитель в установленные Заказчиком сроки устраняет замечания и
проводит повторные предварительные испытания с оформлением протокола
предварительных испытаний и акта готовности модифицированной Системы к
процедуре внедрения в АО «СО ЕЭС».
6.1.3. Регистрация и устранение замечаний
Все замечания, выявленные в ходе внедрения, должны регистрироваться в
виде обращений в Автоматизированной системе учета заявок Заказчика (далее –
АСУЗ).
Замечаниями, являются любые несоответствия настоящим Техническим
требованиям, выявленные в ходе предварительных испытаний и тестирования
модифицированной Системы.
Заказчик на основании журнала обращений в АСУЗ за период внедрения
должен формировать перечень замечаний, который должен являться
приложением к протоколу тестирования. В перечне замечаний должны быть
зафиксированы номера обращений в АСУЗ.
Замечание должно считаться устраненным Исполнителем, если Заказчик
подтвердил его устранение.
Перед тем, как передать устраненное замечание для принятия Заказчиком,
Исполнитель должен предпринять все необходимые шаги для того, чтобы
убедиться, что замечания действительно устранены.
52
7. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
7.1.
Перечень подлежащих разработке и актуализации документов
Исполнителем должен быть предоставлен как минимум следующий состав
документации:
- Заявки на модификацию Системы, утвержденные Заказчиком;
- Актуализированный Эскизный проект;
- Актуализированная
эксплуатационная
документация
на
модифицированную Систему в составе:
 Общее описание Системы;
 Руководство пользователя;
 Руководство администратора;
 Руководство системного администратора;
- Программа и методика испытаний;
- Комплект документов при передаче дистрибутивов в составе:
 Протокол предварительных испытаний и Акт готовности
Системы к процедуре внедрения в АО «СО ЕЭС»;
 Инструкция по установке и настройке Системы;
 Перечень внесенных изменений (в случае обновления или
изменения версии Системы);
 Матрица доступа.
Документация на Систему должна быть подготовлена на основе шаблонов,
предоставляемых Заказчиком.
7.1.1. Заявки
Состав Работ по модификации Системы, подлежащих выполнению
Исполнителем, требования Заказчика к способам и результатам выполнения
Работ по модификации Системы, ориентировочные сроки выполнения Работ по
модификации Системы, оценка трудозатрат на выполнение Работ по заявке и
цели выполнения Работ по модификации Системы определяются Заказчиком в
предоставленной Исполнителю заявке (далее – заявка).
Заявка дорабатывается Исполнителем в сроки, указанные в Договоре,
путем детального анализа требований Заказчика к способам и результатам
выполнения Работ по модификации Системы. В доработанную заявку
Исполнителем должно быть включено детальное содержание функционального
описания Системы в части модифицируемых компонентов, включая подробное
описание реализуемых или модифицируемых функций, при необходимости,
определяемой Заказчиком, с алгоритмами, а также оценка трудозатрат на
выполнение Работ по заявке, сроки выполнения Работ. Доработанная
Исполнителем заявка должна содержать достаточно информации, чтобы
Заказчик мог определить, отвечает ли описанная новая функциональность
Системы требованиям Заказчика к способам и результатам выполнения Работ по
модификации Системы.
53
Доработанная Исполнителем заявка направляется на утверждение
Заказчику в порядке и в сроки, предусмотренные Договором.
С момента утверждения заявки Заказчиком она становится неотъемлемой
частью Договора.
В утвержденной Заявке должны быть указаны: требования Заказчика к
способам и результатам выполнения Работ по модификации Системы, цели
выполнения Работ по модификации Системы, наименование, содержание и
объемы выполнения Работ, сроки их выполнения, стоимость Работ в
соответствии с согласованной Сторонами Оценкой трудозатрат, а также иные
сведения, предусмотренные в настоящем пункте ТТ.
7.1.2. Актуализированный эскизный проект
Эскизный проект на модификацию Системы должен быть актуализирован
Исполнителем по первой утвержденной Заявке.
Актуализированный ЭП должен быть представлен в виде пояснительной
записки, содержащей функциональное и техническое описание программного
обеспечения, а также информацию, необходимую для модификации
программного обеспечения, как минимум включающей:
- описание функциональных компонентов программного обеспечения
Системы, в том числе включающих описание инфраструктурных,
системных, функциональных и других ограничений, которые
должны быть учтены при реализации компонентов Системы;
- структурную схему Системы, включающую в себя взаимосвязи
между компонентами в Составе модифицируемой Системы;
- описание интеграции в внешними технологическими ИУС;
- описание интеграции с инфраструктурными ИУС;
- требования к комплексу технических средств, включающие:
 требования к аппаратному обеспечению с методикой оценки
запрошенных ресурсов;
 требования к сетевой инфраструктуре;
- описание программного обеспечения модифицируемой Системы, в
том числе поддерживаемых ОС;
- описание
дистрибутива
Системы
(формат
и
состав
инсталляционного пакета);
- описание подходов и технологий, используемых при реализации
функциональных компонентов;
- описание реализуемых интерфейсов взаимодействия со смежными
системами, состав функций, предоставляемых и используемых
интерфейсами Системы.
Актуализированный Эскизный проект должен быть представлен на
утверждение Заказчику.
54
7.1.3. Актуализированная эксплуатационная документация на Систему
7.1.3.1. Общее описание Системы
Общее описание Системы является кратким функциональным и
техническим описанием программного обеспечения и должно содержать
следующие разделы:
- общая информация о Системе (наименование, сведения об
организации Заказчика и Исполнителя, основание для выполнения
работ и т.д.);
- назначение Системы (описание деловых процессов СО, которые
автоматизированы с помощью Системы);
- технические требования к функционированию Системы;
- описание Системы (платформа, структурная схема, функциональная
схема с кратким описанием разделов, сервисов, приложений, СУБД
и других компонентов);
- принципы/алгоритмы работы, основные функции Системы;
- описание взаимосвязей Системы с другими системами,
находящимися в составе ИТ-инфраструктуры Заказчика.
7.1.3.2. Руководство пользователя
Руководство пользователя должно содержать инструкции по
эксплуатации, касающиеся всех функциональных возможностей и включать в
себя описание всех функций Системы.
Руководство пользователя должно быть организовано таким образом,
чтобы обеспечить быстрый доступ к подробному описанию пользовательских
процедур, используемых для взаимодействия с функциями Системы. Для
обеспечения быстрого доступа к описанию пользовательских процедур должна
быть использована удобная навигация внутри документа посредством ссылок на
нужные разделы.
Руководство пользователя должно содержать в сжатом виде всю
информацию, необходимую пользователю для эксплуатации Системы.
Уровень детализации описания Системы должен позволять пользователю
обнаруживать и устранять проблемы, возникающие при работе с Системой.
В Руководстве пользователя должны быть описаны рекомендуемые меры
по устранению ошибок, в случае их возникновения.
7.1.3.3. Руководство администратора
Руководство администратора должно описывать только работы
прикладных администраторов, осуществляемые в процессе эксплуатации
Системы. Документ должен представлять собой полное руководство по
администрированию Системы в штатном режиме работы, а также рекомендации
по устранению сбоев в работе ПО.
Руководство администратора должно содержать следующие основные
разделы:
55
-
администрирование Системы;
указания о действиях в разных режимах работы Системы;
описание ролевой модели Системы;
описание процедур по изменению паролей и сервисных учетных
записей.
7.1.3.4. Руководство системного администратора
Руководство системного администратора должно описывать действия
системного администратора, которые осуществляются в процессе подготовки
серверов перед установкой прикладного ПО (в случае отличия от типовых
действий «по умолчанию», выполняемых при подготовке серверов, установке и
настройке соответствующего системного и связующего ПО, включая
рекомендации по обслуживанию и обновлению системного ПО (при
необходимости).
Руководство системного администратора должно включать как минимум
следующие разделы:
1) Основные требования к аппаратному обеспечению серверов, клиентских
ЭВМ для установки программного обеспечения Системы;
2) Требования к системному и связующему программному обеспечению
серверов, клиентских ЭВМ для установки программного обеспечения
Системы;
3) Рекомендации по настройке взаимодействия Системы с внешними
инфраструктурными системами;
4) Рекомендации по настройке резервного копирования и восстановление
файлов Системы;
5) Необходимые регламентные операции по системному и связующему ПО
(при необходимости).
7.1.4. Программа и методика испытаний
Программа и методика испытаний должна быть разработана
Исполнителем с учётом требований Положения о вводе в эксплуатацию и выводе
из эксплуатации информационно-управляющих систем и инфраструктурных
программно-аппаратных комплексов в АО «СО ЕЭС» от 02.10.2019 № 291.
Программа и методика испытаний должна отражать проверку всех
требований к Системе, описанных в настоящих ТТ, включая выполнение
нагрузочного тестирования, а также проверку выявленных и устраненных
дефектов, и проверку модифицируемых и ключевых немодифицируемых
функций Системы (регрессионное тестирование).
Программа и методика испытаний должна быть разработана до начала
проведения предварительных испытаний модифицированной Системы по
второй утвержденной Заявке. Программа и методика испытаний должна
актуализироваться с учетом выполнения модификации Системы до начала
проведения предварительных испытаний модифицированной Системы по
последующим утвержденным Заявкам.
56
Программа и методика испытаний после разработки и актуализации
должна быть представлена на согласование Заказчику.
7.1.5. Комплект документов при передаче дистрибутива
7.1.5.1. Протокол предварительных испытаний
Документ должен предоставляться Исполнителем при передаче каждого
дистрибутива в соответствии с требованиями раздела 6.1.2.1 настоящих ТТ.
7.1.5.2. Акт готовности Системы к процедуре внедрения в АО «СО ЕЭС»
Документ должен предоставляться Исполнителем при передаче каждого
дистрибутива в соответствии с требованиями раздела 6.1.2.1 настоящих ТТ.
7.1.5.3. Инструкция по установке и настройке Системы
Документ должен предоставляться Исполнителем при передаче каждого
дистрибутива, как при модификации Системы, так и при любом обновлении
Системы. В документе должен быть указан номер версии Системы.
В инструкции по установке и настройке должен быть описан процесс
установки дистрибутива Системы на полигонные и основные серверы.
В инструкции по установке и настройке должны быть включены
следующие позиции:
- Описание состава дистрибутива установки;
- Требования к системному и связующему программному
обеспечению серверов, клиентских ЭВМ для установки
программного обеспечения Системы (при отсутствии данного
раздела в составе Руководства системного администратора);
- Порядок установки и настройки системного и связующего ПО (в
случае отличия от типовых действий установки и настройки
соответствующего ПО «по умолчанию» и при отсутствии данного
раздела в составе Руководства системного администратора);
- Дополнительные настройки интеграционного окружения (создание
сервисных учетных записей, предоставление прав и т.д.);
- Указания по настройке параметров ротации логов - максимальный
размер файла, количество хранимых архивов, периодичность смены
файлов и т.п - обеспечивающие предотвращение бесконтрольного
разрастания журналов и заполнения дискового пространства.
- Описание процесса необходимых предварительных работ по
загрузке НСИ и данных для функционирования Системы.
- Настройка интеграции модифицированной Системы с другими
системами, находящимися в составе ИТ-инфраструктуры Заказчика,
из которых осуществляется загрузка информации;
- Проверка работоспособности основной функциональности;
- Откат к предыдущей версии;
- Удаление модифицированной Системы.
57
7.1.5.4. Перечень внесенных изменений
Документ должен предоставляться Исполнителем в случае любого
обновления или изменения Системы. В документе должен быть указан номер
версии Системы, должны содержаться подписи ответственных.
В перечень внесенных изменений должны быть включены следующие
позиции:
- описание новых функций и улучшений;
- описание измененных компонентов;
- перечень используемых сторонних программных модулей и
библиотек с указанием номеров версий и даты их выпуска.
В описании новых функций и улучшений должны отражаться основные
действия по замене (модификации) существующих функций или добавлению
новых, с указанием пункта настоящих ТТ.
В описании измененных компонентов должны отражаться модули,
подвергнутые изменениям, с указанием соответствующей версии Системы.
7.1.5.5. Матрица доступа
Матрица доступа подготавливается при условии работы Системы под
управлением ОС Linux. Матрица доступа должна содержать минимально
необходимые права для каждого процесса, пользователя или программы к
информации (каталогам, файлам и т.д.), ресурсам и командам на серверах
Системы в соответствии с «Требованиями по разграничению прав доступа на ОС
Linux».
Система
должна
модифицироваться
таким
образом,
чтобы
администраторам Системы и учётным записям серверных процессов Системы
(например: веб сервер, СУБД, специализированное ПО и др.) не требовались
права администратора ОС (root, wheel, adm, astra-admins и т.д.) для выполнения
своих функций. Список необходимых прав на каталоги, файлы, команды sudo и
т.п. вместе с назначением этих прав формирует матрицу доступа и
предоставляется в составе документации Системы.
7.2.
Формат документации
Документация должна быть предоставлена на русском языке.
Документация на рассмотрение, согласование и утверждение должна
предоставляться в электронном виде в формате, который может редактироваться
Заказчиком и соответствовать требованиям оформления, принятым у Заказчика
для оформления технической и проектной документации.
Рассмотренная,
согласованная
и
утвержденная
документация
предоставляется Заказчику в форматах, принятых у Заказчика для оформления
технической и проектной документации. Документация должна быть
отформатирована для печати на бумаге формата A4.
58
7.3.
Исходный текст (код)
Каждый раз при передаче дистрибутивов модифицированной Системы
Исполнитель должен предоставлять исходный текст (код) Системы в АИС
«ФПА» Заказчика, в которой Исполнителем и должно производиться создание
дистрибутивов Системы.
Совместно с исходным текстом (кодом) Системы должны предоставляться
инструкции по созданию дистрибутивов Системы в АИС «ФПА» Заказчика и
прочие файлы, необходимые для создания дистрибутивов (сторонние
библиотеки, скрипты и т.д.). Инструкция по созданию дистрибутивов Системы
должна содержать всю необходимую информацию для того, чтобы Заказчик мог
самостоятельно повторить процедуру создания дистрибутивов Системы из
предоставленного исходного текста (кода) Системы.
59
8. НОРМАТИВНЫЕ ДОКУМЕНТЫ, РЕГУЛИРУЮЩИЕ ВЫПОЛНЕНИЕ
РАБОТ ПО МОДИФИКАЦИИ СИСТЕМЫ
Нормативные документы, регламентирующие выполнение работ по
модификации Системы:
1.
Приказ АО «СО ЕЭС» от 14.03.2023 № 73 «О применении
национального стандарта по терминологии».
2.
ГОСТ Р 57114-2022
«Национальный
стандарт
Российской
Федерации. Единая энергетическая система и изолированно работающие
энергосистемы. Электроэнергетические системы. Оперативно-диспетчерское
управление в электроэнергетике и оперативно-технологическое управление.
Термины и определения».
3.
Положение о вводе в эксплуатацию и выводе из эксплуатации
информационно-управляющих систем и инфраструктурных программноаппаратных комплексов в АО «СО ЕЭС», утвержденное приказом АО «СО ЕЭС»
от 02.10.2019 № 291.
4.
ГОСТ 34.201-2020
«Межгосударственный
стандарт.
Информационные технологии. Комплекс стандартов на автоматизированные
системы. Виды, комплектность и обозначение документов при создании
автоматизированных систем».
5.
Актуальная версия Технологического стека программного
обеспечения, утвержденного в АО «СО ЕЭС».
6.
Актуальная версия Требований по разграничению прав доступа на
ОС Linux, утвержденная в АО «СО ЕЭС».
При наличии таковых на момент модификации Системы должны
применяться последние изменения к версиям применимых документов.

=== ФАЙЛ: Приложение 2 к КД Модификация КПА_НМЦ(38955875_256_06_10_2026).docx | docs/32616441078/Приложение 2 к КД Модификация КПА_НМЦ(38955875_256_06_10_2026).pdf
Приложение № 2
к Конкурсной документации по конкурсу в электронной форме на право
заключения договора на выполнение работ по модификации программы для
ЭВМ «Конструктор логических моделей/схем противоаварийной
автоматики»
Обоснование начальной (максимальной) цены Договора
Наименование закупки (предмет договора)
Выполнение работ по модификации программы для ЭВМ «Конструктор
логических моделей/схем противоаварийной автоматики»
Используемый метод определения НМЦ
Метод сопоставимых рыночных цен (анализ рынка)
Величина НМЦ
19 864 550 (Девятнадцать миллионов восемьсот шестьдесят четыре тысячи пятьсот
пятьдесят) рублей 00 копеек без учета НДС
Расчет НМЦ
Приложение 3 к Методическим указаниям, Таблица 1 настоящего Приложения
Таблица 1. Расчет НМЦ методом сопоставимых рыночных цен
(анализа рынка)
Цена закупки, руб. без НДС с учетом коэффициента дефлятора
Наименование закупки
Наименование
поставщика 1,
источник информации
Наименование
поставщика 2,
источник информации
Наименование
поставщика 3,
источник информации
Минимальное
значение цены
НМЦ, руб. без НДС
1
2
19 864 550,00
ООО «Сэлф Софт
Продакшн»,
коммерческое
предложение
3
4
5
6
22 283 352,00
ООО «ОРБСОФТ»,
коммерческое
предложение
25 532 211,60
ООО «СМАРТА»,
коммерческое
предложение
19 864 550,00
19 864 550,00
Выполнение работ
по модификации программы для ЭВМ
«Конструктор логических моделей/схем
противоаварийной автоматики»

=== ФАЙЛ: Приложение 1_к ТТ Модификация КПА(38958262_256_06_10_2026).docx | docs/32616441078/Приложение 1_к ТТ Модификация КПА(38958262_256_06_10_2026).pdf
Приложение № 1
к Техническим требованиям
Приложение № 1
к Конкурсной документации по конкурсу в
электронной форме на право
заключения договора на выполнение работ по
модификации программы для ЭВМ «Конструктор
логических моделей/схем противоаварийной
автоматики»
ЭСКИЗНЫЙ ПРОЕКТ
на выполнение работ по созданию программы для ЭВМ
«Универсальный конструктор моделей устройств (функций)
противоаварийной автоматики»
Москва 2026
2
СОДЕРЖАНИЕ
1.
ПЕРЕЧЕНЬ ОПРЕДЕЛЕНИЙ И СОКРАЩЕНИЙ...........................................4
2.
ВВЕДЕНИЕ............................................................................................................... 6
3.
ОБЩАЯ СТРУКТУРА СИСТЕМЫ.....................................................................7
3.1. Наименование Системы................................................................................................. 7
3.2. Назначение Системы.......................................................................................................7
3.3. Цель разработки Системы............................................................................................. 7
3.4. Перечень диспетчерских центров АО «СО ЕЭС», в которых предполагается
использовать Систему............................................................................................................7
3.5. Характеристика объекта автоматизации....................................................................7
3.5.1. Структура системы Конструктор ПА.......................................................................8
3.5.2. Описание структуры Системы.................................................................................10
4.
КОМПЛЕКС ТЕХНИЧЕСКИХ СРЕДСТВ.......................................................11
4.1. Архитектура.................................................................................................................... 11
4.1.1. Отказоустойчивость...................................................................................................11
4.1.2. Масштабирование.......................................................................................................12
4.1.3. Пользовательский интерфейс..................................................................................12
4.2. Аппаратные ресурсы..................................................................................................... 13
4.2.1. Сервер приложений.................................................................................................... 13
4.2.2. Сервер БД.....................................................................................................................14
4.2.3. Программное обеспечение для эксплуатации системы.......................................15
4.2.4. Рабочие станции.......................................................................................................... 15
5.
ИНТЕГРАЦИЯ С ИНФРАСТРУКТУРОЙ СО................................................16
5.1.
Взаимодействие с системой мониторинга.........................................................16
5.2.
Взаимодействие с системой резервного копирования....................................16
5.3.
Интеграция с Active Directory (AD)....................................................................16
5.4.
Серверные ресурсы................................................................................................17
6.
ИНТЕГРАЦИЯ С ВНЕШНИМИ СИСТЕМАМИ............................................18
6.1.
Интеграция с ИУС АО «СО ЕЭС»......................................................................18
6.2.
Требования к статусу экспортируемых/импортируемых устройств ПА....19
6.3.
Требования к API обмена информацией об устройствах ПА........................19
6.4.
Требования к аутентификации API устройств ПА.........................................19
6.5.
Требования к способу информационного обмена............................................20
6.6.
ОИК СК-11.............................................................................................................. 20
6.6.1.
Способы информационного взаимодействия...................................................20
6.6.2.
Публичное API СК-11............................................................................................21
6.6.3.
SOAP веб-сервисы..................................................................................................22
6.6.4.
Настройки взаимодействия.................................................................................22
6.6.5.
Сценарии взаимодействия...................................................................................23
6.6.6.
Состав данных........................................................................................................23
7.
АНАЛИЗ ПРИМЕНИМОСТИ МОДЕЛИ ПА В СОСТАВЕ СТАНДАРТОВ МЭК
61970 26
8.
АНАЛИЗ ПРИМЕНИМОСТИ БЛОКОВ ПА В СОСТАВЕ СУЩЕСТВУЮЩИХ
ИУС АО «СО ЕЭС»...............................................................................................................27
8.1.
Анализ блоков ПА, используемых в СМФУ ПА.............................................27
8.1.1.
Пусковой орган (ПОр) СМФУ ПА......................................................................27
8.1.2.
Блокировка (БЛК) СМФУ ПА............................................................................30
8.1.3.
Контроль предшествующего режима (КПР) СМФУ ПА...............................31
8.1.4.
Управляющие воздействия (УВ) СМФУ ПА....................................................33
8.1.5.
Анализ блоков ПА, используемых в RastrWin(RUSTab)...............................34
8.1.6.
Итог анализа........................................................................................................... 34
3
9.
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ.............................................36
9.1. Функциональные требования..................................................................................... 36
9.1.1. Требования к редактированию/созданию моделeй ПА.......................................36
9.1.2. Требования к отображению блоков в графическом редакторе.........................36
9.1.3. Требования к созданию укрупненных блоков......................................................38
9.1.4. Требования к графическому редактору.................................................................39
9.1.5. Требования к навигации по логической схеме.....................................................39
9.1.6. Требования к поиску на графической схеме.........................................................40
9.1.7. Требования к валидации логической схемы.........................................................40
9.1.8. Требования к блокировке редактирования схемы устройства ПА..................41
9.1.9. Требования к хранению истории версий созданных черновиков моделей
устройств (функций) ПА......................................................................................................41
9.1.10. Требования к созданию версий черновиков........................................................41
9.1.11. Требования к истории версий черновиков..........................................................42
9.1.12. Требования к сохранению/восстановлению черновика устройства ПА........42
9.1.13. Требования к библиотеке шаблонов устройств ПА...........................................42
9.1.14. Требования к справочной информации...............................................................43
9.1.15. Требования к механизму проверки (эмулятор сигнала) разработанных моделей
ПА
43
9.1.16. Требования к эмуляции сигналов электрооборудования для проверки
корректности работы смоделированного устройства ПА............................................43
9.1.17. Требования к проверке модели (функции) ПА в динамическом режиме......44
9.1.18. Требования к процессу согласования моделей...................................................44
9.1.19. Требования к запросу на согласование/подписание..........................................46
9.1.20. Требования к истории согласования....................................................................47
9.1.21. Требования к системе формирования отчетной документации......................47
9.1.22. Требования к экспорту параметров настройки ЛАПНУ..................................49
9.1.23. Требования к формату данных..............................................................................49
9.1.24. Требования к составу данных................................................................................49
9.1.25. Требования к системе прав доступа......................................................................50
9.1.25.1. Требования к набору ролей пользователей......................................................50
9.1.25.2. Требования к составу прав ролей пользователей...........................................50
9.1.26. Требования к системе журналирования...............................................................53
9.2. Нефункциональные требования.................................................................................54
9.2.1. Требования к информационной безопасности......................................................54
9.2.2. Требования к визуализации......................................................................................54
9.2.3. Требования к отображению справочной информации........................................56
9.2.4. Требования к отображению табличных форм......................................................56
9.2.5. Требования к производительности.........................................................................57
9.2.6. Требования к лингвистическому обеспечению Системы...................................57
9.2.7. Требования к дистрибутиву......................................................................................58
9.2.8. Требования к категорийности Системы................................................................60
10.
ЭТАПЫ СОЗДАНИЯ СИСТЕМЫ......................................................................61
10.1. Этап 1 Разработка MVP..............................................................................................61
10.2. Этап 2 Испытание MVP.............................................................................................. 62
10.3. Этап 3 Итеративное развитие....................................................................................62
ПРИЛОЖЕНИЕ 1. ПРОФИЛЬ ИНФОРМАЦИОННОЙ МОДЕЛИ...........................64
ПРИЛОЖЕНИЕ 2. АЛЬБОМ ФОРМ КОНСТРУКТОРА ПА......................................97
4
1. ПЕРЕЧЕНЬ ОПРЕДЕЛЕНИЙ И СОКРАЩЕНИЙ
Таблица 1. Определения и сокращения
Сокращение
AD
Расшифровка
Active Directory - службы каталогов корпорации Microsoft для операционных
систем семейства Windows Server
Angular
Angular - открытая и свободная платформа для разработки веб-приложений,
написанная на языке TypeScript
REST API, API REST означает REpresentational State Transfer (передача состояния
представления). API означает Application Programming Interface (Интерфейс
программирования приложений) – набор готовых классов, процедур,
функций, структур и констант, предоставляемых приложением (библиотекой,
сервисом) для использования во внешних программных продуктах.
Используется программистами для написания приложений
CIM
Common Information Model (Общая информационная модель) – модель,
определяющая представление управляемых элементов среды в виде
совокупности объектов и их отношений – в энергетике это классы объектов с
атрибутами и связями. Выполняется в соответствии со стандартами,
входящими в IEC 61970, IEC 61968 и их расширениями. В России CIM
представлен серией национальных стандартов ГОСТ Р 58651
CPU
Central Processing Unit (центральное обрабатывающее устройство)
DOM
DOM (от англ. Document Object Model — «объектная модель документа») —
это не зависящий от платформы и языка программный интерфейс,
позволяющий программам и скриптам получить доступ к содержимому
HTML-, XHTML- и XML-документов, а также изменять содержимое,
структуру и оформление таких документов
TCP
Transmission Control Protocol — протокол управления передачей) — один из
основных протоколов передачи данных интернета. Предназначен для
управления передачей данных интернета.
MVCMVC (известный как Model-View-Controller) — это шаблон в разработке
фреймворк
программного обеспечения, который обычно используется для реализации
пользовательских интерфейсов, данных и логики управления
JVM
Java Virtual Machine
UI
User Interface — пользовательский интерфейс
АО «СО ЕЭС», Акционерное общество «Системный оператор Единой энергетической
СО, СО ЕЭС
системы»
АПНУ
Автоматика предотвращения нарушения устойчивости
АЛАР
Автоматика ликвидации асинхронного режима
АОПН
Автоматика ограничения повышения напряжения
АОПО
Автоматика ограничения перегрузки оборудования
АОПЧ
Автоматика ограничения повышения частоты
АОСН
Автоматика ограничения снижения напряжения
АОСЧ
Автоматика ограничения снижения частоты
АРОЛ
Автоматика разгрузки при отключении одной линии электропередачи
БД
База данных
БЛК
Блокировка
5
Сокращение
ДЦ
ЕИМ
ИС
ИУС
КПР
ЛКМ
МДП
МЭК
НСИ
ОДУ
ОЗУ
ОС
ПА
ПО
ПОр
ПУР
РДУ
ОИК СК-11
Расшифровка
Диспетчерский центр
Единая информационная модель
Информационная система
Информационно-управляющая система
Контроль предшествующего режима
Левая кнопка мыши
Максимально допустимый переток
Международная электротехническая комиссия
Нормативно-справочная информация
Объединенное диспетчерское управление АО «СО ЕЭС»
Оперативное запоминающее устройство
Операционная система
Противоаварийная автоматика
Программное обеспечение
Пусковой орган
Положение по управлению режимами
Региональное диспетчерское управление АО «СО ЕЭС»
Информационно-управляющая система «Оперативно-информационный
комплекс CK-11»
Программный комплекс Система мониторинга запасов устойчивости
ПК СМЗУ,
СМЗУ
СМФУ ПА
Система мониторинга функционирования устройств ПА
СУБД
Система управления базами данных
УВ
Управляющие воздействие
ЦП
Центральный процессор
ПТК ВУ ЦСПА, Программно-технический комплекс верхнего уровня Централизованная
ЦСПА
система противоаварийной автоматики
RFC
Request for Comments. Официальный документ рабочей группы по
проектированию Интернета (IETF), в котором содержатся спецификации и
организационные замечания по темам, связанным с интернетом и
компьютерными сетями.
ЦСПА Сибири Централизованная система противоаварийной автоматики, разработанная
"Институтом автоматизации энергетических систем" специально для ОДУ
Сибири
6
2. ВВЕДЕНИЕ
В рамках работ по договору № 273–14-8Н-23 на разработку эскизного проекта
и архитектурного прототипа программы для ЭВМ «Универсальный конструктор
моделей устройств (функций) противоаварийной автоматики» производились
работы согласно плану графику работ.
Были выполнены следующие работы:
1. Разработан архитектурный прототипа Конструктора ПА.
2. Разработан проект профиля информационной модели ПА. Расширение
профиля информационной модели ПА предполагается на этапе
разработки Системы.
3. Разработан альбом форм целевой Системы Конструктора ПА.
4. Разработаны функциональные и нефункциональные требования к
целевой Системе Конструктора ПА.
5. Проведен анализ текущих возможностей двусторонней интеграции с
ИУС АО «СО ЕЭС» (RastrWin (RUStab), СМЗУ, ЦСПА-3, ЦСПА
Сибири, СМФУ ПА и СК-11) и разработаны требования к двусторонней
интеграции с указанными ИУС АО «СО ЕЭС».
7
3. ОБЩАЯ СТРУКТУРА СИСТЕМЫ
3.1. Наименование Системы
Наименование программы для ЭВМ: Универсальный конструктор моделей
устройств противоаварийной автоматики.
Условное обозначение программы для ЭВМ – Конструктор ПА, Система.
3.2. Назначение Системы
Система предназначена для создания, редактирования и согласования моделей
устройств (функций) ПА, проверки корректности разработанных моделей.
3.3. Цель разработки Системы
Разработка и внедрение Системы осуществляется с целью совершенствования
процесса моделирования устройств (функций) ПА благодаря:
 Создания централизованной Системы с единой БД моделей устройств
(функций) ПА.
 Обеспечения единого подхода для создания моделей устройств
(функций) ПА.
 Сокращения степени избыточности и дублирования операций обработки
информации и связанных с этим неэффективных затрат трудовых и
материальных ресурсов.
 Сокращения затрат на администрирование существующих ИУС
АО «СО ЕЭС».
3.4.
Перечень диспетчерских центров АО
предполагается использовать Систему
«СО
ЕЭС»,
в
которых
Система разрабатывается для использования в диспетчерских центрах
Заказчика – ИА, ОДУ, РДУ.
3.5. Характеристика объекта автоматизации
Противоаварийная автоматика – совокупность устройств, обеспечивающая
измерение
и
обработку
параметров
электроэнергетического
режима
энергосистемы, передачу информации, команд управления и реализацию
управляющих воздействий в соответствии с заданными алгоритмами и настройкой
с целью выявления, предотвращения развития и ликвидации аварийного режима
энергосистемы.
Объектом автоматизации является деловой процесс создания и
редактирования моделей устройств (функций) ПА, который включает в себя:
 сбор и анализ информации об имеющихся устройствах ПА;
 непосредственно моделирование устройства ПА;
 экспорт созданных моделей ПА для использования при подготовке
заданий диспетчерских центров по настройке устройств ПА;
 тестирование и проверка корректности функционирования моделей
устройств (функций) ПА перед использованием в ИУС (например,
RUStab, СМЗУ, ЦСПА, ЦСПА Сибири, СМФУ ПА).
8
В настоящее время указанный деловой процесс в АО «СО ЕЭС» имеет
следующие недостатки:
 отсутствие централизованной единой БД моделей устройств (функций)
ПА усложняет процессы актуализации данных моделей и обмена
информацией между пользователями;
 из-за отсутствия полной совместимости моделирование устройств
(функций) ПА выполняется для каждого ИУС, что увеличивает
трудозатраты и не гарантирует идентичности характеристик этих
моделей.
С целью устранения указанных недостатков необходимо разработать и
внедрить Систему с централизованной БД на уровне ИА, посредством которых
будет осуществляться создание и распространение моделей устройств (функций)
ПА, в том числе автоматики:
 предотвращения нарушения устойчивости;
 ликвидации асинхронного режима;
 ограничения снижения частоты;
 ограничения повышения частоты;
 ограничения снижения напряжения;
 ограничения повышения напряжения;
 ограничения перегрузки оборудования.
3.5.1. Структура системы Конструктор ПА
Ниже приведена общая структурная схема, описывающая взаимодействие с
внешними системами (рисунок 1), и детальная структурная схема состава сервисов
Конструктора ПА (рисунок 2).
9
Рисунок 1. Взаимодействие Конструктора ПА с внешними системами
На схеме изображено взаимодействие Конструктора ПА с внешними
системами и потоки данных между системами. Пунктирной стрелкой показана
потенциальная возможность интеграции ИУС АО «СО ЕЭС» напрямую с Системой
через REST API.
Рисунок 2. Структура состава сервисов Конструктора ПА
10
На схеме изображено взаимодействие между сервисами Конструктора ПА
(связь со внешними системами здесь представлена через взаимодействие сервисов
через API и UI).
3.5.2. Описание структуры Системы
Структура Системы проектируется с учетом следующих условий:
 возможность масштабирования объемов хранения данных посредством
добавления новых системных ресурсов;
 возможность отказоустойчивой конфигурации, с возможностью
переключения сервисов Системы с отказавших серверов на оставшиеся
сервера в работе;
 функционирование на основе отечественного системного ПО (ОС Astra
Linux) без использования импортного проприетарного ПО.
Основными сервисами внутри системы являются следующие:
1. Сервис API – доступ к функциям и данным по работе с автоматикой и НСИ;
2. Сервис отчетов – формирование отчетных документов;
3. Шлюз ЕИМ – интеграция с ОИК СК-11 в части взаимодействия с ЕИМ;
4. Менеджер процессов – координация и отслеживание работы сервисов
Системы, монитор состояния основных компонентов системы.
5. Вспомогательными сервисами внутри системы являются следующие:
6. Сервис уведомлений – отправка уведомлений почтовым и веб-клиентам;
7. Сервис авторизации – авторизация и аутентификация пользователей,
обеспечение разграничения прав доступа.
11
4. КОМПЛЕКС ТЕХНИЧЕСКИХ СРЕДСТВ
4.1. Архитектура
Система представляет централизованную архитектуру и на основе
многозвенной (многоуровневой) архитектуры: клиент – сервер приложений –
сервер БД. Вся информация хранится в единой БД. Целевая архитектура Системы
представлена на рисунке 3.
Рисунок 3. Схема комплекса технических средств
4.1.1. Отказоустойчивость
Состав технологий для обеспечения отказоустойчивой работы Системы: nginx
- средство для распределения нагрузки запросов, в том числе с учетом доступности
тех или иных экземпляров сервисов.
12
4.1.2. Масштабирование
В части масштабирования Система должна обеспечивать:
1. Отсутствие принципиальных ограничений на число одновременно
работающих в Системе конечных пользователей (ограничения только по
составу и характеристикам технических средств, сетевого и
каналообразующего оборудования).
2. База данных Системы должна быть способна выдерживать, по крайней
мере, двукратное увеличение объема относительно объема при
первоначальном
развертывании,
не
требуя
восстановления,
перекомпиляции или любой другой обработки. Информацию об объеме
при первоначальном развертывании предоставляет Заказчик.
3. Должна быть предусмотрена возможность масштабирования функций
Системы на произвольное количество серверов. Масштабирование
должно выполняться как по «горизонтали» (в рамках одного ДЦ), так и
по «вертикали» (в рамках иерархии ДУ).
4.1.3. Пользовательский интерфейс
Функционально веб-интерфейс полностью генерируется и работает на стороне
клиента, со стороны клиента осуществляется первоначальная загрузка всех
используемых библиотек (javascript) и объёмных статических ресурсов (например,
картинок) по запросу. Это реализуется посредством использования полноценного
MVC-фреймворка на стороне клиента - Angular.
Данный подход позволяет полностью отделить реализацию интерфейса
пользователя от технологии реализации логики на сервере, от его языковых и
платформенных зависимостей, реализуя всю логику создания, взаимодействия
форм и контролов на стороне клиента, что обеспечивает полностью автономную
реализацию интерфейса от сервера. Взаимодействие с сервером осуществляется в
полностью асинхронном режиме, не блокируя графический интерфейс.
В результате, обеспечивается функционирование интерфейса с временным
отсутствием доступа к серверу (без подвисаний, ожиданий ответа запроса новой
страницы и т.п.), позволяя продолжать работать пользователю в ограниченном
режиме на существующем наборе данных на стороне клиента, имея возможность
использования локального кэша браузера в прозрачном для пользователя виде, при
этом показывая индикацию временной недоступности сервера и время
актуальности информации.
При использовании для создания Системы сторонних программных платформ
(framework) и/или программных библиотек используются актуальные версии, не
содержащие на момент разработки известных уязвимостей программного кода.
Вся разработка пользовательского интерфейса Система выполняется только с
использование open-source решений без использования проприетарного ПО и\или
программных библиотек. В ходе разработки используются актуальные open-source
решения с долгой технической поддержкой разработчика (LTS, Long-term support).
13
Список компонентов и библиотек, используемых при разработке
пользовательского интерфейса:
 angular;
 fortawesome;
 ng-bootstrap;
 ngx-translate;
 popperjs;
 ag-grid-angular;
 ag-grid-community;
 bootstrap;
 core-js;
 css-vars-ponyfill;
 document-register-element;
 file-saver;
 lodash-es;
 rxjs;
 tslib;
 url-search-params-polyfill;
 zone.js.
Состав используемых компонентов по необходимости может быть изменен в
процессе разработки Системы по согласованию с Заказчиком.
4.2. Аппаратные ресурсы
4.2.1. Сервер приложений
Необходимо выделить ресурсы CPU для обрботки запросов пользователя, под
фоновые задачи приложения и задачи интеграции с внешними системами (AD,
ОИК СК-11), чтобы их выполнение не приводило к деградации пропускной
способности сервера. Суммарный объем ЦП с учетом hyper-threading для сервера
приложений:
8 запросы пользователя + 1 задачи интеграция + 1 фоновые задачи + 2
системное ПО = 12 CPU
Сервисам API для обработки запросов редактирования автоматики
планируется выделить 4 Гб ОЗУ. Для кеширования НСИ планируется выделить 2
Гб ОЗУ. Дополнительно необходимо выделить ресурсы ОЗУ под задачи
интеграции и формирование отчетов. Суммарный объем ОЗУ для сервера
приложений с учетом прикладного и системного ПО:
4 ОС + 2 Docker + 4 сервисы API + 2 кеш НСИ + 1 задачи интеграции + 1 сервис
отчетов = 14 Гб
Планируемый средний объем данных, собираемых в логах Системы за день (с
учетом архивирования) составляет не более 30 Мб. Планируемая глубина хранения
в 1 месяц. Максимальный объем журналов составит не более 1 Гб. Планируемый
14
объем данных для Docker-образов приложения, конфигураций и скриптов запуска
не должен превышать 10 Гб.
Для стабильной работы приложения, объем дискового пространства
рекомендовано выбирать из условия заполнения информацией не более чем на
50%, поэтому суммарный объем необходимо дискового пространства с учетом
системного и прикладного ПО для сервера приложений:
2 * (16 ос + 1 логи + 10 Docker-образы) = 54 Гб
4.2.2. Сервер БД
Объем ресурсов, выделяемых для Postgres Pro обусловлен сложностью схемы
данных автоматики и большим количеством связей. Ресурсы необходимы, чтобы
быстро обслуживать пиковые нагрузки во время сохранения/чтения схем из БД и
выполнять сохранение/чтение сразу нескольким пользователям без задержек.
Суммарный объем ядер для сервера БД:
1 ОС + 8 Postgres Pro = 9 CPU
Суммарный объем ОЗУ для сервера БД:
4 ОС + 8 Postgres Pro = 12 Гб
Предполагаемое среднее количество моделей ПА в одном ДЦ 140 шт.
Предполагаемое количество одновременно разрабатываемых/согласуемых
моделей ПА в одном ДЦ 6 шт. Для таких моделей необходимо хранение нескольких
версий (максимум до 80 версий).
Предполагаемый средний объем данных необходимый для представления
одной модели ПА 3 Мб. Предполагаемый объем хранения НСИ не более 4 Гб на
один ДЦ.
Суммарный средний объем данных на один ДЦ:
(140 моделей ПА + 6 моделей ПА * 80 версий) * 3 Мб + 4 ГБ НСИ = 5,86 Гб
Суммарный объем данных на 57 ДЦ:
5,86 Гб * 57 ДЦ = 334 Гб
Для стабильной работы приложения, объем дискового пространства,
рекомендовано выбирать из условия заполнения информацией не более чем на
50%, поэтому суммарный объем необходимо дискового пространства для сервера
БД:
2 * (334 Гб данных + 16 Гб ОС) = 700 Гб
Перечень планируемого к использованию аппаратного обеспечения для
функционирования Системы описан в таблице 2.
Сервер
Сервер приложений
Хранилище
Таблица 2. Аппаратное обеспечение для функционирования Системы
Ресурсы на один экземпляр
ЦП, CPU
ОЗУ, Гб
Хранилище, Гб
12
14
54
9
12
700
15
4.2.3. Программное обеспечение для эксплуатации системы
Перечень планируемого к использованию ПО для функционирования
Системы описан в таблице 3.
Таблица 3. ПО для функционирования Системы
Программное
обеспечение
Astra Linux
Docker
Назначение
Операционная система
Программное обеспечение для автоматизации развёртывания,
управления
приложениями
в
средах
с
поддержкой
контейнеризации/ Среда исполнения сервисов системы.
Объектно-реляционная база данных для задач общего назначения.
Хранилище данных автоматики
Веб-сервер, используется как HTTP-сервер для отдачи статики и
как балансировщик трафика
Postgres Pro
Nginx1
4.2.4. Рабочие станции
Требования к аппаратному обеспечению на клиентском рабочем месте –
минимум 4 Гб ОЗУ. Требования к ПО на клиентском рабочем месте описаны в
таблице 4.
Таблица 4. Требования к рабочим станциям
Название
Yandex.browser
Версия
21 и выше
Описание
Веб-браузер,
используется
для
пользовательских интерфейсов приложения
работы
16
5. ИНТЕГРАЦИЯ С ИНФРАСТРУКТУРОЙ СО
5.1.
Взаимодействие с системой мониторинга
В Системе должны применяться агенты в стандарте SNMP, поддерживающие
протокол SNMPv2C.
Состав контролируемых по протоколу SNMP объектов Системы, параметров
SNMP сообщений и список реализуемых SNMP команд для обработки в
подсистеме должны быть уточнены Исполнителем и согласованы с Заказчиком на
этапе разработки Системы.
5.2.
Взаимодействие с системой резервного копирования
Система должна поддерживать резервное копирование при помощи
имеющихся у Заказчика средств резервного копирования, архивирования и
восстановления, как для программного обеспечения, так и для настроек и данных, в
том числе БД, Системы.
Восстановление Системы должно быть возможным как целиком, так и в её
части, например, в части БД или программного обеспечения. Частичное
восстановление выполняется администратором в ручном режиме. При полном
восстановлении системы восстановление данных должно быть полным, включая
свойства данных и настроек доступа к данным.
Документация Системы должна предусматривать описание типового:
 списка резервируемых объектов – серверов, каталогов, файлов, БД;
 времени и периодичности резервного копирования;
 длительности хранения резервных копий
для учёта в Регламенте резервного копирования Системы.
Система должна сохранять работоспособность во время резервного
копирования и не требовать своей остановки для создания консистентной
резервной копии, данные в которой взаимно согласованы на момент копирования.
Система должна поддерживать резервное копирование на удалённую площадку
при наличии таковой в инфраструктуре резервного копирования Заказчика.
5.3.
Интеграция с Active Directory (AD)
Интеграция с AD в рамках проекта предполагает использование механизмов
аутентификации средствами AD, а также использование существующих
пользователей и групп с назначением соответствующих ролей в системе.
Аутентификация пользователей выполняется по Kerberos-протоколу. Для
взаимодействия со Службой каталогов предполагается использование протокол
LDAP (Lightweight Directory Access Protocol). Авторизация будет выполняться
автоматически с использованием технологии единого входа.
17
Каждой группе пользователей в Системе можно задавать роли (см. Требования
к Системе прав доступа).
5.4.
Серверные ресурсы
Основной базовой средой запуска для систем на текущий момент является
система виртуализации с выделением ресурсов под системы в виде виртуальных
машин. Система должна функционировать с учетом возможности работы в среде
виртуализации.
Запуск Системы выполняется средствами контейнеризации docker. Основным
элементом запуска компонент Системы предполагаются контейнеры образов в
docker. Их работа возможна на виртуальных машинах при наличии аппаратной
виртуализации (которая присутствует и используется в СО). В качестве базовой ОС
для docker-образов предполагается базовый слой на Astra Linux.
Системное ПО должно запускаться средствами операционной системы без
использования docker.
18
6. ИНТЕГРАЦИЯ С ВНЕШНИМИ СИСТЕМАМИ
В рамĸах реализации Системы должна быть учтена двухсторонняя интеграция
со следующими системами:
1. ИУС АО «СО ЕЭС» (ЦСПА, СМЗУ и Rustab) используемых заказчиком для
работы с ПА (в части экспорта/импорта моделей противоаварийной
автоматики).
2. Необходимость и детализация решений (при выявлении необходимости) в части
интеграции с ИУС СМФУ ПА должна быть определена на начальных этапах
разработки Системы.
3. ОИК СК-11 - оперативно-информационный ĸомплеĸс диспетчерсĸого
управления, в части загрузки в Систему корпоративной НСИ и загрузки из
Системы в ОИК СК-11 модели ПА. Реализованная интеграция должна
обеспечивать в последующем возможность проверки работы ПА на
текущем/архивном телеметрическом срезе в ОИК СК-11.
6.1.
Интеграция с ИУС АО «СО ЕЭС»
Система должна предоставлять возможность экспорта/импорта информации о
моделях ПА в формате CIMXML через пользовательский интерфейс и
программный интерфейс Системы.
Для обмена моделями (функциями) ПА разработан проект профиля
информационной модели, представленный в Приложение № 1. Профиль
информационной модели.
Профиль информационной модели должен быть скорректирован, при
необходимости, и дополнен на этапах создания Системы, согласован с Заказчиком.
Структура (состав объектов и полей) будет определена и согласована с
Заказчиком на этапах разработки Системы.
При экспорте/импорте моделей устройств ПА осуществляется передача
следующего набора параметров:
1. Перечень устройств ПА;
2. Состав устройства ПА (информацию об используемых в устройстве ПА
элементах автоматики);
3. Параметры настройки элементов автоматики, используемых в устройстве ПА;
4. Параметры логики подключения элементов автоматики между собой.
При импорте моделей ПА в Систему автоматически должно формироваться ее
графическое отображение.
В настоящий момент времени эксплуатируемые в АО «СО ЕЭС» ИУС,
предназначенные для выполнения расчётов с учётом подробной модели ПА, имеют
очень ограниченный функционал по способам внешнего информационного обмена.
Внутренняя логика учета функций ПА этих комплексов не позволяет реализовать
весь потенциал CIM моделирования без их соответствующей модернизации. Для
организации двухстороннего информационного обмена в формате CIMXML
19
необходима модернизация каждого ИУС АО «СО ЕЭС» в части условий и формата
внешнего информационного обмена.
До окончания модернизации каждого ИУС АО «СО ЕЭС» для осуществления
обмена моделями ПА между Системой и ИУС АО «СО ЕЭС» необходимо
реализовать внутренние конвертеры Системы.
С целью обеспечения возможности коррекции существующих моделей
устройств (функций) ПА, разработанных в ИУС АО «СО ЕЭС», требуется
реализовать в Системе интерфейс импорта данных из ИУС АО «СО ЕЭС»
(например, RUStab, СМЗУ, ЦСПА-3, ЦСПА Сибири, СМФУ ПА). В интерфейсе
должна быть предусмотрена возможность ручного и автоматизированного (на
основании заранее подготовленных таблиц) сопоставления идентификаторов
объектов Системы и идентификаторов объектов существующих моделей устройств
(функций) ПА для осуществления импорта информации.
6.2.
Требования к статусу экспортируемых/импортируемых устройств ПА
Система должна позволять экспортировать устройство ПА, находящиеся в
любом статусе (черновик, утверждена, архив).
При импорте устройства ПА Система должна:
1. Устанавливать статус модели "Черновик".
2. Фиксировать информацию о пользователе и рабочей станции, с которой
выполнен импорт устройства ПА.
3. Фиксировать дату импорта устройства ПА в Систему.
6.3.
Требования к API обмена информацией об устройствах ПА
Система должна предоставлять универсальный прикладной программный
интерфейс API для обмена информацией о смоделированных устройствах ПА с
ИУС АО «СО ЕЭС».
Программный интерфейс должен представлять из себя REST API и
описываться при помощи Open Api Specification.
Состав методов API Системы должен быть согласован на этапе технического
проектирования. Порядок вызова и описание API должены быть разработаны на
этапе разработки основной функциональности Системы.
Система должна предоставлять выдачу через API информации о моделях
устройств (функций) ПА по запросу/по подписке.
6.4.
Требования к аутентификации API устройств ПА
Для обращения к методам API требуется, чтобы запрос был
аутентифицирован. Аутентификация должна осуществляться путем передачи
20
токена доступа в заголовке запроса (Bearer-токена). Получение токена должно быть
доступно двумя способами:
 По схеме Basic – передача имени пользователя в AD/LDAP и его пароля в
соответствии со RFC 7617;
 Встроенная аутентификация – вся необходимая информация будет
получена из операционной системы для текущего пользователя.
Клиентские библиотеки, через которые осуществляется запрос должны
поддерживать работу с данной схемой аутентификации (Kerberos/NTLM в
зависимости от платформы).
Токен доступа должен быть активен определенное количество времени, после
истечения которого его необходимо будет получать заново.
6.5.
Требования к способу информационного обмена
Информационный обмен должен осуществляться посредством REST-запросов
по протоколу HTTP/HTTPS.
Описание состава методов и порядка их вызова должно быть разработано в
рамках разработки Системы.
Проектирование API для интеграции внешних ИУС с Конструктором ПА
будет осуществляться на стадии техно-рабочего проектирования и разработки ПО.
6.6.
ОИК СК-11
6.6.1. Способы информационного взаимодействия
В рамках разработки условий двустороннего информационного обмена
цифровыми информационными моделями электроэнергетических систем
АО «СО ЕЭС» был проведен анализ возможностей информационного обмена с
ОИК СК-11.
На текущий момент существуют два варианта информационного обмена
цифровыми информационными моделями электроэнергетических систем с ОИК
СК-11:
 Public API СК-11 (взаимодействие может осуществляться по REST API
через http(s)-запросы);
 Веб-сервисы (может осуществляться по веб-сервисам через http-запрос в
формате CIMXML по протоколу SOAP).
На текущий момент полноценное взаимодействие Системы с ОИК СК-11 в
формате CIMXML (согласно ГОСТ Р 58651.1) может быть организовано только
через Веб-сервисы. При доработке формата данных и состава методов Public API
СК-11 интеграция может быть реализована через Public API СК-11, по
согласованию с Заказчиком.
21
Загрузка корпоративной НСИ из ОИК СК-11 и запись автоматики в ОИК
СК-11 осуществляется только в ручном режиме Администратором Системы. В
автоматическом режиме осуществляется только обновление корпоративной НСИ,
используемой в Системе, при этом в Системе во всех устройствах ПА также должна
быть автоматически актуализирована используемая НСИ (с формированим
оповещения о реализованных изменениях). Период автоматизированного
информационного обмена определяется в настройках Системы Администратором
со стороны Заказчика (по умолчанию раз в сутки).
6.6.2. Публичное API СК-11
Взаимодействие c ОИК СК-11 может осуществляться по REST API через
http(s)-запросы c использованием методов, описанных в таблице 5. Для обращения
к большинству методов Public API СК-11 требуется, чтобы запрос был
аутентифицирован. Аутентификация в запросах к API СК-11, осуществляется
путем передачи токена доступа в виде Bearer-токена в заголовке каждого запроса и
предназначена для аутентификации запросов.
Скриптовый запрос позволяет извлечь необходимую информацию в формате
JSON из объектной модели с помощью нетривиальных алгоритмов на языке Lua.
Метод
GET
GET
GET
GET
POST
Таблица 5. Список запросов для взаимодействия с публичным API СК-11
URL
Описание
https://{ck11.local}/api/public/core/
Запрос шаблонов базовых адресов API
v{apiVersion}/addresses
https://{ck11.local}/api/public/objectЗапрос списка доступных объектных
models/v{apiVersion}
моделей
https://{ck11.local}/api/public/objectЗапрос списка версий выбранной объектной
models/v{apiVersion}/{modelUid}/
модели
versions
https://{ck11.local}/api/public/objectЗапрос актуальной версии модели
models/v{apiVersion}/{modelUid}/
versions/actual
https://{ck11.local}/api/public/objectВыполняет выборку данных из модели с
models/v{apiVersion}/{modelUid}/
помощью скрипта на языке Lua
versions/{modelVersion}/execute-script
На текущий момент методы для записи объектов модели отсутствуют в
публичном API СК-11.
Для двусторонней интеграции Системы через Public API СК-11 необходимо
расширение состава его методов для возможности записи/модификации
существующих объектов модели и приведение формата информационного обмена
к формату, описанному в ГОСТ Р 58651.1 – CIMXML.
22
6.6.3. SOAP веб-сервисы
Взаимодействие с ОИК СК-11 может осуществляться по веб-сервисам через
http-запрос в формате CIMXML по протоколу SOAP с использованием методов,
описанных в таблице 6.
Сервис доступа к информационной модели предназначен для работы с
версиями моделей: получение списка, создание, изменение статуса, удаление,
сравнение двух версий моделей; получения и изменения данных из указанной в
запросе информационной модели. При получении и изменении данных модели,
обмен осуществляется в формате CIMXML согласно стандарту ГОСТ Р 58651.1, в
части графических схем – в формате Diagram Layout Profile в соответствии со
стандартом IEC 61970-453.
Таблица 6. Список запросов для взаимодействия с веб-сервисами СК-11
Метод
URL
Описание
GetProfiles
http://monitel.com/CK11/
запрос доступных профилей
Services/DIM/DimService/
GetProfiles
GetObjects
http://monitel.com/CK11/
запрос объектов из профиля
Services/DIM/DimService/
GetObjects
GetModelVersionsDifference
http://monitel.com/CK11/
запрос изменений в модели
Services/DIM/DimService/
между версиями
GetModelVersionsDifference
GetActualModelVersion
http://monitel.com/CK11/
запрос актуальной версии
Services/DIM/DimService/
модели
GetActualModelVersion
ChangeObjectsRequest
http://monitel.com/CK11/
запрос на изменение объектов
Services/DIM/DimService/
модели
ChangeObjectsRequest
6.6.4. Настройки взаимодействия
Настройки взаимодействия должны быть доступны в пользовательском
интерфейсе Системы. Список настроек для взаимодействия описан в таблице 7.
Таблица 7. Список настроек взаимодействия
Настройки
Параметры подключения к СК-11
Параметры модели
Описание
 Базовый адрес
 Версия API (при необходимости)
 Логин/Пароль пользователя, из-под которого
осуществляется доступ
 Выбор профиля из списка доступных (Для этого
производится запрос доступных для показа профилей)
23
Настройки
Описание
Параметры автоматической
 Период автоматической проверки изменения
проверки актуальной версии модели
информационной модели (по умолачинию раз в сутки)
6.6.5. Сценарии взаимодействия
В Системе должна быть реализована возможность ручной загрузки
корпоративной НСИ (ЕИМ) из ОИК СК-11 по команде пользователя.
Система должна в соответствии с заданным расписанием проверять изменения
в информационной модели и автоматически принимать изменения по НСИ,
используемой в Системе.
В Системе должна быть реализована возможность ручной записи модели ПА
(утвержденных моделей ПА) в ЕИМ ОИК СК-11.
Для обмена моделями (функциями) ПА разработан проект профиля
информационной модели, представленный в Приложение № 1. Профиль
информационной модели.
Профиль информационной модели должен быть скорректирован, при
необходимости, и дополнен на этапах создания Системы, согласован с Заказчиком.
В таблице 8 описаны сценарии взаимодействия с СК-11, которые должны быть
доступны в Системе.
Таблица 8. Сценарии взаимодействия из Системы с ОИК СК-11
Описание
Принудительный запрос к ИМ (ГИД, КГИД) ОИК СК-11 по команде
пользователя Системы. Проверка изменения актуальной версии
модели.
Сценарий
Принудительный
запрос номера
актуальной версии
модели
Принудительный
Принудительный запрос к ОИК СК-11 по команде пользователя
запрос списка объектов Системы. После получения набор объектов сохраняется в НСИ
актуальной версии
Системы и сохраняется номер текущей версии модели.
модели
Автоматический запрос Автоматический запрос к ОИК СК-11 по расписанию в настройках
номера актуальной
Системы. Проверка изменения актуальной версии модели и объектов
версии модели и списка моедли. Уведомление пользователя Системы о изменениях в объектах
объектов актуальной
информационной модели.
версии модели
Публикация
Запрос к ОИК СК-11 на запись разработанной модели ПА в ИМ
автоматики
(КГИД).
6.6.6. Состав данных
Состав загружаемой информации приведен в таблице 9 и может быть уточнен
на этапе разработки Системы.
24
Проектный состав атрибутов, передаваемых из СК-11, более подробно описан
в Приложение № 1 Профиль информационной модели. Состав атрибутов может
быть уточнен и (или) дополнен на следующих этапах разработки Системы.
Таблица 9. Состав корпоративной НСИ для загрузки в Систему из ОИК СК-11
Объект
Географический субъект
Параметр
Идентификатор
Наименование
Ссылка на вышестоящий географический субъект
Российской Федерации
ДЦ
Идентификатор
Наименование
Ссылка на вышестоящий ДЦ
Ссылка на энергорайон / энергосистему
Стандартные классы напряжения
Идентификатор
Номинальное напряжение
Энергообъект
Идентификатор
Наименование
Тип энергообъекта
Первичное оборудование
Идентификатор
Наименование
Тип первичного оборудования
Класс напряжения
Ссылка на энергообъект
Устройство ПА
Идентификатор
Наименование
Ссылка на первичное оборудование
Ссылка на роль
Ссылка на модель устройства ПА
Модели устройств ПА
Идентификатор
25
(модель физического устройства
ПА)
Наименование
Производитель устройства ПА
26
7. АНАЛИЗ ПРИМЕНИМОСТИ МОДЕЛИ ПА В СОСТАВЕ СТАНДАРТОВ
МЭК 61970
Для работы с ПА в составе стандартов МЭК 61970 было выделены следующие
пакеты для анализа:
1. Пакет "infSIPS" – из состава стандартов МЭК 61970;
2. Пакет "Protection_me" – расширение пакета Protection из CIM от
компании АО «Монитор Электрик», реализованные в канонической
модели ОИК СК-11, эксплуатируемого АО «СО ЕЭС».
Классы из пакетов «infSIPS» и «Protection_me» могут быть использованы в
качестве справочной информации при моделировании устройств ПА, данные
используемых классов этих пакетов могут быть основой для составления блоков
моделей (функций) ПА в Конструкторе ПА.
Пакет «infSIPS» содержит классы для представления информации о логике
соединениях между блоками моделей ПА (классы Gate, GateInputPin, PinGate) и
основных типах элементов автоматики – ПОр, БЛК, КПР и УВ. Данные классы
могут быть использованы для представления логики подключения элементов на
функциональной схеме и элементов автоматики к оборудованию.
Данные могут потребовать конвертации во внутренний формат Конструктора
ПА для сохранения в БД и работы с этими данными в графическом редакторе.
В модели ПА в составе стандартов МЭК 61970 не найдена возможность
хранения параметров АЛАР. Автоматика АЛАР не моделируется в виде блоксхемы из элементов автоматики. Вся логика работы АЛАР моделируется заводом
изготовителем. Все расчетные процессы происходят в микропроцессорном
устройстве АЛАР, согласно зашитой заводом изготовителем логике. Филиал
АО «СО ЕЭС» определяет параметры настройки АЛАР. Необходимо расширить
классы, атрибуты и связи CIM модели для возможности сохранения параметров
АЛАР согласно приложению ПУР № 28 "Объекты электроэнергетики, на которых
размещены АЛАР, их алгоритмы функционирования и параметры настройки".
27
8. АНАЛИЗ ПРИМЕНИМОСТИ БЛОКОВ ПА В СОСТАВЕ
СУЩЕСТВУЮЩИХ ИУС АО «СО ЕЭС»
В настоящем разделе проведен анализ применимости параметров блоков ПА
для следующих ИУС АО «СО ЕЭС»:
1. СМФУ ПА;
2. RUStab (СМЗУ, ЦСПА).
8.1.
Анализ блоков ПА, используемых в СМФУ ПА
Программное обеспечение СМФУ ПА автоматически информирует персонал
и формирует отчётные документы в аварийных ситуациях.
СМФУ ПА в режиме реального времени фиксирует срабатывание устройств
ПА в энергосистеме и сравнивает результат работы реального устройства ПА с
прогнозируемым, определенным на основании расчётов на математической
модели. После этого СМФУ ПА формирует специальный отчёт (экспресс–
протокол), в котором приводятся сведения о работе реального устройства, его
модели и оценивается работа устройства («правильно/неправильно»).
Блоки СМФУ ПА представлены следующими типами:
 ПОр;
 БЛК;
 КПР;
 УВ.
Блоки ПОр, БЛК и КПР представляют из себя отдельные файлы, логика
работы разрабатывается в отдельном окне от общей схемы. Хранятся такие
элементы также в отдельных файлах.
8.1.1. Пусковой орган (ПОр) СМФУ ПА
Пусковой орган (ПОр) в СМФУ ПА представляет из себя единый элемент, к
которому подключаются различные входные сигналы (in) контролируемых
параметров электрооборудования из ОИК СК-11, которые в процессе соединения
их в логические цепочки при помощи операторов "И", "ИЛИ" формируют
выходные сигналы.
28
Рисунок 5. Пример пускового органа в графическом редакторе СМФУ ПА
При нажатии комбинации ЛКМ и клавиши "Щ" откроется окно с логикой
данного элемента:
29
Рисунок 6. Пример логики работы пускового органа в СМФУ ПА
Условием для формирования логики элемента со входными и выходными
сигналами является факт настройки данного блока с типом "ФАЙЛ" (тип блока
проверяется путем нажатия ПКМ на данный элемент автоматики):
Рисунок 7. Настройка блока пускового органа в СМФУ ПА
30
Данный элемент автоматики хранится в виде отдельного файла. Разработка
логики работы данного элемента автоматике происходит в графическом редакторе
СМФУ ПА.
8.1.2. Блокировка (БЛК) СМФУ ПА
Блокировка (БЛК) в СМФУ ПА представляет из себя единый элемент, к
которому подключаются различные входные сигналы контролируемых параметров
электрооборудования из ОИК СК-11, которые и в процессе соединения их при
помощи логических операторов "И", "ИЛИ", формируют выходные сигналы.
Рисунок 8. Пример блокировки в графическом редакторе СМФУ ПА
На данном элементе автоматики входные сигналы (in) являются сигналами
ремонта (отключения) электрооборудования.
При нажатии комбинации ЛКМ и клавиши "Щ" откроется окно с логикой
данного элемента:
31
Рисунок 9. Пример логики работы блокировки в СМФУ ПА
Входные сигналы о ремонтах (отключениях) электрооборудования соединены
в различные комбинации, в результате которых формируется ремонтная схема.
Условием для формирования логики элемента со входными и выходными
сигналами является факт настройки данного блока с типом "ФАЙЛ" (тип блока
проверяется путем нажатия ПКМ на данный элемент автоматики):
Рисунок 10. Настройка блока блокировки в СМФУ ПА
8.1.3. Контроль предшествующего режима (КПР) СМФУ ПА
Контроль предшествующего режима (КПР) в СМФУ ПА представляет из себя
единый элемент, к которому подключаются входные сигналы контролируемых
параметров электрооборудования из ОИК СК-11 и логических схем БЛК, и в
процессе соединения при помощи логических операторов "И", "ИЛИ", формируют
выходные сигналы.
32
Рисунок 11. Пример контроля предшествующего режима в графическом редакторе СМФУ
ПА
На данном элементе автоматики входные сигналы (in) являются сигналами
ремонта (отключения) электрооборудования.
Комбинация ЛКМ и клавиши "Щ" откроется окно с логикой данного элемента:
33
Рисунок 12. Пример логики работы контроля предшествующего режима в СМФУ ПА
Входные сигналы поступают от логических схем БЛК, выходные сигналы
выведены на УВ. Условием для формирования логики элемента со входными и
выходными сигналами является факт настройки данного блока с типом "ФАЙЛ"
(тип блока проверяется путем нажатия ПКМ на данный элемент автоматики):
Рисунок 13. Настройка блока контроля предшествующего режима в СМФУ ПА
8.1.4. Управляющие воздействия (УВ) СМФУ ПА
Элемент УВ представляет из себя элемент типа ВЫХОД. Элемент УВ является
следствием работы цепочки устройства ПА.
34
8.1.5. Анализ блоков ПА, используемых в RastrWin(RUSTab)
В RastrWin (RUSTab) блоки элементов автоматики представлены в виде
отдельных элементов, соединенных между собой по схеме "И", "ИЛИ". Все
основные элементы автоматики, как и в СМФУ ПА, делятся на ПОр, БЛК, КПР, УВ.
Рисунок 14. Пример отображения схемы устройства ПА в RastrWin (RUSTab)
8.1.6. Итог анализа
Блоки элементов автоматики в СМФУ ПА представляют из себя вложенность
других элементов в логические "И", "ИЛИ" в собственном формате СМФУ ПА.
Логику работы такого блока можно понять, открыв данный блок и сопоставив
входы и выходы. Данный принцип не подходит для использования в Конструкторе
ПА.
В Конструкторе ПА предполагается использование стандартных блоков и
создание пользователем произвольного блока. Произвольный блок будет
содержать внутреннюю логику, которую моделирует пользователь из простейших
элементов алгебры логики. Также в Конструкторе ПА предполагается создание
укрупненного блока, который будет представлять из себя вложенность других
блоков в себе (например, укрупненный блок АРОЛ).
Таким образом, концепция вложенности блоков может быть применена в
Конструкторе ПА для произвольных и укрупненных блоков.
Модель устройства ПА в RastrWin (RUSTab) представляет из себя
последовательность блоков элементов, соединенных между собой по "И", "ИЛИ".
Представление модели ПА в таком виде позволяет просмотреть логику работы
устройства ПА, произвести быстрый поиск требуемого элемента автоматике на
графической области.
Принцип построения модели устройства ПА аналогичный RastrWin (RUSTab)
используется также в некоторых существующих программных комплексах АО
СО ЕЭС», например, ПТК ВУ ЦСПА и ПК СМЗУ, потому применение такого
принципа построения модели устройства ПА будет понятно пользователю.
35
Таким образом, в Конструкторе ПА состав блоков и принцип моделирования
устройств ПА (через табличную, либо графическую форму) будет возпроизведен
по технологии, реализованной в RastrWin (RUSTab).
36
9. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ
9.1. Функциональные требования
9.1.1. Требования к редактированию/созданию моделeй ПА
Система должна предоставлять возможность моделирования устройств
(функций) ПА в графическом и табличном редакторе.
Система должна позволять пользователю моделировать логику работы в
графическом и табличном редакторе для следующих устройства ПА:
 АПНУ;
 АОПО;
 АОСН;
 АОПН;
 АОСЧ;
 АОПЧ.
Для устройств АЛАР Система должна позволять пользователю описывать
уставки срабатывания в табличном редакторе.
Устройства ПА моделируется при помощи определеного набора элементов
(блоков). Параметры данных блоков должны соответствовать параметрам блоков в
RastrWin (RUSTab). Параметры блоков могут быть уточнены на следующих
стадиях разработки Системы.
При формировании логики работы устройств (функций) ПА в табличном
редакторе Система должна:
 автоматически формировать графическое отображение данного
устройства (функции ПА) на основе данных табличного редактора;
 автоматически располагать элементы автоматики без пересечений друг с
другом и определять связи между ними.
 позволять просматривать графическую схему устройства ПА
одновременно с табличным редактором (должны быть расположены в
одном окне);
 подсвечивать на графической схеме устройства ПА выбранный в
табличном редакторе элемент автоматики и перемещать графическую
область на выбранный блок.
9.1.2. Требования к отображению блоков в графическом редакторе
Все блоки, кроме блока УВ, в графическом редакторе должны отображаться
прямоугольниками. Внутри блоков типа ФОЛ, ФРЛ и т.д должна отображаться
информация о привязанном объекте.
37
В блоках типа КПР должна отображаться информация о номерах групп и
ступеней.
Блоки типа УВ должны отображаться в виде прямоугольника с описанием
управляющего воздействия, либо в виде комбинированного блока, как
представлено ниже.
Отображение переключающих устройств приведен в таблице 18. (Состав
переключающих устройств может быть уточнен в процессе разработки Системы).
Отображение
переключающего
устройства
Таблица 18. Список переключающих устройств
Описание переключающего устройства
Нормально разомкнутый контакт. Вводится в работу
автоматически
Нормально разомкнутый контакт. Вводится в работу по команде
диспетчера
Нормально замкнутый контакт. Вводится в работу автоматически
Нормально замкнутый контакт. Вводится в работу по команде
диспетчера
Нормально разомкнутый с выдержкой времени на замыкание
Нормально замкнутый с выдержкой времени на размыкание
Переключающее устройство, изменение положения контактов
которого происходит одновременно при выполнении единичной
операции с переключающим устройством.
Изменение положения контактов производится автоматически
Переключающее устройство, изменение положения контактов
которого происходит одновременно при выполнении единичной
операции с переключающим устройством.
Изменение положения контактов производится по команде
диспетчера
Переключающее устройство, изменение положения контактов
которого происходит одновременно при выполнении единичной
операции с переключающим устройством.
Изменение положения контактов производится автоматически
38
Отображение
переключающего
устройства
Описание переключающего устройства
Переключающее устройство, изменение положения контактов
которого происходит одновременно при выполнении единичной
операции с переключающим устройством.
Изменение положения контактов производится по команде
диспетчера
Условие срабатывания ПА (количество блоков, состояние транзита
и т.д.).
Условие фиксируется автоматически
Условие срабатывания ПА (количество блоков, состояние транзита
и т.д.).
Условие фиксируется по команде диспетчера
На графической схеме у контактов с выдержкой времени на срабатывание
должна отображаться уставка по времени:
Рисунок 18. Контакт с выдержкой времени
В системе должна быть возможность добавления текста в графическом
редакторе в произвольном месте графической схемы.
9.1.3. Требования к созданию укрупненных блоков
Система должна позволять пользователю формировать укрупненные блоки в
графическом редакторе. В укрупненный блок можно включить любой элемент
автоматики, кроме блока типа УВ.
Система должна предоставить следующие возможности при работе с
укрупненным блоком:
 на графической схеме определить границы/состав, элементов
автоматики, входящих в укрупнённый блок;
 указать наименование укрупненного блока;
 просмотреть состав и схему соединения элементов автоматики внутри
укрупненного блока;
 просмотреть схему устройства ПА в развернутом режиме и в режиме
укрупненных блоков;
 внести изменения в любой элементов автоматики внутри и/или за
пределами укрупненного блока;
39
 добавить новый блок (все кроме блока УВ) с графического поля к
укрупненному блоку.
Добавление, редактирование, удаление и изменение логики работы элементов
автоматики для укрупненного блока осуществляется только в режиме развернутой
схемы укрупненного блока.
При просмотре схемы в режиме укрупненных блоков Система должна:
 позволять изменять масштаб схемы;
 позволять перемещаться по схеме.
9.1.4. Требования к графическому редактору
В графическом редакторе должны присутствовать:
 библиотека блоков (ПОр, блокировки, УВ, ключи нетиповые блоки и
т.д).
 библиотека шаблонов устройств ПА.
 библиотека готовых элементов автоматики, привязанных к текущему
устройству ПА.
 В графическом редакторе Системы необходимо реализовать
функционал:
 создания новых элементов автоматики;
 использования готовых элементов автоматики;
 создание укрупненных блоков;
 корректировки параметров элементов автоматики;
 моделирования логики работы устройства ПА (привязка блоков между
собой);
 проверки устройства ПА;
 изменения состава отображаемой информации о параметрах
элементов/блоков автоматики на графической области.
Перечень отображаемой информации о параметрах элементов/блоков
автоматики на графической области будет описан на следующих стадиях
разработки Системы.
По команде пользователя на графической области должна отображаться сетка.
9.1.5. Требования к навигации по логической схеме
Система должна предоставлять возможности удобной навигации по схеме
модели ПА в графическом редакторе, а именно:
1. Позволять изменять масштаб схемы модели ПА с помощью кнопок в
интерфейсе Системы и «горячих» клавиш совместно с прокруткой
колеса мыши;
2. Позволять перемещаться по схеме модели ПА с помощью мыши;
3. Позволять отменять/восстанавливать совершенные операции с
помощью кнопок в интерфейсе Системы и «горячих» клавиш;
40
4. Позволять выделять один или группу элементов автоматики на
графической
схеме
(для
дальнейшего
удаления/перемещения/копирования/укрупнения);
5. Позволять копировать один или группу элементов автоматики на
графической схеме при помощи кнопок в интерфейсе Системы и
«горячих» клавиш;
6. Позволять выполнять поиск в библиотеке готовых элементов
автоматики. При поиске должна быть доступна фильтрация.
9.1.6. Требования к поиску на графической схеме
Система должна позволять выполнять поиск элементов автоматики на
графической области по наименованию и номеру.
1. Система должна позволять выполнить поиск элементов автоматики или
нескольких связанных элементов автоматики.
2. Система должна выделять на графической области найденные элементы
автоматики.
3. Если Система нашла несколько подходящих по условию элементов
автоматики, Система должна позволять выполнить навигацию на
графической области между найденными элементами автоматики.
9.1.7. Требования к валидации логической схемы
Система должна выполнять проверку схемы устройства ПА на корректность
соединений и привязок элементов автоматики на графической схеме:
 Выводить предупреждающее сообщение, если в схеме устройства ПА
имеются не связанные между собой элементы автоматики;
 Выделять красным цветом блоки автоматики на схеме устройства ПА,
которые не имеют привязки к элементам автоматики и формировать
предупреждающее сообщение при сохранении такой схемы;
 При создании элемента автоматики, который уже существует, Система
должна уведомить пользователя о существовании такого элемента
автоматики, но не запрещать создание дубликата элемента автоматики
(например, ФРЛ ВЛ 500 кВ Калининская АЭС – Белозерская может
использоваться как в АРОЛ, так и в АРКЗ).
Система не должна препятствовать сохранению модели, при наличии
неустраненных ошибок валидации (при наличии предупреждений).
9.1.8. Требования к блокировке редактирования схемы устройства ПА
Система должна позволять только одному пользователю (если у него есть
соответствующие права) редактировать схему устройства ПА (когда пользователь
41
берет схему на редактирование он блокирует ее для редактирования другими
пользователями).
Система должна:
 Автоматически устанавливать блокировку редактирования схемы
устройства ПА, после того как пользователь берет схему устройства ПА
на редактирование;
 Предупреждать пользователя что схема уже находится на
редактировании (установлена блокировка). Предупреждение должно
содержать информацию о времени, которое схема находиться на
редактировании и пользователе, который в настоящий момент
редактирует схему;
 Автоматически снимать блокировку после выхода из режима
редактирования (сохранение изменений или выход из режима
редактирования без изменений);
 При наличии соответствующих прав позволять принудительно снимать
блокировку.
Система должна позволять одновременно нескольким пользователям (если у
них есть соответствующие права) просматривать схему устройства ПА, независимо
от редактирования.
9.1.9. Требования к хранению истории версий созданных черновиков моделей
устройств (функций) ПА
В Системе должно быть организовано хранение истории версий созданных
черновиков моделей устройств (функций) ПА с заданной администратором
глубиной (количество версий).
Система должна автоматически создавать новую версию при сохранении в
черновике изменений, внесенных пользователем, позволять просматривать
историю версий, осуществлять навигацию между версиями, копировать и удалять
версии.
9.1.10. Требования к созданию версий черновиков
К каждой версии присваивается следующая сопроводительная информация:
 время создания версии;
 учетную запись пользователя, который создал версию;
 номер версии (создается автоматически путем инкрементирования);
 комментарий (в случае если версия была восстановлена из более ранней
версии).
Версия модели также может быть создана путем восстановления более ранней
версии модели, в этом случае Система должна автоматически сформировать
42
комментарий с информацией о версии модели, из которой было выполнено
восстановление.
9.1.11. Требования к истории версий черновиков
Система должна позволять пользователю просматривать историю версий
модели (функции) ПА.
Если количество версий превышает, указанное пользователем, то Система
должна автоматически удалять самую старую версию из Системы.
Система должна предоставлять следующие функции при работе с версиями:
 просмотр схемы устройства ПА любой из версий;
 навигация между версиями схемы в режиме просмотра версий;
 редактирование комментария к версии;
 удаление версии.
Присвоение версии статуса «Избранная», такая версия не должна удаляться
Системой автоматически.
Восстановление/копирование любой версии. При выполнении данной
функции созданется новая версия на основании выбранной. Новой версии
присваивается новый порядковый номер.
9.1.12. Требования к сохранению/восстановлению черновика устройства ПА
В целях предотвращения потери совершенных изменений, Система должна
периодически сохранять текущую версию черновика устройства ПА.
Периодичность сохранения настраивается пользователем с ролью администратор.
При аварийном завершении процесса моделирования (пропала сеть,
принудительный перезапуск браузера и т.д.), Система должна, при следующем
редактировании, предлагать пользователю восстановить последнию версию
черновика.
9.1.13. Требования к библиотеке шаблонов устройств ПА
Система должна позволять создавать шаблоны устройств ПА. Шаблоны
устройств ПА должны состоять из элементов автоматики.
Система должна позволять также создавать шаблон путем выделения части
схемы ПА в графическом редакторе. При создании шаблона НСИ, содержащиеся в
выделенной части схемы ПА, должны быть удалены.
В системе должны присутствовать типовые шаблоны устройств ПА. Типовые
шаблоны будут разработы на следующих этапах разработки Системы.
43
9.1.14. Требования к справочной информации
Система должна предоставлять возможность вызова, просмотра и поиска в
справочной информации об основных элементах управления и сочетаниях горячих
клавиш на формах редакторов.
Требования к справочной информации также представлены в п.9.2.3
настоящего эскизного проекта.
Состав и формат справочной информации может быть уточнен на этапе
разработки Системы.
9.1.15. Требования к механизму проверки (эмулятор сигнала) разработанных
моделей ПА
Система должна предоставлять функцию проверки корректности моделей
(функций) ПА с помощью эмуляции сигналов.
Система должна предоставить возможность проверить устройство ПА в двух
режимах:
1. Проверка корректности собранной схемы;
2. Проверка модели (функции) ПА в динамическом режиме.
9.1.16. Требования к эмуляции сигналов электрооборудования для проверки
корректности работы смоделированного устройства ПА
Для эмуляции тестовых сигналов Система должна:
1. Позволять создавать, редактировать и удалять несколько групп
тестовых сигналов;
2. Обеспечивать добавление, редактирование и удаление сигналов
элементов автоматики в каждой группе.
3. Система должна позволять задавать тестовые сигналы в табличном виде.
4. Система должна позволять выбирать одну из групп тестовых сигналов и
запускать проверку срабатывания блоков автоматики на его основе.
5. Система должна предоставлять результаты проверки модели (функции)
ПА. Результатом проверки модели (функции) ПА должно быть
выделение на схеме устройства ПА отработавших блоков и список
набранных УВ.
6. Должна быть возможность сохранения группы тестовых сигналов для
использования при проверке корректности в дальнейшем.
44
9.1.17. Требования к проверке модели (функции) ПА в динамическом режиме
Система должна предоставлять функцию проверки моделей (функций) ПА на
основе набора тестовых сигналов, которые привязаны в схеме данного устройства
ПА, в динамическом режиме, а также возможность использования csv-файлов
результатов расчетов переходных процессов RusTab.
Динамический режим проверки модели (функции) устройства ПА
предполагает возможность указать N состояний входных параметров
(определяется пользователем, максимум до 1000) для каждого из элементов
моделируемого режима работы и соответствующих им N состояний выходных
параметров (опционально, необходимость задается пользователем).
1. Система должна отобразить в виде списка используемые элементы
автоматики в текущем устройстве ПА.
2. Система должна предоставить возможность указать пользователю
моделируемые сигналы для каждого элемента автоматики, из которых
состоит проверяемое устройство ПА.
3. Система должна позволить добавить новые сигналы моделируемого
режима работы энергосистемы для всех элементов автоматики,
используемых в текущем устройстве ПА. Предусмотреть возможность
копирования/вставки
выбранных
пользователем
сигналов
моделируемого режима работы.
4. Система должна предоставить возможность указать пользователю шаг
проверки в миллисекундах (секундах) и возможность задания
динамического масштаба пользователем.
5. Система должна позволить просматривать работу устройства ПА при
различном наборе сигналов моделируемого режима работы посредством
визуального представления и в виде таблиц.
6. Система должна отобразить путь прохождения сигнала при изменении
состояний сигналов из набора моделируемого режима работы.
7. Система должна отобразить сработавшие УВ, а если таковых нет, то
оповестить пользователя об этом сообщением, при различном наборе
состояний сигналов моделируемого режима работы.
Прототипы форм для проверки моделей (функций) ПА представлены в
Приложении № 2. Альбом форм Конструктора ПА.
9.1.18. Требования к процессу согласования моделей
1. В Системе должна быть возможность согласования разработанных
моделей ПА между различными ДЦ.
2. В Системе должна быть возможность создавать, редактировать и
удалять маршруты согласования моделей ПА. Должна быть
возможность задания параллельных шагов согласования в рамках
одного маршрута.
45
3. Система должна позволять отслеживать продвижение модели ПА по
маршруту, следить за статусом согласования модели ПА, добавлять и
удалять шаги в маршруте в процессе согласования и снимать модель ПА
с маршрута согласования.
4. Модель ПА в Системе должна находиться в одном из следующих
статусов:
a. Черновик – идет разработка модели ПА и ее согласование по
маршруту;
b. Утверждена – модель ПА согласована и подписана;
c. Архив – модель ПА неактуальна и отправлена в Архив.
5. Система должна отображать версию модели ПА, проходящую маршрут
согласования.
6. Смена статусов модели ПА должна происходить автоматически. Общая
последовательность изменения статусов следующая: Черновик →
Утверждена → Архив.
7. Система должна требовать указать завершающий шаг для любого
маршрута согласования, которым должна быть завершающая подпись,
которая утверждает модель ПА.
8. Система должна запрещать редактирование модели ПА в статусе
«Утверждена».
9. Система должна позволять вручную изменить любой статус модели ПА
на «Архив» пользователям с соответствующими правами.
10.Система должна позволять копировать модели ПА с любым статусом.
Создание новой копии в Системе должно всегда создавать модель ПА со
статусом «Черновик»;
11.После утверждения модели ПА Система должна автоматически
архивировать все версии модели ПА, созданные на маршруте
согласования, кроме утвержденной.
12.Система должна позволять вносить изменения в модель ПА всем
пользователям, входящим в маршрут согласования. После сохранения
изменений должна быть возможность как отказать, так и согласовать
проект устройства ПА.
13.Система должна автоматически перемещать модель ПА (актуальную
версию модели ПА) по выбранному маршруту после завершения
согласования на каждом шаге;
14.Система должна автоматически направлять запросы на согласование
всем пользователям, указанным в маршруте;
15.Система должна уведомлять пользователей на текущем этапе
согласования об изменении версии модели.
Ниже представлена упрощенная диаграмма процесса согласования моделей
ПА в Системе.
46
9.1.19. Требования к запросу на согласование/подписание
Получателям должно приходить уведомление о поступлении модели ПА на
согласование/подписание на электронную почту и запрос на согласование модели
ПА в Системе. В уведомлении на электронную почту в теле письма должна
содержаться информация:
 наименование устройства ПА;
 информация о разработчике устройства ПА (ДЦ, ФИО, почта и номер
рабочего телефона);
 ссылка на открытие интерфейса Системы.
Получатель запроса должен иметь возможность:
 просмотреть маршрут согласования, версию модели ПА, визы
согласующих, ранее полученные на маршруте,
 редактировать устройство ПА;
 согласовать/подписать или отказать в согласовании/подписании
модели ПА. В случае отказа у согласующего должна быть возможность
оставить комментарий в Системе.
Результат обработки запроса должен прийти пользователю, который отправил
модель ПА на согласование, на электронную почту и уведомлением о согласовании
в Системе.
47
9.1.20. Требования к истории согласования
В Системе должна быть возможность просмотра истории согласования модели
ПА.
Должна быть доступна информация о выполнении каждого шага согласования
– дата и время создания запроса, дата и время предоставления ответа на запрос,
повторное направление на согласование (при наличии), ответственное лицо (с
указанием информации о пользователе (ФИО, его почта), ДЦ).
9.1.21. Требования к системе формирования отчетной документации
1. В Системе должен быть реализован модуль формирования отчетов устройств
ПА.
2. Формы отчетов должны соответствовать Приложениям 20, 25, 27, 28, 29, 30 к
Типовому положению по управлению режимами работы энергосистем в
операционной зоне диспетчерского центра АО «СО ЕЭС», утвержденному
распоряжением АО «СО ЕЭС» от 13.02.2019 № 16р.
3. Система должна формировать отчеты в формате xlsx, docx, pdf для табличных
форм отчетов и в формате и pdf для графических схем моделей ПА.
4. Система должна формировать отчеты по запросу пользователя и позволять
сохранять с выбором папки сохранения.
5. Система должна предоставлять возможность формировать отчеты для всех
видов ПА.
6. Для отчетных документов устройств ПА, содержащих крупную функциональнологическую схему, расположенную на нескольких листах, отображение блока
УВ должно осуществляться в верхней части каждого листа.
7. Система должна предоставить возможность пользователю просмотреть, как
схема модели ПА будет расположена на листах:
 А4 вертикально;
 А4 горизонтально;
 А3 вертикально;
 А3 горизонтально.
8. Для тех устройств ПА, имеющих в своем составе элемент автоматики типа КПР,
имеется возможность выгрузки логики работы КПР на отдельной странице.
48
Пример
отображения
представлен на рисунке 29.
Рисунок 29. Пример формирования отчета элемента КПР
В таблице 19 приведен состав формируемых отчетов Системой Конструктор
ПА.
Таблица 19. Состав формируемых отчетов Системой Конструктор ПА
Тип
Приложение типового ПУР, в
Формат
Используемые
устройства
соответствии с которым Система
отчета
форматы
автоматики должна формировать отчеты
АПНУ (АРО Приложения 20 "Алгоритмы работы и
Графическая
xlsx, docx, pdf СГО, АРПМ, настройка комплексов (устройств) ПА",
схема и
для табличных
АРКЗ)
Система должна сформировать
табличная
форм отчетов,
графическую модель схемы ПА в
форма
docx и pdf - для
соответствии с рисунками Приложения 20
графических схем
соответствующего типа АПНУ.
моделей ПА
Система должна сформировать табличный
отчет в соответствии с таблицами
Приложения 20.
АЛАР
Приложение 28 "Объекты
Таблица форма
электроэнергетики, на которых размещены
АЛАР, их алгоритмы функционирования и
параметры настройки"
АОПН, АОСН Приложение 25 "Объекты
Таблица форма
электроэнергетики, на которых размещены
АОПН и АОСН, их алгоритмы
функционирования и параметры
настройки"
АОПО
Приложение 29 "Объекты
Графическая
электроэнергетики, на которых размещены схема и
49
Тип
устройства
автоматики
Приложение типового ПУР, в
Формат
соответствии с которым Система
отчета
должна формировать отчеты
АОПО, их алгоритмы функционирования и табличная
параметры настройки"
форма
Используемые
форматы
АОПЧ
Приложение 27 "Информация об
Таблица форма
электростанциях, оснащенных автоматикой
запуска резервных генераторов и набора
мощности (при снижении частоты) и
автоматикой отключения генераторов (при
повышении частоты)"
АОСЧ (АЧВР, Приложение 27 "Информация об
Таблица форма
АЧР, ЧДА,
электростанциях, оснащенных автоматикой
ЧАПВ)
запуска резервных генераторов и набора
мощности (при снижении частоты) и
автоматикой отключения генераторов (при
повышении частоты)"
АОСЧ (ДАР) Приложение 30 "Объекты
Таблица форма
электроэнергетики, на которых размещены
ДАР, их алгоритмы функционирования,
параметры настройки и объемы УВ"
Используемые форматы и состав отчетов могут быть уточнены на стадии
разработки Системы Конструктор ПА.
9.1.22. Требования к экспорту параметров настройки ЛАПНУ
Система должна позволять экспортировать/импортировать параметры
устройства ПА (информацию о функциональной схеме и уставках) для создания
файла единого цифрового бланка уставок (далее ЕЦБУ). Состав и формат данных
ЕЦБУ должен соответствовать актуальной редакции ГОСТ Р 59979-2022 и может
быть уточнен в ходе разработки Системы.
9.1.23. Требования к формату данных
Система должна позволять выгружать данные, содержащие параметры
настройки и алгоритмы функционирования ЛАПНУ в формате xlsx. XLSX —
известный формат документов, входит в серию форматов файлов Office Open XML
для хранения электронных документов пакетов офисных приложений.
9.1.24. Требования к составу данных
Система должна позволять задавать и настраивать параметры ЛАПНУ
достаточные для формирования ЕЦБУ. Данные в ЕЦБУ должны быть
50
представлены в виде иерархии строк (объектов), каждая строка должна содержать
информацию о пусковом органе, схеме работы сети, сечении, критерии строки (ТС
или булева формула), направление перетока, предшествующий режим и
управляющие воздействия. Состав данных ЕЦБУ может быть уточнен на стадии
разработки Системы.
9.1.25. Требования к системе прав доступа
9.1.25.1. Требования к набору ролей пользователей
1. Для функционирования Системы необходимо обеспечить назначение
пользователям следующих ролей:
 Администратор ИА (не менее 1 в ИА АО «СО ЕЭС»);
 Технолог ИА (не менее 1 в ИА АО «СО ЕЭС»);
 Технолог филиала ДЦ (не менее 1 в каждом филиале АО «СО ЕЭС»);
 Согласующий ИА (не менее 1 в ИА АО «СО ЕЭС» и в каждом филиале АО
«СО ЕЭС»);
 Согласующий филиала ДЦ (не менее 1 в каждом филиале АО «СО ЕЭС»);
 Наблюдатель ИА (не менее 1 в ИА АО «СО ЕЭС»);
 Наблюдатель филиала ДЦ (не менее 1 в каждом филиале АО «СО ЕЭС»).
2. Система должна предоставлять возможность совмещения нескольких ролей
одним пользователем.
3. В Системе должна быть обеспечена возможность назначения предопределённой
роли группе AD. При этом администраторы AD филиалов ОДУ АО «СО ЕЭС»
должны иметь возможность назначать роли группам AD только в рамках
филиалов своей операционной зоны.
4. Разграничение полномочий доступа пользователей к информации и функциям
Системы должно быть выполнено в соответствии с принадлежностью
пользователя филиалу АО «СО ЕЭС» (РДУ, ОДУ, ИА).
5. ДЦ пользователя должен определяться однозначно по реквизиту «Организация»
учетной записи в AD.
9.1.25.2. Требования к составу прав ролей пользователей
В Системе должен быть обеспечен первоначальный набор ролей с составом
прав, представленных в таблице 20 описания ролей (может быть уточнен на
следующих этапах разработки системы).
Таблица 20. Описание ролей
51
Роли
Администра Технол Технол Согласую Согласую
тор ИА
ог ИА ог
щий ИА
щий
филиал
филиала
а ДЦ
ДЦ
+
Настройка
Системы и ее
компонентов
Управление
+
ролями
Создание,
корректировка
устройств
(функций) ПА
в Системе
Редактировани +
е внутренних
справочников
Системы
(локальной
НСИ)
Загрузка
+
корпоративной
НСИ из ОИК
СК-11
Просмотр
+
журнала
действий
Формирование +
отчетной
документации
Просмотр
журнала
действий
пользователей,
относящихся к
операционной
зоне ДЦ
Просмотр
локальной и
корпоративной
НСИ,
относящейся к
операционной
зоне ДЦ
Создание,
корректировка
моделей
устройств
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Наблюдат Наблюдат
ель ИА
ель
филиала
ДЦ
Только
просмотр
форм
+
+
+
+
+
+
+
+
+
Только
просмотр
форм
52
Роли
Ф(функций) ПА
у в Системе,
н относящихся к
к операционной
ц зоне ДЦ
и Формирование
и отчетной
документации
устройств
(функций) ПА
в Системе,
относящихся к
операционной
зоне ДЦ
Согласование
устройств
(функций) ПА
в Системе
Согласование
устройств
(функций) ПА
в Системе,
относящихся к
операционной
зоне ДЦ
Архивировани
е моделей
устройств ПА
Архивировани
е моделей
устройств ПА,
относящихся к
операционной
зоне ДЦ
Изменение
+
состава прав
предопределен
ных ролей и
создание
новых ролей
+
+
+
+
+
+
+
+
+
+
Опционально должна быть доступна функция, которую можно предоставить
пользователю или группе индивидуально: Утверждающая подпись устройств
(функций) ПА в Системе
6. Функции в Системе из таблицы 20 должны быть предоставлены указанным
ролям по умолчанию.
7. Перечисленные функции в Системе из пункта 1 настоящего раздела должны
быть отображены в виде списка с выбором каждой функции на запись или
чтение для каждого пользователя или группы.
53
9.1.26. Требования к системе журналирования
1. Система журналирования (архив событий) должна обеспечивать формирование
записи в журнал событий при каждом изменении состояния Системы.
2. Система журналирования должна обеспечивать фиксацию возникающих в
Системе событий и действий пользователей в следующих журналах:
 журнал изменений НСИ, на основе которой формируются модели
устройств (функций) ПА;
 журнал действий в устройствах ПА (должен содержать действия
пользователей, не связанные с изменениями НСИ);
 журнал фиксации изменений настроек Системы Конструктора ПА.
3. Все сообщения должны иметь метку времени, краткое описание и результат
действия. Если действие производится пользователем, то отображать логин
пользователя и его роль для последующего анализа.
4. Система журналирования должна обеспечивать возможность фильтрации,
упорядочивания, поиска, просмотра и печати записей журналов за выбранный
пользователем промежуток времени.
5. Перечень событий журнала изменений НСИ:
 загрузка новой НСИ;
 автоматическое обновление НСИ.
6. Перечень событий журнала действий в устройствах ПА:
 создание/удаление устройства ПА;
 внесение изменений в любой элемент автоматики;
 создание/удаление/изменение перечня сигналов проверки устройства ПА;
7. Перечень событий журнала фиксации изменений настроек Системы
Конструктора ПА.
 фиксация любых изменений настроек Системы;
 добавление нового пользователя в Систему с назначенной ролью ему и
выданными правами;
 фиксация изменений в правах доступа любого пользователя.
Перечень событий и действий пользователей, фиксируемых в журналах
Системы, может быть уточнен на этапе разработки Системы.
54
9.2. Нефункциональные требования
9.2.1. Требования к информационной безопасности
Система должна обеспечивать:
 защиту от несанкционированного доступа к информации, хранящейся в
базе данных Системы;
 ведения журнала всех действий пользователя в модернизируемой части
Системы, и там, где это возможно, сохранение истории изменённых
пользователем данных;
 аутентификацию и авторизацию пользователей с использованием учетных
записей из Active Directory;
 разграничение полномочий доступа пользователей на уровне
пользовательского интерфейса и запросов к API путём назначения
каждому
пользователю
Системы
одной
или
нескольких
предопределенных ролей;
 аутентификацию компонентов Системы при обращении к API со стороны
компонентов;
 возможность обращения к функциям API по защищённому протоколу
HTTPS с криптографической защитой не ниже TLS 1.2 (при этом ключ
электронной подписи и сертификат выпускаются силами и средствами
Заказчика).
 Основные элементы информационной безопасности вĸлючают в себя:
 шифрование ĸаналов связи для всех пользователей и внешних систем
посредством использования протоĸола https;
 взаимодействие между ĸомпонентами сети посредством ĸаналов связи,
доступных тольĸо внутри системы;
 доступ ĸ НСИ, данным и фунĸциям системы с помощью прав, основанных
на ролевой модели пользователей/внешних систем.
9.2.2. Требования к визуализации
Интерфейс должен быть выдержан в едином стиле для всех разделов Системы.
Все формы отображения должны иметь единообразную компоновку и не
противоречащие друг другу правила работы. Для обеспечения этого соответствия
все формы отображения и свойства выводимых значений (формат, шрифт) должны
быть основаны на единых библиотеках стилей.
Интерфейс Системы должен позволять решать задачи пользователя наиболее
быстрым и простым способом: доступ к любой функции Системы должен
осуществляться посредством минимально возможного количества команд. Для
ускорения и упрощения работы в интерфейсе Системы должны быть реализованы:
55
 возможность использования сочетания клавиш, для выполнения действий
на форме отображения;
 возможность отмены последних правок данных, выполненных на форме
отображения;
 возможность вызова функций из контекстного меню, вызываемого
нажатием правой кнопки мыши на объекте Системы;
 возможность выбора подлежащих вводу данных из предопределенного
списка;
 проверка введенных данных на корректность.
Доступ к основным функциям Системы (в т.ч. управление настройками
текущей формы) должен осуществляться с активной (текущей) формы.
Интерфейс Системы должен предоставлять доступ к функциям и данным
согласно роли пользователя, а также ДЦ пользователя.
Отображение экранных форм, результатов моделирования и данных,
полученных из внешних систем, должно производиться в соответствии с часовым
поясом, указанным в настройках операционной системы пользователя.
Интерфейс должен масштабироваться при изменении разрешения экрана,
используемого в операционной системе (все элементы управления должны быть
доступны пользователю).
В Системе должен быть реализован как минимум следующий состав форм
визуализации:
главная форма отображения;
 формы отображения справочников НСИ;
 форма администрирования прав пользователей;
 форма настройки взаимодействия с ИУС АО «СО ЕЭС»;
 форма настройки хранения данных в Системе;
 форма для моделирования устройств (функций) ПА;
 форма для проверки устройств (функций) ПА;
 форма отображения журнала работы Системы.
В заголовке главной формы отображения (форме, на которой у пользователя
должна быть возможность перейти ко всем реализованным формам отображения)
должно быть указано краткое наименование Системы. В общей для всех форм
отображения области должны отображаться ФИО, роль и ДЦ текущего
пользователя.
Элементы управления на всех формах отображения должны быть
сгруппированы согласно выполняемым функциям.
Каждый элемент управления должен иметь наименование. В случае, если
наименование элемента управления превышает его размеры, элемент должен быть
обозначен пиктограммой. При наведении курсора мыши на элемент управления во
всплывающей подсказке должно отобразиться его полное наименование.
Отображение элементов управления в активированном состоянии должно
визуально отличаться от их отображения в не активированном состоянии.
56
В случае невозможности размещения информации в пределах экрана на форме
отображения необходимо реализовать полосы горизонтальной/вертикальной
прокрутки.
9.2.3. Требования к отображению справочной информации
У пользователя должна иметься общая и конкретная контекстно-зависимая
справочная информация, содержащая описание всех компонентов Системы и
методов решения проблем, возникающих в процессе эксплуатации. Доступ к
справочной информации должен осуществляться:
 путем нажатия на соответствующую кнопку в интерфейсе Системы;
 путем выбора соответствующего пункта в меню «Справка»;
 посредством подсказок, которые отображаются, когда метка курсора
помещается над соответствующим элементом формы отображения.
Справочная информация должна быть реализована в виде встроенной
документации, доступ к которой должен осуществляться посредством
пользовательского интерфейса.
Время отображения подсказки должно быть неограниченно, её закрытие
должно выполняться при перемещении указателя мыши с объекта, для которого
отображается подсказка.
Если подсказка содержит большой объем информации, должен
осуществляться перенос текста по словам на несколько строк для отображения
всего сообщения. В случае, если для отображения сообщения во всплывающей
подсказке требуется более 5 строк, во всплывающей подсказке должна быть
реализована полоса вертикальной прокрутки.
9.2.4. Требования к отображению табличных форм
Табличные формы отображения информации должны удовлетворять
следующим требованиям:
 заголовки столбцов таблицы должны переноситься на следующую строку
для обеспечения полного отображения заголовка и сохранения заданной
ширины столбца (но не более трех строк);
 верхняя строка и первый столбец таблицы, при наличии в них заголовков
столбцов и наименований строк, должны быть зафиксированы и не
должны смещаться при использовании вертикальных и/или
горизонтальных полос прокрутки;
 пользователю
должна
быть
предоставлена
возможность
отображать/скрывать определенные столбцы таблицы;
 пользователю должна быть предоставлена возможность контекстного
поиска информации по таблице;
 пользователю должна быть предоставлена возможность сортировки по
возрастанию/убыванию информации по всем столбцам таблицы;
57
 пользователю
должна
быть
предоставлена
возможность
последовательной сортировки по любым нескольким столбцам таблицы;
 пользователю должна быть предоставлена возможность настройки
перечня, последовательности и ширины отображаемых столбцов таблицы;
 при необходимости в табличной форме должны быть реализованы
вертикальные и горизонтальные полосы прокрутки для обеспечения
возможности просмотра всех столбцов и строк таблицы;
 при добавлении новой строки таблицы, она должна становиться активной,
а вертикальная полоса прокрутки должна устанавливаться таким образом,
чтобы обеспечивать отображение вновь добавленной строки;
 при сохранении внесенных изменений должны быть сохранены
выбранные до корректировок настройки сортировки и фильтрации
табличной формы.
Многостраничные формы отображения таблиц должны удовлетворять
дополнительным требованиям:
 пользователю должна быть предоставлена возможность выбора
количества отображаемых на странице строк;
 пользователю должна быть предоставлена возможность перехода на
любую страницу таблицы, в том числе последующую и предыдущую.
9.2.5. Требования к производительности
Время отклика интерфейса Системы на действия пользователя не должно
превышать 1 секунды.
Время формирования Системой отчета не должно превышать 10 секунд.
9.2.6. Требования к лингвистическому обеспечению Системы
Должна быть обеспечена поддержка английского (латинского) и русского
(кириллического) алфавитов. Русские буквы (и язык) должны использоваться при
создании и представлении форм отображения Системы.
Должны обеспечиваться интерактивные возможности пользовательского
интерфейса по вводу и отображению как русского, так и английского алфавитов.
Все формы отображения, предназначенные для использования пользователем,
должны быть представлены на русском языке. Сюда должны входить все формы
отображения, включая экраны со справочной информацией, сообщения о
взаимодействии с пользователем, предупреждающие (аварийные) сообщения,
меню и любые другие формы или сообщения. Формы и интерфейсы программного
обеспечения третьих сторон (формы командных строк операционной системы), а
также инструменты для поддержки и ведения системы управления базой данных и
т.п., если доступно, должны быть предоставлены на русском языке.
58
Данные, вводимые пользователем (например, тексты баз данных, тексты
примечаний) должны быть представлены на том языке, на котором они вводятся:
русский, английский, комбинация русских и английских символов.
9.2.7. Требования к дистрибутиву
При подготовке дистрибутива Системы, работающей под управлением
операционной системы семейства Linux, должны быть учтены следующие
требования:
1. Дистрибутив Системы должен содержать только прикладное программное
обеспечение, в том числе необходимые для работы Системы файлы
конфигурации;
2. В части установки системного программного обеспечения должен быть
представлен полный список компонентов системного и связующего
программного обеспечения (включая зависимости от иных компонентов,
требующих предварительной установки и настройки). В случае
использования
параметров
установки
системного
программного
обеспечения, отличных от заданных по умолчанию, в руководстве
системного администратора Системы должен быть подробно описан процесс
их установки и настройки, а также для каждого компонента должен быть
разработан и приложен пример конфигурации, содержащий необходимые
изменения в файле конфигурации «по умолчанию» с комментариями по
назначению и установленному значению для каждого параметра;
3. В случае необходимости для работы Системы системного ПО,
отсутствующего у Заказчика и в репозиториях ОС Astra Linux, дистрибутивы
такого ПО должны быть предоставлены Исполнителем для помещения в
корпоративный репозиторий Заказчика, и устанавливаться оттуда. Не
допускается установка любых компонентов Системы из сети интернет;
4. Не допускается использование технологий контейнеризации для системного
и связующего программного обеспечения;
5. Прикладное программное обеспечение в составе дистрибутива Системы
должно быть разработано с учетом требований Технологического стека
программного обеспечения, утвержденного Директором по цифровой
трансформации АО «СО ЕЭС» (актуальная редакция Протокола совещания
предоставляется Заказчиком Исполнителю);
6. Дистрибутив Системы должен предоставляться в виде стандартного
инсталляционного deb пакета (пакетов, в случае необходимости разделения
по функциональному назначению) для операционной системы Astra Linux.
При подготовке инсталляционного пакета (-ов) должно быть выполнено
следующее:
- сформирован файла манифеста, как минимум содержащий:
i. имя пакета;
ii. версия пакета;
59
iii. зависимости от необходимых для работы прикладного
программного обеспечения пакетов (за исключением системного
программного обеспечения);
iv. пакеты, вызывающие конфликты (программное обеспечение,
которое не должно быть установлено, в т.ч. системное);
v. описание пакета;
vi. описание архитектуры системы, в которой можно установить
пакет;
- все необходимые настройки компонентов программного обеспечения
должны выполняться скриптами установки (preinst, postinst, prerm,
postrm);
- настроено логирование установочного процесса в syslog или
отдельный файл лога установки;
- в скриптах установки Системы не допускается использование систем
управления конфигурациями SCM (Ansible, Puppet, Chef и т.д.).
7. В случае использования для запуска прикладного программного обеспечения
Системы технологий контейнеризации (Docker) на этапе планирования и
подготовки дистрибутива должно быть выполнено следующее:
- базовый образ, используемый в контейнерах, должен соответствовать
требованиям настоящих ТТ (должен быть подготовлен на основании
разрешенной в АО «СО ЕЭС» к использованию версии ОС Linux);
- образы используемых в Системе контейнеров должны собираться в
АИС «ФПА» Заказчика на основании переданных Исполнителем
файлов с инструкциями (Docker файлов) с последующим размещением
собранных образов в корпоративном репозитории Заказчика;
- операции по скачиванию, обновлению образа контейнера, запуска
контейнера на выполнение должны выполняться в рамках исполнения
скриптов в составе инсталляционного deb пакета (-ов);
- обновление образа контейнера должно выполняться путем скачивания
образа из корпоративного репозитория Заказчика;
8. Прикладное программное обеспечение Системы, передаваемое в составе
дистрибутива, должно создаваться путем компиляции и сборки в АИС
«ФПА» Заказчика из переданного Исполнителем Заказчику исходного текста
(кода) Системы;
9. Детальные требования и состав дистрибутивов прикладного программного
обеспечения Системы должны быть согласованы с Заказчиком.
В случае развертывания компонентов Системы (веб-сервер / сервер
приложений / сервер БД) на отдельных серверах в состав дистрибутива Системы
должны входить инсталляционные пакеты для каждого из компонентов.
При подготовке дистрибутива Системы должна быть предусмотрена
возможность деинсталляции Системы (компонентов Системы) с учетом
технических особенностей используемой операционной системы.
60
При выполнении обновления Системы (компонентов Системы) должна быть
обеспечена возможность возврата к предыдущей версии Системы, а также
повторного выполнения процедуры обновления.
9.2.8. Требования к категорийности Системы
Система должна относиться ко 2 категории оперативного обслуживания –
категория систем базового приоритета оперативного обслуживания. Системы
данной категории требуют оперативного обслуживания и обеспечения их
работоспособности подразделениями блока информационных технологий.
61
10.ЭТАПЫ СОЗДАНИЯ СИСТЕМЫ
Функции системы предполагается реализовывать тремя этапами – разработка
MVP, испытание MVP и итеративное развитие по беклогу фукнций. В процессе
итерационного развития Системы новые функции поставляются в виде обновлений
для установки на полигон в целях апробации и демонстрации прогресса.
10.1. Этап 1 Разработка MVP.
Разработка базовых полезных функций для запуска пилотной версии Системы.
Состав функций этапа:
 загрузка в Систему корпоративной НСИ путем ручного импорта
(загрузки) файла (CIM XML или другой по согласованию с Заказчиком);
 формы работы с корпоративной НСИ (таблицы и детальные формы для
просмотра и редактирования);
 формы работы с внутренними справочниками Системы;
 создание и редактирование устройств автоматики – заведение типа,
производителя и параметров устройства (кроме АЛАР);
 создание, редактирование и привязка к корпоративной НСИ типовых
элементов автоматики (стандартные типы элементов, их параметры
настройки);
 добавление и редактирование логики в графическом редакторе –
элементов автоматики, связей, вспомогательных элементов и
переключающих элементов на графической схеме;
 добавление и редактирование логики в табличном редакторе;
 поиск и навигация на графической схеме модели ПА с помощью панелей
управления, мыши и горячих клавиш;
 автоматизированное создание версий устройства ПА;
 восстановление версии устройства ПА из ранее созданных;
 эмуляция сигнала в режиме «Проверка корректности собранной схемы»;
 настройка прав доступа;
 автоматизированное сохранение черновика модели ПА и его
восстановление в случае некорректного завершения работы с вебприложением.
Состав работ этапа:
 разработка и добавление в Систему устройств автоматики (в объеме
необходимом и достаточном для проведения ПМИ);
 разработка алгоритма функционала проверки корректности собранной
схемы;
 разработка CIM профиля в объеме, необходимом для описания
представленной в Системе автоматики;
 разработка ТТ на организацию приема данных из Системы (в формате
CIM) для каждой ИУС Заказчика (Rastr, ЦСПА/СМЗУ, СМФУ ПА).
62
10.2. Этап 2 Испытание MVP.
Испытание базовых функций и согласование пакета документации для запуска
пилотной версии Системы. Состав работ этапа:
 разработка и согласование с Заказчиком руководства пользователя,
руководства администратора;
 разработка и согласование с Заказчиком ПМИ;
 проведение испытаний MVP на полигоне Заказчика.
10.3. Этап 3 Итеративное развитие.
Итеративное развитие функциональности Системы небольшими итерациями
(длина итерации не более 2-3 месяцев).
Функции по развитию редактора автоматики:
 библиотеки шаблонов устройств ПА;
 создание и моделирование устройств ПА типа АЛАР;
 использование укрупненных блоков при моделировании устройств ПА;
 эмуляция сигнала в режиме «Проверка модели (функции) ПА в
динамическом режиме»;
 автоматизированный экспорт корпоративной НСИ из ОИК СК-11;
 создание и использование при моделировании устройств ПА нетиповых
элементов автоматики.
Функции модуля согласования:
 уведомление пользователя о событиях внутри Системы;
 настройка уведомлений в Системе (по группам и ролям);
 отправка уведомлений пользователю на почту;
 фиксация действий пользователя в архиве событий;
 формы для согласования моделей ПА.
Функции по интеграции с внешними ИУС:
 API Системы для доступа к моделям ПА в формате CIMXML;
 экспорт\импорт моделей ПА в формате CIMXML через пользовательский
интерфейс Системы;
 экспорт\импорт параметров настройки ЛАПНУ в формате ЕЦБУ;
 публикация моделей ПА в ОИК СК-11 в формате CIMXML.
Функции модуля генерации отчетов:
 формирование табличных отчетов в xlsx;
 формирование табличных отчетов в docx;
 формирование табличных отчетов в pdf;
 построение функционально-логической схемы в отчетах;
 предпросмотр функционально-логической схемы перед формированием
отчета;
63
 формирование отчета элементов автоматики КПР отдельно, с указанием
приходящих сигналов (ветвей) на КПР, в которых происходит замер
физической величины.
64
ПРИЛОЖЕНИЕ 1. ПРОФИЛЬ ИНФОРМАЦИОННОЙ МОДЕЛИ
Для обмена моделями (функциями) ПА разработан проект профиля
информационной модели, представленный в Приложение № 1. Профиль
информационной модели.
Профиль информационной модели должен быть скорректирован, при
необходимости, и дополнен на этапах создания Системы, согласован с Заказчиком.
.
В настоящий момент времени все действующие системы, работающие с
моделями (функциями) ПА: RUStab, СМЗУ, ЦСПА-3, ЦСПА Сибири, СМФУ ПА,
имеют очень ограниченный функционал по способам внешнего информационного
обмена в части моделей ПА, использование CIM-гармонизированных стандартов в
них не предусмотрено. Внутренняя логика учета функций ПА этих комплексов не
позволяет реализовать весь потенциал CIM моделирования без их
соответствующей модернизации.
Находящиеся в промышленной эксплуатации в ДЦ АО «СО ЕЭС» указанные
выше программные комплексы - RUStab, СМЗУ, ЦСПА-3 – обладают собственным
оригинальным языком описания функций ПА, позволяющим сообщить расчетным
алгоритмам всю требуемую на настоящий момент информацию и хранить ее в
табличном или графическом виде.
Таким образом, вплоть до соответствующей модернизации RUStab, СМЗУ,
ЦСПА-3 и других комплексов, использование CIM профиля описания функций ПА
потребует разработки соответствующих конвертеров двусторонней интеграции.
Абстрактные классы
Перечень необходимых абстрактных классов профиля информационной
модели приведен в таблице 1.
Таблица 1. Абстрактные классы профиля информационной модели
Смысловое определение абстрактного Имя класса (англ.)
класса
Полюс постоянного и переменного тока ACDCTerminal
(точка электрического подключения (на
переменном или постоянном токе) к
элементу электросилового оборудования.
Полюса присоединяются к физическим
местам присоединения – Точкам
подключения)
Вспомогательное оборудование (единица AuxiliaryEquipment
вспомогательного оборудования. Не
несёт основных функций, но
способствует их несению иным
оборудованием. Вспомогательное
оборудование привязывается к
основному ссылкой на его полюс)
Электропроводящее оборудование
ConductingEquipment
Проводник
Conductor
Имя вышестоящего
класса (англ.)
IdentifiedObject
Equipment
Equipment
ConductingEquipment
65
Смысловое определение абстрактного Имя класса (англ.)
Имя вышестоящего
класса
класса (англ.)
Контейнер соединительных узлов
ConnectivityNodeContainer PowerSystemResource
Соединительный проводник
Connector
ConductingEquipment
Оборудование
Equipment
PowerSystemResource
Контейнер оборудования
EquipmentContainer
ConnectivityNodeContainer
Энергоблок
GeneratingUnit
Equipment
Идентифицирующий класс —
IdentifiedObject
обеспечивает идентификацию и набор
наименований для наследуемых классов
Обобщенный объект энергосистемы
PowerSystemResource
IdentifiedObject
Первичный двигатель
PrimeMover
PowerSystemResource
Защищающий коммутационный аппарат ProtectedSwitch
Switch
Регулирующее электропроводящее
RegulatingCondEq
ConductingEquipment
оборудование (единица электросилового
оборудования, способная управлять
параметрами режима сети (напр.,
напряжением или перетоком мощности))
Вращающаяся машина
RotatingMachine
RegulatingCondEq
Измерительное устройство
Sensor
AuxiliaryEquipment
Шунтирующее компенсирующее
ShuntCompensator
RegulatingCondEq
устройство
Коммутационный аппарат
Switch
ConductingEquipment
Электрический вывод трансформатора
TransformerEnd
IdentifiedObject
Оборудование
Equipment
PowerSystemResource
Функция РЗА — функционально
ProtectionEquipment
Equipment
завершенный алгоритм
функционирования устройства РЗА,
позволяющий на основе информации,
полученной от измерительных органов
устройства РЗА и (или) от других
устройств (функций) РЗА, выявлять
повреждения, отключения оборудования
(ЛЭП) или другие ненормальные режимы
и в соответствии с заданными
параметрами настройки действовать на
предотвращение развития и ликвидацию
нарушения нормального режима, а также
на изменение параметров режима
энергосистемы (частоты электрического
тока, напряжения, активной и реактивной
мощности) в соответствии с Правилами
технического учета и анализа
функционирования релейной защиты и
автоматики (утверждены Приказом
Минэнерго России от 8 февраля 2019 г.
№ 80)
Событие срабатывания, пуска или отказа PACSOperationEvent
ActivityRecord
66
Смысловое определение абстрактного Имя класса (англ.)
класса
РЗА
Имя вышестоящего
класса (англ.)
Основные классы
Перечень необходимых основные классов профиля информационной модели
приведен в таблице 2.
Таблица 2. Основные классы профиля информационной модели
Смысловое определение
Имя класса (англ.)
основного класса
Участок линии переменного
ACLineSegment
тока
Материальный объект
Asset
Материальный объект,
AssetContainer
который может состоять из
других материальных объектов
Асинхронная машина
AsynchronousMachine
Стандартное номинальное
BaseVoltage
напряжение
Ячейка распределительного
Bay
устройства (класс,
предназначенный для
группировки оборудования,
обычно обозначающий ячейку
распределительного
устройства)
Выключатель
Breaker
Секция шин
BusbarSection
Газовая турбина
CombustionTurbine
Трансформатор тока
CurrentTransformer
Трансформатор напряжения
PotentialTransformer
Федеральный округ
GeographicalRegion
Российской Федерации
Гидрогенератор
HydroGeneratingUnit
Гидротурбина
HydroTurbine
ЛЭП
Line
Линейное шунтирующее
LinearShuntCompensator
компенсирующее устройство
(секции линейного
шунтирующего
компенсирующего устройства
всегда имеют равные
проводимости)
Выключатель нагрузки
LoadBreakSwitch
Типизированное
Name
Имя вышестоящего класса
(англ.)
Conductor
IdentifiedObject
Asset
RotatingMachine
IdentifiedObject
EquipmentContainer
ProtectedSwitch
Connector
PrimeMover
Sensor
Sensor
IdentifiedObject
GeneratingUnit
PrimeMover
EquipmentContainer
ShuntCompensator
ProtectedSwitch
-
67
Смысловое определение
Имя класса (англ.)
основного класса
дополнительное наименование
Тип наименования
NameType
Нелинейное шунтирующее
NonlinearShuntCompensator
компенсирующее устройство
(секции нелинейного
шунтирующего
компенсирующего устройства
могут иметь неравные
проводимости)
Атомный энергоблок
NuclearGeneratingllnit
Организация
Organisation
Типизированная роль
OrganisationRole
организации по отношению к
другим объектам
информационной модели
Электростанция
Plant
Силовой трансформатор
PowerTransformer
Тип объекта энергосистемы
PSRType
Секционирующий пункт
Recloser
Продольное компенсирующее SeriesCompensator
устройство
Регулируемое шунтирующее StaticVarCompensator
компенсирующее устройство
(например, статический
тиристорный компенсатор)
Паровая турбина
SteamTurbine
Субъект Российской
SubGeographicalRegion
Федерации
Подстанция
Substation
Синхронная машина
SynchronousMachine
Полюс электропроводящего
Terminal
оборудования (элемент модели
для обозначения
электрического подключения к
электропроводящему
оборудованию)
Тепловой энергоблок
ThermalGeneratingUnit
Распределительное устройство VoltageLevel
Ветроэлектрогенератор
WindGeneratingUnit
Линия постоянного тока
DCLine
Обобщенный объект
PowerSystemResource
энергосистемы
Ответственный за
ModelingAuthority
моделирование
Имя вышестоящего класса
(англ.)
ShuntCompensator
GeneratingUnit
IdentifiedObject
IdentifiedObject
EquipmentContainer
ConductingEquipment
IdentifiedObject
ProtectedSwitch
ConductingEquipment
RegulatingCondEq
PrimeMover
IdentifiedObject
EquipmentContainer
RotatingMachine
ACDCTerminal
GeneratingUnit
EquipmentContainer
GeneratingUnit
DCEquipmentContainer
IdentifiedObject
IdentifiedObject
68
Смысловое определение
Имя класса (англ.)
основного класса
Набор ответственный за
ModelingAuthoritySet
моделирование
Диспетчерский центр
ControlAreaOperator
Производитель техники
Manufacturer
Сечение
BranchGroup
Энергопотребитель
EnergyConsumer
Вид параметра, которым может RegulatingControlModeKind
управлять регулятор:
напряжение, мощность,
коммутационное состояние
Контейнер материальных
PACSDevice
объектов, содержащий одну
или несколько функций РЗА.
Развернутое определение
данного класса:
Моделирование материальных
объектов устройств РЗА
выполняется с использованием
класса PACSDevice, который
является наследником класса
cinrAssetContainer и
представляет собой контейнер
материальных объектов.
Под устройствами РЗА в
данном контексте понимаются
аппараты, терминалы, блоки,
шкафы, панели и прочие
материальные объекты,
реализующие заданные
функции РЗА. Все эти
сущности моделируются
одним классом PACSDevice, а
их типизация выполняется с
помощью предиката
PACSDevice.kind.
Моделирование любого
устройства РЗА
обеспечивается свободной
комбинацией вложенных друг
в друга материальных
объектов, с использованием
ассоциации часть-целое
cim:Asset.AssetContainer.
Непротиворечивость модели
обеспечивается на уровне
программного обеспечения, в
котором производится
моделирование
Имя вышестоящего класса
(англ.)
IdentifiedObject
Organisation
OrganisationRole
LoadSheddingStage
-
AssetContainer
69
Смысловое определение
Имя класса (англ.)
основного класса
Функция релейной защиты
RelayProtection
Функция противоаварийной
EmergencyControlAutomation
автоматики
Аварийное событие,
Fault
вызывающее возмущение в
энергосистеме (под аварийным
событием понимается не
только замыкание, а любое
возмущение в энергосистеме
(качание, асинхронный ход,
замыкание и т. д.). Тип этого
возмущения указывается с
помощью класса FaultType)
Аварийное событие на ЛЭП
LineFault
Аварийное событие на единице EquipmentFault
силового оборудования
Измерение. Представляет
Measurement
собой любую измеряемую,
вычисляемую или
неизмеряемую и
невычисляемую величину.
Любая единица оборудования
может быть охвачена
измерениями, напр., на
подстанции может измеряться
температура и
контролироваться открытость
дверей, у трансформатора
могут измеряться температура
и давление масла, в ячейке
может быть несколько
измерений мощности, а у
выключателя может
контролироваться
коммутационного состояние.
Связь Энергообъект–
Измерение полезна для
навигации по названиям,
основанной на Контейнерах
оборудования. Измерения в
дереве названий обычно
являются листьями, например,
ПС–РУ–Ячейка–
Коммутационный_аппарат–
Измерение.
Некоторые Измерения
представляют величины,
характеризующие конкретное
Имя вышестоящего класса
(англ.)
ProtectionEquipment
ProtectionEquipment
IdentifiedObject
Fault
Fault
IdentifiedObject
70
Смысловое определение
Имя класса (англ.)
основного класса
место установки датчика в
сети, например, трансформатор
напряжения (ТН) на шинах или
трансформатор тока (ТТ),
установленный между
выключателем и
разъединителем.
Местоположение датчика не
фиксируется ссылкой
Энергообъект–Измерение. Оно
определяется связью
Измерение–Полюс, которая
обеспечивает и
топологическую привязку
датчика, и привязку его к
Единице оборудования.
Возможны два варианта
построения пути по дереву
названий:
1) Измерение–Полюс–
ТочкаПодключения–Полюс–
ЕдиницаОборудования
2) Измерение–Полюс–
ЕдиницаОборудования
Разрешён только второй.
Если требуется указать
местоположение датчика,
используются обе ссылки:
Измерение–Энергообъект и
Измерение–Полюс. Связь же
Измерение–Полюс по
отдельности никогда не
используется.
Вторичная обмотка
PotentialTransformerWinding
трансформатора напряжения.
(пакет GOSTR58651)
Вторичная обмотка
CurrentTransformerWinding
трансформатора тока. (пакет
GOSTR58651)
Автоматика ограничения
LoadSheddingEquipment
потребления (пакет
Protection_me)
Ступень устройства релейной PEStage
защиты или автоматики (пакет
Protection_me)
Логический вентиль, который SIPSGate
поддерживает логические
операции над входными
Имя вышестоящего класса
(англ.)
SensorWinding
SensorWinding
EmergencyControlAutomation
PowerSystemResource
IdentifiedObject
71
Смысловое определение
Имя класса (англ.)
основного класса
данными (пакет infSIPS)
Выход с одного вентиля
PinGate
представляет из себя вход для
другого (пакет infSIPS)
Входные сигналы для
GateInputPin
логического вентиля. Условия,
описанные входным сигналом,
преобразуются в true или false.
Результат измерений или
вычислений преобразуется в
true или false. (пакет infSIPS)
Числовое значение уставки, с ThresholdValue
которым выполняется
сравнение входного сигнала
вентиля (пакет SIPS_me)
Значение, связанное с полюсом PinTerminal
и используемое для сравнения
(пакет infSIPS)
Значение, связанное с
PinBranchGroup
сечением и используемое для
сравнения (пакет infSIPS)
Значение, связанное с
PinEquipment
оборудованием и используемое
для сравнения (пакет infSIPS)
Входной сигнал, который
PinMeasurement
связан с измерением или
расчетным значением по
измерениям (пакет infSIPS)
Управляющие воздействия,
ProtectiveAction
обеспечивающие сохранение
целостности энергосистемы
(пакет infSIPS)
Совокупность управляющих
ProtectiveActionCollection
воздействий
Управляющие воздействия по ProtectiveActionEquipment
вводу/выводу оборудования из
работы (пакет infSIPS)
Управляющие воздействия в ProtectiveActionRegulation
виде изменение параметра
регулятора оборудования
(пакет infSIPS)
Управляющее воздействие на ProtectiveActionAdjustment
некоммутационное
оборудование. Обеспечивает
изменение режимного
параметра (пакет infSIPS)
Управляющее воздействие
ProtectiveActionPEStage
Имя вышестоящего класса
(англ.)
GateInputPin
IdentifiedObject
-
GateInputPin
GateInputPin
GateInputPin
GateInputPin
IdentifiedObject
IdentifiedObject
ProtectiveAction
ProtectiveAction
ProtectiveAction
ProtectiveAction
72
Смысловое определение
Имя класса (англ.)
основного класса
ступени РЗА на ступени иных
РЗА (пакет infSIPS)
Блокировка ступени РЗА
PEStageBlocking
(пакет Protection_me)
Блокировка с
UnformalizedBlocking
неформализованным
описанием (пакет
Protection_me)
Блокировка, условия
FormalizedBlocking
срабатывания которой
описываются уставкой (пакет
Protection_me)
Ступень устройства РЗА,
LoadSheddingStage
действующая на отключение
нагрузки. Используется в
случае упрощенного
представления нагрузок в
модели, когда несколько
потребителей представлены
одним объектом. Позволяет
как отключать выключатель
нагрузки, так и снижать
частично заданное значение
нагрузки (пакет Protection_me)
Ступень устройства РЗА,
GenerationUnloadingStage
действующая на разгрузку
турбин и отключение
генераторов. Позволяет как
отключать генераторы, так и
снижать заданное значение
генерации (пакет
Protection_me)
Ступень токовой защиты
CurrentFlowStage
(пакет Protection_me)
Уставка устройства РЗА (пакет PESetpoint
Protection_me)
Устака ступени РЗА (пакет
PEStageSetpoint
Protection_me)
Уставка для описания условий BlockingSetpoint
срабатывания блокировки
ступени РЗА (пакет
Protection_me)
Имя вышестоящего класса
(англ.)
PEStageBlocking
PEStageBlocking
PEStage
PEStage
PEStage
IdentifiedObject
PESetpoint
PESetpoint
Перечень атрибутов классов
Перечень необходимых атрибутов приведен в таблице 3.
Таблица 3. Атрибуты классов информационной модели
73
Смысловое
Имя атрибута (англ.)
назначение
атрибута
Порядковый
sequenceNumber
номер полюса
электропроводящ
его оборудования
Значение
nominalVoltage
номинального
напряжения, кВ
Присвоенное
normallylnService
значение
«Истина»
признак того, что
оборудование
находится в
работе
Дополнительное aliasName
наименование
идентифицируем
ого объекта
Описание
description
объекта
информационной
модели
Глобальный
mRID
уникальный
идентификатор
объекта
информационной
модели
Имя класса атрибута
(англ.)
Тип данных
ACDCTerminal
Положительное целое
BaseVoltage
Вещественный
Equipment
Логический
IdentifiedObject
Строка
IdentifiedObject
Строка
IdentifiedObject
Наименование
name
объекта
информационной
модели (если
объект модели
имеет
диспетчерское
наименование, то
указывается
диспетчерское
наименование)
Типизированное name
дополнительное
наименование
объекта
информационной
модели
Тип
name
IdentifiedObject
UUID (тип представляет
собой 16-байтный (128битный) номер в
шестнадцатеричной
системе счисления, как
определено в ГОСТ Р
ИСО/МЭК 9834-8)
Строка
Name
Строка
NameType
Строка
74
Смысловое
Имя атрибута (англ.)
назначение
атрибута
наименования
Версия алгоритма algorithmVersion
функционирован
ия (данный
атрибут следует
применять только
для
микропроцессорн
ых устройств
РЗА)
Версия
firmwareID
программного
обеспечения,
установленного
на устройстве
РЗА
Вид контейнера kind
материальных
объектов,
содержащего
одну или
несколько
функций РЗА
Элементная база elementBaseKind
контейнера
материальных
объектов,
содержащего
одну или
несколько
функций РЗА
Тип аварийного type
события
Логическая
kind
операция вентиля
Если true, то
absoluteValue
используется
модуль для
сравнения
Операция
aDLogicKind
сравнения
Значение
precedingStateControl
контролируется в
текущем или в
предыдущем
режиме? КПР?
Имя класса атрибута
(англ.)
Тип данных
ProtectionEquipment
Строка
PACSDevice
Строка
PACSDevice
PACSDeviceKind
PACSDevice
ElementBaseKind
Fault
FaultType
SIPSGate
GateLogicKind
GateInputPin
Логический
GateInputPin
AnalogToDigitalLogicKind
GateInputPin
Логический
75
Смысловое
Имя атрибута (англ.)
назначение
атрибута
Инверсия/
negate
отрицание
результата
сравнения
Длительность, в duration
течение которой
должны
выполняться
условия
сравнения для
достижения true.
По умолчанию
равно 0 секунд.
Номер группы
groupNumber
уставок
Значение уставки value
Вид блокировки kind
срабатывания
ступени РЗА
Коррекция
byPercentage
выполняется в
процентах от
текущего
значения
управляемого
параметра, %
Коррекция
byValue
выполняется на
заданное
значение
относительно
текущего
значения
управляемого
параметра
Определяет тип kind
коррекции,
который будет
выполнен. С
помощью этого
значения
определяется
атрибут, который
должен
использоваться
для внесения
корректирующих
Имя класса атрибута
(англ.)
Тип данных
GateInputPin
Логический
GateInputPin
Seconds
ThresholdValue
Integer
ThresholdValue
UnformalizedBlocking
Вещественный
BlockingKind
ProtectiveActionAdjustm PerCent
ent
ProtectiveActionAdjustm Вещественный
ent
ProtectiveActionAdjustm ProtectiveActionAdjustment
ent
Kind
76
Смысловое
Имя атрибута (англ.)
назначение
атрибута
воздействий.
Если атрибут
reduce
принимает
значение истина,
то коррекция
выполняется в
сторону
уменьшения. В
противном
случае в сторону
увеличения.
Корректировка
setValue
задается новым
активным
значением.
Если истина, то inService
оборудования
вводится в
работу, в
противном
случае выводится.
Уставка,
targetValue
подаваемая на
вход регулятора.
Значение имеет
единицы
измерения
регулируемого
параметра.
Управляющее
воздействие не
изменяет вид
управляемого
параметра.
Операция
kind
сравнения,
выполняемая для
полюса (тип
контролируемого
параметра)
Операция
kind
сравнения,
выполняемая для
сечения. (тип
контролируемого
параметра)
Имя класса атрибута
(англ.)
Тип данных
ProtectiveActionAdjustm Логический
ent
ProtectiveActionAdjustm Вещественный
ent
ProtectiveActionEquipme Логический
nt
ProtectiveActionRegulati Вещественный
on
PinTerminal
PinTerminalKind
PinBranchGroup
PinBranchGroupKind
77
Смысловое
Имя атрибута (англ.) Имя класса атрибута Тип данных
назначение
(англ.)
атрибута
Операция
kind
PinEquipment
PinEquipmentKind
сравнения,
выполняемая для
оборудования.
(тип
контролируемого
параметра)
Объем
loadSheddingCapacity
LoadSheddingStage
ActivePower
отключаемой
нагрузки
Объем
generationUnloadingCap GenerationUnloadingStag ActivePower
воздействия на
acity
e
разгрузку
турбины или
отключения
генерации
Фазы, на которых phases
CurrentFlowStage
PhaseCode
установлены
измерительные
органы ступени
защиты
Признак
actionDisabled
PEStage
Логический
выведения
выходных цепей
из работы, при
этом ступень
устройства РЗА
действует только
на сигнал.
Является ли
normallyInService
PEStage
Логический
включенное
состояние
ступени РЗА
нормальным для
устройства
Время от
startTimeDelay
PEStage
Seconds
поступления
возмущения от
измерительного
устройства до
начала отсчета
времени
выдержки. Время
пуска зависит от
конструктивной
реализации
устройства.
78
Смысловое
Имя атрибута (англ.)
назначение
атрибута
Выдержка
timeDelay
времени в
секундах.
Атрибут
controlledPhases
показывает, в
каких фазах
контролируются
режимные
параметры.
Необходим в
случае, когда в
модели три
однофазных
трансформатора
тока
представлены
одним
трёхфазным
трансформатором
.
Тип
controlledValueType
контролируемой
величины.
Направление
direction
контроля (снизу,
сверху, по
модулю).
Эксплуатационно inService
е состояние
пусковых
органов.
Тип
kind
контролируемого
параметра (ток,
напряжение,
переток
реактивной
мощности и т.п.)
Предел для
limit
контролируемого
параметра
(значение
уставки).
Контроль
precedingStateControl
предыдущего
режима.
Коэффициент
resetRatio
Имя класса атрибута
(англ.)
Тип данных
PEStage
Seconds
PESetpoint
PhaseCode
PESetpoint
ControlledValueSetpointTyp
e
PESetpoint
OperationalLimitDirectionK
ind
PESetpoint
Логический
PESetpoint
RegulatingControlModeKin
d
PESetpoint
Вещественный
PEStageSetpoint
Логический
PEStageSetpoint
Вещественный
79
Смысловое
Имя атрибута (англ.)
назначение
атрибута
возврата ступени
РЗА.
Время возврата resetTime
ступени РЗА.
Предельная
kMax
кратность, о.е.
Коэффициент
kt
трансформации
обмотки
трансформатора
тока.
Собственное
r
активное
сопротивление.
Собственное
x
реактивное
сопротивление
Коэффициент
nominalRatio
преобразования
напряжения
Номинальное
nominalVoltage
напряжение
(линейное)
Напряжение
shortCircuitVoltage
короткого
замыкания.
Имя класса атрибута
(англ.)
Тип данных
PEStageSetpoint
Seconds
CurrentTransformerWind Вещественный
ing
CurrentTransformerWind Вещественный
ing
CurrentTransformerWind Resistance
ing
CurrentTransformerWind Resistance
ing
PotentialTransformerWin Вещественный
ding
PotentialTransformerWin Вещественный
ding
PotentialTransformerWin Вещественный
ding
Перечень ассоциаций
Перечень необходимых ассоциаций информационной модели приведен в
таблице 4.
Таблица 4. Ассоциации классов информационной модели
Смысловое
назначение
ассоциации
Объекты
энергосистемы,
ассоциированные
с материальным
объектом
Материальный
объект,
включающий в
себя текущий
материальный
Начальный
класс
Конечный
класс
Имя ассоциации Множественность
(англ.)
Asset
PowerSystemRes PowerSystemResou 0..*
ource
rces
Asset
AssetContainer
AssetContainer
0..1
80
Смысловое
Начальный
Конечный
Имя ассоциации Множественность
назначение
класс
класс
(англ.)
ассоциации
объект
Материальные
AssetContainer
Asset
Assets
0..*
объекты, которые
входят в состав
текущего
материального
объекта
Первичный
AsynchronousMa PrimeMover
PrimeMover
0..1
двигатель
chine
асинхронного
генератора
Полюс
AuxiliaryEquipm Terminal
Terminal
1..1
вспомогательного ent
оборудования
Электропроводящ BaseVoltage
ConductingEquip ConductingEquipm 0..*
ее оборудование,
ment
ent
относящееся к
стандартному
номинальному
напряжению
Вводы
BaseVoltage
TransformerEnd TransformerEnds 0..*
трансформатора,
относящиеся к
стандартному
номинальному
напряжению
Распределительны BaseVoltage
VoltageLevel
VoltageLevel
0..*
е устройства,
относящиеся к
стандартному
номинальному
напряжению
Распределительно Bay
VoltageLevel
VoltageLevel
1..1
е устройство, к
которому
относится
присоединение
Стандартное
ConductingEquip BaseVoltage
BaseVoltage
0..1
номинальное
ment
напряжение
электропроводяще
го оборудования
Полюса
ConductingEquip Terminal
Terminals
0..*
электропроводяще ment
го оборудования
Контейнер
ConnectivityNode ConnectivityNode ConnectivityNodeC 1..1
81
Смысловое
Начальный
Конечный
Имя ассоциации Множественность
назначение
класс
класс
(англ.)
ассоциации
соединительных
Container
ontainer
узлов
Соединенные
ConnectivityNode Terminal
Terminals
0..*
полюса
Соединительные ConnectivityNode ConnectivityNode ConnectivityNodes 0..*
узлы, входящие в Container
контейнер
соединительных
узлов
(агрегирование) Equipment
EquipmentContai EquipmentContaine 0..1
Контейнер
ner
r
оборудования, к
которому
относится
единица
оборудования
Дополнительная Equipment
EquipmentContai AdditionalEquipme 0..*
ассоциация
ner
ntContainer
оборудования с
другим
контейнером
(например,
выключатель и
другое
оборудование в
ячейке могут быть
ассоциированы с
ЛЭП либо участок
ЛЭП может быть
ассоциирован с
ячейками
подстанций
(подстанциями))
Единицы
EquipmentContai Equipment
Equipments
0..*
оборудования,
ner
относящиеся к
контейнеру
оборудования
Единицы
EquipmentContai Equipment
AdditionalGrouped 0..*
оборудования,
ner
Equipment
имеющие
дополнительную
ассоциацию с
контейнером
оборудования
(например,
выключатель и
82
Смысловое
Начальный
Конечный
Имя ассоциации
назначение
класс
класс
(англ.)
ассоциации
другое
оборудование в
ячейке могут быть
ассоциированы с
ЛЭП либо участок
ЛЭП может быть
ассоциирован с
ячейками
подстанций
(подстанциями))
Генераторы,
GeneratingUnit RotatingMachine RotatingMachine
входящие в состав
энергоблока
Субъекты
GeographicalRegi SubGeographical Regions
Российской
on
Region
Федерации
Набор
IdentifiedObject Name
Names
типизированных
наименований
Роли организаций IdentifiedObject OrganisationRole OrganisationRoles
по отношению к
объекту
информационной
модели
(ассоциация
является
расширением
стандартной
модели и
используется на
практике для
указания ролей
организаций в
отношении к
объектам
информационной
модели
различного типа, а
не только для
моделей
материальных
объектов.
Применяется в
случаях, когда
включение
моделей
материальных
Множественность
0..1
0..*
0..*
0..*
83
Смысловое
Начальный
Конечный
Имя ассоциации Множественность
назначение
класс
класс
(англ.)
ассоциации
объектов в
информационный
обмен
нецелесообразно
либо они
отсутствуют)
Субъекты
Line
SubGeographical- Region
0..*
Российской
Region
Федерации, по
территории
которых проходит
ЛЭП
Объект, имеющий Name
IdentifiedObject IdentifiedObject
1..1
типизированное
наименование
Тип наименования Name
NameType
NameType
1..1
Наименование
NameType
Name
Names
0..*
заданного типа
Дочерние и
Organisation
Organisation
ChildOrganisations 0..*
зависимые
организации,
филиалы
Вышестоящая
Organisation
Organisation
ParentOrganisation 0..1
организация,
филиал
Роли,
Organisation
OrganisationRole Roles
0..*
выполняемые
организацией
Объекты
OrganisationRole IdentifiedObject Objects
0..*
информационной
модели,
связанные с
ролью
организации
(ассоциация
является
расширением
стандартной
модели и
используется на
практике для
указания ролей
организаций в
отношении к
объектам
информационной
модели
84
Смысловое
Начальный
Конечный
Имя ассоциации
назначение
класс
класс
(англ.)
ассоциации
различного типа, а
не только для
моделей
материальных
объектов.
Применяется в
случаях, когда
включение
моделей
материальных
объектов в
информационный
обмен
нецелесообразно
либо они
отсутствуют)
Организации,
OrganisationRole Organisation
Organisation
имеющие
заданную роль
Субъект
Plant
SubGeographical- Region
Российской
Region
Федерации, на
территории
которого
находится
электростанция
Группы
Plant
Substation
Substations
распределительны
х устройств
электростанции
Материальные
PowerSystemRes Asset
Assets
объекты,
ource
ассоциированные
с объектом
энергосистемы
Дополнительный PowerSystemRes PSRType
PSRType
классификатор
ource
Электрические
PowerTransforme PowerTransforme PowerTransformer
выводы силового r
rEnd
End
трансформатора
Силовой
PowerTransforme PowerTransforme PowerTransformer
трансформатор, к r-End
r
которому
относится вывод
Асинхронный
PrimeMover
AsynchronousMa AsynchronousMac
генератор,
chine
hine
соединенный с
Множественность
0..1
0..1
0..*
0..*
0..1
0..*
0..1
0..1
85
Смысловое
Начальный
назначение
класс
ассоциации
первичным
двигателем
Синхронный
PrimeMover
генератор,
соединенный с
первичным
двигателем
Энергообъекты с PSRType
дополнительным
классификатором
(агрегирование) RotatingMachine
Энергоблок, к
которому
относится
генератор
Паровые турбины, SteamSupply
снабжаемые
котлом
Географический SubGeographical
регион,
Region
объединяющий
субъекты
Российской
Федерации
Линии,
SubGeographical
проходящие по
Region
территории
субъекта
Российской
Федерации
Электростанции, SubGeographical
находящиеся на Region
территории
субъекта
Российской
Федерации
Подстанции,
SubGeographical
находящиеся на Region
территории
субъекта
Российской
Федерации
Электростанция, к Substation
которой относится
группа
распределительны
Конечный
класс
Имя ассоциации Множественность
(англ.)
SynchronousMac SynchronousMachi 0..*
hine
nes
PowerSystemRes PowerSystemResou 0..*
ource
rces
GeneratingUnit
GeneratingUnit
0..1
SteamTurbine
SteamTurbines
0..*
GeographicalRegi Region
on
0..1
Line
Lines
0..*
Plant
Plants
0..*
Substation
Substations
0..*
Plant
Plant
0..1
86
Смысловое
Начальный
Конечный
Имя ассоциации Множественность
назначение
класс
класс
(англ.)
ассоциации
х устройств
(агрегирование) Substation
SubGeographical Region
0..1
Субъект
Region
Российской
Федерации, на
территории
которого
находится
подстанция
Распределительны Substation
VoltageLevel
VoltageLevels
0..*
е устройства,
входящие в состав
подстанции
Первичный
SynchronousMac PrimeMover
PrimeMovers
0..*
двигатель
hine
синхронного
генератора
Вспомогательное Terminal
AuxiliaryEquipm AuxiliaryEquipmen 0..*
оборудование,
ent
t
подключенное к
полюсу
электропроводяще
го оборудования
Электропроводящ Terminal
ConductingEquip ConductingEquipm 1..1
ее оборудование,
ment
ent
к которому
принадлежит
полюс
Соединительный Terminal
ConnectivityNode ConnectivityNode 0..1
узел полюсов
(агрегирование) Terminal
TransformerEnd TransformerEnd
0..*
Выводы
трансформатора, к
которым
подключен полюс
Стандартное
TransformerEnd BaseVoltage
BaseVoltage
0..1
номинальное
напряжение
вывода
трансформатора
Полюс силового TransformerEnd Terminal
Terminal
0..1
трансформатора, к
которому
подключены его
выводы
Стандартное
VoltageLevel
BaseVoltage
BaseVoltage
0..1
87
Смысловое
Начальный
Конечный
Имя ассоциации Множественность
назначение
класс
класс
(англ.)
ассоциации
номинальное
напряжение
распределительно
го устройства
Присоединения
VoltageLevel
Bay
Bays
0..*
распределительно
го устройства
(агрегирование) VoltageLevel
Substation
Substation
1..1
Подстанция, в
состав которой
входит
распределительно
е устройство
Функции РЗА,
ConductingEquip ProtectionEquipm ProtectionEquipme 0..*
защищающие
ment
ent
nts
первичное
оборудование
Первичное
ProtectionEquipm ConductingEquip ConductingEquipm 0..*
оборудование,
ent
ment
ents
защищаемое
функцией РЗ
Коммутационные ProtectionEquipm ProtectedSwitch ProtectedSwitches 0..*
аппараты, на
ent
которые
воздействует
функция РЗА
Функции РЗА,
Protected Switch ProtectionEquipm OperatedByProtecti 0..*
воздействующие
ent
onEquipment
на
коммутационный
аппарат
Обмотки
ProtectionEquipm SensorWinding SensorWindings
0..*
трансформатора ent
тока и (или)
напряжения, к
которым
относится
функция РЗА
Функции РЗА,
SensorWinding ProtectionEquipm ProtectionEquipme 0..*
которые относятся
ent
nt
к обмотке
трансформатора
тока или
напряжения
Поврежденное
Fault
Equipment
FaultyEquipment 0..1
при наступлении
88
Смысловое
Начальный
Конечный
назначение
класс
класс
ассоциации
аварийного
события
оборудование
Повреждения
Equipment
Fault
первичного
оборудования
Отклонение от
Fault
Outage
нормального
режима ЭЭС,
вызванное
аварийным
событием
Аварийные
Outage
Fault
события,
произошедшие
при данном
отклонении от
нормального
режима ЭЭС
Оборудование,
Outage
Equipment
связанное с
аварийным
событием
Аварийное
Equipment
Outage
событие,
связанное с
оборудованием
Аварийное
PACSOperationE Fault
событие, при
vent
котором
произошло
срабатывание/пус
к РЗА
Связь
PinTerminal
Terminal
используется для
описания
параметра, с
которым
выполняется
сравнение.
Сечение,
PinBranchGroup BranchGroup
используемое для
сравнения.
Оборудование,
PinEquipment
Equipment
для которого
выполняется
Имя ассоциации Множественность
(англ.)
Faults
0..*
Outage
0..1
Faults
0..*
Equipments
0..*
Outages
0..*
Fault
0..*
TerminaThreshold 0..1
Operand
BranchGroup
1
EquipmentThreshol 0..*
dOperand
89
Смысловое
назначение
ассоциации
контроль
состояния, с
которым
выполняется
сравнение.
Измерение,
которое должно
использоваться
для сравнения.
Потребители
электроэнергии,
заведенные под
действие ступени
РЗА.
Генераторы,
заведенные под
действие ступени
РЗА
Ступень РЗА, для
которой описаны
управляющие
воздействия.
Управляющие
воздействия,
заведенные под
ступень РЗА.
Коммутационные
аппараты,
заведенные под
ступень
устройства РЗА.
Регулятор, на
который
осущевствляется
выдача
управляющих
воздействий.
Оборудование,
заведенное под
управляющее
воздействие.
Оперативное
состояние
проводящего
оборудования
меняется когда
управляющие
Начальный
класс
Конечный
класс
PinMeasurement Measurement
Имя ассоциации Множественность
(англ.)
Measurement
0..1
LoadSheddingSta EnergyConsumer ControlledEnergyC 0..*
ge
onsumers
GenerationUnload SynchronousMac ControlledGenerato 0..*
ingStage
hine
rs
ProtectiveAction PEStage
PEStage
PEStage
ProtectiveAction ProtectiveActions
ProtectiveActionE ProtectedSwitch
quipment
1
0..*
ControlledSwitches 1..*
ProtectiveAction RegulatingContro RegulatingControl 1
Regulation
l
ProtectiveAction ConductingEquip ConductingEquipm 1
Adjustment
ment
ent
90
Смысловое
Начальный
Конечный
Имя ассоциации Множественность
назначение
класс
класс
(англ.)
ассоциации
воздействия
введено в работу.
Для
шунтирующего
компенсатора или
другого
проводящего
оборудования,
которое оперирует
дискретными
значениями,
значение должно
округляться.
[Допускается
описание
управляющих
воздействий этого
типа только на
классы
SynchronousMachi
ne и
EnergyConsumer]
Обмотка ТТ, к
PESetpoint
CurrentTransform CurrentTransforme 0..1
которой
erWinding
rWinding
подключен
пусковой орган
для замеров по
току
Обмотка ТН, к
PESetpoint
PotentialTransfor PotentialTransform 0..1
которой
merWinding
erWinding
подключен
пусковой орган
для замеров по
напряжению
Трансформатор
PotentialTransfor PotentialTransfor Transformer
1
напряжения,
merWinding
mer
который
использует
обмотки датчика
Трансформатор
CurrentTransform CurrentTransform Transformer
1
тока, который
erWinding
er
использует
обмотки датчика.
Полюс основного AuxiliaryEquipm Terminal
Terminal
1
оборудования, к ent
которому
подключена
91
Смысловое
Начальный
назначение
класс
ассоциации
единица
вспомогательного
оборудования.
Измерения,
Measurement
привязанные к
полюсу.
Определяют
привязку
Измерения к
топологии сети.
Могут
использоваться,
например, для
фиксации
размещения
измерительного
оборудования,
такого как
трансформатор
напряжения или
трансформатор
тока.
Вентили,
PEStage
срабатывание
которых
описывает
состояние
ступени.
Ступень РЗА,
SIPSGate
состояние
которых
описывает
выходной сигнал
вентиля.
Вентиль, на
GateInputPin
который подается
входной сигнал.
Сигналы, которые SIPSGate
подаются на вход
логическому
вентилю.
Вентили, на вход SIPSGate
которых подается
сигнал.
Вентиль, с выхода PinGate
которого
снимается сигнал.
Конечный
класс
Имя ассоциации Множественность
(англ.)
Terminal
Terminal
0..1
SIPSGate
Gates
0..*
PEStage
PEStage
0..1
SIPSGate
Gate
1
GateInputPin
GateInputPin
1..*
PinGate
GateOutput
0..*
SIPSGate
PinGate
1
92
Смысловое
назначение
ассоциации
Уставки ступени
устройства РЗА
Начальный
класс
Конечный
класс
Имя ассоциации Множественность
(англ.)
PEStage
PEStageSetpoint PESetpoints
0..*
Справочные классы
Перечень необходимых справочных классов профиля информационной
модели приведен в таблице 5.
Таблица 5. Справочные классы профиля информационной модели
Смысловое определение справочного
Имя класса (англ.)
Имя вышестоящего
класса
класса (англ.)
Тип аварийного события
FaultType
Элементная база устройства РЗА
ElementBaseKind
Вид контейнера материальных объектов, PACSDeviceKind
содержащего одну или несколько функций
РЗА
Определяет различные логические
GateLogicKind
операции.
Типы преобразований аналогового
AnalogToDigitalLogicKind сигнала в цифровой (или логический
результат).
Вид блокировки срабатывания ступени
BlockingKind
РЗА
Разновидность корректирующих
ProtectiveActionAdjustment управляющих воздействий, которые могут Kind
оказываться на оборудование
Категоризация типов для сравнения,
PinTerminalKind
выполняемых для полюса.
Категоризация типов сравнений,
PinBranchGroupKind
выполняемых для сечения.
Категоризация типов для сравнения,
PinEquipmentKind
выполняемых для оборудования
Описание отсутствует
ControlledValueSetpointTyp e
Направление ограничения.
OperationalLimitDirectionK ind
Вид параметра, которым может управлять RegulatingControlModeKin регулятор: напряжение, мощность,
d
коммутационное состояние.
Перечень атрибутов справочных классов
Перечень необходимых атрибутов справочных классов приведен в таблице 6.
Таблица 6. Атрибуты справочных классов информационной модели
93
Смысловое назначение атрибута
Имя атрибута (англ.)
Устройство РЗА
relayProtectionDevice
Шкаф
relayProtectionCabinet
Панель
relayProtectionPanel
Терминал
relayProtectionTerminal
Реле
relay
Модуль
module
Асинхронный ход
asynchronousStroke
Замыкание
closure
Короткое замыкание
shortCircuit
Межвитковое короткое замыкание
turnToTurnShortCircuit
Качание
sweep
Снижение уровня изоляции
decreaselnsulationLevel
Перегрузка по току
overloadCurrent
Повышение напряжения
overVoltage
Понижение напряжения
underVoltage
Повышение частоты
overFrequency
Снижение частоты
underFrequency
Перегрузка по мощности
overloadPower
Электромеханика
electromechanics
Микроэлектроника
microelectronics
Микропроцессор
microprocessor
Операция логического И. Истина
and
если все входные параметры истина.
Операция логического ИЛИ. Истина or
если хотя бы один входной параметр
истина
Логическая операция "ИЛИ-НЕ".
nor
Ложь, если хотя бы один входной
параметр истина
Логиечская операция И-НЕ. Ложь,
nad
если все входные параметры
истинны.
Логическая операция "НЕ". Имеет
not
один входной параметр и истиный
входной параметр преобразуется в
ложный.
Логическая операция XNOR.
xnor
Функция является инверсией
функции исключающее ИЛИ. Если
все входные аргументы ложны или
истины, то на выходе получим
истиное значение. В противном
случае ложное.
Имя класса атрибута
(англ.)
PACSDeviceKind
PACSDeviceKind
PACSDeviceKind
PACSDeviceKind
PACSDeviceKind
PACSDeviceKind
FaultType
FaultType
FaultType
FaultType
FaultType
FaultType
FaultType
FaultType
FaultType
FaultType
FaultType
FaultType
ElementBaseKind
ElementBaseKind
ElementBaseKind
GateLogicKind
GateLogicKind
GateLogicKind
GateLogicKind
GateLogicKind
GateLogicKind
94
Смысловое назначение атрибута
Имя атрибута (англ.)
Логическая операция исключающее xor
ИЛИ. Если все входные аргументы
ложны или истины, то выходное
значение ложно. В противном случае
истино
Неравно
ne
Равно
eq
Меньше или равно
le
Меньше
lt
Больше или равно
ge
Больше
gt
Блокировка ступени РЗА при КЗ.
shortCircuit
Блокировка ступени РЗА при
circuitFailure
неисправностях цепей напряжения и
тока
Блокировка ступени РЗА при
powerSwing
синхронных качаниях
Блокировка ступени РЗА в
outOfStepTripping
асинхронных режимах
Задание значения управляемого
setValue
параметра.
Изменение значения управляемого byValue
параметра на заданную величину.
Изменение значения управляемого byPercentage
параметра относительно текущего на
заданную в процентах величину.
Активная мощность в полюсе
activePower
Полная мощность в полюсе
apparentPower
Реактивная мощность в полюсе
reactivePower
Напряжение в полюсе
voltage
Ток в полюсе
current
Частота в полюсе
frequency
Скорость изменения частоты в
frequencyPerTime
полюсе
Проводимость шунта на землю в
admittance
полюсе
Скорость изменения напряжения в
voltagePerTime
полюсе
Активная мощность
activePower
Реактивная мощность
reactivePower
Полная мощность
apparentPower
Ток
current
Выставлеятся, если оборудование
inService
Имя класса атрибута
(англ.)
GateLogicKind
AnalogToDigitalLogicKind
AnalogToDigitalLogicKind
AnalogToDigitalLogicKind
AnalogToDigitalLogicKind
AnalogToDigitalLogicKind
AnalogToDigitalLogicKind
BlockingKind
BlockingKind
BlockingKind
BlockingKind
ProtectiveActionAdjustment
Kind
ProtectiveActionAdjustment
Kind
ProtectiveActionAdjustment
Kind
PinTerminalKind
PinTerminalKind
PinTerminalKind
PinTerminalKind
PinTerminalKind
PinTerminalKind
PinTerminalKind
PinTerminalKind
PinTerminalKind
PinBranchGroupKind
PinBranchGroupKind
PinBranchGroupKind
PinBranchGroupKind
PinEquipmentKind
95
Смысловое назначение атрибута
введено в работу, true - если
оборудование находится в работе, в
противном случае - false.
Выставляется true, если хотя бы на
одном полюсе есть напряжение.
Выставляется true, если заземлен
хотя бы один полюс.
Фазное
Имя атрибута (англ.)
Имя класса атрибута
(англ.)
isEnergized
PinEquipmentKind
isGrounded
PinEquipmentKind
phase
ControlledValueSetpointTyp
e
ControlledValueSetpointTyp
e
ControlledValueSetpointTyp
e
ControlledValueSetpointTyp
e
ControlledValueSetpointTyp
e
OperationalLimitDirectionK
ind
Линейное
lineToLine
Прямая последовательность
sequenceDirect
Обратная последовательность
sequenceReverse
Нулевая последовательность
sequenceZero
Ограничение сверху. Если оно
high
характеризует переток, то
положительным считается
направление в сторону извне в полюс
оборудования.
Ограничение снизу. Если оно
low
характеризует переток, то
положительным считается
направление в сторону извне в полюс
оборудования.
Ограничение сверху по модулю,
absoluteValue
т.е.сверху для положительных
величин и снизу для отрицательных
Задано напряжение
voltage
Задана активная мощность
activePower
Задана реактивная мощность
reactivePower
Задан ток
currentFlow
Задана проводимость
admittance
Регулятор включает/отключает по
timeScheduled
суточному графику, который может
зависеть от дня недели и сезона.
Задана температура (режим
temperature
термостата)
Коэффициент мощности.
powerFactor
Частота
frequency
Скорость изменения частоты
frequencyPerTime
Полная мощность
apparentPower
Скорость изменения напряжения.
voltagePerTime
OperationalLimitDirectionK
ind
OperationalLimitDirectionK
ind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
RegulatingControlModeKind
96
Смысловое назначение атрибута
Имя атрибута (англ.)
Состояние
Для шунта означает, что задача
оптимизации режима может
изменять параметры шунта и
состояние шунта:
включен/отключен.
status
admittance_and_status
Имя класса атрибута
(англ.)
RegulatingControlModeKind
RegulatingControlModeKind
97
ПРИЛОЖЕНИЕ 2. АЛЬБОМ ФОРМ КОНСТРУКТОРА ПА
Приложение содержит альбом следующих форм Конструктора ПА:
1. Формы эмулятора сигнала и проверки моделей ПА.
2. Альбом форм процесса согласования устройств ПА.
3. Формы версионности моделей ПА.
Альбом форм эмулятора сигнала и проверки моделей ПА
Ниже представлено графическое отображение результата проверки логики работы устройства ПА при задании
определенного набора параметров:
- ФОЛ ВЛ 500 кВ №1 – сработанное состояние;
- Ремонт ВЛ 500 кВ №2 – несработанное состояние;
- величина КПР1 – 2500.
Рисунок 1. Результат проверки устройства ПА
98
Альбом форм процесса согласования устройств ПА
Форма создания маршрута согласования представлена на рисунке 2.
Рисунок 2. Форма маршрута согласования
Описание доступных полей на форме представлено в таблице 1:
99
Таблица 1
Поля/кнопки
Описание
Поле «Название Название текущего устройства ПА
устройства»
Поле
письма»
Вид
«Текст Указывает разработчик текст письма при отправке устройства ПА на
согласование
Поле
«Шаблон Позволяет выбрать разработчику устройства ПА готовый маршрут
маршрута»
согласования из списка шаблонов ранее сохраненных
Поле «Роль»
Позволяет выбрать разработчику устройства ПА роль согласующего
пользователя для согласования устройства ПА
Кнопка «Добавить Позволяет добавить следующий шаг. Например, следующим шагом
следующий шаг» может быть другой филиал диспетчерского центра, с которым требуется
согласование устройства ПА
Кнопка «Добавить Позволяет добавить утверждающего, чья подпись будет финальной в
утверждающего» процессе согласования устройства ПА
Кнопка
«Сохранить
шаблон»
Кнопка
«Сохранить»
Позволяет сохранить созданный шаблон в библиотеку шаблонов
маршрутов согласования
Кнопка
«Запустить»
Позволяет запустить
Сохранение текущего маршрута согласования
После запуска маршрута согласования на почту и в Систему будут приходить уведомления о завершении этапа
согласования.
Для специалиста уведомления будут выглядеть следующим образом (рисунок 3):
100
Рисунок 3. Уведомления в Системе для специалиста
101
Для согласующего и утверждающего уведомления будут выглядеть следующим образом (рисунок 4):
Рисунок 4. Уведомления в Системе для согласующего
102
В случае отказа в согласовании отображается следующая форма:
Рисунок 5. Окно отказа в согласовании устройства ПА
После запуска процесса согласования имеется возможность посмотреть процесс согласования в виде диаграммы
(рисунок 6, 7):
Рисунок 6. Маршрут согласования
103
Рисунок 7. Диаграмма маршрута согласования
104
Альбом форм версионности моделей ПА
В графическом редакторе должна присутствовать кнопка «История» в правой верхней части экрана (рисунок 8).
Рисунок 8. Форма просмотра схемы модели ПА
После нажатия левой клавишей мыши на кнопку «История», происходит переход в режим просмотра формы
версионности модели ПА.
На форме просмотра версионности модели ПА должна присутствовать следующая информация:
105
- дата и время создания версии (столбец «Время сохранения»),
- номер версии,
- какой пользователь сохранил изменения в модели ПА,
- комментарий (если версия создана из ранней версии, то будет комментарий из какой версии восстановлено),
- действия:
Доступные функции, содержащиеся в столбце «Действия», представлены в таблице 10:
Кнопка
Кнопка «Восстановить»
Пиктограмма в виде «звезды»
Пиктограмма в виде «урны»
Описание
Вид
Позволяет восстановить выбранную версию
Позволяет указать избранную версию. Данную версию Система не удалит
автоматически при достижении максимума количества версий
Позволяет удалить выбранную версию
При активации чекбокса «Только избранные» отображаются только избранные версии.
В системе необходимо реализовать:
 режим просмотра любой из версий в графическом редакторе;
 возможность переключения между версиями в графическом редакторе;
 переход к последней/текущей версии (версия, имеющей наибольший порядковый номер) в графическом
редакторе.
106
Рисунок 9. Форма просмотра схемы модели ПА

=== ФАЙЛ: текст разъяснения.doc | docs/32616441078/текст разъяснения.pdf
Запрос:
По п.5.2.2 исполнитель должен установить совместимый клиент защищённого доступа и передать
в удостоверяющий центр носители ключей. Названия и версии этих средств в данном пункте не
указаны. Просим указать: какой клиент и версия нужны; какие носители ключей поддерживаются;
какие дополнительные средства защиты и документы об их установке обязательны для
подключения. Какие из этих средств предоставляет заказчик, а какие приобретает исполнитель?
Эти сведения нужны для подбора совместимого рабочего места и расчёта обязательных расходов
до подачи ценового предложения.
Разъяснения:
1. какой клиент и версия нужны – инсталляционный пакет клиента защищенного доступа (S-terra)
предоставляется АО «СО ЕЭС» вместе с Инструкцией по установке на безвозмездной основе; 2.
какие носители ключей поддерживаются – JaCarta PKI или LT приобретается Исполнителем за
свой счет. Обращаем Ваше внимание, один носитель ключа – один сотрудник Исполнителя. 3.
какие дополнительные средства защиты – антивирусное ПО на стороне Исполнителя; 4.
документы об их установке обязательны для подключения – с Победителем конкурса заключается
Соглашение о соблюдении требований по информационной безопасности. Форма Соглашения
представлена в разделе 4 Конкурсной документации.
