Разработка телекоммуникационной системы АСУТП сбора и анализа метеоданных

Размещено на http://www.allbest.ru/

[Введите текст]

Введение

Автоматизированная система управления технологическим процессом (АСУ ТП) на сегодняшний день является необходимым критерием каждого крупного предприятия. Наличие подобных систем на производстве позволяет с высокой точностью задавать различные параметры и поддерживать их в заданных интервалах. В последние годы крупные производители все большее внимание уделяют именно автоматизации. И это не удивительно. Высокая конкуренция заставляет руководителей более серьезно относиться к внедрению высоких технологий на своем предприятии. Автоматизация технологических процессов - это, прежде всего, экономия денежных средств за счет оптимизации расхода сырья и энергоресурсов. Высокая производительность, минимизация брака, увеличение КПД производства, улучшение качества продукции, вот ряд преимуществ АСУ ТП.



1. Назначение и цели создания системы

1.1 Назначение системы

ТКС АСУ ТП СИАМ предназначена для повышения оперативности и качества принимаемых решений сотрудниками Заказчика. Основным назначением ТКС АСУ ТП СИАМ является автоматизация информационно-аналитической деятельности в сборе и анализе метеоданных Заказчиком.

1.2 Цели создания системы

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



2. Характеристика объектов автоматизации

Структурное подразделение	Наименование процесса	Возможность авторизации	Решение об автоматизации в ходе проекта
Подсистема отопления	Управление подсистемой отопления	Возможна	Будет автоматизирован
Отдел автоматизированного обмена информацией	Управления различными процессами в рамках процесса обмена информацией	Возможна	Будет автоматизирован



3. Требования к системе

3.1 Требования к системе в целом

3.1.1 Требования к структуре и функционированию системы

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

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

- подсистема хранения данных, которая предназначена для хранения данных в структурах, нацеленных на принятие решений; - подсистема формирования и визуализации отчетности, которая предназначена для формирования данных и отчетности.

Требования к способам и средствам информационного обмена между компонентами системы.

В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня, такие как: NFS, HTTP и его расширение HTTPS, NetBios/SMB, Oracle TNS. Для организации доступа пользователей к отчетности должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.

Определяются требования к режимам функционирования системы

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

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

Требования по диагностированию

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

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

3.1.2 Показатели назначения

Параметры, характеризующие степень соответствия системы назначению

Система должна обеспечивать следующие количественные показатели, которые характеризуют степень соответствия ее назначению: - Количество измерений - X. - Количество показателей - Y. - Количество аналитических отчетов - Z.

Требования к приспособляемости системы к изменениям

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

Требования сохранению работоспособности системы в различных вероятных условиях

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

Вероятное условие	Требование
Нарушения в работе системы внешнего электроснабжения серверного оборудования продолжительностью до 15 мин.	Функционирование в полном объеме.
Выход из строя сервера подсистемы хранения данных	Уведомление администратора подсистемы хранения данных и администратора подсистемы сбора, обработки и загрузки данных

3.1.3 Требования к надежности

Состав показателей надежности для системы в целом

Уровень надежности должен достигаться согласованным применением организационных, организационно-технических мероприятий и программно-аппаратных средств. Надежность должна обеспечиваться за счет: - применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач; - своевременного выполнения процессов администрирования ТКС АСУ ТП СИАМ ; - соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств; - предварительного обучения пользователей и обслуживающего персонала. Время устранения отказа должно быть следующим: - при перерыве и выходе за установленные пределы параметров электропитания - не более X минут.

- при перерыве и выходе за установленные пределы параметров программного обеспечением - не более Y часов. - при выходе из строя ТКС АСУ ТП СИАМ - не более Z часов. Система должна соответствовать следующим параметрам: - среднее время восстановления Q часов - определяется как сумма всех времен восстановления за заданный календарный период, поделенные на продолжительность этого периода; - коэффициент готовности W - определяется как результат отношения средней наработки на отказ к сумме средней наработки на отказ и среднего времени восстановления; - время наработки на отказ E часов - определяется как результат отношения суммарной наработки Системы к среднему числу отказов за время наработки. Средняя наработка на отказ АПК не должна быть меньше G часов.

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

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

Требования к надежности технических средств и программного обеспечения

К надежности оборудования предъявляются следующие требования: - в качестве аппаратных платформ должны использоваться средства с повышенной надежностью; - применение технических средств соответствующих классу решаемых задач; - аппаратно-программный комплекс Системы должен иметь возможность восстановления в случаях сбоев. К надежности электроснабжения предъявляются следующие требования: - с целью повышения отказоустойчивости системы в целом необходима обязательная комплектация серверов источником бесперебойного питания с возможностью автономной работы системы не менее X минут; - система должны быть укомплектована подсистемой оповещения Администраторов о переходе на автономный режим работы; - система должны быть укомплектована агентами автоматической остановки операционной системы в случае, если перебой электропитания превышает Y минут; - должно быть обеспечено бесперебойное питание активного сетевого оборудования. Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий: - предварительного обучения пользователей и обслуживающего персонала; - своевременного выполнения процессов администрирования; - соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;

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

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

Проверка выполнения требований по надежности должна производиться на этапе проектирования расчетным путем, а на этапах испытаний и эксплуатации - по методике Разработчика, согласованной с Заказчиком.



3.1.4 Требования к эргономике и технической эстетике

Подсистема формирования и визуализации отчетности данных должна обеспечивать удобный для конечного пользователя интерфейс, отвечающий следующим требованиям. В части внешнего оформления: - интерфейсы подсистем должен быть типизированы; - должно быть обеспечено наличие локализованного (русскоязычного) интерфейса пользователя; - должен использоваться шрифт: Times New Roman. - размер шрифта должен быть: 14. - цветовая палитра должна быть: чернобелая. - в шапке отчетов должен использоваться логотип Заказчика.

В части диалога с пользователем: - для наиболее частых операций должны быть предусмотрены «горячие» клавиши; - при возникновении ошибок в работе подсистемы на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке. В части процедур ввода-вывода данных: - должна быть возможность многомерного анализа данных в табличном и графическом видах. К другим подсистемам предъявляются следующие требования к эргономике и технической эстетике.

В части внешнего оформления: - интерфейсы по подсистемам должен быть типизированы. В части диалога с пользователем:

- для наиболее частых операций должны быть предусмотрены «горячие» клавиши; - при возникновении ошибок в работе подсистемы на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке. В части процедур ввода-вывода данных: - должна быть возможность получения отчетности по мониторингу работы подсистем.

3.1.5 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Условия эксплуатации, а также виды и периодичность обслуживания технических средств системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них. Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80 % при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба). Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76«Система "Человек-машина". Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования». Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запитывается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом.

Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП). Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

3.1.6 Требования к защите информации от несанкционированного доступа

Требования к информационной безопасности

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

Требования к антивирусной защите

Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей и администраторов ТКС АСУ ТП СИАМ. Средства антивирусной защиты рабочих местах пользователей и администраторов должны обеспечивать: - централизованное управление сканированием, удалением вирусов и протоколированием вирусной активности на рабочих местах пользователей; - централизованную автоматическую инсталляцию клиентского ПО на рабочих местах пользователей и администраторов; - централизованное автоматическое обновление вирусных сигнатур на рабочих местах пользователей и администраторов; - ведение журналов вирусной активности; - администрирование всех антивирусных продуктов.

Разграничения ответственности ролей при доступе к отчет, показатель, измерение

Требования по разграничению доступа приводятся в виде матрицы разграничения прав.

Матрица должна раскрывать следующую информацию: - код ответственности: Ф - формирует, О - отвечает, И - использует и т.п.; - наименование объекта системы, на который накладываются ограничения; - роль сотрудника/единица организационной структуры, для которых накладываются ограничения.



3.1.7 Требования по сохранности информации при авариях

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

3.1.8 Требования к защите от влияния внешних воздействий

Применительно к программно-аппаратному окружению системы предъявляются следующие требования к защите от влияния внешних воздействий. Требования к радиоэлектронной защите: - электромагнитное излучение радиодиапазона, возникающее при работе электробытовых приборов, электрических машин и установок, приёмопередающих устройств, эксплуатируемых на месте размещения АПК системы, не должны приводить к нарушениям работоспособности подсистем. Требования по стойкости, устойчивости и прочности к внешним воздействиям: - Система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % - 30 %);

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

3.1.9 Требования по стандартизации и унификации

Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования». Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.х.

Для разработки пользовательских интерфейсов и средств генерации отчетов должны использоваться встроенные возможности ПО а также, в случае необходимости, языки программирования <SCADA >.

В системе должны использоваться (при необходимости) общеукраинские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.

Дополнительные требования

ТКС АСУ ТП СИАМ должно разрабатываться и эксплуатироваться на уже имеющемся у Заказчика аппаратно-техническом комплексе. Необходимо создать отдельные самостоятельные зоны разработки и тестирования ТКС АСУ ТП СИАМ. Для зоны разработки и тестирования должны использоваться те же программные средства, что и для зоны промышленной эксплуатации.

Требования безопасности

При внедрении, эксплуатации и обслуживании технических средств системы должны выполняться меры электробезопасности в соответствии с «Правилами устройства электроустановок» и «Правилами техники безопасности при эксплуатации электроустановок потребителей». Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования». Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании системы в процессе эксплуатации.

Аппаратная часть системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации». Значения эквивалентного уровня акустического шума, создаваемого аппаратурой системы, должно соответствовать ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение», но не превышать следующих величин: - 50 дБ - при работе технологического оборудования и средств вычислительной техники без печатающего устройства; - 60 дБ - при работе технологического оборудования и средств вычислительной техники с печатающим устройством.

Требования к транспортабельности для подвижных АИС

КСА системы являются стационарными и после монтажа и проведения пуско-наладочных работ транспортировке не подлежат.

3.2 Требования к функциям, выполняемым системой

3.2.1 Подсистема сбора, обработки и загрузки данных

Перечень функций, задач подлежащей автоматизации

Функция	Задача
Управляет процессами сбора, обработки и загрузки данных	Создание, редактирование и удаление процессов сбора, обработки и загрузки данных
	Формирование последовательности выполнения процессов сбора, обработки и загрузки данных (регламентов загрузки данных)
	Определение и изменение расписания процессов сбора, обработки и загрузки данных
Выполнение процессов сбора, обработки и загрузки данных из источников на сервер	Запуск процедур сбора данных из систем источников, загрузка данных в область временного, постоянного хранения
	Обработка и преобразование извлечённых данных
	Поддержка медленно меняющихся измерений
Протоколирует результаты сбора, обработки и загрузки данных	Ведение журналов результатов сбора, обработки и загрузки данных
	Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы

Временной регламент реализации каждой функции, задачи

Задача	Требования к временному регламенту
Создание, редактирование и удаление процессов сбора, обработки и загрузки данных	Весь период функционирования системы, при возникновении необходимости изменения процессов сбора, обработки и загрузки данных
Формирование последовательности выполнения процессов сбора, обработки и загрузки данных (регламентов загрузки данных)	Весь период функционирования системы, при возникновении необходимости модификации регламента загрузки данных
Определение и изменение расписания процессов сбора, обработки и загрузки данных	Весь период функционирования системы, при возникновении необходимости изменения расписания процессов
Запуск процедур сбора данных из систем источников, загрузка данных в область временного, постоянного хранения	После готовности данных в системах источниках, ежедневно во временном интервале 00:00 - 03:00
Обработка и преобразование извлечённых данных	Ежедневно, после появления всех извлечённых данных во временном интервале 00:00 - 06:00
Поддержка медленно меняющихся измерений	Регулярно, при работе подсистемы для измерений соответствующего типа
Ведение журналов результатов сбора, обработки и загрузки данных	Регулярно, при работе подсистемы
Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы	Регулярно, при возникновении нештатной ситуации в процессе работы подсистемы

3.3 Требования к видам обеспечения

Требования к математическому обеспечению

Не предъявляются.

Требования к информационному обеспечению

Требования к составу, структуре и способам организации данных в системе

Требования к информационному обмену между компонентами системы Информационный обмен между компонентами Системы должен быть реализован следующим образом:

	Подсистема сбора, обработки и загрузки данных	Подсистема хранения данных	Подсистема формирования и визуализации отчетности
Подсистема сбора, обработки и загрузки данных		X
Подсистема хранения данных	X		X
Подсистема формирования и визуализации отчетности		X

Требования к информационной совместимости со смежными системами

Состав данных для осуществления информационного обмена по каждой смежной системе должен быть определен Разработчиком на стадии «Проектирование. Разработка эскизного проекта. Разработка технического проекта» совместно с полномочными представителями Заказчика. Система не должна быть закрытой для смежных систем и должна поддерживать возможность экспорта данных в смежные системы. Система должна обеспечить возможность загрузки данных, получаемых от смежной системы.

Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных

Процесс сбора, обработки и передачи данных в системе определяется регламентом процессов сбора, преобразования и загрузки данных, разрабатываемом на этапе «Проектирование. Разработка эскизного проекта. Разработка технического проекта».

Требования к защите данных от разрушений при авариях и сбоях в электропитании системы

Информация в базе данных системы должна сохраняться при возникновении аварийных ситуаций, связанных со сбоями электропитания. Система должна иметь бесперебойное электропитание, обеспечивающее её нормальное функционирование в течение 15 минут в случае отсутствия внешнего энергоснабжения, и 5 минут дополнительно для корректного завершения всех процессов. Резервное копирование данных должно осуществляться на регулярной основе, в объёмах, достаточных для восстановления информации в подсистеме хранения данных.

Требования к контролю, хранению, обновлению и восстановлению данных

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

К обновлению и восстановлению данных предъявляются следующие требования: - для сервера сбора, обработки и загрузки данных необходимо обеспечить резервное копирование его бинарных файлов (Home) раз в 2 недели и хранение копии на протяжении 2-х месяцев; - для сервера базы данных необходимо обеспечить резервное копирование его бинарных файлов раз в 2 недели и хранение копии на протяжении 2-х месяцев;

Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами системы Требования не предъявляются.

Требования к программному обеспечению

К обеспечению качества ПС предъявляются следующие требования: - функциональность должна обеспечиваться выполнением подсистемами всех их функций; - надежность должна обеспечиваться за счет предупреждения ошибок - не допущения ошибок в готовых ПС; - легкость применения должна обеспечиваться за счет применения покупных программных средств; - эффективность должна обеспечиваться за счет принятия подходящих, верных решений на разных этапах разработки ПС и системы в целом; - сопровождаемость должна обеспечиваться за счет высокого качества документации по сопровождению, а также за счет использования в программном тексте описания объектов и комментариев; использованием осмысленных (мнемонических) и устойчиво различимых имен объектов; размещением не больше одного оператора в строке текста программы; избеганием создания фрагментов текстов программ с неочевидным или скрытым смыслом; - также на каждом этапе в разработке ПС должна проводится проверка правильности принятых решений по разработке и применению готовых ПС.

Требования к техническому обеспечению

Система должна быть реализована с использованием специально выделенных серверов Заказчика. Сервер базы данных должен быть развернут на HP9000 SuperDome №1, минимальная конфигурация которого должна быть: CPU: 16 (32 core); RAM: 128 Gb; HDD: 500 Gb; Network Card: 2 (2 Gbit); Fiber Channel: 4. Сервер сбора, обработки и загрузки данных должен быть развернут на HP9000 SuperDome №2, минимальная конфигурация которого должна быть: CPU: 8 (16 core); RAM: 32 Gb; HDD: 100 Gb; Network Card: 2 (1 Gbit); Fiber Channel: 2. Сервер приложений должен быть развернут на платформе HP Integrity, минимальная конфигурация которого должна быть: CPU: 6 (12 core); RAM: 64 Gb; HDD: 300 Gb; Network Card: 3 (1 Gbit). Приведенные сервера должны быть подключены к дисковому массиву HP XP с организацией сети хранения данных. Минимальный объем свободного пространства для хранения данных на дисковом массиве должен составлять 100 Тб.

Требования к метрологическому обеспечению

Не предъявляются.

Требования к организационному обеспечению

Основными пользователями Системы являются сотрудники подразделения Заказчика. Обеспечивает эксплуатацию Системы подразделение информационных технологий Заказчика. Состав сотрудников каждого из подразделений определяется штатным расписанием Заказчика, которое, в случае необходимости, может изменяться. К организации функционирования Системы и порядку взаимодействия персонала, обеспечивающего эксплуатацию, и пользователей предъявляются следующие требования:

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

- подразделение, обеспечивающее эксплуатацию системы, должно заранее информировать всех пользователей о переходе её в профилактический режим.

К защите от ошибочных действий персонала предъявляются следующие требования: - должна быть предусмотрена система подтверждения легитимности пользователя при просмотре данных; - для всех пользователей должна быть запрещена возможность удаления преднастроенных объектов и отчетности; - для снижения ошибочных действий пользователей должно быть разработано полное и доступное руководство пользователя.



4. Состав и содержание работ по созданию системы

Работы по созданию системы выполняются в три этапа: Проектирование. Разработка эскизного проекта. Разработка технического проекта (продолжительность - X месяца). Разработка рабочей документации. Адаптация программ (продолжительность - Y месяцев). Ввод в действие (продолжительность - Z месяца). Конкретные сроки выполнения стадий и этапов разработки и создания Системы определяются Планом выполнения работ, являющимся неотъемлемой частью Договора на выполнение работ по настоящему Частному техническому заданию. Перечень организаций - исполнителей работ, определение ответственных за проведение этих работ организаций определяются Договором.



5. Порядок контроля и приёмки системы

5.1 Виды и объем испытаний системы

Система подвергается испытаниям следующих видов:

1. Предварительные испытания.

2. Опытная эксплуатация.

3. Приемочные испытания.

Состав, объем, методы предварительных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Рабочая документация». Состав, объем, методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым на стадии «Ввод в действие».

Состав, объем, и методы приемочных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Ввод в действие» с учетом результатов проведения предварительных испытаний и опытной эксплуатации.

5.2 Требования к приемке работ по стадиям

Требования к приемке работ по стадиям приведены в таблице

Стадия испытаний	Участники испытаний	Место и срок проведения	Порядок согласования документации	Статус приемочной комиссии
Предварительные испытания	Организации Заказчика и Разработчик	На территории Заказчика, с dd.mm.yyyy по dd.mm.yyyy	Проведение предварительных испытаний.	Экспертная группа
Опытная эксплуатация	эксплуатация Организации Заказчика и Разработчик	На территории Заказчика, с dd.mm.yyyy по dd.mm.yyy	Проведение опытной эксплуатации.	Группа тестирования
Приемочные испытания	Организации Заказчика и Разработчика	На территории Заказчика, с dd.mm.yyyy по dd.mm.yyyy	Проведение приемочных испытаний.	Приемочная комиссия



6. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

6.1. Технические мероприятия

Силами Заказчика в срок до начала этапа «Разработка рабочей документации. Адаптация программ» должны быть выполнены следующие работы: - осуществлена подготовка помещения для размещения АТК системы в соответствии с требованиями, приведенными в настоящем техническом задании; - осуществлена закупка и установка необходимого АТК; - организовано необходимое сетевое взаимодействие.

6.2 Организационные мероприятия

Силами Заказчика в срок до начала этапа работ «Разработка рабочей документации. Адаптация программ» должны быть решены организационные вопросы по взаимодействию с системами-источниками данных. К данным организационным вопросам относятся: - организация доступа к базам данных источников; - определение регламента информирования об изменениях структур систем-источников; - выделение ответственных специалистов со стороны Заказчика для взаимодействия с проектной командой по вопросам взаимодействия системы.

6.3 Изменения в информационном обеспечении

Для организации информационного обеспечения системы должен быть разработан и утвержден регламент подготовки и публикации данных из систем-источников. Перечень регламентов может быть изменен на стадии «Разработка рабочей документации. Адаптация программ».



7. Требования к документированию

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



8. Источники разработки

Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов: - Договор № 15789 от 21.0212 между ЗАО ИТ фирмой «Аспект» и «Украинским гидрометеорологическим центром». - ГОСТ 24.701-86 «Надежность автоматизированных систем управления». - ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды». - ГОСТ 21958-76 «Система "Человек-машина". Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования». - ГОСТ 12.1.004-91 «ССБТ. Пожарная безопасность. Общие требования». - ГОСТ Р 50571.22-2000 «Электроустановки зданий». - и т.д.



9. Технический проект

Полное наименование системы

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

Краткое наименование системы - ТКС АСУТП СИАМ, Система.

Основания для проведения работ.

Работа выполняется на основании договора № 15789 от 21.02.12 между ЗАО ИТ фирмой «Аспект» и «Украинским гидрометеорологическим центром».

Наименование организаций - Заказчика и Разработчика.

Заказчик

Заказчик: «Украинский гидрометеорологический центр». Адрес фактический: г. Киев ул. Золотоворотская, 6-В. Телефон / Факс: 0(44) 239 93 87.

WEB-адрес: www.meteo.gov.ua

Разработчик

Разработчик: ЗАО ИТ фирма «Аспект». Адрес фактический: г. Сумы ул.Воскресенская 3. Телефон / Факс: 0 (5242) 335289.

Цели, назначение и область использования системы

ТКС АСУ ТП СИАМ предназначена для повышения оперативности и качества принимаемых решений сотрудниками Заказчика. Основным назначением ТКС АСУ ТП СИАМ является автоматизация информационно-аналитической деятельности в сборе и анализе метеоданных Заказчиком.

Цели создания системы

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

Очередность создания системы

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

Основные технические решения

Решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы.

Логическая и компонентная архитектура системы

№	Наименование
1	Oracle Enterprise Edition Database Server 10g rel.2 (10.2.0.4)
2	Oracle Label Security (10.2.0.4)
3	Oracle Application Server Enterprise Edition 10g rel.2 (10.1.2.2)
3.1	Oracle Discoverer Server 10g
3.2	Oracle Internet Directory 10g

Рис. 1

В состав разрабатываемой системы будут включены следующие технологические компоненты: - программное обеспечение поддержки модели данных представляет собой программное обеспечение, автоматизирующее разработку и поддержку модели - ERwin; - ETL-приложение - это комплексное решение Informatica Power Center, с помощью которого реализуются процессы извлечения, проверки, преобразования и загрузки данных из источников, - сервер представляет собой промышленную систему управления данными. На данном сервере хранятся НСИ, область временного и постоянного хранения данных, агрегаты данных. Реализована система разграничений прав доступа на уровне объектов и записей в таблицах. В качестве сервера будет использоваться Oracle DB EE 10g rel.2; - сервер приложений - продукт, обеспечивающий поддержку промышленной инфраструктуры приложений. Включает в себя следующий ряд приложений обеспечивающих: - стандартные подходы к организации служб каталогов, централизованные методы организации; - развертывание сервисов разработки дополнительных приложений; развертывание сервисов анализа и отчетности - средства администрирования и разработки - набор программных продуктов, предназначенных для администрирования системы ETL (Administrator, Manager), баз данных, сервера приложений (Enterprise Manager) и разработки отчетности (Developer Suite). - клиентские места сотрудников (внутри локальной вычислительной сети), представляющие собой автоматизированные рабочие места.

Функциональная структура системы

Рис. 2



Решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости.

Перечень смежных систем, способы взаимодействия.

Наименование смежной системы	Предпочтительный способ взаимодействия	Прикладной протокол взаимодействия	Регламент взаимодействия
Информационная система управления	Использование ПБД	Протокол MS SQL Server	Дается ссылка на детальный регламент взаимодействия (обычно отдельный документ или приложение к техническому проекту)
Информационно-справочная система	Файлы ОС определенного формата	FTP	Дается ссылка на детальный регламент взаимодействия (обычно отдельный документ или приложение к техническому проекту)

Ниже представлена детальная схема взаимодействия Системы и смежных систем.

Рис. 3

Решения по режимам функционирования, диагностированию работы системы

Предлагается следующая реализация решений по режимам функционирования системы: - Основной режим, в котором все подсистемы выполняют свои основные функции. - Профилактический режим, в котором одна или все подсистемы не выполняют своих функций. В данный режим работы система переходит в следующих случаях: возникновение необходимости модернизации аппаратно-программного комплекса; возникновение необходимости проведения технического обслуживания; выход из строя аппаратно-программного комплекса, вызванный выходом из строя элементов аппаратной или программной базы; выход из строя сети передачи данных и другие аварийные ситуации. В основном режиме функционирования система обеспечивает: - работу пользователей в режиме - 24 часа в день, 7 дней в неделю (24х7); - выполнение своих функций - сбор, обработка и загрузка данных; хранение данных, предоставление отчетности по показателям. В профилактическом режиме система обеспечивает возможность проведения следующих работ:

- техническое обслуживание; - модернизация аппаратно-программного комплекса; - устранение аварийных ситуаций. Принимается предварительное решение о том, что общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (XX часов в месяц). Принимается предварительное решение о том, что для обеспечения высокой надежности функционирования как системы в целом, так и ее отдельных компонентов необходимо проводить регулярное диагностирование состояния компонентов.

В таблице ниже представлены средства диагностики по подсистемам.

Подсистема	Средства диагностирования
Подсистема сбора, обработки и загрузки данных	ETL Administrator - диагностика и настройка ETL-приложения, управление критериями извлечения, установка NLS; ETL Manager - просмотр и редактирование репозитория.
Подсистема хранения данных	DB Manager - диагностика и настройка и конфигурация
Подсистема отображения отчетности	BI Administrator - диагностика и настройка описания и представления витрин данных

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

Сведения об обеспечении заданных в техническом задании потребительских характеристик системы, определяющих ее качество

Требование	Метод реализации
Взаимодействие со смежными системами	Реализуется за счет наличия интерфейсов с системами - источниками данных. Планируется использование промежуточных баз данных; интеграция «точка - точка» (point-to-point); интерактивная загрузка информации из файлов определенного формата.
Диагностирование системы	Реализуется путем определения перечня работ по диагностированию подсистем.
Сохранение работоспособности системы в различных вероятных условиях	Реализуется путем разработки процедур резервного копирования, подготовки персонала, использования современных методов разработки и проверенных на практике стандартных программных средств. На объекте автоматизации обязательно ведение журналов инцидентов в электронной форме, а также графиков и журналов проведения ППР, в соответствии с утвержденными для каждого объекта ХД мероприятиями по поддержанию его работоспособности.
Подсистема	Функция	Метод реализации
Подсистема сбора, обработки и загрузки данных	Управление процессами сбора, обработки и загрузки данных	Путем внедрения комплексного ETL-приложения
	Запуск процессов сбора, обработки и загрузки данных из источников в ХД	Путем разработки и внедрения регламентов запуска ETL-процессов
Подсистема хранения данных	Создание и сопровождение структур базы данных	Путем применения CASE средства и средств администрирования
	Осуществление резервного копирования данных	Путем применения следующих видов копирования: полное холодное копирование; логическое копирование; инкрементальное копирование

Состав функций, комплексов задач, реализуемых системой

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

Подзадача	Действие
...	...

В данной таблице для каждой задачи приводится перечень подзадач и сценарий их выполнения. Перечень подзадач формируется следующим образом: берется наименование задачи и из названия задачи выделяются подзадачи, например задача «Поддержка (разработка, модификация) модели ХД» содержит в себе две подзадачи «Разработка» и «Модификация», задача «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» содержит в себе следующие подзадачи: «Создание нового процесса», «Редактирование процесса», «Удаление процесса» и т.п.

Далее для каждой выделенной подзадачи приводится описание сценариев её выполнения. Сценарий формируется путем последовательных ответов на следующие вопросы: Вопрос: «Кто производит действия для выполнения подзадачи?» Ответ: «Администратор подсистемы...» Вопрос: «Что должен сделать Администратор? К какому ПС обратиться? Какой файл выбрать?» Ответ: «Администратор подсистемы обращается к программе... и открывает ранее разработанный... » Вопрос: «Какие действия после открытия в рамках подзадачи должен выполнить Администратор?» Ответ. «Администратор подсистемы обращается к программе... и открывает ранее разработанный... Администратор вносит изменения в..., содержащие...» Вопрос: «Какие действия выполняет сама подсистема в момент действия Администратора? Появляется ли диалоговое окно?» Ответ: «Администратор подсистемы обращается к программе... и открывает ранее разработанный.... Администратор вносит изменения в..., содержащие.... Подсистема запрашивает необходимость сохранения работы в виде рабочего файла...» Вопрос: «Какие действия выполняет Администратор после появления диалогового окна?» Ответ: «Администратор подсистемы обращается к программе... и открывает ранее разработанный.... Администратор вносит изменения в..., содержащие.... Подсистема запрашивает необходимость сохранения работы в виде рабочего файла... Администратор подтверждает команду сохранения».

Подсистема сбора, обработки и загрузки данных 2.6.1.1 Функция «Управление процессами сбора, обработки и загрузки данных» Описание возможного сценария для последующей реализации задачи «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» приведено в таблице.



Подзадача	Действие
Создание нового процесса	- Администратор обращается к модулю разработки подсистемы на сервере разработки. - Подсистема предоставляет инструментальные средства для создания нового процесса. - Администратор подсистемы создает схему нового процесса ETL. На схеме указываются компоненты процесса: источники данных, компоненты преобразования данных, таблицы. - Администратор подсистемы инициирует команду сохранения созданного процесса. - Подсистема размещает созданный процесс на сервере среды разработки. - Администратор подсистемы выполняет запуск, тестирование и отладку создаваемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы среды разработки, Администратор принимает решение о готовности нового процесса. - Готовый процесс переносится на продуктивный сервер.
Редактирование процесса	- Администратор подсистемы вызывает подсистему среды разработки на сервере разработки. - Используя инструментальные программные средства подсистемы, Администратор изменяет схему процесса ETL, размещает измененный процесс на сервере среды разработки. - Подсистема размещает редактируемый процесс на сервере среды разработки. - Администратор подсистемы выполняет запуск, тестирование и отладку редактируемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы БД среды разработки, Администратор принимает решение о готовности редактируемого процесса. - Готовый процесс переносится на продуктивный сервер.
Удаление процесса	- Администратор подсистемы вызывает подсистему среды разработки на сервере разработки. - Используя инструментальные программные средства подсистемы, Администратор удаляет процесс ETL, размещает изменения на сервере среды разработки. - Подсистема размещает внесенные изменения на сервере среды разработки. - Изменения переносятся на продуктивный сервер.

AD Server - служба каталога Active Directory, содержащая учетные записи пользователей информационных ресурсов и являющаяся источником информации об учетных записях сотрудников Заказчика. Firewall - межсетевой экран. Application Server - сервер приложений. ETL server - сервер, на котором устанавливается ПО подсистемы извлечения, преобразования и загрузки данных. DB server - сервер, на котором устанавливается ПО подсистемы хранения данных.

...