Module <UserProtocol> of subsystem “Protocols”
Русская версия
Українська версія?
| Module: | UserProtocol |
| Name: | User protocol |
| Type: | Protocol |
| Source: | prot_UserProtocol.so |
| Version: | 0.5.0 |
| Author: | Roman Savochenko |
| Translated: | Maxim Lysenko |
| Description: | Allows you to create your own user protocols on any OpenSCADA's language. |
| License: | GPL |
Introduction
Module UserProtocol of the transport protocol is made to provide the user with the possibility of creation the implementations of different protocols by himself at one of the internal languages of OpenSCADA, usually JavaLikeCalc, without necessity of low-level programming of OpenSCADA.
The main purpose of the module is to simplify the task of connecting to the OpenSCADA system devices of data sources, that have limited distribution and/or provide access to their own data on a specific protocol that is usually fairly simple to implement in the internal language of OpenSCADA. For implementation of this the mechanism for the formation of the outgoing request protocol is provided.
In addition to the mechanism of the outgoing request protocol the mechanism for incoming request protocol is provided, which allows OpenSCADA to process the requests for data get on specific protocols, which simply can be implemented in the internal language of OpenSCADA.
The module provides the ability to create multiple implementations of different protocols in the object "User protocol" (Fig. 1).
Fig.1. The main tab of the object "User protocol".
The main tab contains the basic settings of the user protocol:
- Section "Status" - contains properties that characterize the status of the protocol:
- Status - current status of the protocol.
- Enable - the protocol's status "Enabled".
- DB - DB that stores configuration.
- Section "Config" - directly contains the configuration fields:
- ID - information on the protocol's identifier.
- Name - specifies the name of the protocol.
- Description - brief description of the protocol and its purpose.
- To enable - indicates the status "Enable", in which to transfer the protocol at startup.
1. Part of the protocol for incoming requests
Protocol of incoming requests is working in cooperation with the incoming transport and the separate object "User Protocol" is set in the configuration field of transport protocol, together with the UserProtocol module's name. In the future, all requests to the transport will be sent to the processing procedure of the protocol's request (Fig. 2).
Fig.2. Tab of the processing procedures of the incoming requests.
Tab of the processing procedures of the incoming request contains the field for selecting the internal programming language of OpenSCADA and the text entry field for the typing the processing procedure.
For the processing procedure the following exchange variables with incoming traffic are predetermined:
- rez - processing result (false-full request;true-not full request);
- request - request message;
- answer - answer message;
- sender - request sender.
Общий сценарий обработки входящих запросов:
- Запрос формируется удалённой станцией и через сеть попадает на транспорт OpenSCADA.
- OpenSCADA транспорт передаёт запрос, выбранному в поле протокола, модулю UserProtocol и объекту пользовательского протокола в виде значений переменной "request" - для блока запроса и "sender" - для адреса отправителя запроса.
- Запускается выполнение процедуры протокола входящего запроса, в процессе которой анализируется содержимое переменной "request" и формируется ответ в переменной "answer". По окончанию выполнения процедуры формируется переменная "rez", которая указывает транспорту на факт получения полноценного запроса и формирование корректного ответа (false) или необходимость транспорту ожидать оставшихся данных (true).
- Если в результате процедуры обработки переменная "rez" равна 'false' и ответ в переменной "answer" не нулевой, то транспорт отправляет ответ и обнуляет накопление "request".
- Если в результате процедуры обработки переменная "rez" равна 'true' то транспорт продолжает ожидать данные. При получении следующей порции данных они добавляются к переменной "request" и выполнение процедуры повторяется.
2. Часть протокола для исходящих запросов
Протокол исходящих запросов работает в кооперации с исходящим транспортом и отдельным объектом "Пользовательского протокола". Источником запроса через протокол может выступать функция общесистемного API пользовательского программирования исходящего транспорта int messIO( XMLNodeObj req, string prt );, в параметрах которой указывается:
- req - запрос в виде дерева XML со структурой соответствующей входному формату реализованного протокола;
- prt - имя модуля "UserProtocol".
Запрос отправленный вышеуказанным образом направляться в процедуру обработки запроса протокола (рис.3) с идентификатором пользовательского протокола указываемым в атрибуте req.attr("ProtIt").
Рис.3. Вкладка процедуры обслуживания исходящих запросов.
Вкладка процедуры обработки исходящих запросов содержит поле для выбора внутреннего языка программирования OpenSCADA и поле ввода текста процедуры обработки.
Для процедуры обработки предопределены следующие переменные обмена:
- io - XML узел обмена с клиентом, через который протокол принимает запросы и в который помещает результат с форматом реализуемым в процедуре;
- tr - объект транспорта, предназначен для вызова функции транспорта string messIO( string mess, real timeOut = 1000 ); "tr.messIO(req)".
Общий сценарий формирования исходящего запроса:
- Формирование XML-дерева в соответствии со структурой реализуемой протоколом и указание идентификатора пользовательского протокола в атрибуте "ProtIt".
- Отправка запроса к транспорту через протокол SYS.Transport["Modul"]["OutTransp"].messIO(req,"UserProtocol");.
- Выбор пользовательского интерфейса в соответствии с req.attr("ProtIt") и инициализация переменных исходящего транспорта io - соответственно к первому аргументу messIO() и tr - объект "OutTransp".
- Вызов процедуры на исполнение, которая обработав структуру "io" формирует прямой запрос транспорту tr.messIO(req);, результат которого обрабатывается и помещается назад в io.
Суть выделения протокольной части кода в процедуру пользовательского протокола заключается в упрощении интерфейса клиентского обмена при многократном использовании и предпологает формирование структуры XML-узла обмена в виде атрибутов адресов удалённых станций, адресов читаемых и записываемых переменных, а также значений самих переменных. При этом весь груз непосредственного кодирования запроса и декодирования ответа возлагается на процедуру пользовательского протокола.
Ссылки