Архитектура АСУТП

Архитектура АСУТП

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

 

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

Рис_.10.1 Централизованная архитектура Однако эта архитектура имеет ряд серьезных недостатков:

·       начальные   инвестиции   слишком   высоки   для   небольших приложений;

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

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

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

При полностью распределенной архитектуре, популярной в конце 80-х г.г., задачи управления и сбора данных выполняются на нескольких небольших компьютерах (как правило, ПК). Каждый компьютер решает собственную задачу и работает со своей базой данных (БД), как показано на рис.10.2.

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

К датчикам и исполнительным механизмам

Рис.10.2 Распределенная архитектура

 

Резервирование может применяться выборочно к задачам, критически важным для предприятия.

Такая система решает проблемы, присущие централизованным архитектурам управления.

Однако распределенные системы также имеют свои недостатки:

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

·       отсутствует оптимизация запросов к данным производства - если два оператора запрашивают одни и те же сведения, запрос повторяется дважды.

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

Осознание того факта, что необходим принципиально иной подход к построению АСУТП, привело в начале 90-х г.г. к появлению новых разработок. Автором наиболее известного решения является фирма CiTechnologies, предложившая в 1992 г. программный пакет Citect для Windows.

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

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

Оптимизация клиент-серверной обработки данных в Citect

Для того чтобы понимать, как Citect использует архитектуру клиент-сервер, необходимо иметь четкое представление об основных задачах Citect: ввод/вывод; отображение; тревоги; графики; отчеты.

 

Графики Тревоги Дисплей Отчеты

Данные процесса

 

Рис.10.3 Системная архитектура Citect

Каждая из этих задач управляет собственной БД независимо от других. Такое разделение БД поддерживается даже тогда, когда все задачи исполняются на одном и том же компьютере (рис.10.3).

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

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

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

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

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

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

Клиент-серверная архитектура - с распределенными задачами как клиентами и общими задачами как серверами - оптимизирует распределение информации между БД. Citect для Windows может поддерживать высокую производительность даже при распределении задач по многим компьютерам.

Масштабируемая архитектура

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

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

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

Рис.10.4 Масштабируемая архитектура

 

По мере расширения приложения (например, добавляются два узла) дополнительный компьютер может быть использован для каждого узла - и на каждом устанавливается ПО Citect для Windows (рис.10.5).

                       

Рис.10.5 ПО Citect установлено на каждом узле

Рис.10.6 Схема с добавлением локальной сети

Однако такую схему можно улучшить добавлением ЛВС и выделенного сервера ввода/вывода. Такая централизация устраняет ненужные вычисления. Задачи отображения распределены по компьютерам, так что каждый оператор может получать необходимые данные (рис.10.6).

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

 

Рис. 10.7 Многоуровневая система по паролю

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

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

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

 

Рис 10.8 Система с отдельными серверами

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

Вопросы для самопроверки:

1. В чем заключается задача проектирования АСУТП? 2.Недостатки централизованной архитектуры.

3.   Достоинства и недостатки распределенной архитектуры.

4.   В чем смысл системной архитектуры Citect? 5.Как происходит обработка данных в Citect? 6.Что такое масштабируемая архитектура?