QO: BOOL
This qualifier output is used to indicate whether the service has been successfully completed for any input event. For example, following an initialisation INIT event, a ‘true’ value would indicate a successful start-up; ‘false’ would indicate that the service has failed to be initialised.
STATUS: ANY
This output can be set with any of the input events and is used to provide the status from processing the last input event. For example, Status will be set when a service is initialised using the INIT event and has been unsuccessful. Similarly when a REQ event used to transmit values to a remote device is processed and subsequently fails, Status is used to hold the reason for the failure.
RD_1, ..., RD_N: ANY
indications. As with the SD_1 ... SD_N inputs, the number of these outputs and their data types will be specific to the type of service being provided.
For eample, consider when a request has been made to read, say, the values from a set of 10 input points—an IND indication event will occur when the service has received the values from the I/O sub-system; their values will be available on a set of RD_1...RD_10 outputs.
Figure 4.1 depicts two SI function blocks that are given as examples in the IEC 61499 standard. These blocks are still ‘generic’ in the sense that they have not been given a specific number of inputs and outputs. Data types of inputs and outputs are also defined using the keyword ANY. In other words, these are outline templates for type definitions. Further specific details and data types will be required to use these in a particular application domain.
The Requester SI function block provides a communications service to obtain data from a remote resource. The PARAMS input is used to specify the communica- tions address and other details; inputs SD_1 to SD_m provide parameters for a request, e.g. by sending a request command string and arguments. The RD_1 to RD_n outputs are used for the response data received from the remote resource and will arrive when the block issues a confirmation CNF output event.
The Responder SI function block, in effect, provides the other end of the commu- nications. It receives requests arriving from a remote resource and creates an indication IND event and output data on RD_1 to RD_n to indicate that a remote
Figure 4.1 Requester, Responder SI function blocks
REQUESTER Service Interface function block
data request has been received. The response to the request can be returned, by writing the data to the Responder inputs SD_1 to SD_m and triggering an event at the response RSP event input. This data will then be sent by the communications system back to the originating Requester block where it will be received and in turn trigger a confirmation CNF output event with data, as already discussed.
Together, the Requester and Responder SI function blocks can be used to exchange data between two resources linked by some form of communications or networking facility. The Requester block provides a service for what IEC 61499 calls an “application-initiated interaction”; in other words, the request for external data is triggered by an event generated within an application.
In contrast, the Responder block provides a service for a “resource-initiated interaction”. The request for data arrives from an external resource and results in an indication IND event being produced. In this case, the application will need to react to an event that can occur at any time.
Figure 4.2 shows two further examples of SI function blocks; IO_Writer is used to write values to physical outputs while IO_Reader is provided to read in values from selected physical inputs. Both function in a similar manner.
Let us consider how the IO_Writer block could be used. An application will require at least one instance of this block to write values out to physical outputs.
Figure 4.2 IO_Writer, IO_Reader SI function blocks IO_READER Service Interface function block
To set up the service, the application must first send an INIT event with QI input set to ‘true’ and the PARAMS input set to identify characteristics of the service. The PARAMS input could contain details, such as ‘write’ update rates, number of retries on failure and so on. Thereafter, data can be sent to the selected output by setting the input SD_1 to an output address, e.g. rack, channel and I/O point and setting the new value to input SD_2. The write is initiated by an event at event input REQ .
Some time later when the hardware I/O system has completed the write operation, an output event CNF will occur to confirm that the ‘write’ has been completed. The output STATUS provides an indication of whether the operation has been successful. If the operation has failed, STATUS will contain an appropriate error code. The output RD_1 provides a feedback of the value as read from the output device. This can be used to confirm that the write has been successful.
The IO_Reader block performs in a very similar manner. After initialising the service using the INIT event, with the QI and PARAMS inputs, the value of any physical input can be read by setting the IO address at input SD_1 and sending an event to event input REQ . Some time later, when the data has been read from the input sensor, a confirmation event will occur at output event CNF. The success of the read operation will be indicated by the value of output STATUS and, if success- ful, the value read from the input will be available on output RD_1.
IO_WRITER and IO_READER are fairly simple forms of SI blocks for accessing hardware I/O. However, more complex blocks could be considered to model facilities to read and write, say, multiple values for many I/O points in one operation.
Note that the time taken between issuing a request by triggering a REQ event and receiving the confirmation event CNF will depend on many factors such as: • the loading of the resource scheduling system
• the speed of the device operating system in responding to the request from the resource
• the time to transmit a request to the physical I/O point.