Logical level of parameters of OpenSCADA
Русская версия?
Українська версія?
Author: /RomanSavochenko
Translation is in progress...
1 Introduction
Open SCADA system OpenSCADA belongs to the class of SCADA (Supervisory Control and Data Aquisition) systems. Systems of this class are used as an element of technological processes automation systems (ACS TP).
OpenSCADA system is constructed as a modular and highly scalable system. Hence the internal structure of the system must meet the high demands of flexibility.
To get data from outside the OpenSCADA system provides so-called "Data sources". All data sources are contained in the subsystem of the same name and grouped by type of data sources, defining the module of subsystem of data sources (DAQ). The module is the separate component of the OpenSCADA system, which for the "DAQ" subsystem's modules contains the controllers with parameters of the predetermined structure. Under the structure of the parameter it is meant the number of its attributes.
The nature of the data source can range from "raw" to the full. The "raw" means the source that provides only the basic signal (integer, float, boolean). The full one means the source, which in the parameter contains the attributes of additional values, covering virtually all diagnostic tasks, ie parameter is a complete object, not requiring additional information.
Given this variation, the situation may cause when information in the object of the parameter is not enough to describe the object as a whole and the derived object is needed on the higher level of abstraction. The solution of this situation may be the formation of complementary parameters, which is not convenient and confusing. The better solution is to create layer, so-called "Logic level", which serves as the flexible formation of parameters/objects with necessary structure, including post-processing.
2 Purpose
Functionally, the development is intended to provide the OpenSCADA system with the mechanism of freely formation of parameters' objects of required structure.
Operating purpose of the development is:
- broadening the scope of the OpenSCADA system by increasing flexibility of description of objects of parameters;
- reducing the labor costs for the creation of complex automated systems.
3 Requirements
Architecturally logical level must meet the following requirements:
- be implemented as the subsystem of the OpenSCADA system (subsystem "Parameters");
- contain the containers of parameters and parameters' templates;
On the basis of architectural considerations it can be formed the requirements for individual components.
Requirements for the subsystem "Perameters":
- contain the containers of parameters and their templates;
- provide the mechanism for periodic calculation of the parameters built on templates;
- provide the scripts(scenarios) of the user interface for the configuration of subsystem and for the access to the parameters and their templates.
Requirements for objects "Prameters templates":
- contain the structure of the attributes of the parameter;
- support the user access to the attributes (the side of configuration): constant, link;
- support the grouping of the attributes' links by the to the parameters with the automatic appointment of the necessary attributes after specifying the parameter;
- support the ability to specify the type of the attribute (the side of the resulting parameter): no attribute, an attribute with full access, attribute for read-only access;
- provide the mechanism for calculating of the imported attributes with the purpose of the formation of new (based on the object model of the OpenSCADA system);
- provide the scripts(scenarios) of the user interface for configuring the template of the parameters.
Requirements for the objects of "Parameters":
- support the modes: direct mapping and the formation on the template;
- realization of high-performance mechanism of linkage with the original attributes/parameters;
- provide scripts(scenarios) of the UI (control interface of the system) for the configuration of the parameter.
4 Projecting
Based on the above requirements we will develop the logic level of the parameters. The overall structure of the Logical level, in the context of its interaction with the physical one, is shown in Fig. 1.
Fig. 1. The overall structure of the logic level
Разработка подсистемы "Параметры" ничем существенно не отличается от других подсистем системы OpenSCADA, поэтому рассматривать особенности её формирования не будем. Шаблоны параметров и параметры являются интересным вопросом, поэтому рассмотрим особенности их формирования.
Требованиями к шаблону параметров, озвучена необходимость содержания структуры атрибутов, которые будут фигурировать как со стороны конфигурации параметра, так и со стороны результирующих атрибутов. Кроме того, необходимо обеспечить возможность вычисления атрибутов. Хорошим решением будет использования для этих целей объектов функций среды программирования?. Такой подход избавит от необходимости создания механизма добавления атрибутов, поскольку добавляться и формироваться они будут в виде параметров функции. Общую структуру формирования параметра по шаблону представлено на рис. 2.
Рис. 2. Формирование параметра логического уровня по шаблону
Архитектура логического уровня получается предельно простая. В виде диаграммы классов её можно изобразить следующим образом (рис 3). Описание классов приведено в таблице 1.
Рис. 3. Диаграмма классов логического уровня параметров
Таблица 1. Классы логического уровня параметров
| Класс | Ответственность | Связи |
| TParamS | Класс подсистемы "Параметры". Содержит механизм вычисления параметров на шаблонах | Содержит параметры и их шаблоны. |
| TParam | Класс параметра. Содержит структуру связей, кадр значений функции и может выполнять вычисления с помощью функции шаблона | Содержится в подсистеме "Параметры". Включает кадр значений объекта функции. |
| TPrmTmpl | Класс шаблона параметра. Содержит структуру атрибутов(параметров функции) | Содержится в подсистеме "Параметры". Включает ссылку на объект функции. |
Логику работы логического уровня параметров можно записать следующим образом:
- Параметр связывается с шаблоном, из которого приобретает структуру атрибутов в соответствии с функцией шаблона.
- В момент связывания параметра с функцией выполняется связывание кадра значений параметра с функцией из шаблона.
- Далее, в соответствии с шаблоном функции, формируется структура связей.
- Исходя из структуры связей формируется форма связывания параметра.
- Пользователь устанавливает связи.
- После этого, при доступе к атрибутам полученного параметра производится проверка на наличие прямой связи. В случае наличия прямой связи запрос перенаправляется по этой связи, в противном случае значение берётся из кадра значений функции.
- В этот момент работает вычисление функции шаблона, по кадру значений параметров. При этом перед вычислением производится чтение значений по ссылкам, а после вычисления запись результатов по этим ссылкам.
В шаблоне параметра, у атрибута, предусмотрено два свойства: "Атрибут", "Доступ" и "Значение". Свойство "Атрибут" описывает отражения на атрибут параметра. Предусмотрены следующие варианты этого свойства:
- не атрибут - параметр функции не является атрибутом;
- только чтение - параметр функции является атрибутом с доступом только на чтение;
- полный доступ - параметр функции является атрибутом с полным доступом.
Свойство "Доступ" определяет связи этого параметра функции с физическим уровнем. Предусмотрены следующие варианты этого свойства:
- константа - устанавливается только на уровне шаблона;
- публичная константа - устанавливается на уровне параметра, пользователем;
- Связь - связь на атрибут параметра физического уровня.
Поле "Значение" описывает значение для констант и предпочитаемый атрибут параметра для связей. Описание предпочитаемого атрибута параметра, для связей, используется в целях описания неявного распределения атрибутов параметров. Структура описания следующая: <Описание параметра>|<атрибут>. Где "Описание параметра" используется для объединения параметров и помещения на форму конфигурации, а атрибут для автоматического связывания при назначении параметра.
5 Реализация
В процессе реализации были созданы все компоненты, а также сценарии конфигурации, интерфейса управления, для них. Формы конфигурации подсистемы "Параметры" приведены на рис. 4. и рис. 5. Формы конфигурации шаблонов параметров приведены на рис. 6 и рис. 7. Формы конфигурации параметров логического уровня приведены на рис. 8, рис. 9 и рис.10.
6 Замечания
- В процессе реализации остался не решен вопрос производительности. Проблема заключается в том, что для адресации атрибутов используется строковый идентификатор, причём как при обращении к атрибутам параметра, так и в процессе вычисления кадра значений функцией шаблона. В результате этого, общее время вычисления и доступа оказывается значительным!
- В процессе использования логического уровня параметров появилась мысль задействовать разработанные механизмы на физическом уровне отдельных источников данных. Например, эти механизмы можно использовать в источнике данных контроллеров S7 для формирования параметров требуемой структуры. Отличием от логического уровня параметров буде только иной смысл связей, так они будут описывать блоки данных и смещения в них.
- В последствии практического использования и соображений выше было выполнено упразднение подсистемы логического уровня параметров, как отдельной сущности, а её механизмы, в составе шаблонов параметров и параметров логического уровня, были перемещены в подсистему "DAQ" (шаблоны параметров) и в отдельные модули (параметры логического уровня). Таким образом, стало возможным включение механизмов формирования параметров по шаблону в любой модуль источника данных.
- Реализован механизм полного описания шаблона в нем самом. Теперь не нужно отдельно формировать функции для объектной модели.
Рис. 4. Подсистема "Параметры": Параметры
Рис. 5. Подсистема "Параметры": Шаблоны
Рис. 6. Шаблон: Общая информация
Рис. 7. Шаблон: Конфигурация
Рис. 8. Параметр: Общая информация
Рис. 9. Параметр: Атрибуты
Рис. 10. Параметр: Конфигурация шаблона
Ссылки