Распределенная автоматизированная система управления (стр. 11 из 16)

7. Возможность ручной коррекции информации в архиве средствами SCADA. Естественно, в этом случае должна быть защита коррекции данных паролем и в архив должна заноситься отметка, что такая коррекция была произведена.

8. Временная глубина, объем, набор параметров должны задаваться (настраиваться пользователем).

TRACEMODEимеет широкие возможности по архивированию данных о технологических процессах. TRACEMODEподдерживает три архива [11]:

1. СПАД (локальный архив);

2. Отчет тревог;

3. Глобальный регистратор.

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

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

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

Для контроля процесса архивирования данных в СПАД и управления им предусмотрены каналы, позволяющие управлять и контролировать выполнение следующих операций:

· управление сохранением данных в СПАД;

· контроль текущего состояния операций со СПАД;

· копирование локального архива СПАД;

· контроль и управление очередью сообщений в СПАД.

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

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

Отчет тревог ведется в ASCII-формате. В этом архиве осуществляется фиксация событий. Теоретически он не имеет ограничений на размер. Данные заносятся в отчет тревог в виде отдельных строк. Каждая строка содержит время и дату ее формирования, а также ряд дополнительных полей. Эти поля могут содержать разную информацию в зависимости от того, какое событие фиксируется данной строкой. Такой информацией может быть, например, имя канала и его значение, сообщение из файлов пользовательских словарей и т.д.

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

1. Управление сохранением данных в отчет тревог.

2. Копирование отчета тревог.

3. Контроль состояния операций с отчетом тревог.

4. Контроль состояния очереди сообщений в отчет тревог.

5. Контроль текущей длины файла отчета тревог.

6. Зацикливание отчета тревог.

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

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

Рис. 4.9. Окно тренда “Архив”.

По моему мнению, применение TRACEMODE в разработке распределенных АСУ ТП перспективно и позволяет значительно сократить сроки проектирования и отладки.

5. Сервер производственного контроля

5.1. Назначение сервера

Основные функции сервера производственного контроля:

1. получение и обработка информации о технологическом процессе;

2. отслеживание событий (нештатных ситуаций);

3. передача команд оператора на исполнительные механизмы;

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

5. сохранение параметров в базе данных, ведение журнала событий.

5.2. Анализ информационных потребностей фирмы

При работе над проектом были определены следующие функциональные требования:

1. Централизованный доступ к данным. Хранение данных на выделенном файл-сервере с разграничением прав доступа к информации;

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

3. Использование Internet-технологий;

4. Обеспечение информационной безопасности и сохранности данных.

Рис. 5.1. Схема работы сервера производственного контроля.

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

1. Элементы однопроводной сети MicroLAN фирмы «DallasSemiconductor». Однопроводная сеть присоединяется к компьютеру через последовательный порт. Сеть содержит 17 датчиков, 6 ключей дискретного ввода/вывода, 8 меток линии, а также мастер линии.

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

3. Сервер позволяет обмениваться данными с удаленными серверами производственного контроля с помощью семейства протоколов TCP/IP. Это может быть необходимо, например, для ведения централизованной базы данных.

4. Сервер позволяет передавать данные любому внешнему приложению по интерфейсу DDE.

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

5.3. Выбор сетевой ОС

Ключевым звеном в сети является операционная система, своего рода «сердце сети». Рассмотрим две операционные системы: MicrosoftWindows 2000 Server и ASPLinux 7.3. Следует сразу отметить, что одним из важнейших критериев выбора ОС являются затраты, необходимые на приобретение как собственно ОС, так и программных продуктов для неё.

Рассмотрим сетевую операционную систему Windows 2000 Server корпорации Microsoft, кажущаяся простота которой часто сбивает с толку начинающих системных администраторов. И хотя Microsoft позиционирует данную ОС как серверную сетевую платформу для малого и среднего бизнеса, общеизвестно, что серьезные сетевые проекты в большинстве случаев по-прежнему базируются на платформе UNIX. Следует отметить завышенные требования к аппаратному обеспечению, например, для полноценного функционирования сервера требуется не менее 128 мегабайт оперативной памяти.

Так же, на мой взгляд, большим недостатком является то, что Windows 2000 Server – коммерческий продукт, стоимость которого составляет порядка 750 долларов США. Также следует отметить тот факт, что большая часть офисных программных продуктов (MicrosoftOffice, Visio и т.д.) являются коммерческими, что при проектирование тепличного комбината резко повысит его себестоимость.

Итак, ОС Windows 2000 Server была отвергнута по следующим причинам:

1. Как ОС, так и большая часть прикладного программного обеспечения являются коммерческими продуктами, цена которых достаточно велика.

2. Общее недоверие к программным продуктам Microsoft, их ненадежность, большое количество ошибок.

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

4. Определенная функциональная неполноценность Windows 2000 Server как сетевой ОС.

С другой стороны ОС Linux обладает следующими неоспоримыми преимуществами:

1. Относительно невысокие требования к аппаратному обеспечению.

2. Бесплатное распространение ОС по лицензии GNU.

3. Гибкость настроек при одновременной мощности и традиционной высокой функциональности UNIX – систем.

4. Огромное количество свободно распространяемых продуктов (в том числе в виде исходных текстов).

5. Отличная репутация ОС.

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