ТТ_на_ССД_финал_публ.[1]. Версия 002018 г. Технические требования на систему автоматизированного сбора
 Скачать 1.29 Mb.
|
|
4.1.4. ТРЕБОВАНИЯ ПО СТАНДАРТИЗАЦИИ И УНИФИКАЦИИ Технические и программные решения должны быть максимально унифицированы и совместимы в рамках разрабатываемой Системы. Система должна быть построена на базе стандартных лицензионных программных и серийно выпускаемых технических средств. ПО Системы должно поставляться в виде, не требующем пользовательской доработки. Составные части комплекса технических средств должны быть стандартными и допускать возможность замены соответствующим оборудованием без дополнительного и перенастройки комплекса в целом. Система должна отвечать общим принципам стандартизации и унификации: открытость и модульность построения технических и программных средств; максимально возможное использование стандартного программного и аппаратного обеспечения; использование стандартных протоколов обмена информации; использование единой системы классификации и кодирования возможность масштабирования аппаратных и программных средств, в зависимости от количества, размера и назначения используемых подсистем; использование стандартных средств разработки приложений; единый стиль всех клиентских приложений. Интерфейсные формы должны проектироваться с учетом требований: Все формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации по стандартам, действующим на предприятии или в соответствии с разработанным унифицированным представлением информации. В разделах интерфейса для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении, должны быть унифицированы. 18 Внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов. Ввод/вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме, в реальном режиме времени. Унификации подлежат также структура данных и совокупность информационных объектов, используемых в Системе. Справочники, кодификаторы и классификаторы, создаваемые и планируемые к использованию в Системе, должны соответствовать международным, общероссийским, отраслевым и корпоративным справочникам, если аналогичные существуют. Справочники, кодификаторы и классификаторы должны быть совместимы со справочниками, кодификаторами и классификаторами, ведущимися во внешних (смежных) информационных Системах, с которыми осуществляется информационное взаимодействие Система. Система должна иметь возможность обновления и ручной корректировки справочников, кодификаторов и классификаторов При создании/реконструкции Системы необходимо руководствоваться нормативными документами, приведенными в Приложении 1. 4.1.5. ТРЕБОВАНИЯ К ЭРГОНОМИКЕ И ТЕХНИЧЕСКОЙ ЭСТЕТИКЕ Поставляемое программное обеспечение должно иметь русифицированный интерфейс, позволяющий свободно ориентироваться в информационном наполнении и функциональном применении программного обеспечения. Пользовательский интерфейс должен быть разработан с учетом современных требований по эргономике и технической эстетике. К числу таких требований относятся: Взаимодействие пользователей с Системой посредством визуального графического интерфейса; Удобный доступ к основным функциям и операциям, выполняемым Системой; Интуитивно понятный интерфейс, реализованный с учетом привычных для пользователя задач; Группировка пунктов меню в соответствии с функциями, задачами и технологией работы пользователей; Однозначность в понимании назначения пунктов меню; Цветовое решение интерфейса должно быть выдержано в спокойных тонах, не вызывающих утомление органов зрения; Сигнализация об ошибках или ошибочных действиях пользователей должна сопровождаться индикацией на экране и/или звуковым сигналом и/или подсказкой о необходимых дальнейших действиях; Задание критериев для выполнения поиска и выборки информации без программирования; Наличие оптимального набора используемых словарей и справочников; С технологической точки зрения, пользовательский интерфейс должен выполняться в виде набора взаимосвязанных форм и средств навигации. 19 4.2. ТРЕБОВАНИЯ К ФУНКЦИЯМ (ЗАДАЧАМ), ВЫПОЛНЯЕМЫМ СИСТЕМОЙ Система должна обеспечивать выполнение следующих функций (задач): Автоматизированный сбор данных; Ручной ввод данных; Первичная обработка собираемых данных; Создание единой информационной модели производства и структурирование собираемых данных; Архивирование и долгосрочное хранение собираемой информации; Управление базами данных реального времени; Управление базами данных (СУБД); Дополнительная обработка информации, включая выполнение всех необходимых расчетов и вычислений; Системное обслуживание и администрирование системы; Обеспечение обмена данными с другими программными пакетами, БД и АСУ на всех уровнях управления производством; Автоматизация ведения оперативной диспетчерской документации установленной формы; Графический интерфейс пользователей; Формирование запросов к БД и составление отчетов с сортировкой и статической обработкой данных, возможностью их просмотра, и передачи в MS Word, MS Excel и другие средства документирования; 4.2.1. ТРЕБОВАНИЯ К ФУНКЦИЯМ ПОДСИСТЕМЫ СБОРА ДАННЫХ Подсистема сбора данных должна обеспечивать в автоматическом режиме гарантированную доставку данных в подсистемы хранения и обработки от всех источников на предприятии. Основная функция Базы данных реального времени – прием и упорядоченное хранение данных, поступающих в режиме реального времени от подсистемы сбора данных и на программном уровне должна удовлетворять следующим требованиям : Прием данных и запись с различных источников в режиме реального времени по расписанию или по изменениям; Обеспечение скорость записи в архив не менее 50 000 операций в секунду; Удаленная конфигурация настроек программ сбора данных; Редактирование атрибутов точек хранения информации (тегов) в процессе работы программ сбора данных; Индикация некачественных данных или обрыва связи; Буферизацию данных с последующим автоматическим восстановлением при обрыве физической связи; 20 Программное резервирование; Унификация данных при передаче в подсистему хранения информации; Возможность сжатия данных (аппроксимация) перед их записью в БД с заданной индивидуально для каждого тега точностью, но не ниже класса точности прибора; Протоколирование событий (нарушений передачи данных, выхода данных за допустимые пределы измерений, регистрация времени и автора последнего изменения конфигурации). Система должна иметь возможность синхронизировать собираемую базу данных (БДРВ) с базой данных любой АСУТП, если можно получить экспорт базы данных АСУТП. Система должна позволять собирать и хранить любые типы данных (Таблица 4) - включая целые числа и числа с плавающей запятой, логические значение, строки фиксированной и неограниченной длины, и крупные бинарные объекты (такие как документы, изображения и т.п.). Таблица 4 ТИП ОПИСАНИЕ Аналоговый Аналоговая величина является переменной со значением измеряемого физического параметра (температура, расход, давление, уровень, перемещение и т.д.) Логический Логическое значение является переменной, которая может иметь два состояния: «1» (On) или «0» (Off'). Строковый Строковая величина является текстовым выражением, рассматриваемым как отдельный элемент данных. Строка не требует какого-либо специального формата или синтаксиса. Событийный (Event) Тэг события является именем определения события в системе. Составной (Complex) Составной тэг содержит данные, которые не могут быть отнесены ни к одному из четырёх основных типов 4.2.1.1. ТРЕБОВАНИЯ ПО ЧАСТОТЕ СБОРА ИНФОРМАЦИИ. Частота сбора информации от различных источников определяется функциями, реализуемыми АСОУП. При этом частоты сбора информации должна определяться исходя из требовательной к частоте опроса функции. Для уменьшения информационной нагрузки на источники информации Система должна минимизировать количество и частоту обращений к ним. Исходя из выполняемых функций АСОУП и характера технологических процессов, устанавливаются приведенные ниже частоты сбора информации: Таблица 5. ПАРАМЕТР И ТИП ИЗМЕРЕНИЯ СИГНАЛА ТИП ИЗМ. КОЛ-ВО (В МИНУТУ) Расходы жидкостей всех типов AI 12 Расходы газов всех типов AI 12 Расходы твердых веществ, всех типов AI 12 21 ПАРАМЕТР И ТИП ИЗМЕРЕНИЯ СИГНАЛА ТИП ИЗМ. КОЛ-ВО (В МИНУТУ) Давление жидкостей всех типов AI 12 Давление газов всех типов AI 12 Уровни жидкостей всех типов AI 6 Температуры жидкостей всех типов AI 3 Температуры газов всех типов AI 3 Температуры твердых веществ всех типов AI 3 Обороты динамического оборудования всех типов AI/РI 12 Линейные перемещения всех типов AI 6 DI/DO всех типов по всем параметрам DI/DO 6 Аналоговые выходы для управления AO 12 Динамическое технологическое оборудование All 6 Статическое оборудование всех типов All 6 Динамическое энергетическое оборудование All 6 Статическое энергетическое оборудование All 6 Статическое оборудование КИПиА All 6 Динамическое оборудование КИПиА All 6 4.2.1.2. СБОР ДАННЫХ С НЕАВТОМАТИЗИРОВАННЫХ УСТАНОВОК Сбор данных с неавтоматизированных установок должен удовлетворять следующим требованиям: обеспечивать регистрацию значений технологических параметров; обеспечивать ввод данных о состоянии оборудования и причинах его простоя; обеспечивать ввод комментариев к технологическим данным; обеспечивать полный русскоязычный интерфейс; обеспечивать ограничение ввода по времени; обеспечивать отслеживание границ ввода данных; обеспечивать буферизация при обрыве связи на узле сбора данных; В случае отказа или ошибок автоматического сбора, должна иметься возможность внести данные с сохранением истории изменений, и вводом комментария о возможных причин не достоверности данных. 4.2.2. ТРЕБОВАНИЯ ИНФОРМАЦИОННОЙ МОДЕЛИ ПРОИЗВОДСТВА В системе должна быть создана единая информационная модель предприятия (справочная модель предприятия), в виде иерархической структуры, имеющей как вертикальные, так и горизонтальные связи, где описываются все объекты управления, процессы и средства управления, детальная классификация до уровня: производственные 22 операции, технологическое оборудование, потоки, сырьё, выпускаемые продукты и полупродукты, датчики и т.д. Объекты базы данных модели предприятия должны обеспечивать замещение имен – возможность ассоциировать себя с группой тегов базы данных реального времени, то есть, заменить сложные имена инструментальных тегов именами, интуитивно понятными пользователю, основываясь, например, на наименованиях конкретного оборудования и физических величин, характеризующих его работу. Эта возможность должна обеспечить перекодировку обозначений параметров в различных базах данных внешних АС и привести их к единому стандарту. Информация модели предприятия, должна конфигурироваться один раз и затем использоваться всеми подсистемами АСОУП и другими приложениями. Должны иметься простые инструментальные средства для создания единой программной модели предприятия и поддержки её в актуальном состоянии, действительному состоянию производства в любой момент времени. Система должна позволять в режиме реального времени вносить новые и изменять существующие элементы и связи элементов в программной модели предприятия. 4.2.3. ТРЕБОВАНИЯ К АРХИВИРОВАНИЮ И ДОЛГОСРОЧНОМУ ХРАНЕНИЮ ДАННЫХ Основная нагрузка по обработке и хранению информации выполняется сервером (серверами) хранения данных. Сервер хранения данных должен обеспечивать сохранение и накопление (архивирование) собираемых и расчетных данных в виде массивов информации. База данных реального времени на программном уровне должна обеспечить: Архивное хранение информации на протяжении всего времени работы Системы; Возможность доступа к архивным данным в режиме прямого доступа за период не менее 5 лет; Для создаваемых архивов назначать размер файлов архива и определять директорию для их хранения; При хранении лабораторных показателей качества, данных ручного ввода обеспечивать 100% хранение информации; Производить операции добавления, удаления, переименования и изменения конфигурации точек хранения информации (тегов) в режиме реального времени, без потери данных; Быстрый поиск и обеспечение доступа к собираемым данным пользователям и клиентским приложениям для дальнейшего использования во всех подсистемах АСОУП и других пользовательских приложениях и системах предприятия, ERP и др.; Скорость чтения из архива не менее 50 000 операций в секунду; Возможность резервного копирования и быстрого восстановления информации; Администрирование БД; Должны быть доступны следующие типы сохранения: В архив не записываются никакие значения; В архив записываются все значения («принудительное» сохранение); 23 В архив записываются значения только при их изменении (сохранение по изменению); В архив записываются данные, разделённые по времени указанным интервалом (циклическое сохранение). Реляционная база данных (СУБД) должна хранить конфигурационную информацию, требуемую приложениями истории, а также интегрированную справочную информацию об операциях на предприятии, используемую для работы приложениями. Объекты базы данных должны обеспечивать хранение свойств в виде: статической информации об объектах, (например, спецификации оборудования, производительность и т.д.); ссылок или запросов к внешним источникам информации – файлам на сетевых дисках, URL, внешним БД. В подсистеме хранения необходимо вести протоколирование нарушений передачи данных, выхода данных за допустимые пределы измерений, времени последнего изменения в конфигурации параметра. 4.2.4. ТРЕБОВАНИЯ К ПОДСИСТЕМЕ ИНЖЕНЕРНЫХ РАСЧЕТОВ Подсистема выполнения инженерных расчетов должна обеспечить выполнение сложных производственных расчетов и вычисления для преобразования исходных данных в полезную информацию (расчет массы, объема и плотности, ключевых показателей эффективности, энергетических показателей и др.). Подсистема должна иметь возможность создания и многоразового использования шаблонов вычислений для однотипных объектов. Разработка соответствующих модулей должна иметь возможность поэтапного создания и дальнейшего изменения. Основные задачи, решаемые подсистемой инженерных расчетов: Выполнять первичную обработку данных перед их записью в БДРВ; Выполнение аналитических и вычислительных задач, как в режиме реального времени, так с определенным периодом, по событию или расписанию; Расчет неизменяемых напрямую величин и вычислений по различным формулам с поправочными коэффициентами; Проведение повторных вычислений, при изменении исходных данных; начиная с заданного момента начала или конца операции; Сохранение результатов вычислений в подсистеме хранения информации; Отслеживание и генерация событий (нарушение технологических регламентов, отклонение качества и т.д.) на основании данных, поступающих в систему; Отслеживание загрузки сервера инженерных расчетов. 4.2.5. ТРЕБОВАНИЯ К ПРЕДСТАВЛЕНИЮ ДАННЫХ Информацию, собираемую и хранимую в Системе необходимо предоставлять специалистам АО «НГПЗ» и Центрального аппарата Компании, имеющих доступ в локальную информационную сеть АО «НГПЗ» и Компании, для этого создается подсистема визуализации и представления информации/данных. Информация пользователям должна предоставляться в виде мнемосхем, любых отчетных форм документов по оперативным и архивным данным за любой период времени, включая сводные отчеты, справки, рапорта, тренды, диаграммы и пр. 24 В рамках Системы создаются только первичные отчетные и графические формы. Перечень формируемых мнемосхем и отчетных форм уточняется Заказчиком на этапе внедрения Системы. Ориентировочное количество: мнемосхемы – 50 шт.; отчеты – 30 шт. В таблице 6 приведен список подразделений АО «НГПЗ», которым будут предоставляться данные из Системы: Таблица 6. ПОДРАЗДЕЛЕНИЕ РАБОЧИЕ МЕСТА (АРМ) Производственно-технологический отдел 4 Оперативное управление производством 15 Управление метрологии, автоматизации, информационных технологий и телекоммуникаций 7 Cпециалисты АО «НГПЗ» 14 Резерв: 10 ИТОГО: 50 Точный перечень подразделений и количество рабочих мест будет определен в процессе проектирования. Система должна обеспечивать беспрепятственное наращивание количества рабочих мест просмотра. Развитие подсистемы визуализации и представления данных для автоматизации бизнес- процессов производства будет проводиться при внедрении системы Диспетчеризации на следующих этапах создания АСОУП. 4.2.6. ТРЕБОВАНИЯ К АДМИНИСТРИРОВАНИЮ СИСТЕМЫ Данная подсистема предназначена для выполнения задач администрирования, конфигурирования и мониторинга работы компонентов Системы группой сопровождения для обеспечения работы как Системы в целом, так и отдельных ее компонентов. Подсистема должна предоставлять необходимый набор функций для проведения диагностики, настройки и конфигурирования базовых подсистем. Инструментарий администрирования подсистемы должен обеспечивать реализацию следующих функций: конфигурирование и гибкую настройку интерфейсов, серверных подсистем и клиентских приложений; диагностика и контроль работоспособности программных и аппаратных средств, состояния каналов связи сети информационного пространства; оповещение о системных событиях и их регистрация; коррекцию системных часов; 25 отображение в реальном времени контролируемых параметров в АРМ администратора; возможность динамического изменения списка контролируемых параметров; отслеживание загрузки аппаратно-программных средств, при проведении вычислений; возможность автоматического и по требованию резервирования программного обеспечения Системы; средства аудита базовых подсистем; средства для определения плохих переменных; сигнализация пользователям о возникновении любых нарушений в работе системы, которые приводят к тем или иным нарушениям в выдаче пользователям текущей информации; настройка и проверка доступа пользователей к системе; просмотр системных журналов, log-файлов и т.д. |