Главная страница
Навигация по странице:

  • ИТОГО 3000 Резерв, 30 % 900 ВСЕГО 3900

  • 4.1.2.

  • 4.1.3.

  • ТТ_на_ССД_финал_публ.[1]. Версия 002018 г. Технические требования на систему автоматизированного сбора


    Скачать 1.29 Mb.
    НазваниеВерсия 002018 г. Технические требования на систему автоматизированного сбора
    Анкор132313
    Дата02.12.2021
    Размер1.29 Mb.
    Формат файлаpdf
    Имя файлаТТ_на_ССД_финал_публ.[1].pdf
    ТипОтчет
    #288747
    страница2 из 5
    1   2   3   4   5

    AI
    DI
    1
    2
    3
    4
    5
    6
    15
    СИКП-9
    WinCC
    (Siemens)
    OPC, Ethernet
    TCP/IP,
    (480 тегов)
    21 30 16
    СИКГ-10
    -
    RS-485 3
    -
    17
    СИКГ-1*
    Intouch
    (Wonderware),
    SOFTNET (Siemens)
    OPC, Ethernet,
    TCP/IP, ModBus
    RTU
    75 24 18
    СИКГ-2*
    19
    СИКГ-3*
    20
    СИКГ-4*
    21
    СИКГ-6*
    22
    ЛИМС
    LabWare
    Ethernet, TCP/IP, (до
    600 тегов)
    23
    Система учета стоков в промканализацию по GSM-каналам
    Ethernet
    8 24 АСТУЭ АО «НГПЗ»
    Энергия+
    (ООО НТП
    «Энергоконтроль»)
    Ethernet, RS-485 25
    СИКП ШФЛУ на входе в АО «ОГПЗ»,
    АО «ННК»**,
    СИКГ 3-й ступени с
    Нефтегорского
    НСП** по GSM- каналам
    26
    Не измеряемые данные
    Ручной ввод
    250
    ИТОГО

    3000
    Резерв, 30
    %
    900
    ВСЕГО
    3900
    * - этап СМР;
    ** - этап ПИР
    Точное количество объектов, сигналов и тегов будет определено после проведения предпроектного обследования.

    10
    4.
    ТРЕБОВАНИЯ К СИСТЕМЕ
    4.1.
    ТРЕБОВАНИЯ К СИСТЕМЕ В ЦЕЛОМ
    4.1.1.
    ТРЕБОВАНИЯ К СТРУКТУРЕ И ФУНКЦИОНИРОВАНИЮ СИСТЕМЫ
    1) Требования к числу уровней иерархии и степени централизации Системы.
    Требования к составу программно-технических комплексов (описание требований к
    структуре может сопровождаться графическим изображением структуры);
    Система должна быть реализована в АСОУП . Система создается в виде иерархической, функционально и территориально распределенной системы управления и должна соответствовать ГОСТ 24.104-85.
    Система должна иметь стандартную клиент-серверную структуру;
    Иерархическая структура системы включает в свой состав следующие уровни контроля и управления:

    нижний уровень – сбор данных;

    средний уровень – обработка данных и их долговременное хранение;

    верхний уровень – подготовка данных, визуализация и предоставление информации.
    В нижний уровень системы входят

    программно-технические средства для автоматического сбора данных от всех имеющихся на заводе автоматизированных систем контроля и управления технологическими процессами;

    интерфейсы обмена данными с системами и бизнес-приложениями на предприятии;

    ручной ввод данных.
    В средний уровень системы входят средства для вычислительной обработки, архивирования и долговременного надежного хранения данных.
    По функциональным признакам верхний уровень подразделяется на следующие подсистемы:

    Подсистема управления базами данных;

    Подсистема управления средствами предоставления информации коллективного пользования (АРМ пользователей), включая средства документирования и диалога с системой, различные способы визуализации (тренды, мнемосхемы, KPI и т.д.)

    Компоненты администрирования и вспомогательных служб (АРМ инженеров и администраторов системы);
    Подсистема защиты информации, представляющая собой совокупность модулей, входящих в её состав (модуль контроля доступа, модуль регистрации и учёта, модуль контроля целостности), а также специальных средств (средства межсетевого экранирования, средства защиты каналов связи, средства анализа защищённости, ПО антивирусной защиты).Источниками данных являются любые системы, подсистемы, узлы и устройства нижних, по отношению к АСОУП уровней системы управления. Кроме этого, источником

    11 данных могут являться любые необходимые вышестоящие системы и подсистемы, такие как
    ERP и другие. Система должна обеспечивать:

    Автоматический сбор данных от автоматизированных систем управления технологическим процессом;

    Сбор данных от узлов технического и коммерческого учета сырья и продукции;

    Сбор данных от различных узлов, аппаратов, агрегатов, автомобильных и железнодорожных весов, систем налива, систем вибромониторинга, систем обнаружения загазованности, охранной и пожарной сигнализации и т.д.;

    Сбор данных при ее ручном вводе;

    Сбор данных от имеющихся систем третьих производителей, т.к. ЛИМС, АСКУЭ,
    АСТУЭ, ERP и т.д.
    Хранение данных должно выполняться в следующих базах:

    База данных реального времени (БДРВ), используется для хранения собираемых с производства данных параметров технологического режима;

    Реляционной базе данных (СУБД), используется для хранения технической информации и остальных данных, включая данные событий/транзакций и справочные данные предприятия.
    Основные технические компоненты системы:

    серверы, получающие, обрабатывающие, хранящие данные и выдающие пользователям необходимую им информацию;

    рабочие станции администратора и пользователей во всех подразделениях завода;

    вычислительная сеть, объединяющая все средства системы;

    программно-технические средства обмена данными с другими системами автоматизации разных уровней, шлюзовые станции, станции ручного ввода данных.
    Система, в зависимости от объемов данных и сложности обработки, может состоять из одного или нескольких технологических серверов. Распределение функций между серверами
    Системы может, осуществляется как по видам обрабатываемой информации, так и по общности выполняемых функций для данного вида информации.
    2) требования к способам и средствам связи для информационного обмена между
    компонентами системы;
    При внедрении Системы предлагается использовать имеющуюся инфраструктуру вычислительных сетей АО «НГПЗ»
    и Компании.
    На рисунке 1 приведена схема информационного взаимодействия между компонентами
    Системы
    В качестве протокола взаимодействия между компонентами Системы на транспортно- сетевом уровне необходимо использовать протоколы TCP/IP.
    Для каждого клиентского приложения пользователя или серверов приложений, в рамках их роли, должны быть четко установлены объекты СУБД и БДРВ, с которыми они взаимодействует.
    Используемое для передачи данных в сети оборудование должно обеспечивать:

    12

    обмен данными в режиме реального времени;

    безопасное разделение технологических и бизнес-сегментов сетей;

    устойчивое сетевое соединение на базе использования различных технологий построения территориально - распределенных систем.
    При отсутствии на объектах АСУТП для сбора необходимо использовать АРМ ручного ввода данных параметров технологического процесса, который должен быть организован непосредственно на объекте.
    Рисунок 1. Схема информационного взаимодействия между компонентами Системы.
    При разработке проектных решений должны быть проработаны варианты по сбору данных, со всех технологических объектов.
    3) требования к взаимодействию создаваемой системы со смежными системами;
    Система расположена на среднем уровне управления производством, при этом она территориально распределена по всему производству и должна взаимодействовать:

    13

    со всеми системами автоматизации нижнего уровня (отдельными АСУТП всех производственных цехов и производственных участков, с системами контроля и коммерческого учета, системами отгрузки и т.д.);

    с существующими на предприятии системами и бизнес-приложениями (ERP, PIMS,
    LIMS и т.д.);

    с пользователями всех производственных служб, отделов и руководством завода;

    с инфраструктурными системами (служба каталогов Active Directory, система корпоративной почты, система антивирусной защиты, система резервного копирования, системой обновлений операционной системы и системного программного обеспечения).
    Интерфейсы взаимодействия с АСУТП должны обеспечить сбор данных в режиме реального времени от существующих и от вновь вводимых АСУТП по стандартным протоколам обмена данными (DDE, ОРС, OLEDB, ODBC и пр.). Интерфейсы взаимодействия с АСУТП и специальное программное обеспечение устанавливаются на компьютер (шлюзовая станция) на технологических объектах, в непосредственной близости от АСУТП или в их составе. В случае отказа/недоступности канала связи между шлюзовой станцией с установленным интерфейсом и сервером БД Системы, интерфейс должен продолжать собирать и буферизировать данные с АСУТП и выполнить их автоматическое восстановление в БД Системы при возобновлении сетевого соединения.
    Взаимодействие с системой антивирусной защиты, системой резервного копирования, должно осуществляться с использованием сетевых протоколов и портов, согласно рекомендациям разработчиков соответствующих инфраструктурных систем.
    Система должна обеспечивать подключение новых смежных систем источников данных, без значительного изменения состава и настроек программного и аппаратного обеспечения.
    4) требования к режимам функционирования системы;
    Система предназначена для постоянной, ежедневной работы сотрудников – пользователей системы. Пользователи работают в диалоговом режиме в реальном времени с базами данных и серверами приложений системы.
    Серверы Системы должны работать в непрерывном круглосуточном режиме, кроме периодов проведения регламентных работ по копированию данных системы, по обновлению и поддержке работоспособности системы и баз данных, а также регламентных процедур по техническому обслуживанию оборудования и сопровождению общесистемного программного обеспечения.
    Эксплуатационные характеристики системы приведены в таблице 2.
    Таблица 2
    Эксплуатация системы
    Средний срок службы Системы, с учетом модернизации программных и аппаратных средств - не менее 15 лет
    Требования к доступности системы (суммарное допустимое время простоя)
    Система должна обеспечивать непрерывную работу объекта автоматизации в режиме 24/7 (штатный режим).
    Суммарно допустимая продолжительность простоя подсистем
    – не более 4 часов в месяц.
    Максимальное время восстановления после сбоя
    Допустимое время восстановления после сбоя не должно превышать 2 часа.

    14
    Требования к потере данных
    Максимальное возможное время потери данных – 24 часа
    Нагрузка
    Количество пользователей Системы приведено в таблице 6.
    Максимальное количество пользователей одновременно работающих в Системе 20.
    Точное количество будет определено на этапе проектирования.
    Для обеспечения работоспособности Системы, каналообразующее оборудование должно гарантированно обеспечивать характеристики приведенные в таблице 3.
    Таблица 3
    Нагрузка
    Пропускная способность не менее 25 Мбит/с
    Эксплуатация
    Работоспособность каналообразующего оборудования должна обеспечивать режим 24 часа в сутки 7 дней в неделю.
    Максимальное время восстановления после сбоя
    Максимальное время восстановления работоспособности каналообразующего оборудования – 12 часов в случае аппаратного сбоя (при наличии резервного оборудования у
    Заказчика) и также 12 часов в случае программного сбоя.
    Высокая надежность процесса функционирования Системы и своевременность восстановления ее работоспособности должны достигаться:

    размещение СУБД и БДРВ на выделенных серверах;

    отказоустойчивостью сервера СУБД и БДРВ (допускается вариант резервирования сервера с использованием кластерной технологии);

    отказоустойчивостью технического обеспечения за счет резервирования;

    обязательным ведением журналов инцидентов (событий) в электронной форме, а также графиков и журналов проведения восстановительных и ремонтных работ;

    постоянным поддержанием необходимого уровня защищенности компонентов
    Система, непрерывным управлением и административной поддержкой корректного применения средств защиты;

    обеспечением бесперебойного электропитание всего оборудования Системы на период достаточный для корректного завершения работы пользователей с функциональными подсистемами.
    Мероприятия по обслуживанию средств вычислительной техники, приложений, сохранности информации в аварийных ситуациях должны быть определены в «Руководстве администратора информационной системы» и в рамках технической поддержки Системы.
    Гарантийный срок на Систему должен составлять не менее 3 лет.
    5) перспективы развития, модернизации системы.
    Для обеспечения эффективности
    Система должна обладать высокой приспособляемостью в части использования, иметь гибкую структуру, легко адаптируемую к изменениям, обеспечивать модификацию алгоритмов решения задач и наборов участвующих в них переменных, гарантировать ее развитие и модификацию во времени
    Для обеспечения реализации необходимых изменений Система должна соответствовать следующим требованиям:

    15

    иметь гибкую структуру, легко адаптируемую к изменениям, обеспечивать модификацию алгоритмов решения задач и наборов участвующих в них переменных;

    обеспечивать возможность увеличения количества одновременно работающих пользователей (при условии приобретения необходимого/дополнительного количества лицензий);

    обеспечивать необходимую производительность при поэтапном наращивании объема обрабатываемой информации без модификации программного обеспечения системы;

    обеспечивать возможность настройки и изменения конфигурации автоматизированных рабочих мест пользователей;

    Система не должна зависеть от изменений в организационной структуре подразделений Заказчика при сохранении состава и содержания выполняемых функций;

    Система должна допускать возможность передислокации пользователей в пределах
    ЛВС Заказчика;

    структура и состав программного обеспечения Системы не должны накладывать ограничения на возможность модернизации комплекса технических средств.
    Разработанные в рамках проекта модели цехов, процессов, активов и другие данные должны иметь возможность переноса на другой однотипный цех, процесс, актив.
    4.1.2.
    ТРЕБОВАНИЯ ПО СОХРАННОСТИ ИНФОРМАЦИИ ПРИ АВАРИЯХ
    Система должна использовать средства и решения, обеспечивающие сохранность информации и восстановление функционирования системы без потери информации в аварийных ситуациях.
    Система должна сохранить накопленную информацию при следующих аварийных ситуациях, отказах или выходе из строя одного или нескольких элементов оборудования:

    сбой электропитания;

    выход из строя элемента сетевой инфраструктуры системы;

    выход из строя одиночного сервера;

    выход из строя одиночного дискового массива сервера;

    выход из строя диска сервера;

    выход из строя процессора сервера;

    выход из строя оперативной памяти сервера;

    выход из строя сетевого адаптера сервера;

    выход из строя внутреннего источника питания сервера;

    нарушение логической целостности информации, хранящейся на диске сервера;

    сбои прикладного или системного программного обеспечения.
    Система должна обеспечивать восстановление данных следующими способами:

    установка режима зеркального копирования дисков сервера средствами операционной системы или другого программного обеспечения;

    16

    регулярное резервное копирование базы данных, в поставляемом программном обеспечении должны быть предусмотрены средства для резервного копирования всей централизованно сохраняемой и критической для функционирования системы информации;

    восстановление данных в БД с использованием последней резервной копии;
    После сбоя серверной операционной системы, БДРВ или СУБД, в процессе выполнения пользовательских задач, должно быть обеспечено восстановление данных до состояния на момент окончания последней нормально завершенной перед сбоем процедуры или транзакции.
    Для исключения потери данных, в самих источниках информации должна быть реализована независимая от АСОУП архивация параметров, предназначенных для передачи в Систему. Время архивации источника информации должно составлять не менее 3 суток.
    Частота сбора информации должна быть не хуже чем частоты сбора Системы.
    При проектировании и разработке технических регламентов по эксплуатации системы должны быть предусмотрены средства для резервного копирования информации. В состав эксплуатационной документации должен входить регламент, определяющий процедуры резервного копирования, восстановления данных и программного обеспечения.
    Выход из строя комплекса технических средств, вследствие аварий техногенного или природного характера, таких как, но не только – землетрясение, наводнение, пожар, повреждение системы водоснабжения здания, механические разрушения помещения и т.д. не нормируется и зависит от характера техногенной или природной катастрофы.
    4.1.3.
    ТРЕБОВАНИЯ К ЗАЩИТЕ ИНФОРМАЦИИ ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА
    Категория конфиденциальности информации, обрабатываемой в Системе – ограниченного доступа.
    Система должна удовлетворять всем требованиям регламентирующих документов
    Компании по информационной безопасности для возможности обработки информации максимальной категории конфиденциальности - ограниченного доступа.
    Система должна обеспечивать защиту от несанкционированного доступа на уровне не ниже установленного требованиями, предъявляемыми к классу защищенности 1Г АС по классификации действующего руководящего документа
    Гостехкомиссии
    России
    «Автоматизированные системы. Защита от несанкционированного доступа к информации.
    Классификация автоматизированных систем и требования по защите информации» 1992 г.
    Уровень защищённости от несанкционированного доступа средств вычислительной техники, обрабатывающих информацию, должен соответствовать требованиям к классу защищённости 5 согласно требованиям действующего руководящего документа
    Гостехкомиссии
    России
    «Средства вычислительной техники.
    Защита от несанкционированного доступа к информации.
    Показатели защищенности от несанкционированного доступа к информации».
    Система не требует проведения оценки соответствия требованиям по информационной безопасности.
    В Системе должна быть реализована ролевая модель разграничения доступа.
    Различным группам пользователей должны назначаться различные права доступа в Системе, в рамках их должностных обязанностей, в соответствии Регламентом предоставления доступа.

    17
    Если каналы связи выходят за пределы контролируемой зоны, необходимо использовать защищенные каналы связи, защищенные волоконно-оптические линии связи либо сертифицированные криптографические средства защиты.
    Во всех случаях при наличии технической возможности, аутентификацию и авторизацию пользователей Системы необходимо осуществлять с использованием службы корпоративного каталога на базе Microsoft Active Directory. Случаи невозможности интеграции со службой корпоративного каталога должны быть согласованы с СИТ и СБ.
    Также, при наличии технической возможности, для доступа к Системе рекомендуется использовать механизм единого входа – SSO (single sign-on), основанный на первоначальной доменной аутентификации.
    Требования по защите информации от несанкционированного доступа на стадии проектирования могут быть уточнены и изменены Службой Безопасности предприятия в соответствии с действующими или вновь введенными в действие требованиями и нормативными документами.
    1   2   3   4   5


    написать администратору сайта