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

Для определения ускорений в опорных точках продифференцируем выражение (6.3)

Приравнивая значения скоростей слева и справа в узловых точках, получаем систему уравнений для определения ускорений M_j:

Приравнивая полученные выражения, получим

, (6.4)

где ;

;

.

Недостающие два уравнения для первой и последней точек траектории найдем исходя из начальных условий.

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

Из уравнения (6.4) следует:

, .

Используя матричную форму записи полученных m+1 уравнений, получаем выражения для вычисления M_j:



где n - число интервалов разбиения;

л₀=м_n=1

j = 1..n-1

,

,

,

где j = 1..n-1.

Решив это матричное уравнение, и подставив полученные значения ускорений в выражение (6.3), получим уравнение для вычисления значений сплайнов на каждом участке траектории.

6.3 Выбор эталонного переходного процесса

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

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

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

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

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

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

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

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

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

,

где - момент инерции двигателя, - частота вращения вала двигателя.

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

6.4 Программная реализация алгоритма синтеза

Описанный в пятом разделе метод синтеза системы управления промышленным роботом программно реализован в широко распространенном пакете MatLab. Выбор пакета объясняется наличием необходимых функций для реализации этого метода. Листинг программы приведен в приложении А.

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

Укрупненный алгоритм метода, использованного для синтеза, изображен на рисунке 6.2

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

Рисунок 6.2 Укрупненный алгоритм программы синтеза системы управления

6.5 Пример решения задачи синтеза управления при изготовлении
кулачка

6.5.1 Описание изготавливаемой детали

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

В состав РТК входит следующее технологическое оборудование:

- робот для манипулирования лазерным лучом;

- лазерный излучатель;

- стол для лазерной резки;

- система управления роботом для лазерной резки;

- накопитель для заготовок;

- накопитель для обработанных деталей;

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

- система управления роботом.

РТК функционирует следующим образом. ПР для транспортировки устанавливает заготовку на стол для резки. Следующий ПР осуществляет её обработку. Далее первый робот снимает обработанную деталь и устанавливает новую заготовку. Безопасность РТК обеспечивается системой светозащиты.

Форма кулачка задается в полярной системе координат таблично величинами полярного радиуса (расстояние от полюса до точки на контуре) и полярного угла (относительно полярной оси). Таблица может иметь ограниченное количество координат точек контура в полярной системе координат. В качестве полюса принимается центр вращения кулачка (рисунок 6.3).

Рисунок 6.3. Кулачок и полярная система координат

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

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

Номер точки	Полярный угол, градусы	Полярный радиус, мм
1	0	110
2	15	104
3	30	95
4	45	92
5	60	94
6	75	97
7	90	102
8	105	106
9	120	115
10	135	128
11	150	140
12	165	148
13	180	150
14	195	146
15	210	136
16	225	126
17	240	115
18	255	105
19	270	100
20	285	100
21	300	102
22	315	103
23	330	105
24	345	108
25	360	110

6.5.1 Управление ПР при движении вдоль контура кулачка при лазерной резке

Для обеспечения движения по контуру кулачка требуется знать координаты точек положения рабочего органа ПР в моменты дискретизации по времени. Для обеспечения высокой точности количество моментов дискретизации должно быть больше, чем количество узловых точек. Поэтому по узловым точкам необходимо построить кубический сплайн [24], а затем на сплайне выбрать равноотстоящие точки, в которые рабочий орган должен попадать в моменты квантования по времени (через каждые 1 градус друг от друга).

Контур кулачка графическими средствами MathCAD изображен на рисунке 6.4



Рисунок 6.4 Контур кулачка

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

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

Пусть центр вращения кулачка (полюс полярной системы координат) будет расположен на оси X системы координат робота на расстоянии 500 мм от его начала. Направим полярную ось вдоль оси Х системы координат робота. Расположим плоскость кулачка параллельно плоскости OXY системы координат робота.

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

;

;

.

Рисунок 6.5 Положение кулачка в рабочей зоне

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

Графики первой и третьей обобщенных координат приведены соответственно на рисунке 6.7 и рисунке 6.8.

Для нахождения эталонных обобщенных скоростей осуществим решение обратной задачи кинематики о скоростях.

На рисунке 6.9 и 6.10 приведены графики первой и третьей обобщенных скоростей.



Рисунок 6.7 График первой обобщенной координаты

Рисунок 6.8 График третьей обобщенной координаты



Рисунок 6.9 График обобщенной скорости первого сочленения

Рисунок 6.10 График обобщенной скорости для третьего сочленения

На рисунке 6.11 и 6.12 приведены графики эталонных моментов в двигателях первого и третьего сочленений.



Рисунок 6.11 График момента для первого сочленения

Рисунок 6.12 График момента для третьего сочленения

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

В результате синтеза получены управляющие воздействия, графики которых приведены на рисунке 6.13 и рисунке 6.14 соответственно для первого и третьего сочленений.

Рисунок 6.13 График управляющего воздействия для первого сочленения

Рисунок 6.14 График управляющего воздействия для третьего сочленения

Из графиков следует, что значения управляющих воздействий не выходят за допустимые пределы.

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

6.5.2 Управление ПР при вертикальном движении

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

- интервал разгона от нулевой скорости к максимальной;

- интервал движения с максимальной скоростью;

- интервал торможения.

Максимальная скорость для второго сочленения равна 0,7 м/с.

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

Длительность интервала торможения равна длительности интервала разгона.

Во время интервалов разгона и торможения РО опустится на величину

.

Необходимо опускание осуществить на величину 0,2 м, то на интервале движения с максимальной скоростью необходимо переместится на величину 0,2-0,116=0,084 м.

Таким образом, интервал движения с максимальной скоростью длится 6 шагов квантования.

График эталонной обобщенной координаты приведен на рисунке 6.15

График эталонной обобщенной скорости приведен на рисунке 6.16

График эталонного момента приведен на рисунке 6.17

Рисунок 6.15 График второй обобщенной координаты



Рисунок 6.16 График обобщенной скорости для второго сочленения

Рисунок 6.17 График момента для второго сочленения

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



Рисунок 6.18 График управляющего воздействия для второго сочленения

6.6 Оценка погрешности позиционирования РО

При изготовлении детали важное значение имеет точность позиционирования РО ПР. На практике важно оценить точность позиционирования в декартовой системе координат.

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

,

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

- матрица Якоби на -ом шаге дискретизации по времени;

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

- вектор-столбец ошибок по обобщенным координатам на -ом шаге дискретизации по времени.

Ошибки по обобщенным координатам в й момент дискретизации вычисляются по формуле:

где эталонное положение в обобщенной системе координат;

реальное положение в обобщенной системе координат.

Величины ошибок по обобщенным координатам приведены на листах 8 и 9 графической части.

Матрица Якоби вычисляется по формуле

,

где , , - функции, решения прямой задачи кинематики:



Матрица Якоби равна:

Величины ошибок по осям декартовой системе координат, связанной с основанием робота, приведены на листах 8 и 9 графической части.

В -ый момент дискретизации по времени отклонение вычисляется по формуле

.

Как следует из графиков, отклонение рабочего органа от заданного при движении вдоль контура кулачка не превышает 0,1 мм, что удовлетворяет требуемой точности.

Рисунок 6.19 График отклонения траектории движения рабочего органа от эталонной траектории при отработке контура кулачка



Рисунок 6.20 График отклонения траектории движения рабочего органа от эталонной траектории при подходе к поверхности резания

7. Визуализация и архивирование технологического процесса

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

7.1 Выбор SCADA системы

В настоящее время существует огромный выбор SCADA систем: TRACE MODE, Genesis, iHistorian, DSC и многие другие. На мой взгляд, наиболее перспективной является SCADA система TRACE MODE, разработанная в 1992 году российской фирмой AdAstra Research Group, Ltd. TRACE MODE позволяет добиться значительной экономии средств, затрачиваемых на АСУТП, при сохранении ее качества. Это достигается за счет следующих свойств системы.

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

Во-вторых, TRACE MODE ориентирована на стандартные и легкодоступные, а потому и недорогие аппаратные и программные средства. Операционные системы MS DOS, Windows или Novell Netware, сетевые платы Ethernet и Arcnet, карты Sound Blaster есть на любом промышленном предприятии, они стоят недорого и любое предприятие располагает квалифицированными кадрами, способными их обслуживать. Это означает резкое сокращение непрямых расходов и т.н. «скрытой цены», столь характерной для экзотических систем, использующих в качестве операционной системы Linux, QNX и т.д.

И, наконец, TRACE MODE экономична сама по себе. Использование труда только российских разработчиков, отсутствие накладных расходов, связанных с доставкой и таможенным оформлением - все это делает TRACE MODE доступной по стоимости любому промышленному предприятию, которое всерьез решило заняться проблемами автоматизации производства. По показателям цена/производительность TRACE MODE значительно превосходит зарубежные аналоги. Так, например, в АСУТП среднего размера, имеющей 1000 входов/выходов (I/O) типичным соотношением дискретных и аналоговых параметров 6:1, стоимость одного I/O составляет $ 1,72 (с учетом инструментальной системы и всех налогов), а в крупной системе автоматизации, имеющей 10.000 входов/выходов, стоимость одного I/O и вовсе ничтожна - $ 0,17. Аналогичные показатели западных SCADA-систем, составляют $ 20-25 и $ 2,0-2,5 за I/O, т.е. в 11-15 раз выше.

7.2 SCADA система TRACE MODE

В общем случае, система АСУ на предприятии включает в себя нескольких уровней:

– уровень контрольно-измерительных приборов и аппаратуры (КИПиА);

– уровень контроллеров (традиционные ПЛК и Softlogic);

– уровень рабочих станций (АРМ);

– уровень операторских мест руководства (супервизорный) и уровень управления предприятием (АСУП).

АСУ тепличного комбината включает в себя три первых уровня.

7.2.1 Общая структура и возможности TRACE MODE

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

Программное обеспечение уровня SCADA (Supervisory Control And Data Acquisition) выполняет следующие функции:

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

2) Обмен с контроллерами в реальном времени - получение информации от контроллеров по последовательному интерфейсу, сети Ethernet или по полевым шинам, первичная обработка этих данных, а также пересылка в контроллеры управляющей информации.

3) Архивирование - сохранение информации в специальные промышленные архивы, основными требованиями к которым являются надёжность и быстродействие.

4) Документирование процесса - создание отчётов по заранее созданным шаблонам с последующей их передачей по разным каналам обмена информации (распечатка, электронная почта, web-сайт).

5) Получение и передача информации в другие программные пакеты - обмен оперативными и архивными данными со специализированным ПО, либо с ПО уровня АСУП.

6) Неоперативная обработка информации - вычисление статистической информации, управление небыстрыми процессами.

7) Управление тревогами - список тревог, фильтр событий, квитирование.

Термин Softlogic подразумевает:

1) Использование контроллеров с PC-совместимой архитектурой. Программирование таких контроллеров может осуществляться написанием специфических программ на языках программирования типа ассемблер или С, а может осуществляться с помощью инструментальных пакетов на визуальных языках верхнего уровня, совместимых со стандартом МЭК61131-3, например на языке функциональных блоков или языке инструкций;

2) Обеспечение связи с уровнем АРМ. Может быть автоматизировано с помощью интеграции SCADA и Softlogic систем. В этом случае не требуется совершать двойную работу по созданию каналов в контроллере, в АРМ и описанию обмена между ними;

3) При необходимости ведение архивов, например когда связь между контроллером и АРМ устанавливается на сеансовой основе - дозвон по коммутируемым линиям;

4) Возможность ОЕМ (производитель оригинального оборудования) проектов - совместных проектов производителей программного и аппаратного обеспечения. В этом случае заказчики приобретают конечный продукт, например контроллер, уже с предынсталлированным исполнительным модулем и инструментальной средой разработки, что значительно сокращает время и силы для подготовки оборудования к работе и сокращает издержки.



Рисунок 7.2 - Программирование контроллеров на языке функциональных блоков

К дополнительным, теоретически не обязательным, но могущим оказаться необходимыми, функциям SCADA и Softlogic систем можно отнести следующие:

1) Многоуровневое горячее резервирование - дублирование или троирование плат/модулей ввода-вывода, контроллеров, линий связи, архивов, операторских станций для увеличения надёжности работы объекта;

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

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

4) Web- и GSM-управление - удалённый мониторинг и управление через web и GSM сети для возможности непрерывного контроля и оперативного вмешательства в ситуацию;

5) Документирование проекта - функция, облегчающая разработчику процесс создания проекта и внесения в него изменений путём сохранения информации о версиях проекта в удобовоспринимаемой форме;

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

7.2.2 Исполнительные модули TRACE MODE

Исполнительные системы TRACE MODE включают в себя следующие программы:

– NT-МРВ - монитор реального времени;

– Supervisor - аналог «монитора архива»;

– специальные утилиты просмотра архивов - UTIL-NT.

NT-МРВ предназначен для сбора, обработки, графической визуализации и управления технологическими процессами в реальном времени. На его основе можно создавать автоматизированные рабочие места операторов-технологов, диспетчеров, смененных инженеров и т.д.. Система способна принимать данные через 16 последовательных портов, обрабатывать их при помощи десятков встроенных математических алгоритмов, графически отображать в удобной для оператора форме, вести архивы, генерировать и печатать отчеты, а также поддерживать сетевой обмен с другими компьютерами, используя следующие протоколы: NetBios, NetBEUI, TCP/IP, IPX, SPX, Banian Vines.

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

Две программы, входящие в состав UTIL-NT (Report Viewer и Alarm Viewer), имеют вспомогательный характер. С их помощью оператор, не прерывая работы в реальном времени, может просматривать архивы технологической информации и получить информацию о накопленных данных. Утилита просмотра отчета тревог (Alarm Viewer) - программа предназначена для просмотра отчета тревог с использованием временных и строчных фильтров и позволяет производить квитирование сообщений, а также выводить данные из отчета тревог на печать. Программа предусматривает использование одного основного и трех дополнительных фильтров, с помощью которых оператор может произвести отбор данных о технологических событиях, фильтруя их по времени, месту, либо типу события. Кроме того, специальный фильтр позволяет оператору выводить на экран только неквитированные сообщения. Любая строка в отчете тревог может быть помечена «закладкой». После этого возможен быстрый переход на нее из любого места отчета тревог. Программа Report Viewer предназначена для просмотра и редактирования уровневого архива TRACE MODE и позволяет выполнять ряд операций с выделенными столбцами данных (печать, изменение формата, экспорт данных), а также редактировать данные, записанные в архив. Данные, отображаемые программой, могут обновляться с заданным периодом.

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

Важное значение для АСУТП имеет вытесняющая многозадачность, предоставляемая операционными системами Windows NT и Linux. Благодаря этому свойству операционной системы оператор получает возможность использовать любые дополнительные приложения без риска остановить работу системы реального времени. Кроме того, исключительно важным свойством Linux для задач АСУТП является ее высокая устойчивость к сбоям. В режиме реального времени NT-МРВ, Supervisor и утилиты работают в своем изолированном адресном пространстве.

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

Крупные корпоративные пользователи найдут удобным повышенные средства защиты данных от несанкционированного доступа. Кроме стандартных средств ограничения доступа к данным, предоставляемых TRACE MODE, в NT-МРВ и Supervisor возможно блокировать доступ к файлам на уровне операционной системы.

7.2.3 TRACE MODE 6 - синтез новых технологий

Новая версия программы по своему инновационному характеру превосходит все существующие версии программы. В ней предложен совершенно новый подход к разработке систем управления, наглядный и интуитивно понятный специалистам разной профессиональной подготовки: инженерам по АСУ ТП, программистам, технологам и даже экономистам. Новая версия программы будет давать интегрированный инструмент для программирования контроллеров (Softlogic), разработки операторского интерфейса (SCADA), управления производственными заданиями (MES) и основными фондами (EAM). TRACE MODE 6 станет многоплатформной - Windows, UNIX, LINUX, QNX. При этом сохранится полная совместимость TRACE MODE 6 с TRACE MODE 5.

7.3 Графическое отображение состояния производственных процессов

В соответствии с техническим заданием в ходе выполнения дипломного проекта мною на базе SACDA системы TRACE MODE была разработана программа графического отображения состояния производственных процессов.

7.3.1 Назначение программы

Основные функции программы графического отображения:

1) Получение информации о технологическом процессе с сервера производственного контроля;

2) Отображение состояния технологического процесса в реальном времени в виде мнемосхем, карт объекта и т. п., содержащих произвольные графические и текстовые объекты, на которые может быть наложена анимация (масштабирование, изменение цвета, движение и т. п. в зависимости от состояния параметров тех. процесса);

3) Звуковое и визуальное (графическое) оповещение о событиях (нештатных ситуациях);

4) Передача команд оператора на исполнительные механизмы (управление);

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

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

7) Экспорт информации в другие приложения, печать.

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

7.3.2 Требования к аппаратным и программным ресурсам

Минимальные требования к аппаратным ресурсам:

– процессор Pentium II, 300 МГц;

– память 64 Мб;

– 30 мегабайт свободного места на жестком диске для размещения программы.

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

– операционная система Windows /NT/2000/XP или Linux, с использованием эмулятора wine;

– установленные протоколы TCP/IP;

– MYSQL сервер.

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

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



Рисунок 7.3 - Схема работы программы графического отображения

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

7.3.4 Запуск и работа программы графического отображения

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

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

При выборе оператором пункта меню, соответствующего выводу графиков, появляется окно, изображенное на рис. 4.7. Чтобы в реальном времени переключить вертикальную шкалу тренда или изменить порядок расположения нескольких вертикальных шкал, нужно нажать ЛК на кнопке «Подробно». При этом на экране появится окно со списком кривых.

Шкала выбранной в этом списке кривой будет отображаться на тренде. Если тренд выводит шкалы для всех кривых, то шкала выбранной кривой переместится в крайнюю правую позицию. Для управления видимостью кривых в начале строки описания каждой из них имеется специальное поле. Кривая будет видима, если для нее в этом поле установлен флаг.

Во время работы с трендом может возникнуть необходимость уточнить значение кривой в некоторой точке. Для этой цели служит визир. Чтобы вывести на экран визир, нужно нажать ЛК в области построения графика. Перемещение визира производится нажатием ЛК на требуемой точке графика или клавишами стрелок в соответствующем направлении. Для изменения масштаба тренда используются сочетания клавиш Ctrl+<стрелки>. Клавиши вправо и вверх увеличивают масштаб, а влево и вниз - уменьшают. Значение, на которое указывает визир, отображается в поле под кнопкой «Подробно».

Универсальный тренд имеет меню управления выводимой информацией. Для входа в него следует нажать ПК в пределах тренда. Это меню содержит следующие команды:

1) Переход на время - вывод данных в указанное время. При выполнении этой команды появляется диалог настройки даты и времени. После выхода из него на тренд выводится информация начиная с указанного времени.

2) Свойства - выводит на экран диалог настройки тренда. В нем можно изменить список кривых и их настройки.

3) Восстановить пределы - возврат к исходному масштабу.

4) Архивный - переход в режим отображения данных из архива.

5) Реальное время - переход в режим отображения данных реального времени.

7.3.5 Система архивов TRACE MODE

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

1) Информация в архиве должна иметь однозначную привязку к астрономическому времени.

2) Темп записи (сброса) информации на диск должен превышать темп поступления данных.

3) Кратковременная ошибка записи (т.е. ошибка ОС, драйвера, контроллера диска) не должна приводить к искажению на период больший, чем время длительности ошибки. При этом пользователь системы должен иметь доступ к информации о нарушениях в сохранении данных. Отключение ЭВМ должно приводить к как можно меньшей потере данных (минимальный размер буферов ОЗУ) и ни в коем случае не к исчезновению архива.

4) Извлечение данных из архива - такая же важная задача, как и сохранение их.

5) В программе, работающей в режиме реального времени, должны иметься хотя бы минимальные средства извлечения и просмотра архивных данных (таблицы и тренды) за произвольный момент времени.

6) Структура архива должна быть документирована. Извлечение данных может быть произведено программными средствами других производителей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 4.9 - Окно тренда «Архив»

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

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

7.4.1 Назначение сервера

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7) Полная документированность.

ОС Linux стала привлекательной альтернативой коммерческих ОС. Лавинообразный рост интереса к Linux во всем мире подтверждает это. В ней объединены мощь и гибкость UNIX-станции, возможность использования полного набора приложений Internet и полнофункциональный графический интерфейс (например, X Window).

В качестве дистрибутива Linux возьмем ASP Linux 7.3 Server Edition .

7.4.4 Выбор сетевых протоколов

7.4.5 Протокол 1-Wire

Протокол интерфейса 1-Wire обеспечивает возможность работы с множеством iButton, подключенных параллельно к линии данных однопроводной сети сбора первичной информации тепличного комбината. Команды интерфейса позволяют определить ID всех iButton, подключенных в данный момент к линии и затем работать с конкретным прибором, переведя остальные в режим ожидания. Управление линией данных и выдачу команд производит ведущее устройство, в качестве которого может использоваться любой микроконтроллер или персональный компьютер (ПК).

7.4.6 Стек протоколов TCP/IP

Протокол TCP/IP (Transmission Control Protocol/Internet Protocol) - основное средство современного сетевого и межсетевого взаимодействия. Не секрет, что большинство современных систем поддерживают данный протокол. Распространению данного протокола способствовало, в частности, развитие сети Internet и использование TCP/IP в качестве универсального транспорта. TCP/IP предоставляет пользователям однородный интерфейс, обеспечивающий взаимодействие с сетевыми аппаратными средствами различных типов. Этот протокол гарантирует возможность обмена данными между системами, невзирая на многочисленные различия, существующие между ними. TCP/IP, кроме того, позволяет соединять на программном уровне отдельные физические сети в более крупную и более гибкую логическую сеть.

В состав комплекта TCP/IP входит несколько компонентов [7]:

- межсетевой протокол (Internet Protocol, IP), который обеспечивает транспортировку без дополнительной обработки данных с одной машины на другую;

- межсетевой протокол управления сообщениями (Inernet Control Message Protocol, ICMP), который отвечает за различные виды низкоуровневой поддержки протокола IP, включая сообщения об ошибках , содействие в маршрутизации, подтверждение получения сообщения;

- протокол преобразования адресов (Adsress Resolution Protocol, ARP), выполняющий трансляцию логических сетевых адресов в аппаратные;

- протокол пользовательских дейтаграмм (User Datagram Protocol, UDP) и протокол управления передачей (Transmission Control Protocol, TCP), которые обеспечивают пересылку данных из одной программы в другую с помощью протокола IP. Протокол UDP обеспечивает транспортировку отдельных сообщений без проверки, тогда как TCP более надежен и предполагает проверку установления соединения.

7.4.7 Протокол РРР

В качестве альтернативы аппаратным сетевым соединениям, таким как Ethernet, можно воспользоваться модемом и телефонными линиями. Существуют два протокола, которые позволяют передавать IP-пакеты по коммутируемым телефонным каналам. Это SLIP (Serial Line Internet Protocol - межсетевой протокол для последовательного канала) и протокол РРР (Point-to-Point Protocol - протокол «точка-точка»). SLIP - старый протокол, а РРР - более современный и очень стабильный. В АСУ тепличного комбината этот протокол используются для соединения сервера производственного контроля с Internet-провайдером. РРР - это «универсальный» протокол оформления (инкапсуляции) пакетов. Он позволяет передавать мультипротокольные пакеты по одному каналу. Описание этого протокола приведено в RFC 1331. Он отличается большей гибкостью, чем SLIP, который обрабатывает только IP-пакеты. Подключение АСУ тепличного комбината к Internet дает возможность отправки с помощью TRACE MODE sms-сообщений на мобильный телефон стандарта GSS900/1800 о нарушении в технологическом процессе. А также возможность организации на базе сервера производственного контроля WEB-сервера для размещения рекламы в сети Internet.

В состав протокола РРР входят три компонента:

1) процедура инкапсуляции дейтаграмм для передачи их по последовательным каналам;

2) протокол управления каналом» (Link Control Protocol, LCP), предназначенный для установления, конфигурирования и тестирования соединения на канальном уровне;

3) семейство «протоколов управления сетью» ( Network Control Protocols, NCP), обеспечивающий конфигурирование и функционирование различных протоколов сетевого уровня.

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

Использование протокола РРР достигается его встроенными реализациями в ядре Linux и программными компонентами, основу которых составляет демон pppd.