ТТ_автоматизация_ОРЭМ_ТНЭ ктябрьx

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
на создание автоматизированной системы
поддержки работы на оптовом рынке электроэнергии и мощности
(АС ОРЭМ)
2
ОГЛАВЛЕНИЕ
1.
ВВЕДЕНИЕ ...................................................................................................................................... 3
1.1 Полное наименование информационной системы .............................................................. 3
1.2 Термины и сокращения .......................................................................................................... 3
1.3 Назначение системы ............................................................................................................... 4
1.4 Цели создания системы .......................................................................................................... 4
2. ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ .......................................................................... 5
2.1 Сведения об объекте автоматизации ..................................................................................... 5
2.2 Исходное состояние объекта автоматизации ........................................................................ 5
2.3 Целевое состояние объекта автоматизации .......................................................................... 5
2.4 Категория обрабатываемой информации ............................................................................. 5
3. ТРЕБОВАНИЯ К СИСТЕМЕ .............................................................................................................. 6
3.1 Структура системы ................................................................................................................... 6
3.2 Требования к АРМ ................................................................................................................... 6
3.3 Требования к оснащению рабочих мест пользователей: ..................................................... 6
3.4 Требования к серверному оборудованию ............................................................................. 7
3.5 Функциональная архитектура Системы .................................................................................. 8
3.6 Подсистема «Сбор данных» ..................................................................................................... 8
3.7 Подсистема «НСИ» ................................................................................................................... 9
3.8 Подсистема «Работа с торговой системой» ..........................................................................10
3.9 Подсистема «Формирование отчетов и анализ» ..................................................................10
3.10 Подсистема «Администрирование» ......................................................................................11
3.11 Требования по взаимодействию с другими системами .....................................................11
3.12 Дополнительные требования к системе ...............................................................................12
3.13 Требования к численности и квалификации персонала Системы и режиму его работы .12
3.14 Показатели назначения ........................................................................................................13
3.15 Требования к надежности .....................................................................................................13
3.16 Требования к эргономике и технической эстетике .............................................................14
3.17 Требования к информационной безопасности ..................................................................15
3.18 Требования по сохранности информации при авариях .....................................................18
3.19 Требования к патентной чистоте ..........................................................................................18
3.20 Требования по стандартизации и унификации ....................................................................18
4. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ ........................................................................... 20
4.1 Порядок оформления и предъявления заказчику результатов работ. ...............................20
4.2 Этапы и результаты работ по созданию системы ................................................................20
4.3 Требования к испытаниям системы и ее составных частей ..............................................22
4.4 Мероприятия по обучению персонала .................................................................................23
4.5 Мероприятия по организационному обеспечению ............................................................24
5. ТРЕБОВАНИЯ ПО ОРГАНИЗАЦИИ ГАРАНТИЙНОЙ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ ...................... 25
6. ПРИЛОЖЕНИЯ............................................................................................................................... 26
6.1 Приложение 1. Функциональная архитектура Системы ......................................................26
6.2 Приложение 2. Перечень данных, подлежащих автоматическому сбору ..........................27
6.3 Приложение 3. Взаимодействие со смежными системами ...............................................34
3
1.
ВВЕДЕНИЕ
1.1 Полное наименование информационной системы
1.1.1 Автоматизированная
система
поддержки
энергосбытовой
деятельности участника на оптовом рынке электроэнергии и мощности (далее Система).
1.1.2
Условное обозначение системы: АС ОРЭМ.
1.2 Термины и сокращения
АИИС КУЭ
- автоматизированная
информационно-измерительная
система коммерческого учета электроэнергии;
АПК
- аппаратно-программный комплекс;
АРМ
- автоматизированное рабочее место;
БД
- база данных;
БР
- балансирующий рынок;
ВСВГО
- выбор состава включенного генерирующего оборудования;
ГТП
- группа точек поставки;
ДПМ
- Договор поставки мощности;
ЕСПД
- единая система программной документации;
Заказчик
- ООО «Транснефтьэнерго»;
ЗСП
- Зона свободного перетока;
Исполнитель
- организация, на основании договора выполняющая работы
по созданию информационной системы в соответствии с
настоящими требованиями;
Информационная - Совокупность содержащейся в базах данных информации и
система
обеспечивающих ее обработку информационных технологий
и технических средств;
ККС
Информационно-телекоммуникационная сеть, объединяющая
локальные вычислительные сети организаций системы
«Транснефть» и обеспечивающая защищенный обмен
информацией между ними;
КОМ
- конкурентный отбор мощности;
Коммерческий
- Коммерческий оператор оптового рынка электроэнергии и
оператор (КО)
мощности, ОАО «АТС»;
Макет 30308
- Формат СО для предоставления заявок на почасовое
потребление участников ОРЭМ;
НСИ
- нормативно-справочная информация;
ОДУ
- объединенное
диспетчерское управление, филиал
ОАО «СО ЕЭС»;
ОРЭМ
- оптовый рынок электроэнергии (мощности);
ОС
- операционная система;
4
ПО
ППП
РД
РДУ
РСВ
СДД
СДЭМ
Системный
оператор (СО)
СУБД
ТЗ
ФСТ
ЭЦП
- программное обеспечение;
- плановое почасовое потребление;
- регулируемые договора;
- региональное
диспетчерское
управление,
филиал
ОАО «СО ЕЭС»;
- рынок на сутки вперед;
- свободные двухсторонние договора;
- свободные договора электроэнергии и мощности;
- Системный оператор единой энергетической системы,
ОАО «СО ЕЭС»;
- система управления базами данных;
- Техническое задание на создание Системы;
- федеральная служба по тарифам;
- Электронно-цифровая подпись.
1.3 Назначение системы
1.3.1 Система предназначена для автоматизации процесса сбора,
обработки, и представления показателей работы Заказчика на оптовом рынке
электроэнергии и мощности, на основании данных АИИС КУЭ, внутренней
отчетности, а также сведений, представляемых Коммерческим оператором и
Системным оператором по конкретному участнику ОРЭМ. Система также
предназначена для автоматизации расчетов на ОРЭМ и подачи ценовых заявок.
1.4 Цели создания системы
1.4.1 Целью создания Системы является повышение эффективности
деятельности Заказчика за счет:
 автоматизированного сбора исходных данных;
 создания единого хранилища данных о результатах работы данного
участника на ОРЭМ;
 обеспечения эффективной обработки и представления информации;
 оперативного и автоматического формирования необходимой
отчетности.
5
2.
ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ
2.1 Сведения об объекте автоматизации
2.1.1 Система создается как локальная система ООО «Транснефтьэнерго»,
организационный объем внедрения охватывает отдел по работе на ОРЭМ.
2.1.2 Объектом автоматизации являются бизнес-процессы отдела по
работе на ОРЭМ ООО «Транснефтьэнерго».
2.2 Исходное состояние объекта автоматизации
2.2.1 На текущий момент бизнес-процессы отдела по работе на ОРЭМ
ООО «Транснефтьэнерго» не автоматизированы. Информация с сайтов КО и СО
загружается специалистами отдела вручную, данные о плановых объемах
потребления ОСТ поступают в виде excel-файлов, получение информации из
автоматизированной системы «1С-Предприятие» осуществляется периодической
ручной выгрузкой, формирование ценовых заявок ведется в АРМ «Заявки»
(предоставляется КО), формирование макетов 30308, а также анализ результатов
работы Заказчика на ОРЭМ ведется посредством MS Excel.
2.3 Целевое состояние объекта автоматизации
2.3.1 По завершении внедрения Системы, деятельность по обеспечению
работы Заказчика на ОРЭМ должна вестись в Системе.
2.3.2 Сбор информации с сайтов КО и СО, информации, регулярно
поступающей по e-mail, информации из АИИС КУЭ должен быть максимально
автоматизирован.
2.3.3 Формирование макетов 30308 и ценовых
производиться в Системе в автоматизированном режиме.
заявок
должно
2.3.4 Система должна вести накопление информации о результатах работы
общества на ОРЭМ для ее дальнейшего анализа и формирования необходимых
отчетов.
2.3.5 Система должна обеспечивать работу следующих типов (групп)
пользователей:
 Пользователь;
 Администратор;
 Куратор информационной безопасности.
2.4 Категория обрабатываемой информации
2.4.1 Обрабатываемая в Системе информация относится к категориям
«коммерческая тайна» и «конфиденциально», и подлежит защите в соответствии с
требованиями федерального законодательства и корпоративных нормативных
актов.
6
3.
ТРЕБОВАНИЯ К СИСТЕМЕ
3.1 Структура системы
3.1.1
Система должна состоять из следующих компонентов:
 Автоматизированные рабочие места (АРМ);
 Технологические узлы (Серверы).
3.1.2 АРМ и технологические узлы должны быть объединены в общую
информационную сеть с использованием телекоммуникационных сетей связи и
передачи данных.
3.1.3 АРМ предназначены для получения доступа к функциям подсистем
Системы согласно предоставленным пользователю полномочиям.
3.1.4 Каждое АРМ должно быть подключено к сети передачи данных и
иметь возможность доступа к технологическим узлам Системы по стандартным
сетевым протоколам.
3.1.5 Технологические узлы предназначены для обслуживания запросов
пользователей
Системы,
обладающих
соответствующими
правами
и
использующими для получения доступа к узлу свои АРМ.
3.1.6 Технологический узел Системы, в общем случае, должен включать
следующие логические типы серверов:
 сервер(ы) БД;
 сервер(ы) с модулями программного обеспечения.
3.1.7 Система должна иметь возможность интеграции и информационного
обмена с имеющимися автоматизированными системами Заказчика.
3.1.8
Количество пользователей системы: 20 конкурентных клиентских
мест.
3.2 Требования к АРМ
3.2.1 Разрабатываемые АРМы Системы должны обладать следующими
общими функциональными возможностями:
 Управление процессом ввода и обработки данных (ввод, отмена ввода,
сохранение данных, изменение данных);
 Просмотр введенной (полученной) информации на экране монитора;
 Печать информации на бумажном носителе;
 Доступ к выполнению всех операций ввода, вывода или просмотра
должен предоставляться в соответствии с правами и полномочиями
пользователя.
3.3 Требования к оснащению рабочих мест пользователей:
3.3.1
Аппаратные средства (предоставляются Заказчиком):
 Системный блок:
7





тип процессора: Intel Core 2 Duo 2 GHz;
объем оперативной памяти: не менее 4096 MB;
жесткий диск: от 500GB, свободное место не менее 100 GB;
сетевая карта: 100Mbps.
Монитор:
 разрешение: от 1280х1024;
 диагональ: от 20’’;
 Клавиатура;
 Мышь.
3.3.2
Программные средства:
 Операционная система Windows 7 и выше;
 MS Internet Explorer 8.0 и выше.
3.3.3 Аппаратные и программные средства рабочих мест пользователей
предоставляются Заказчиком
3.3.4 Связь между АРМ и технологическими узлами Системы должна
осуществляться техническими и программными средствами сети передачи данных.
3.3.5 Система должна обеспечивать возможность ввода и корректировки
данных, как ручным способом, так и путем автоматической обработки (загрузки)
данных, полученных посредством электронной почты или через общую файловую
систему с использованием форматов TXT, XML, XLS, CSV.
3.3.6 Разрабатываемое ПО не должно иметь лицензионных ограничений
по количеству каких-либо объектов НСИ, временных ограничений использования,
ограничений на количество запусков системы и всех ее модулей.
3.4 Требования к серверному оборудованию
3.4.1
Аппаратные средства (предоставляются Заказчиком):
 Аппаратный или виртуальный сервер с параметрами не хуже:
 архитектура: 2-х процессорный;
 тип процессора: Intel Xeon E5-2650; частота не ниже 2 GHz;
 объем оперативной памяти: не менее 8 GB;
 объем дискового массива: не менее 500 GB;
 сетевая карта: 1Gbps.
3.4.2
Программные средства:
 операционная система: Семейство Windows Server 2008-2012 (MS
Windows Server 2012 (R2) Standard);
 СУБД: MS SQL-Server версии не ниже 2008 (MS SQL-Server 2012 (R2)
Standard).
3.4.3 Окончательные параметры и состав серверного оборудования
согласовываются на этапе согласования ТЗ.
3.4.4
Необходимые лицензии в рамках Microsoft Enterprise Agreement
8
предоставляются Заказчиком.
3.5 Функциональная архитектура Системы
3.5.1
Система должна состоять из следующих подсистем:
 Подсистема «Сбор данных» - предназначена для автоматизированного
сбора данных по показателям работы на оптовом рынке электроэнергии
и мощности;
 Подсистема «НСИ» - обеспечивает возможность ввода и редактирования
нормативно-справочной информации о различных информационных
объектах, используемых при работе на ОРЭМ;
 Подсистема «Работа с торговой системой» - предназначена для
формирования уведомлений СО о ППП и ценовых заявок КО для участия
в торгах на РСВ;
 Подсистема «Формирование отчетов и анализ» - предназначена для
формирования отчетности о результатах торгов на ОРЭМ,
количественных и ценовых показателях ОРЭМ.
3.5.2
Функциональная архитектура Системы приведена в Приложении 1.
3.6 Подсистема «Сбор данных»
3.6.1
Подсистема должна обеспечивать выполнение следующих функций:







Ведение архива полученных макетов и результатов их обработки;
Ведение регламента поступления макетов и контроль его исполнения;
Выгрузку данных из архива полученных макетов;
Повторную обработку полученных макетов;
Просмотр и управление очередями обработки полученных макетов;
Проверку данных на соответствие макету;
Настройку расписания автоматического запуска подсистемы для
доставки и загрузки отчетов в указанное время без участия
пользователя;
 Возможность конфигурирования интерфейсов загрузки данных
средствами Системы и силами специалистов Заказчика без
привлечения специалистов Исполнителя или других сторонних
специалистов.
3.6.2 В зависимости от способа предоставления исходных данных,
подсистема должна обеспечивать выполнение, следующих методов загрузки
данных:
 Загрузку файлов данных, переданных по электронной почте с почтового
сервера Заказчика, в том числе подписанных электронной цифровой
подписью;
 Загрузку файлов данных, хранящихся в указанных каталогах файловых
серверов;
9
 Автоматическую загрузку отчетов из персональных разделов сайта КО, в
том числе подписанных электронной цифровой подписью;
 Автоматическую загрузку данных из открытого раздела сайта КО;
 Автоматическую загрузку данных с сайта балансирующего рынка СО, в
том числе доступ к которым осуществляется с помощью ключей
электронных цифровых подписей;
 Автоматическую загрузку данных с технологических сайтов СО, в том
числе доступ к которым осуществляется с помощью ключей электронных
цифровых подписей;
 Автоматическую загрузку данных с сайта ОАО «Московская
энергетическая биржа», в том числе доступ к которым осуществляется с
помощью ключей электронных цифровых подписей.
3.6.3 Подсистема должна предоставлять пользователю системы настройку
следующих параметров:
 Имя пользователя и пароль для доступа к персональному разделу сайта
КО;
 Перечень почтовых серверов, имен пользователей и паролей для
загрузки данных по электронной почте;
 Перечень файловых каталогов для загрузки файлов данных;
 Реестр типов обрабатываемых макетов;
 Допустимое количество параллельных потоков обработки (разбора)
поступивших макетов, выполняемых на сервере Системы.
3.6.4 Перечень данных, подлежащих автоматическому сбору, обработке и
сохранению в БД, представлен в Приложении 2.
3.7 Подсистема «НСИ»
3.7.1 Подсистема
должна
обеспечивать
справочников следующих информационных объектов:














Справочник контрагентов;
Справочник ГТП;
Справочник ЗСП;
Справочник регионов;
Справочник секторов ОРЭМ;
Справочник ценовых зон;
Справочник типов обязательств ОРЭМ;
Реестр договоров РД;
Реестр договоров ДПМ;
Реестр договоров КОМ;
Реестр договоров РСВ;
Реестр договоров БР;
Реестр договоров СДД;
Реестр внебиржевых СДЭМ;
возможность
ведения
10




Графики поставки и платежей по договорам;
Реестры обязательств по договорам;
Реестр платежей по договорам;
Тарифы ФСТ по станциям, индикативные цены по регионам.
3.7.2 Полный перечень хранимых информационных объектов должен быть
определен на этапе разработки ТЗ.
3.7.3 Подсистема должна предоставлять возможность отбора (поиска)
информационных объектов по произвольным критериям.
3.7.4 Подсистема
должна
поддерживать
(историчности) информационных объектов.
ведение
версионности
3.7.5 Подсистема должна предоставлять возможность выгрузки реестров
информационных объектов в формате MS Excel.
3.8 Подсистема «Работа с торговой системой»
3.8.1 Подсистема предназначена для подготовки ценовых заявок СО и КО
для участия в торгах на РСВ.
3.8.2
Подсистема должна обеспечивать выполнение следующих задач:
 Формирование и подача заявки на плановое почасовое потребление на
технологический сайт СО как в разрезе ГТП, так и в целом по ОДУ;
 Формирование и подача заявки на плановое почасовое потребление с
использованием ПО «АРМ Заявки» для отправки заявок в КО;
 Выполнять корректировку сформированных ценовых заявок;
 Обеспечивать хранение сформированных заявок;
 Выполнять сервисные операции: печать, экспорт.
3.9 Подсистема «Формирование отчетов и анализ»
3.9.1 Подсистема предназначена для формирования статистической
отчетности о результатах торгов на оптовом рынке электроэнергии (мощности) с
возможностью формирования плановых данных об объемах, ценах и стоимости
покупки электроэнергии и мощности на ОРЭМ по ГТП в разрезе месяц, квартал,
год. Отчетность необходимо получать как в табличном, так и в графическом виде.
Состав и формат стандартизированных форм отчетности определяется на этапе
разработки ТЗ. Сведения в отчетах необходимо детализировать по временным
периодам, а также по различным объектам учета:
 ГТП;
 узлам расчетной модели;
 видам финансовых обязательств.
3.9.2
Подсистема формирования отчетов и анализа должна обеспечивать:
 формирование аналитических отчетов о результатах оптовой торговли
электроэнергией в стандартизированном формате с возможностью
11





корректировки
(пользователь
самостоятельно
устанавливает
необходимую структуру отчетов, состав данных и период отчета);
формирование плановой структуры затрат на ОРЭМ (месяц, контрольная
дата) по ГТП на основе данных предыдущих периодов, данных о
плановых объемах и структуре потребления электроэнергии и мощности,
тарифах и ценах;
формирование разноски оплат по договорам ОРЭМ в разрезе секторов
и контрагентов;
контроль исполнения бюджетных показателей;
расчет стоимости услуг инфраструктурных организаций;
визуальное представление сведений, содержащихся в отчетах, в виде
графиков и диаграмм.
3.9.3 В подсистеме должен применяться механизм, который позволяет
настраивать отчеты в режиме визуального проектирования. Пользователи должны
иметь возможность создавать произвольные отчеты без необходимости
программирования.
3.9.4 Система должна обеспечивать как формирование отчетов по
заранее определенным отчетным формам, так и гибкую систему формирования
отчета в различных разрезах. Кроме того, должна быть доступна возможность
сохранения данных отображаемых на экранных формах представлений бизнесаналитики с учетом следующих требований:
 В гибкой системе формирования отчетов должна быть возможность
использовать все данные, перечисленные в п.п.3.6 и 3.7 настоящих
Технических требований;
 Экспорт отчетов в форматах: документов MS Office, XML, HTML, PDF.
3.10
Подсистема «Администрирование»
3.10.1 Подсистема
возможность:
«Администрирование»
должна
обеспечивать
 настройки разграничения прав доступа для ролей и пользователей;
 конфигурирования технических параметров системы;
 конфигурирования интерфейсов загрузки/выгрузки данных.
3.11
Требования по взаимодействию с другими системами
3.11.1 Система должна иметь возможность интеграции и информационного
обмена с имеющимися информационными системами Заказчика.
3.11.2 Схема взаимодействия с информационными системами приведена в
Приложении 3.
3.11.3 Подсистема «Сбор данных» должна взаимодействовать со
следующим ПО (импорт данных): «1С Предприятие», ПК «Энергосфера» (данные
АИИС КУЭ), Банк Клиент (настраиваемый интерфейс обмена данными), Почтовая
система Заказчика (MS Exchange) с возможностью приема подписанных ЭЦП
12
и/или
зашифрованных
ООО «Транснефтьэнерго».
сообщений,
АРМ
Участника
ОРЭМ,
Биллинг
3.11.4 Подсистема НСИ должна взаимодействовать со следующим ПО
(импорт/экспорт данных): Биллинг ООО «Транснефтьэнерго», ПО «1С Предприятие»,
Банк Клиент (настраиваемый интерфейс обмена данными).
3.11.5 Подсистема
«Работа
с
торговой
системой»
должна
взаимодействовать со следующим ПО (импорт/экспорт данных): Почтовая система
Заказчика (MS Exchange) с возможностью приема и отправки подписанных ЭЦП
и/или зашифрованных сообщений, АРМ «Заявки».
3.11.6 Работа с ЭЦП (прием и отправка подписанных и зашифрованных
сообщений), а также доступ в закрытые (персональные) разделы сайтов КО и СО
должны осуществляться посредством ПО CryptoPro.
3.12
Дополнительные требования к системе
3.12.1 Система и входящие в ее состав подсистемы должны поддерживать
следующие режимы функционирования:
 Основной режим;
 Профилактический режим.
3.12.2 Развитие и модернизация Системы должны быть предусмотрены в
следующих направлениях:
 Масштабируемость Системы как относительно количества объектов
НСИ, пользователей Системы, объема накопленных оперативных
данных, так и модернизации аппаратных средств серверной и
клиентских частей;
 В рамках технической поддержки Системы должно быть предусмотрена
оперативная адаптация выполняемых Системой функций в случае
изменения норм и правил (регламентов) работы ОРЭМ.
3.13
Требования к численности и квалификации персонала Системы и
режиму его работы
3.13.1 В состав персонала, обеспечивающего физическую эксплуатацию
АРМ и технологических узлов Системы, должны быть включены следующие типы
пользователей:
 Администратор;
 Пользователи;
 Куратор информационной безопасности.
3.13.2 Окончательный список типов персонала, осуществляющего
эксплуатацию Системы, определяется на этапе согласования ТЗ.
3.13.3 Администратор – обеспечивает функционирование технических и
программных средств подсистем. Его функциональные обязанности:
 настройка и диагностирование подсистем и их частей;
13





управление и настройка базового ПО системы;
определение прав уровня доступа для различных групп пользователей;
резервное копирование данных;
восстановление данных;
осуществление контроля доступа к системе.
3.13.4 Пользователь
–
обеспечивает
технологический
функционирования Системы. Функции пользователя:
процесс
 ввод и контроль информации;
 формирование запросов на получение информации из БД;
 формирование и вывод выходных документов и материалов.
3.13.5 Куратор информационной безопасности – имеет доступ к просмотру
журналов событий (логов) системы, прав уровня доступа для различных групп
пользователей.
3.13.6 Эксплуатация Системы должна проводиться персоналом, прошедшим
обучение работе с Системой. Администраторы должны пройти обучение у
поставщика соответствующего общесистемного программного обеспечения (ПО) и
иметь (по возможности) соответствующие сертификаты.
3.13.7 Численность, должностные обязанности и режим работы персонала,
а также требования к его квалификации определяются на стадии «Рабочая
документация» на основании (с учетом) организационной структуры объекта
автоматизации.
3.14
Показатели назначения
3.14.1 Система должна быть реализована как открытая, т.е. допускать
наращивание функциональных возможностей на основе подключения
дополнительных (или изменения существующих) подсистем в связи с изменением
существующих и возникновением новых автоматизируемых процессов.
3.14.2 Разрабатываемое ПО Системы должно быть гибким, т.е. легко
настраиваемым в соответствии с изменениями условий функционирования и
организационной структуры объекта автоматизации Системы.
3.14.3 Разрабатываемое ПО должно сохранять работоспособность при
увеличении количества пользователей в пределах, поддерживаемых аппаратнопрограммной средой технологического узла, но не менее 20 АРМ.
3.14.4 Технологические
узлы
должны
обеспечивать
возможность
модернизации как путем замены на новую версию общесистемного ПО, так и за
счет модернизации ПО разрабатываемых Исполнителем подсистем.
3.15
Требования к надежности
3.15.1 Архитектура Системы должна обеспечивать отказоустойчивый режим
функционирования при круглосуточном режиме работы, при наличии связи между
АРМ и технологическим узлом, а так же проведение полного и инкрементального
14
архивирования данных.
3.15.2 В качестве аппаратных платформ при построении технологических
узлов Системы должны использоваться средства повышенной надежности.
Среднее время восстановления аппаратно-программных комплексов (АПК)
технологических узлов не должно превышать 4 часов.
3.15.3 Надежность ПО Системы должна обеспечиваться следующими
средствами:
 Совокупностью общесистемного и разрабатываемого Исполнителем ПО,
в том числе:
 средствами управления базами данных;
 ПО разрабатываемой Исполнителем Системы;
 общесистемным ПО АРМ;
 средствами резервного копирования БД и серверной конфигурации
Системы; (обеспечивается Заказчиком)
 проведением Исполнителем комплекса мероприятий отладки, поиска
и исключения ошибок на стадии «Ввод в действие» (этап
«Проведение опытной эксплуатации»);
 алгоритмы и программные комплексы должны быть проверены на
наличие системных и логических ошибок путем проведения
испытаний;
 на этапе опытной эксплуатации должны быть исправлены все
выявленные ошибки кодирования и сборки программ.
3.15.4 Проверка выполнения требований по надежности должна
производиться на стадии «Ввод в действие» - по методике Исполнителя,
согласованной с полномочными представителями Заказчика.
3.15.5 В Системе должно быть обеспечено создание резервных копий
данных и основных настроек системы, а также восстановление после сбоев.
3.15.6 Максимальное
время
восстановления
работоспособности
подсистемы при любых сбоях и отказах технологического узла не должно
превышать 4-х часов. За это время должны быть выполнены:
 установка и настройка ПО на сервере;
 восстановление данных с использованием последней резервной копии.
(В указанное время не входит время на решение проблем с
техническим обеспечением и время инсталляции (установки)
общесистемного ПО.)
3.16
Требования к эргономике и технической эстетике
3.16.1 Требования текущего раздела не распространяются на интерфейс
пользователя общесистемных программных средств, а относятся лишь к
разрабатываемому Исполнителем ПО, непосредственно взаимодействующему с
операторами Системы:
15
 Система должна иметь графический интерфейс пользователя;
 Система должна использовать единый стиль оформления графического
интерфейса для всех подсистем;
 Система должна предоставлять полностью русскоязычный интуитивно
понятный
интерфейс пользователя (при этом допускается
использование англоязычного интерфейса для общесистемных
программных компонентов);
 В Системе должны быть предусмотрены «горячие» клавиши для наиболее
частых операций;
 Система должна предоставлять возможность настройки собственных
меню, наиболее удобных для каждой группы пользователей;
 Система должна поддерживать возможность многопользовательской
работы.
3.16.2 Организация графического пользовательского интерфейса должна
препятствовать ошибочным действиям пользователей, в том числе:
 Пользователь должен иметь возможность контролировать ввод данных:
просматривать введенные данные, производить их корректировку или
же отказаться от ввода;
 При вводе должны максимально использоваться справочники и списки
допустимых значений;
 Должна обеспечиваться возможность определения и сохранения
значений по умолчанию;
 При обнаружении Системой ошибок в действиях пользователя должно
выдаваться сообщение с диагностикой, достаточной для исправления
ошибки. Алгоритмы определения ошибочных действий пользователя и
содержание сообщений должны быть определены и согласованы с
Заказчиком на стадии «Технорабочий проект».
3.17
Требования к информационной безопасности
3.17.1 Средства информационной безопасности системы должны
представлять комплекс организационных, технических и программных решений по
обеспечению безопасности информации, циркулирующей в системе и связанных с
ней объектов.
3.17.2 Методы защиты информации и реализующие их технические
решения в средствах защиты информации не должны снижать функциональные
возможности
Системы,
вносить
принципиальные
ограничения
по
производительности и времени реакции систем.
3.17.3 Средства и методы информационной безопасности Системы не
должны противоречить уже существующим в информационной инфраструктуре
Общества механизмам защиты информации.
3.17.4 Функционирование Системы будет осуществляться в рамках ККС.
16
3.17.5 При создании Системы необходимо учесть требования нормативных
документов ОАО «АК «Транснефть» и ООО «Транснефтьэнерго»:
 - ОР-35.240.00-КТН-09907 Регламент организации работ по защите
информации
при
разработке,
внедрении
и
эксплуатации
информационных систем, информационно-коммуникационных сетей и
автоматизированных систем предприятий группы «Транснефть»;
 - Политика парольной защиты в ООО «Транснефтьэнерго, утвержденной
приказом ООО «Транснефтьэнерго» от 28.03.2013 № 72;
 - других нормативных документов ООО «Транснефтьэнерго» по работе с
информацией, имеющей ограничительные грифы «Конфиденциально» и
«Коммерческая тайна».
3.17.6 Требования к программному обеспечению
 Разрабатываемое ПО не должно требовать для установки, активации,
работы, обновления или деинсталляции связи с ресурсами разработчика
или ресурсами, размещенными в публичной (общедоступной) сети
Интернет.
 Разрабатываемое ПО не должно использовать в своей работе
протоколы, передающие аутентификационные данные в открытом виде.
 В
случае,
если
разрабатываемое
ПО
предполагает
многопользовательский доступ к системе, ПО должно позволять
назначать каждому пользователю уникальный идентификатор.
 Для взаимодействия компонентов ПО в автоматическом режиме
должны
использоваться
уникальные
предустанавливаемые
технологические учетные записи. Все предустановленные учетные
записи должны иметь возможность смены пароля.
 Должна осуществляться идентификация субъектов доступа при входе в
систему.
 Должна осуществляться аутентификация (проверка подлинности)
субъекта при доступе в систему на основе имени пользователя и пароля.
Пароль должен отвечать требованиям Политики парольной защиты в
ООО «Транснефтьэнерго»,
утвержденной
приказом
ООО «Транснефтьэнерго» от 28.03.2013 № 72.
 Отображение аутентификатора при вводе его пользователем должно
обеспечивать защиту от несанкционированного использования.
 Должна
быть
обеспечена
криптографическая
защита
аутентификационных данных, хранимых и передаваемых по сети в
рамках процедур идентификации и аутентификации.
 Разрабатываемое ПО не должно требовать использования в штатном
режиме работы пользователей съемных носителей информации. Все
типовые операции обмена файлами должны быть автоматизированы.
Место расположения объекта для выгрузки/загрузки должно быть
настраиваемым и должно позволять загружать/выгружать файлы с
ресурса сети, идентифицируемого IP-адресом или DNS-именем.
17
 Разрабатываемое ПО должно обеспечивать возможность разграничения
доступа на основе ролевой модели. Набор предоставляемых роли
полномочий должен быть настраиваемым.
 Любое назначение прав в системе должно выполняться явным образом.
 12)
Административные функции должны быть отделены от
пользовательских функций.
 Доступ к наиболее критичным функциям, влияющим на безопасность
системы, в том числе правам управления учетными записями,
изменениям настроек протоколирования работы системы, должен
предоставляться в явном виде.
 Должна осуществляться регистрация следующих видов событий:
 вход субъектов доступа в систему;
 использование административных привилегий, в том числе создание,
модификация, удаление учетных записей, а также изменение прав
доступа к системе.
 В параметрах регистрации должны быть указаны:
 дата и время события;
 вид события;
 идентификатор пользователя.
 Разрабатываемое ПО не должно требовать для работы пользователей
предоставления им дополнительных привилегий в ОС или СУБД.
 Разрабатываемое ПО должно ограничивать возможность ввода и
проверять достоверность вводимых данных на предмет синтаксиса,
формата данных, соответствия диапазонам граничных значений и др.
3.17.7 Требования к работам по созданию и поддержке программного
обеспечения
 Документация на разрабатываемое ПО должна содержать:
 описание реализованных защитных мер;
 перечень используемых протоколов/сервисов с указанием их
назначения;
 перечень и описание предустановленных учетных записей, в том
числе технологических.
 Документ «Программа и методика испытаний» на разрабатываемое ПО
должен в явном виде включать в себя тесты по безопасности,
обеспечивающие
проверку
работоспособности
реализованных
защитных мер.
 В случае выявлений уязвимостей в разработанном им программном
обеспечении в период действия гарантийного срока или услуг по
технической поддержке, Разработчик обязан обеспечить выпуск
обновления, закрывающего данную уязвимость, не позднее 30 дней с
момента уведомления его о наличии уязвимости.
18
 Должна быть обеспечена совместимость прикладного ПО с критичными
обновлениями безопасности (патчами) используемых ОС и СУБД. В
период действия гарантийного срока или услуг по технической
поддержке Разработчик обязан в срок, не превышающий 30 дней от
выпуска соответствующего обновления разработчиком ОС или СУБД,
подтвердить возможность установки данного обновления на
промышленные системы без риска нарушения их работоспособности
или, в случае наличия неразрешенного конфликта между прикладным
ПО и обновлением, предложить компенсационные меры снижения
риска, связанного с незакрытыми уязвимостями, на период устранения
данного конфликта.
 Обновления ПО должны быть обеспечены способом, исключающим его
случайное или преднамеренное искажение.
3.18
Требования по сохранности информации при авариях
3.18.1 Сохранность информации в Системе должна обеспечиваться при
следующих аварийных ситуациях:
 импульсные помехи, сбои и перерывы в электропитании;
 нарушение или выход из строя каналов связи;
 полный или частичный отказ технических средств Системы, включая
сбои и отказы накопителей на жестких магнитных дисках;
 сбой общесистемного ПО, отдельного АРМ, сервера технологического
узла;
 ошибки в работе персонала.
3.19
Требования к патентной чистоте
3.19.1 Проектные решения Системы должны отвечать требованиям по
патентной чистоте согласно действующему законодательству Российской
Федерации.
3.19.2 Необходимые лицензии общесистемного ПО (ОС, СУБД и т.д.) не
входящие в Microsoft Enterprise Agreement должны быть предоставлены
Исполнителем в рамках договора по созданию Системы.
3.19.3 Все лицензии на Систему (неисключительные), обеспечивающие
отсутствие каких-либо ограничений на использование Системы за исключением
количества пользователей, указанного в п.3.1.8, а также используемого
серверного оборудования, указанного в п.3.4.1 настоящих ТТ, должны быть
предоставлены Исполнителем в рамках договора по созданию Системы.
3.20
Требования по стандартизации и унификации
3.20.1 При разработке Системы должна обеспечиваться унификация и
стандартизация на уровне интерфейсов взаимодействия пользователей с
разрабатываемыми Исполнителем подсистемами Системы.
3.20.2 Должна
обеспечиваться
возможность
совмещения
на
одном
19
физическом рабочем месте нескольких подсистем и различных АРМ (в
соответствии с правами пользователя).
20
4.
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ
4.1 Порядок оформления и предъявления заказчику результатов работ.
4.1.1 Сдача-приемка этапов выполненных работ на стадиях работ
осуществляется по предъявлении Исполнителем комплектов соответствующих
документов и завершается оформлением акта сдачи-приемки, подписанного
Исполнителем и утвержденного Заказчиком.
4.1.2 В процессе приемки результатов должна быть осуществлена их
проверка на соответствие требованиям «Технического задания».
4.1.3 Испытания Системы должны быть проведены на стадии «Ввод в
эксплуатацию» на основании Программы и методики испытаний, подготовленной
Исполнителем и утвержденной Заказчиком на стадии «Технорабочий проект».
4.1.4 Этап «Предварительные испытаний» завершается оформлением акта
о приемке Системы в опытную эксплуатацию с приложением к нему протоколов
испытаний.
4.1.5 Результаты работ по этапу «Опытная эксплуатация» принимаются с
оформлением Акта о завершении опытной эксплуатации.
4.1.6 Все замечания к ПО и эксплуатационной документации, выданные
Заказчиком при сдаче системы в опытную эксплуатацию или в процессе опытной
эксплуатации, должны быть устранены Исполнителем до предъявления Системы к
приемочным испытаниям.
4.1.7 Порядок и сроки проведения приемочных испытаний определяются
на этапе «Опытная эксплуатация».
4.1.8 Приемку
работ
осуществляет
приемочная
комиссия,
сформированная Заказчиком, в состав которой могут быть включены
представители Заказчика и других организаций по согласованию с Заказчиком.
4.1.9 Этап «Проведение приемочных испытаний» заканчивается
оформлением акта о приемке Системы в промышленную эксплуатацию.
4.2 Этапы и результаты работ по созданию системы
Таблица 4.2.1
№
пп
1
1.1
Наименование
фазы и этапов
работ
Содержание
этапа
Проведение
предпроектного
обследования
Изучение
объекта
автоматизации,
сбор
необходимой
информации.
Результаты
21
№
пп
1.2
2
2.1
3
3.1
3.2
3.3
Наименование
фазы и этапов
работ
Содержание
этапа
Результаты
Разработка
технического
задания
Подготовка
Утвержденное техническое задание
проекта ТЗ и
утверждение
его у Заказчика
Разработка
технорабочего
проекта
Разработка
проектной
документации,
программ и
методик
испытаний.
Разработка и
адаптация
программного
обеспечения
Подготовка
объекта
автоматизации к
вводу в
действие
Подготовка
инфраструктуры
, установка
необходимого
ПО, подготовка
информации
для
первоначальной
загрузки данных
Передача всех
необходимых
лицензий на
поставляемое
ПО
Обучение
Обучение
персонала
пользователей
работе с
системой
Предварительны Проверка
Детальный
состав
проектной
документации определяется в ТЗ
Минимальный состав документации:
- пояснительная записка;
- руководство пользователя;
- руководство администратора;
- руководство
куратора
информационной безопасности;
- технические
решения,
информационно-вычислительная
инфраструктура ИС;
- регламент обслуживания;
- утвержденные программы и методики
проведения испытаний.
Готовое
к
развертыванию
программное обеспечение
Развернутая
на
оборудовании
Заказчика ИС;
переданные лицензии;
заполненные справочники по данным
Заказчика (в соответствии с п.п.4.2.2.1
настоящих технических требований)
Акт об окончании обучения
Система
готовая
к
опытной
22
№
пп
Наименование
фазы и этапов
работ
е испытания
3.4
Опытная
эксплуатация
3.5
Приемочные
испытания
Содержание
этапа
работоспособно
сти развернутой
Системы
Проверка
соответствия ИС
требованиям
рабочей
документации.
Доработка ИС
по замечаниям
заказчика
Проверка
полноты и
качества
реализации
функций ИС,
готовности
персонала
Результаты
эксплуатации.
Протокол предварительных испытаний
Акт ввода в опытную эксплуатацию
ИС готовая к приемочным испытаниям
Журнал учета и устранения замечаний,
выявленных
в
ходе
опытной
эксплуатации.
Акт
готовности
к
приемочным
испытаниям
АС ОРЭМ, соответствующая ТЗ, готовая
к промышленной эксплуатации.
Акт
приемки
в
промышленную
эксплуатацию
4.2.1 На стадии «Техническое задание» должны быть сформированы
требования пользователей, выбраны производители общесистемного ПО, а так же
разработано и утверждено техническое задание на разработку Системы.
4.2.2 На стадии «Технорабочий проект» должна быть осуществлена
разработка проектных решений по Системе и ее разделам, а также проектной
документации на Систему.
4.2.3 На стадии «Ввод в действие» должна быть выполнена адаптация
программ, включая базы данных и пользовательские интерфейсы, проведены
работы по подготовке объекта автоматизации к вводу Системы в действие,
подготовке персонала, комплектации Системы поставляемыми изделиями (в том
числе программными и техническими средствами), пусконаладочные работы,
предварительные испытания, опытная эксплуатация и приемочные испытания.
4.2.4 По завершении стадии «Ввод в действие» должна начаться стадия
сопровождения, требования и условия которой должны быть определены
отдельным договором.
4.3 Требования к испытаниям системы и ее составных частей
4.3.1 Система должна пройти испытания и опытную эксплуатацию на
объектах автоматизации в соответствии с требованиями соответствующего
ГОСТ 34.603-92 и ТЗ. Для Системы устанавливаются следующие виды испытаний:
23
 предварительные испытания;
 опытная эксплуатация;
 приемочные (окончательные) испытания.
4.3.2 В процессе предварительных испытаний на объектах автоматизации
должна быть осуществлена проверка соответствия Системы требованиям,
содержащимся в Техническом задании, а также полноты содержащихся в
эксплуатационной документации указаний персоналу по выполнению им функций
во всех режимах функционирования, и ее соответствия реальному
функционированию Системы.
4.3.3 Опытная эксплуатация проводится в реальном режиме работы на
объектах автоматизации в пределах автоматизируемых функций, предусмотренных
к реализации РЕАЛЬНЫЕ ДАННЫЕ. Все функции персонала подразделения,
автоматизация которых предусмотрена в Системе, должны выполняться с
использованием средств автоматизации.
4.3.4 Во время опытной эксплуатации должен вестись рабочий журнал
опытной эксплуатации, в который должны заноситься сведения о
продолжительности функционирования Системы, отказах, сбоях, аварийных
ситуациях, изменениях параметров объекта автоматизации, проводимых
корректировках документации и программных средств, наладке технических
средств, а также замечания персонала по удобству эксплуатации Системы.
Выявленные замечания и неисправности должны быть устранены Исполнителем в
сроки, согласованные с представителями Заказчика.
4.3.5 Приемочные (окончательные) испытания проводятся в соответствии
с утвержденной Программой и методикой приемочных испытаний путем
выполнения комплексных тестов, подготовленных Исполнителем на стадии
«Технорабочий проект» и согласованных с представителями Заказчика.
4.3.6
Приемочные испытания должны включать проверку:
 полноты и качества реализуемых функций при штатных, предельных,
критических значениях параметров объекта автоматизации и в других
условиях функционирования Системы, указанных Техническом задании;
 выполнения каждого требования, относящегося к интерфейсу Системы;
 работы персонала в диалоговом режиме;
 комплектности и качества эксплуатационной документации.
4.3.7
Испытания системы проводятся на территории Заказчика.
4.4 Мероприятия по обучению персонала
4.4.1 Обучение
ключевых
пользователей
осуществляется
в
подготовленном помещении на территории ООО «Транснефтьэнерго» в г. Москва.
4.4.2 Заказчик самостоятельно организует мероприятия, техническое
обеспечение помещений для обучения, а также программного обеспечения,
необходимого для обучения пользователей.
24
4.5 Мероприятия по организационному обеспечению
4.5.1 Мероприятия,
связанные
со
своевременным
выпуском
организационно-распорядительных документов, регламентов и других внутренних
документов Заказчика, организуются заказчиком самостоятельно.
25
5.
ТРЕБОВАНИЯ ПО ОРГАНИЗАЦИИ ГАРАНТИЙНОЙ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ
5.1.1 Исполнитель должен предоставить гарантийную техническую
поддержку внедренного решения в течение не менее 12 месяцев с момента
завершения работ по договору.
26
6.
ПРИЛОЖЕНИЯ
6.1 Приложение 1. Функциональная архитектура Системы
27
6.2 Приложение 2. Перечень данных, подлежащих автоматическому сбору
Загрузка данных осуществляется в соответствии с разделом 9 «Информирование
участника оптового рынка о состоянии расчетов» Приложения № 16 к Договору о присоединении
к торговой системе оптового рынка - Регламент финансовых расчетов на оптовом рынке
электроэнергии.
№
Название макета
Способ получения макета
Таблица 6.2
Периодичность
загрузки
1. Регламентные отчеты ОРЭМ (Отчеты с персональной страницы сайта КО)
1.1
Фактические почасовые значения
стоимости и объемов отклонений
по итогам отчетного периода.
1.2
Отчет о торговой сессии (Отчет по
потреблению НОРЭМ).
1.3
Отчет о состоянии обязательств по
покупке и продаже.
1.4
Отчёт о состоянии
обязательств.
1.5
Отчёт о состоянии обязательств по
пени.
1.6
Отчет о состоянии матричных
обязательств по оплате пени за
месяц
1.7
Отчет по обязательствам
контрольную дату.
1.8
Отчет об исполнении платежей.
1.9
Отчет по потреблению в узлах
расчетной модели.
1.10
Свободные
двусторонние
договоры (ежедневные отчеты)
1.11
Свободные двусторонние договоры
(ежемесячные отчеты).
матричных
на
Автоматически с сайта КО
Персональный раздел
(Пункт 20)
Автоматически с сайта КО
Персональный раздел
(Пункт 28)
Автоматически с сайта КО
Персональный раздел
(Пункт 29)
Автоматически с сайта КО
Персональный раздел
(Пункт 291)
Автоматически с сайта КО
Персональный раздел
(Пункт 292)
Автоматически с сайта КО
Персональный раздел
(Пункт 293)
Автоматически с сайта КО
Персональный раздел
(Пункт 30)
Автоматически с сайта КО
Персональный раздел
(Пункт 31)
Автоматически с сайта КО
Персональный раздел
(Пункт 34)
Автоматически с сайта КО
Персональный раздел
(Пункт 40)
Автоматически с сайта КО
Персональный раздел
(Пункт 41)
Ежемесячно
(1 числа)
Ежедневно
Ежедневно
Ежедневно
Ежедневно
Ежемесячно
Ежедневно
Ежедневно
Ежедневно
Ежедневно
Ежемесячно
28
№
Название макета
Способ получения макета
Периодичность
загрузки
1.12
Уведомление о расчете пени.
Автоматически с сайта КО
Персональный раздел
(Пункт 42)
Ежедневно
1.13
Корреляция индексов хабов и цены
в ГТП за сутки.
Автоматически с сайта КО
Персональный раздел
(Пункт 47)
Ежедневно
1.14
Ежемесячный
отчет
по
фактическим объемам покупкипродажи мощности на оптовом
рынке для ГТП потребления
(экспорта) Участников неценовых
зон
Автоматически с сайта КО
Персональный раздел
(Пункт 51)
Ежемесячно
1.15
Уведомление о расчете пени (за
месяц).
Автоматически с сайта КО
Персональный раздел
(Пункт 55)
Ежемесячно
1.16
Ежемесячный
отчет
по
фактическим
максимальным
часовым значениям потребления
электроэнергии для ГТП (экспорта)
Участников неценовых зон
Автоматически с сайта КО
Персональный раздел
(Пункт 56)
Ежемесячно
1.17
Расширенный
комиссионера.
1.18
Расширенный отчет по мощности
комиссионера
1.19
Структура задолженности.
1.20
1.21
1.22
отчет
по
ЭЭ
Аналитический
отчет
по
определению авансовых величин
покупки и продажи мощности в
неценовой зоне
Аналитический
отчет
по
определению
фактической
стоимости
покупки/продажи
мощности в неценовой зоне
Аналитический
отчет
по
определению плановой почасовой
стоимости
потребления
по
неценовым зонам
Автоматически с сайта КО
Персональный раздел
(Пункт 63)
Автоматически с сайта КО
Персональный раздел
(Пункт 64)
Автоматически с сайта КО
Персональный раздел
(Пункт 65)
Ежемесячно
Ежемесячно
Ежедневно
Автоматически с сайта КО
Персональный раздел
(Пункт 66)
Ежемесячно
Автоматически с сайта КО
Персональный раздел
(Пункт 68)
Ежемесячно
Автоматически с сайта КО
Персональный раздел
(Пункт 70)
Ежемесячно
29
№
1.23
1.24
1.25
1.26
1.27
1.28
1.29
1.30
1.31
1.32
1.33
Название макета
Аналитический
отчет
по
определению авансовых величин
покупки и продажи электроэнергии
в неценовой зоне
Аналитический
отчет
по
определению фактических величин
покупки и продажи электроэнергии
в неценовой зоне
Ежемесячный
отчет
по
фактическим
максимальным
часовым значениям потребления
электроэнергии
для
ГТП
потребления (экспорта) Участников
ценовых зон.
Ежемесячный
отчет
по
фактическим объемам покупки
мощности на оптовом рынке для
ГТП
потребления
Участников
ценовых зон.
Ежемесячный отчет по объемам
покупки и продажи мощности по
ЗСП и ГТП для Участников ценовых
зон.
Ежемесячный отчет по объемам
покупки/продажи мощности по ГТП
генерации Участников ценовых
зон.
Ежемесячный отчет об объемах
мощности,
используемых
для
начисления
авансовых
обязательств.
Величина ВСВГО.
Аналитический отчет по авансам
ВР
Данные,
предоставляемые
коммерческим оператором ГП
(ЭСО, ЭСК) для определения
предельных уровней цен на
розничных рынках электрической
энергии на территориях неценовых
зон оптового рынка
Информация
о
перетоках
мощности в сечениях за сутки
Способ получения макета
Периодичность
загрузки
Автоматически с сайта КО
Персональный раздел
(Пункт 73)
Ежемесячно
Автоматически с сайта КО
Персональный раздел
(Пункт 74)
Ежемесячно
Автоматически с сайта КО
Персональный раздел
(Пункт 76)
Ежемесячно
Автоматически с сайта КО
Персональный раздел
(Пункт 77)
Ежемесячно
Автоматически с сайта КО
Персональный раздел
(Пункт 78)
Ежемесячно
Автоматически с сайта КО
Персональный раздел
(Пункт 80)
Ежемесячно
Автоматически с сайта КО
Персональный раздел
(Пункт 81)
Ежемесячно
Автоматически с сайта КО
Персональный раздел
Автоматически с сайта КО
Персональный раздел
Ежемесячно
Ежемесячно
Автоматически с сайта КО
Персональный раздел
Ежемесячно
Автоматически с сайта КО
Персональный раздел
Ежедневно
30
№
1.34
1.35
1.36
Название макета
Итоговый почасовой отчет по
определению
обязательств/требований по оплате
отклонений участника
Отчет
о
перетоках
между
субъектами РФ ЕЭС
Отчет о торгах по субъектам РФ ЕЭС
Способ получения макета
Автоматически с сайта КО
Персональный раздел
Автоматически с сайта КО
Персональный раздел
Автоматически с сайта КО
Персональный раздел
Периодичность
загрузки
Ежемесячно
Ежедневно
Ежедневно
2. Регламентные отчеты ОРЭМ (Отчеты с сайта Балансирующего рынка СО)
Автоматически с сайта СО
Ежедневно
Балансирующий рынок
Результаты БР по сессиям по ГТП Автоматически с сайта СО
По сессиям каждые
2.2
потребления.
Балансирующий рынок
3 часа
3. Регламентные отчеты ОРЭМ (Отчеты, обеспечивающие финансовые расчеты между
участниками оптового рынка, направляемые КО/ОАО «ЦФР» на адреса электронной почты)
Реестр регулируемых договоров
3.1
купли-продажи
электрической
По электронной почте
Ежегодно
энергии и мощности.
График поставки электроэнергии по
регулируемому договору купли3.2
По электронной почте
Ежегодно
продажи электрической энергии и
мощности.
График поставки мощности по
регулируемому договору купли3.3
По электронной почте
Ежегодно
продажи электрической энергии и
мощности.
График платежей по регулируемому
договору
купли-продажи
3.4
По электронной почте
Ежегодно
электрической
энергии
и
мощности.
Реестр
обязательств
по
Ежемесячно
3.5
КО по почте
Регулируемым договорам (РД).
(28 и 14 числа)
Реестр обязательств/требований
по
договорам
купли-продажи
Ежемесячно
3.6
электроэнергии
для
КО по почте
(14-20 числа)
балансирования системы (покупка)
по ГТП.
Реестр обязательств/требований
по договорам комиссии на продажу
Ежемесячно
3.7
электроэнергии
для
КО по почте
(14-20 числа)
балансирования
системы
(продажа) по ГТП.
2.1
Участие в регулировании.
31
№
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
Название макета
Реестр требований по договорам
комиссии на РСВ по ГТП.
Реестр обязательств по договорам
купли-продажи на РСВ по ГТП.
Реестр обязательств/требований
по авансовым платежам по
договорам
куплипродажи/комиссии на РСВ по ГТП
участника.
Реестр обязательств по доплате
(возврату) денежных средств в
целях исполнения договоров куплипродажи/комиссии, заключенных
на РСВ по ГТП участника.
Реестр требований по договорам
комиссии на продажу мощности
(КОМ).
Реестр обязательств по договорам
купли-продажи мощности (КОМ).
Реестр обязательств за мощность,
продаваемую по договору куплипродажи мощности, производимой
на генерирующем оборудовании
атомных
электростанций
и
гидроэлектростанций.
Реестр авансовых требований по
договору купли-продажи мощности,
производимой с использованием
генерирующих
объектов,
поставляющих
мощность
в
вынужденном режиме мощности
(продажа).
Аналитический отчет об авансовых
обязательствах/требованиях
по
договору купли-продажи мощности,
производимой с использованием
генерирующих
объектов,
поставляющих
мощность
в
вынужденном режиме.
Реестр авансовых обязательств по
договорам
о
предоставлении
мощности (покупатели)
Способ получения макета
КО по почте
КО по почте
Периодичность
загрузки
Ежемесячно
(14-20 числа)
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(1-10 числа)
32
№
3.18
3.19
3.20
3.21
Название макета
Итоговый
реестр
финансовых
обязательств по договорам о
предоставлении
мощности
(покупатели)
Реестр рассчитанных штрафов по
договорам
о
предоставлении
мощности (покупатели)
Отчет о результатах расчетов
объемов
и
стоимости
электроэнергии и мощности на
оптовом рынке (Финансовый отчет)
Отчет о результатах расчетов
объемов
и
стоимости
электроэнергии и мощности на
оптовом рынке (Финансовый отчет
НЦЗ)
Способ получения макета
Периодичность
загрузки
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
КО по почте
Ежемесячно
(14-20 числа)
4. Регламентные отчеты ОРЭМ (Информация с технологических сайтов СО)
4.1
Параметры
оборудования.
4.2
Плановое почасовое потребление.
4.3
4.4
генерирующего
Состав
генерирующего
оборудования.
Плановые
почасовые
объемы
дополнительно передаваемых в КО
показателей
Автоматически с
технологических сайтов СО
Автоматически с
технологических сайтов СО
Автоматически с
технологических сайтов СО
Автоматически с сайта СО
– «Витрина ОДУ Востока»
Ежесуточно до 13-00
Ежесуточно до 13-00
Ежесуточно до 13-00
Ежесуточно до 13-00
5. Регламентные отчеты ОРЭМ (Информация с открытых разделов сайта КО)
5.1
Торговый график для режимных
генерирующих единиц
Сайт КО. Открытый раздел
Ежедневно
5.2
Отчёт о перетоках между ЗСП ЕЭС
Сайт КО. Открытый раздел
Ежедневно
5.3
Индексы цен РСВ в ЗСП
Сайт КО. Открытый раздел
Ежедневно
5.4
Индексы Хабов
Сайт КО. Открытый раздел
Ежедневно
5.5
Сезонные коэффициенты
Сайт КО. Открытый раздел
Ежегодно
5.6
Предварительная
средневзвешенная цена мощности
по
результатам
конкурентного
отбора мощности
Сайт КО. Открытый раздел
Ежегодно
33
№
5.7
5.8
5.9
5.10
5.11
5.12
Название макета
Средневзвешенная цена покупки
мощности
Ежемесячный отчет по величине
фактического
коэффициента
резервирования мощности для
ценовых зон
Отчёт о торгах по зонам свободного
перетока ЕЭС
Отчет об объемах планового
почасового производства по типам
станций
Отчет об объемах планового
почасового
потребления
электрической энергии по типам
потребителей
Объемы суммарных нагрузочных
потерь э/э по каждой ГТП
потребления за день
Способ получения макета
Сайт КО. Открытый раздел
Периодичность
загрузки
Ежемесячно
(14-20 числа)
Сайт КО. Открытый раздел
Ежемесячно
Сайт КО. Открытый раздел
Ежедневно
Сайт КО. Открытый раздел
Ежедневно
Сайт КО. Открытый раздел
Ежедневно
Сайт КО. Открытый раздел
Ежедневно
6. Показатели потребления
6.1
Макет 80020
По электронной почте
Ежедневно
6.2
Макет 51070
По электронной почте
Ежемесячно
6.3
Макет 80040
По электронной почте
Ежемесячно
7. Показатели суточного планового почасового потребления
7.1
Таблица MS Excel
По электронной почте
Ежедневно
34
6.3 Приложение 3. Взаимодействие со смежными системами