1. Функции системы.
Рис. 1. Блочная схема системы OpenSCADA
1.1. Модульность.
Для придания гибкости и высокой степени масштабируемости система OpenSCADA построена по модульному принципу. Тесная интеграция модулей с ядром улучшает стабильность системы в целом, благодаря повторному использованию отлаженного кода. Однако сам процесс разработки собственного кода модулей OpenSCADA накладывает большую ответственность, возможные ошибки вводят элемент нестабильности в систему. Возможность создания распределённых конфигураций сглаживает эту опасность.
Модули системы OpenSCADA хранятся в динамических библиотеках. Каждая динамическая библиотека может содержать множество модулей различного типа. Наполнение динамических библиотек модулями определяется функциональной связностью самих модулей. Динамические библиотеки допускают горячую замену, что позволяет в процессе функционирования производить обновление отдельных частей системы. Метод хранения кода модулей в динамических библиотеках является основным для системы OpenSCADA, поскольку поддерживается практически всеми современными операционными системами(ОС). Однако это не исключает возможности разработки других методов хранения кода модулей.
На основе модулей реализованы следующие функциональные части системы OpenSCADA:
- базы данных;
- коммуникационные интерфейсы, транспорты;
- протоколы коммуникационных интерфейсов;
- источники данных и сбор данных;
- архивы (сообщений и значений);
- интерфейсы пользователя (GUI, TUI, WebGUI, speach, signal ... .);
- дополнительные модули, специальные.
Управление модулями осуществляется подсистемой «Управление модулями». Функциями подсистемы является: подключение, отключение, обновление модулей, а также другие операции, связанные с модулями и библиотеками модулей.
1.2. Подсистемы.
Архитектурно система OpenSCADA делится на подсистемы. Подсистемы могут быть двух типов: обычные и модульные. Модульные подсистемы обладают свойством расширения посредством модулей. Каждая модульная подсистема может содержать множество модульных объектов. Например, модульная подсистема «Базы данных» содержит модульные объекты типов баз данных. Модульный объект является корнем внутри модуля.
Всего система OpenSCADA содержит 9 подсистем из них 7 подсистем являются модульными. 9 подсистем системы OpenSCADA являются базовыми и присутствуют в любой конфигурации. К списку 9 подсистем могут добавляться новые подсистемы посредством модулей. Подсистемы системы OpenSCADA:
- Безопасность.
- Управление модулями.
- Базы данных (модульная).
- Транспорты (модульная).
- Транспортные протоколы (модульная).
- Сбор данных (модульная).
- Архивы (модульная).
- Интерфейсы пользователя (модульная).
- Специальные (модульная).
1.3. PLC и другие источники динамических данных. Подсистема "Сбор данных".
Для обеспечения поддержки источников динамических данных, будь то PLC-контроллеры, платы УСО, виртуальные источники и т.д., предназначена подсистема «Сбор данных». В функции этой подсистемы входит предоставление полученных данных в структурированном виде и обеспечение управления этими данными, например, модификация данных.
Подсистема «Сбор данных» является модульной и, как следствие, содержит модульные объекты типов источников динамических данных. Например, на октябрь 2007г, система OpenSCADA поддерживает следующие типы источников данных:
- Платы сбора данных от "Diamond systems".
- Сбор данных операционной системы (ОС).
- Блочный вычислитель.
- Вычислитель на Java-подобном языке.
- Транспортёр данных подсистемы "Сбор данных" от одной OpenSCADA станции к другой.
- Доступ к логическим контроллерам посредством протокола "ModBUS".
- Сбор данных сетевых устройств посредством протокола SNMP.
- Источник данных логического уровня системы OpenSCADA.
- Доступ к высокоинтеллектуальным логическим контроллерам посредством протокола MPI и коммуникационного процессора CIF50PB, фирмы Hilscher GMBH.
Каждый тип источника выполнен в виде отдельного модуля, который может быть подключен/отключен. Каждый тип источника может содержать отдельные источники (контроллеры).
Отдельно взятый контроллер может содержать параметры определённых модулем типов. Например, параметры аналогового типа; основной информацией, которую они предоставляет, является значение целого или вещественного типа. Структурно параметр представляет собой список атрибутов, которые и содержат данные. Атрибуты могут быть четырёх базовых типов: символьная строка(текст), целое, вещественное и логический тип.
Структуры контроллеров, параметров и их типов содержатся в подсистеме "Сбор данных", а объекты модулей выполняют их заполнение в соответствии с собственной спецификой.
Источник динамических данных может быть удалённым, т.е. быть подключен на удалённой системе OpenSCADA. Для связи с такими источниками данных используется транспортный тип контроллеров (Transporter). Функцией данного типа источника данных является отражение источников данных удалённой OpenSCADA станции на локальную станцию.
1.4. Базы данных. Подсистема "Базы данных"
Для хранения данных системы повсеместно используются базы данных (БД). В целях систематизации доступа и управления базами данных в системе OpenSCADA предусмотрена подсистема "Базы данных". Для обеспечения поддержки различных БД/СУБД подсистема выполнена модульной.
В роли модульных объектов, содержащихся в подсистеме, выступает тип БД/СУБД, т.е. модуль подсистемы «Базы данных» практически содержит реализацию доступа к определённому типу БД. Например, модули: DBF, MySQL, SQLite.
Объект типа БД/СУБД в свою очередь содержит список объектов отдельных БД данного типа, а объект БД содержит список объектов таблиц, которые и содержат данные в табличной форме.
Практически все данные системы OpenSCADA хранятся в той или иной БД. Инструментарий системы позволяет легко переносить данные из одного типа БД в другой, и, как следствие, оптимально подбирать тип БД под конкретную область применения системы OpenSCADA. Перенос информации с одной БД в другую может быть выполнен двумя способами. Первый - это изменение адреса рабочей БД и сохранение всей системы на неё, второй - это прямое копирование информации между БД. Кроме копирования поддерживается и функция прямого редактирования содержимого таблиц БД.
Для организации централизованного доступа распределённой системы к единой БД предусматриваются два способа. Первый это использование сетевых СУБД, например, MySQL. Второй способ это использование транспортного типа БД на локальных системах для доступа к одной центральной БД (
Планируется). Функцией транспортной БД является пересылка запросов к БД на удалённую OpenSCADA систему.
Данные могут храниться также в конфигурационном файле системы. Реализован механизм полного отражения структуры БД на структуру конфигурационного файла. Т.е. стандартную конфигурацию можно размещать в конфигурационном файле. Суть такого механизма в том, что данные системы по умолчанию, например, при старте без БД можно описывать в конфигурационном файле. В дальнейшем эти данные могут переопределяться в БД. Кроме этого для случаев невозможности запуска какой либо БД вообще можно все данные хранить в конфигурационном файле.
Для доступа к базам данных используется механизм регистрации БД. Зарегистрированные в системе БД доступны всем подсистемам системы OpenSCADA и могут использоваться в их работе. Благодаря этому механизму можно обеспечить распределёность хранения данных. Например, различные библиотеки могут храниться и распространяться независимо, а подключение библиотеки будет заключаться в простой регистрации нужной БД.
В дальнейшем планируется реализация дублирования БД путём связывания зарегистрированных БД. Этот механизм позволит значительно повысить надёжность системы OpenSCADA в целом путём резервирования механизма хранения данных (
Планируется).
1.5. Архивы. Подсистема "Архивы".
Любая SCADA система предоставляет возможность архивирования собранных данных, т.е. формирование истории изменения (динамики) процессов. Архивы условно можно разделить на два типа: архивы сообщений и архивы значений.
Особенностью архивов сообщений является то, что архивируются так называемые события. Характерным признаком события является время возникновения этого события. Архивы сообщений обычно используются для архивирования сообщений в системе, т.е. ведение логов и протоколов. В зависимости от источника сообщения могут классифицироваться по различным критериям. Например, это могут быть протоколы аварийных ситуаций, протоколы действий операторов, протоколы сбоев связи и др.
Особенностью архивов значений является их периодичность, определяемая промежутком времени между двумя смежными значениями. Архивы значений применяются для архивирования истории непрерывных процессов. Поскольку процесс непрерывный, то и архивировать его можно только путём введения понятия квантования опроса значений, поскольку иначе мы получаем архивы бесконечных размеров, ввиду непрерывности самой природы процесса. Кроме этого практически мы можем получать значения с периодом ограниченным самими источниками данных. Например, довольно качественные источники данных в промышленности редко позволяют получать данные с частотой более 1 кГц. И это без учёта самих датчиков имеющих ещё менее качественные характеристики.
Для решения задач архивирования потоков данных в системе OpenSCADA предусмотрена подсистема "Архивы". Подсистема "Архивы" позволяет вести как архивы сообщений, так и архивы значений. Подсистема "Архивы" является модульной. Модульным объектом, содержащимся в подсистеме "Архивы", выступает тип архиватора. Тип архиватора определяет способ хранения данных, т.е. хранилище (файловая система, СУБД, сеть и т.д.). Каждый модуль подсистемы "Архивы" может реализовывать как архивирование сообщений, так и архивирование значений. Подсистема "Архивы" может содержать множество архивов, обслуживаемых различными модулями подсистемы.
Сообщение в системе OpenSCADA характеризуется датой, уровнем важности, категорией и текстом сообщения. Дата сообщения указывает на время создания сообщения. Уровень важности указывает на степень важности сообщения. Категория определяет адрес или условный идентификатор источника сообщения. Обычно, категория содержит полный путь к источнику сообщения в системе. Текст сообщения, собственно, и несёт смысловую нагрузку сообщения.
В процессе архивирования сообщения пропускаются через фильтр. Фильтр работает по уровню важности и категории сообщения. Уровень сообщения в фильтре указывает, что нужно пропускать сообщения с указанным или более высоким уровнем важности. Для фильтрования по категории применяются шаблоны или регулярные выражения, которые определяют какие сообщения пропускать. Каждый архиватор содержит собственные настройки фильтра. Следовательно можно легко создавать различные специализированные архиваторы для архива сообщений. Например, архиваторы сообщений можно специализировать на:
- логи, для хранения отладочной информации и другой рабочей информации сервера;
- различные протоколы (протокол действий клиентов, протокол нарушений и исключений, протокол событий ... ).
В виду похожей природы сообщения и нарушения подсистема "Архивы" содержит буфер текущих нарушений, который содержит активные на данный момент нарушения с использованием категории сообщения в роли ключа-идентификатора нарушения. Доступ к списку-буферу текущих нарушений осуществляется путём указания отрицательного значения уровня сообщения. Так, формирование сообщения с отрицательным уровнем -2 вызывает помещение в буфер активных нарушений этого сообщения с уровнем 2, а так-же дублирование его непосредственно в архиве сообщения. При последующем формировании сообщения, в такой же категории, но положительным уровнем, скажем 1, будет осуществлено удаление указанного нарушения из буфера нарушений, а само сообщение так-же попадёт в архив сообщений. Такой механизм позволяет одновременно вести учёт активных нарушений и протоколировать их прохождение в архиве сообщений. При запросе к архиву сообщений, указание положительного уровня осуществляет запрос к архиву сообщений, а отрицательного к буферу-списку текущих нарушений.
Архив значений в системе OpenSCADA выступает как независимый компонент, который включает буфер обрабатываемый архиваторами. Основным параметром архива значения является источник данных. В роли источника данных могут выступать атрибуты параметров системы OpenSCADA, а также другие внешние источники данных (пассивный режим). Другими источниками данных могут быть сетевые архиваторы удалённых OpenSCADA систем, среда программирования системы OpenSCADA и др.
Ключевым компонентом архивирования значений непрерывных процессов является буфер значений. Буфер значений предназначен для промежуточного хранения массива значений, полученных с определённой периодичностью (квантом времени). Буфер значений используется как для непосредственного хранения больших массивов значений в архивах значений как перед непосредственным «сбросом» на физические носители, так и для манипуляций с кадрами значений, т.е. в функциях покадрового запроса значений и их помещения в буфера архивов.
Для организации выделенных архиваторов в распределённых системах можно использовать транспортный тип архиватора (
Планируется). Функцией транспортного типа архиватора является отражение удалённого центрального архиватора на локальной системе. Как следствие архиваторы транспортного типа выполняют передачу данных между локальной системой и архиватором удалённой системы, скрывая от подсистем локальной системы реальную природу архиватора.
1.6. Коммуникации. Подсистемы "Транспорты" и "Транспортные протоколы".
Поскольку система OpenSCADA закладывается как высоко-масштабируемая система, то поддержка коммуникаций должна быть достаточно гибкой. Для удовлетворения высокой степени гибкости коммуникации в системе OpenSCADA реализованы в подсистемах "Транспорты" и "Транспортные протоколы", которые являются модульными.
Подсистема «Транспорты» предназначена для обмена неструктурированными данными между системой OpenSCADA и внешними системами. В роли внешних систем могут выступать и удалённые OpenSCADA системы. Под неструктурированными данными понимается массив символов определённой длины. Модульным объектом, содержащимся в подсистеме «Транспорты», выступает тип транспорта. Тип транспорта определяет механизм передачи неструктурированных данных. Например, это могут быть:
- сокеты (TCP/UDP/UNIX);
- каналы;
- разделяемая память.
Подсистема "Транспорты" включает поддержку входящих и исходящих транспортов. Входящий транспорт предназначен для обслуживания внешних запросов и отправки ответов. Исходящий транспорт, наоборот, предназначен для отправки сообщений и ожидания ответа. Следовательно, входящий транспорт содержит конфигурацию данной станции как сервера, а исходящий транспорт содержит конфигурацию удалённого сервера. Модуль подсистемы "Транспорты" реализует поддержку как входящего, так и исходящего транспортов.
Подсистема "Транспортные протоколы" предназначена для структуризации данных, полученных от подсистемы "Транспорты". По сути, подсистема "Транспортные протоколы" является продолжением подсистемы "Транспорты" и выполняет функции проверки структуры и целостности полученных данных. Так, для указания протокола, в связке с которым должен работать транспорт, предусмотрено специальное конфигурационное поле. Модульным объектом, содержащимся в подсистеме "Протоколы", является сам протокол. Например, транспортными протоколами могут быть:
- HTTP (Hyper Text Transfer Protocol);
- SelfSystem (OpenSCADA системный протокол).
Полную цепочку связи можно записать следующим образом:
- сообщение передаётся в транспорт;
- транспорт передаёт сообщение связанному с ним протоколу путём создания нового объекта протокола;
- протокол проверяет целостность данных;
- если пришли все данные, то сообщить транспорту о прекращении ожидания данных и передать ему ответ иначе сообщить, что нужно ожидать ещё;
- транспорт, получив подтверждение, отсылает ответ и удаляет объект протокола;
- если подтверждения нет, то транспорт продолжает ожидание данных, и в случае их поступления передаёт их сохранённому объекту протокола.
Поддерживаются протоколы и для исходящих транспортов. Исходящий протокол берёт на себя функцию общения с транспортом и реализацию особенностей протокола. Внутренняя сторона доступа к протоколу реализуется потоковым образом с собственной структурой для каждого протокольного модуля. Такой механизм позволяет выполнять прозрачный доступ к внешней системе, посредством транспорта, просто указывая имя протокола, с помощью которого обслуживать передачу.
Благодаря стандартному API-доступа к транспортам системы OpenSCADA можно легко менять способ обмена данными, не затрагивая самих обменивающихся систем. Например, в случае локального обмена можно использовать более быстрый транспорт на основе разделяемой памяти, а в случае обмена через интернет и локальную сеть использовать TCP или UDP сокеты.
1.7. Интерфейсы пользователя. Подсистема "Интерфейсы пользователя".
SCADA-системы, как класс, предполагают наличие интерфейсов пользователя. В OpenSCADA для предоставления пользовательских интерфейсов предусмотрена подсистема "Пользовательские интерфейсы". Под пользовательским интерфейсом системы OpenSCADA понимается не только среда визуализации, с которой должен работать конечный пользователь, но и всё, что имеет отношение к пользователю, например:
- среды визуализации;
- конфигураторы;
- сигнализаторы.
Подсистема "Пользовательские интерфейсы" является модульной. Модульным объектом подсистемы выступает собственно конкретный интерфейс пользователя. Модульность подсистемы позволяет создавать различные интерфейсы пользователей на различных GUI/TUI библиотеках и использовать наиболее оптимальное из решений в конкретно взятом случае, например, для сред исполнения программируемых логических контроллеров можно использовать конфигураторы и визуализаторы на основе Web-технологий (WebCfg, WebUI), а в случае стационарных рабочих станций использовать те же конфигураторы и визуализаторы, но на основе библиотек типа Qt, GTK.
1.8. Безопасность системы. Подсистема "Безопасность".
Система OpenSCADA является разветвлённой системой, которая состоит из десятка подсистем и может включать множество модулей. Следовательно, предоставление всем неограниченного доступа к этим ресурсам является по крайней мере небезопасным. Поэтому для разграничения доступа в системе OpenSCADA предусмотрена подсистема "Безопасности". Основными функциями подсистемы "Безопасности" является:
- хранение учётных записей пользователей и групп пользователей;
- аутентификация пользователей;
- проверка прав доступа пользователя к тому или иному ресурсу.
1.9. Управление библиотеками модулей и модулями. Подсистема "Управление модулями".
Система OpenSCADA построена по модульному принципу, что подразумевает наличие множества модулей, которыми необходимо управлять. Для выполнения функции управления модулями системы OpenSCADA предусмотрена подсистема "Управление модулями". Все модули на настоящий момент поставляются в систему посредством разделяемых библиотек(контейнеров). Каждый контейнер может содержать множество модулей различного типа.
Подсистема "Управление модулями" реализует контроль за состоянием контейнеров и позволяет выполнять горячее добавление, удаление и обновление контейнеров и содержащихся в них модулей.
1.10. Непредусмотренные возможности. Подсистема "Специальные".
Разумеется, предусмотреть всех возможных функций невозможно, поэтому в системе OpenSCADA предусмотрена подсистема "Специальные". Подсистема "Специальные" является модульной и предназначена для добавления в систему OpenSCADA непредусмотренных функций путём модульного расширения. Например, с помощью подсистемы «Специальные» могут быть реализованы:
- тесты системы OpenSCADA и её модулей;
- библиотеки функций пользовательского программирования.
1.11. Пользовательские функции. Объектная модель и среда программирования системы.
Любая современная SCADA система должна содержать механизмы, предоставляющие возможность программировать на пользовательском уровне, т.е. содержать среду программирования. Система OpenSCADA содержит такую среду. С помощью среды программирования системы OpenSCADA можно реализовывать:
- Алгоритмы управления технологическими процессами.
- Крупные динамические модели реального времени технологических, химических, физических и других процессов.
- Адаптивные механизмы управления по моделям.
- Пользовательские процедуры управления внутренними функциями системы, её подсистемами и модулями.
- Гибкое формирования структур параметров на уровне пользователя, с целью создания параметров нестандартной структуры и заполнения её по алгоритму пользователя.
- Вспомогательные вычисления.
Среда программирования системы OpenSCADA представляет собой комплекс средств, организующих вычислительное окружение пользователя. В состав комплекса средств входят:
- объектная модель системы OpenSCADA;
- модули библиотек функций;
- вычислительные контроллеры подсистемы «Сбор данных» и другие вычислители.
Модули библиотек функций предоставляют множество функций определённой направленности, расширяющих объектную модель системы. Библиотеки могут реализоваться как набором функций фиксированного типа, так и функциями, допускающими свободную модификацию и дополнение.
Библиотеки функций фиксированного типа могут предоставляться стандартными модулями системы, органично дополняя объектную модель. Функции таких библиотек будут представлять собой интерфейс доступа к средствам модуля на уровне пользователя. Например, «Среда визуального представления данных» может предоставлять функции для выдачи различных сообщений. Используя эти функции, пользователь может реализовывать интерактивные алгоритмы взаимодействия с системой.
Библиотеки функций свободного типа предоставляют среду написания пользовательских функций на одном из языков программирования. В рамках модуля библиотек функций могут предоставляться механизмы создания библиотек функций. Так, можно создавать библиотеки аппаратов технологических процессов, а в последствии использовать их путём связывания. Различные модули библиотек функций могут предоставлять реализации различных языков программирования.
На основе функций, предоставляемых объектной моделью, строятся вычислительные контроллеры. Вычислительные контроллеры выполняют связывание функций с параметрами системы и механизмом вычисления.