Module <UserProtocol> of subsystem “Protocols”

Ðóññêàÿ âåðñèÿ
Óêðà¿íñüêà âåðñ³ÿ?

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.

The overall scenario of processing of the incoming requests:

• Request is formed by the remote station and through the network it gets on the transport of OpenSCADA.
• OpenSCADA transport sends the request to the selected in the protocol's field UserProtocol module and to the objects of the user's protocol in the form of the variable's "request" values - for the block of the request and "sender" - for the sender address of the request.
• The execution of the the procedure of protocol of the incoming request is started, during which the contents of the variable "request" is analyzed and the response in the variable "answer" is formed. At the end of the procedure's execution the variable "rez" is formed, which indicates the transport to the fact of reception of full request and the formation of the correct answer (false) or to the necessity for the transport to expect for the remaining data (true).
• If the result of the processing procedure is the variable "rez" with the 'false' and the response in the variable "answer" is not zero, then the transport sends the response and reset the accumulation of "request".
• If the result of the processing procedure is the variable "rez" with 'true' then the transport continues to expect for the data. When it receives the next portion of data they are added to the variable "request" and this procedure is repeated.

2. Part of the protocol for outgoing requests

The protocol of outgoing requests is working in cooperation with the outgoing transport and with the separate object of the "User Protocol". The source of the request through the protocol may be a function of the system-wide API of the user programming of the outgoing transport int messIO(XMLNodeObj req, string prt );, in the parameters of which it must be specified:

• req - request as an XML tree with the structure corresponding to the input format of the implemented protocol;
• prt - the name of the "UserProtocol" module.

The request which is sent with the aforesaid way is directed to the processing procedure of the protocol's request (Fig. 3) with the user protocol's ID which is specified in the attribute req.attr( "ProtIt").

Fig.3. Tab of the processing procedures of the outgoing requests.

Âêëàäêà ïðîöåäóðû îáðàáîòêè èñõîäÿùèõ çàïðîñîâ ñîäåðæèò ïîëå äëÿ âûáîðà âíóòðåííåãî ÿçûêà ïðîãðàììèðîâàíèÿ 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-óçëà îáìåíà â âèäå àòðèáóòîâ àäðåñîâ óäàë¸ííûõ ñòàíöèé, àäðåñîâ ÷èòàåìûõ è çàïèñûâàåìûõ ïåðåìåííûõ, à òàêæå çíà÷åíèé ñàìèõ ïåðåìåííûõ. Ïðè ýòîì âåñü ãðóç íåïîñðåäñòâåííîãî êîäèðîâàíèÿ çàïðîñà è äåêîäèðîâàíèÿ îòâåòà âîçëàãàåòñÿ íà ïðîöåäóðó ïîëüçîâàòåëüñêîãî ïðîòîêîëà.

Ññûëêè