Web function block in automation equipment

ES 2 339 741 T3

DESCRIPTION

WEB function block in an automation equipment.

The present invention refers to a communication system of an automation equipment in a global network of the Internet, Intranet or Extranet type, which allows implementing a WEB server function and a WEB client function within an automation application, thanks to at least one WEB function block that can interact with the automation application program. The present invention also refers to an automation equipment that integrates said communication system as well as a programming station capable of parameterizing WEB function blocks. This communication system can be applied to any application pertaining to the field of industrial automation, building automation or the control / drive of electrical distribution networks.

Under the term "automation equipment", a programmable automaton, a control / drive station, a digital control or any equipment that can contain and develop a user program that controls an automation application will be designated below. This user program, also called an application program, is in charge of controlling and activating an automation application by means of, in particular, inputs / outputs controlled by this application program. It is prepared by a designer and is written in one or more graphical automation languages ​​that particularly integrate ladder diagrams (Ladder language), functional diagrams in sequence (Sequential Function Chart or Grafcet language), function blocks (Function Block Description) or in IL (Instruction List) or ST (Structured Text) type automation textual languages. These automation languages ​​are advantageously compliant with the IEC1131-3 standard, in order to facilitate programming by an automatic designer who does not necessarily master computer languages. They can be used in programming stations that are computer equipment, particularly personal computers of the PC type, connectable with the automation equipment to be programmed.

It is already known that an automation equipment of this type can integrate a WEB server in order to be able to exchange data related to this automation equipment with a distant WEB client, such as a browser, connected to a global network of the Internet type, Intranet o Extranet, conforming to the TCP / IP standard, then called TCP / IP network. These functionalities are particularly described in documents WO99 / ​​63409, WO9913418, US6061603 and US5805442. The data relating to the automation equipment is then compiled and sent by the WEB server, for example in the form of HTML or XML pages. It is also possible for a WEB server implanted in an automation equipment to load a program, generally called Applet, in a WEB client, whose program is developed in the WEB client in order to exchange with the Web server of the automation equipment requests transported by the TCP / IP protocol.

However, these solutions are more oriented to the use of a browser (or browser) and do not allow the designer of an automation application to control the data exchanged on the TCP / IP network. Indeed, the designer does not have the possibility of creating, directly from the application program, a client-server communication on the TCP / IP network.

Now, this functionality would be interesting in some cases, to communicate in a TCP / IP network in order to receive requests or requests from a distant WEB client and respond to these requests, controlling the data exchanged in the TCP / IP network. . Furthermore, it would be interesting if an application program could behave as an active WEB client and be able to send requests and receive data from a distant WEB server. A communication could thus be placed in a TCP / IP network between the application program of an automation equipment and a remote WEB server / WEB client, such as an ERP, to exchange manufacturing orders and reports, for example.

To this end, the invention describes a communication system of an automation equipment in a TCP / IP network that includes exchange means to implement a WEB server function or a WEB client function within an application program of a loaded automation application. in the automation equipment, these exchange means comprising at least one WEB function block that can interact with the application program, This can be written in one or more languages ​​conforming to the IEC1131-3 standard. The communication system comprises at least one reception WEB function block for implementing a WEB server function and / or at least one transmission WEB function block for implementing a WEB client function in an application program.

The communication system also comprises a front HTTP interface in the automation equipment capable of, on the one hand, routing the messages from the TCP / IP network to a reception WEB function block identified by a URL address, and on the other hand the routing of messages from a broadcast WEB function block to a URL address on the TCP / IP network .

The invention also describes an automation equipment that integrates said communication system as well as a programming station that allows a designer of an automation application to view, introduce, delete, modify and parameterize at least one WEB function block integrated into an application program. , in order to implement the communication system described.

Thus, thanks to the present invention, it will also be possible to place a direct communication using the capabilities of the WEB, between the application programs of several remote automation equipment, for example to carry out

ES 2 339 741 T3 manufacturing timing. If this communication is placed in application programs of automation equipment using languages ​​that are regularly used by the designers of these application programs, namely the languages ​​conforming to the IEC1131-3 standard, then this will advantageously allow them to conceive distributed automation applications very easily. in the web.

In the same way, it will now be possible to introduce current automation equipment into a WEB architecture by slightly modifying its application programs.

Other characteristics and advantages will appear in the detailed description that follows with reference to an embodiment given by way of example and represented by the attached drawings in which:

FIG. 1 represents a first example of communication of an automation equipment according to a communication system according to the invention with a client device,

- Figure 2 represents a second communication example in which an automation device communicates with a device that is both client and server,

- figure 3 shows a third example of communication between two automation equipment,

Figures 4 and 5 respectively detail a reception WEB function block and a transmission WEB function block in a representation of the ladder diagram type (LADDER language).

Figure 1 shows an automation equipment 10 that communicates with a device 40 in a TCP / IP network 50. The automation equipment 10 comprises a front HTTP interface 15 and an application program 20. The device 40 comprises a client module 41, which can be a WEB browser, capable of issuing over the TCP / IP network 50 requests conforming to the HTTP protocol, containing a recipient URL address and receiving responses 52 conforming to the HTTP protocol. The content of an HTTP 51 request or an HTTP 52 response can be encoded in different ways, such as for example an XML frame, a URL encoded frame ("URL encoded"), an HTML frame, WML, SOAP or other ASCII formats. or binary.

Figure 2 shows an automation equipment 10 that communicates on the one hand with a WEB client module 31 capable of issuing 50 HTTP requests 51 over the TCP / IP network and receiving HTTP responses 52, and on the other hand with a WEB server module 32 capable of receiving HTTP requests 51 from the TCP / IP network 50 and sending HTTP responses 52. The WEB client 31 and WEB server 32 modules may eventually belong to the same computer 30 connected to the TCP / IP network 50 and comprising, for example, an ERP (Enterprise Resource Planning) application.

Figure 3 shows two automation equipment 10, 10 'that communicate with each other over a TCP / IP network 50. Each automation equipment 10, 10' comprises a front HTTP interface 15, 15 'and an application program 20, 20' .

An application program 20, 20 'is in charge of controlling / activating an automation application by means of inputs / outputs controlled by this application program. It is drawn up by a designer and is written in one or more languages ​​that particularly integrate ladder diagrams (LD), sequence functional diagrams (SFC), instruction lists (IL), structured programming (ST) or function blocks. (BF). These languages ​​are preferably in accordance with the IEC1131-3 standard, in order to facilitate programming by an automatic designer, who does not necessarily master computer languages.

One of the objects of the invention is to integrate in an application program 20 (respectively 20 ') exchange means that allow the designer of the application program to open a communication on the TCP / IP network 50. For this, the communication system described in the The invention comprises at least one WEB function block 21, 22 (respectively 21 ', 22') configurable and which can interact with the application program 20 (respectively 20 ') of an automation equipment 10 (respectively 10'). According to a preferred embodiment, two different types of WEB function blocks can be considered: a first type is called the reception WEB function block 21 (respectively 21 ') and allows implementing a WEB server function in the application program 20 (respectively 20' ) and a second type is called the broadcast WEB function block 22 (respectively 22 ') and allows implementing a WEB client function in the application program 20 (respectively 20').

Thus, thanks to a WEB reception function block 21, the application program 20 of an automation equipment 10 is waiting for an HTTP request 51 that emanates from a WEB client, such as a WEB client module 31, 41 or a block WEB broadcast function 22 'of an application program 20' of an automation equipment 10 ', and forwards an HTTP response 52 to this request 51. Thanks to a transmission WEB function block 22, the application program 20 of an automation equipment 10 can take the initiative to send a request 51 to a WEB server module 32 or to a reception WEB function block 21 'of an application program 20' , and wait for an HTTP response to this request 51.

According to the invention, the WEB function blocks are integrated into the application program 20 which can be written in one or more languages ​​conforming to the IEC1131-3 standard. The WEB function blocks are inspired by the communication function blocks defined in the IEC1131-5 standard, but such WEB function blocks are not

ES 2 339 741 T3 described in the standard. Thus, in Figures 4 and 5, a reception WEB function block 21 and a transmission WEB function block 22 are graphically symbolized with the formalism of a ladder-type language (LADDER Language). They comprise a service or identification number 214, 224 and are provided with input parameters 212, 222 and output parameters 213,223 that are logically connected with elements of the application program 20, such as variables 215, 216, 225, 226. The input parameters 212, 222 correspond to commands or controls given by the application program 20 to the WEB function block 21, 22 and the output parameters 213, 223 correspond to manufacturing reports or results provided by the WEB function block 21, 22 to the application program 20.

With reference to an embodiment shown in figure 4, the input parameters 212 of a reception WEB function block 21 comprise:

- an input of Boolean type RESP ("Respond") which, at the moment of entering the VRAI state, causes the sending of a response 52 to a request 51. In the example of figure 4, this input is connected to a contact of a variable of the application program 20 called SEND ANSWER 215, in such a way that the state of the input RESP of the WEB function block 21 is equal to the state of this variable SEND ANSWER,

- a Boolean input EN_R (“Enable Receive”) which, when in VRAI state, validates the taking into account of the reception of a request by the WEB 21 function block,

- one or more inputs IN_1 to IN_n that contain different parameters that will be forwarded in the response 52 to the WEB client issuing the request 51.

Similarly, the output parameters 213 of a reception WEB function block 21 comprise:

- an output of Boolean type NDR ("New Data Received") which, at the moment of the transition to the VRAI state, signals to the application program 20 that a request 51 has just been received by the WEB 21 function block. Figure 4, this output is connected to the coil of a variable of the application program 20 called REQUEST RECEIVED 216, in such a way that the state of this ReQuEST ReCeIVED variable is equal to the state of the NDR output of the WEB 21 function block,

- an ERROR boolean output that indicates that the WEB 21 function block is wrong,

- an integer output STATUS that provides the last valid state of the WEB 21 function block,

- one or more outputs OUT_1 to OUT_n that are loaded with parameters contained in request 51.

With reference to an embodiment shown in Figure 5, the input parameters 222 of a broadcast WEB function block 22 comprise:

- an input of Boolean type REQ that, at the moment of entering the VRAI state, causes the sending of a request 51. In the example of figure 5, this input is connected to a contact of a variable of the application program 20 called START REQUEST 225, in such a way that the state of the REQ input of the WEB 22 function block is equal to the state of this START REQUEST variable,

- an input of Boolean type R that allows to reinitialize the WEB 22 function block,

- one or more inputs IN_1 to IN_n that contain parameters that will be sent in the request 51 to the recipient WEB server.

Similarly, the output parameters 223 of a broadcast WEB function block 22 comprise:

- an output of Boolean type NDR which, at the moment of entering the VRAI state, signals to the application program 20 that a response 52 to the request 51 has just been received by the WEB function block 22. In the example of figure 5, This output is connected to the coil of a variable of the application program 20 called ANSWER RECEIVED 226, in such a way that the state of this variable ANSWER RECEIVED is equal to the state of the NDR output of the WEB 22 function block,

- an ERROR boolean output that indicates that the WEB 22 function block is wrong,

- an integer output STATUS that provides the last valid state of the WEB 22 function block,

- one or more outputs OUT_1 to OUT_n that are loaded with parameters forwarded by the WEB server in response 52.

A WEB function block 21, 22 comprises a generic program code that is common to each type of WEB function block, in this case reception type WEB function block 21 and transmission type WEB function block 22. A WEB function block 21, 22 comprises also specific configuration data 219, 229, which are for example

ES 2 339 741 T3 stored in its own configuration file for each WEB function block. These configuration data 219, 229 contain in particular:

• the number of the service or identification that occurs, in the case of a receiving WEB function block 21, of relative URL in the automation equipment 10 and that allows any WEB client to identify it and send it a request, • the URL address recipient in the case of a sending WEB function block 22, • the type of HTTP request (called HTTP method) that the WEB function block 21, 22 is capable of sending or receiving (generally of the POST or GET methods, but also of the PUT, DELETE, TRACE, OPTIONS, ...) methods, • the content of the message or the location of an indexed message (for example an HTML page, an XML message, or others) that will be integrated in the response 52 of the reception WEB function block 21, • in the case of the configuration data 229 of a transmission WEB function block 22, means for making a correspondence between, on the one hand, the input parameters IN_1, IN_n of the WEB function block of emission 22 and, on the other hand, of the elements of an HTTP request 51 (headers), of the elements of an XML frame or of an encoded URL frame contained in an HTTP request 51, • in the case of configuration data 229 of a broadcast WEB function block 22, means for making a correspondence between, on the one hand, elements of an HTTP response 52 (headers) or elements of an XML frame contained in an HTTP request 52 and, on the other hand, the output parameters OUT_1, OUT_n of the transmission WEB function block 22, • in the case of the configuration data 219 of a reception WEB function block 21, means for making a correspondence between elements of an HTTP request 51 (headers), elements of an XML frame or an encoded URL frame contained in an HTTP request 51 and, on the other hand, the output parameters OUT_1, OUT_n of the reception WEB function block 21, • in the case of the configuration data 219 of a function block Reception WEB 21, means to make a correspondence between the input parameters IN_1, IN_n of the reception WEB function block 21 and on the other hand elements of an HTTP response 52 (headers) or elements of an XML frame contained in an HTTP request 52, • the format of the frames (called “Content Type”) that a function block WEB will be able to generate or interpret. This aspect is important as this will authorize the taking into account of future developments of the WEB. Indeed, thanks to this parameterization and from stabilized protocols (HTTP and XML), it will be possible to integrate data libraries (XML schemas) in order to implement new evolving protocols.

The means for making a correspondence between the input / output parameters of a function block and the elements of an XML frame, a URL frame or an HTTP request / response are implemented by the function block and may resort to a variable sophistication according to the desired flexibility of use and the complexity of the format to be interpreted.

For a good understanding of the present invention, examples of means for matching are described below. These examples stick to a simple implementation, which corresponds to the case of function blocks capable of accepting only a rigid request format and also producing only a rigid response format. However, the state of the computer technology made it possible to easily produce, from this case, more sophisticated variants both with regard to the conversion formats between the data of the automation equipment and the WEB textual data as well as with regard to the format of the WEB document itself.

To satisfy the four cases mentioned above, the means of making a match are based on two mechanisms:

a) the analysis of an incoming frame (response or request received) to extract from it the output parameters OUT_1, OÜT-n of the function block. This analysis is based on a description of the plot that makes it possible to find the place of the parameters again and, for each parameter, a description of the conversion between the textual format contained in the request and the internal format of the automation equipment. This case applies both to the issuance of a request by a sending WEB function block and to the issuance of a response by a receiving WEB function block.

b) the synthesis of a frame to be sent (request or response to be sent) from the input parameters IN_1, IN-n of the function block. This synthesis also uses two types of elements: a type-frame and substitution rules that allow the value of the parameters to be entered.

ES 2 339 741 T3

The configuration of a given function block therefore comprises two parts specifically assigned to analysis and synthesis.

Example of the conversion description for an incoming request in a reception WEB function block formatted according to the XML language:

<? xml version = l.0? s <! DOCTYPE tagl SYSTEM exemple.dtd "s <sur-veil lances <type s% OUT_1: STRING </ type> <br / s <number_requets% 0'JT_2: INT </ num_requets </ surveillances

At the beginning of the application, the program code of the function block analyzes this description and records the correspondence between the areas of the expected document (inside the tags: <type> and <num_requete>, themselves included in a <surveillance tag >) and the function block parameters.

Upon receipt of the following request:

<? xml version =ⁿl.0?>

<! EOCTYPE tagl SYSTEM exemple.dtd> <Bur-veil lances <typesalarmec / typescbr /> <num_reque tes 5 8 </ num__reque te> </ surveillances the program code of the function block positions the indicated output parameters: OUT_1 = "alarm ", OUT_2 = 58.

Example of the conversion description for the response to be issued in a reception WEB function block:

<? xml version- · '1 0?>

«IDOCTYFE tagl SYSTEM exemple.dtds <notifications <numbers% lN_l: INT </ numbers« contenus «validites% lN_2: BOOL« / validites <message>% IN_3: STRING </ measages </ contenus <code_cemandeurs% IN__4: INT «/ code_demandeurs «num requetes% IN_5: INT <num_recuetes« / notifications

At the beginning of the application, the program code of the function block records this description as well as the locations where the values ​​of the input parameters must be set as well as the address of these input parameters in the memory of the automation equipment.

In the activation of the response by the application program, it converts the input parameters IN_1 to IN_5 and introduces the result of this conversion in the memorized locations and then causes the response to be sent by resorting to a function of the generic part of a function block WEB.

Thus, for current values ​​such as: IN_1 = 2, IN_2 = true, IN_3 = "Alarme temperature", IN_4 = 1234, IN 5 = 58, it is easy to generate the following response document:

<? xml version-.1.0? s ciDOCTYPE tagl SYSTEM exemple.dtds «notifications« number> 2 «/ number>

«Cor.tenus <validitestrue« / validite>

"MeBBagesalarm.e temperature" / messages "/ contenus <code_demandeur> 1234" / code_demandeur>

<num_jrequetes5 8 «r.um_requete>

</ nctif ications

ES 2 339 741 T3

As previously specified, the example is simple but more flexible representations can be used, for example:

- Control of data conversion, for example using the C language formalism (printf and scanf);

- Control of the validity and format of a received document, for example using a parser with SAX or DOM format, or XSL-T;

- Variable generation of a document, using the values ​​of the IN_x input parameters to drive an XSL-T transformation.

The conception of an application program is usually carried out thanks to a programming station that offers in particular all the reading / writing functionalities of an automation application program, loading / unloading in an automation equipment and monitoring / visualization of its development in the automation equipment. One of the advantages of the present invention resides in the fact that the integration of the WEB function blocks in the application program 20 is immediate since the connection of the WEB function blocks with the instructions of the application program 20 is carried out directly with the station programming that allows to write this application program. By means of said programming station, the designer of an application program is therefore capable of viewing, modifying, introducing or deleting WEB function blocks 21, 22 without any other particular knowledge than those that allow him to conceive the application program 20, which It will greatly facilitate the opening of WEB communications in automation applications.

The programming station can directly parameterize the configuration data 219, 229 of the WEB function blocks 21, 22 in text form, making them also easily accessible to the application program designer. It can, for example, be considered that the configuration data 219, 229 are viewable in plain language and modifiable in a specific window, which opens when the designer points to the graphical representation of a WEB function block on the programming station.

Furthermore, the programming station can use preconfigured, memorizable and manipulable WEB function block libraries from the programming station and offer sets of WEB function blocks specialized in a type of content and / or a protocol implemented with the help of HTTP. Examples that can be included in such libraries include: an HTML server function block, a WML server function block, a SOAP client or server function block, etc ... Thus, these libraries facilitate the work of a designer by offering him several preconfigured function blocks, which he can quickly insert and install in his application program.

When a request 51 is received by an automation equipment 10, the HTTP interface 15 of the automation equipment 10 analyzes it and detects whether the recipient URL address contained in the request 51 corresponds to the URL address of a reception WEB function block 21 of the automation equipment 10. If this is the case, the HTTP interface 15 plays the role of the HTTP server performing the routing and signaling to the reception WEB function block 21 the arrival of the request 51. The URL address of the sender of the request 51 is memorized to be in a position to forward the response 52 that will be elaborated by the reception WEB function block 21.

When a request 51 is issued by a WEB broadcast function block 22 of an automation equipment 10, the HTTP interface 15 of this automation equipment plays the role of HTTP client and routes the request to the recipient URL contained in the request 51 .

It is understood that it is possible, without departing from the scope of the invention, to conceive other variants and refinements of detail and even to consider the use of equivalent means.