The architectural

reference model (ARM)

The architectural reference model is drawn from the proposal of the international standard IEC 1499: Function Blocks for Industrial-Process Measurement and Control Systems [IEC1499D]. It is based on a fundamental module, the function block (FB), which represents a functional unit of software. Following the object-oriented approach, the FB can be sketched as shown in Fig. 2 [CARFER98][MAFFER98]

A FB instance is characterised by the following elements (the definitions are taken from the IEC standard):

· its type name and instance name;

· a set of event inputs, each of which can receive events from an event connection, which may affect the execution of one or more algorithms;

· a set of event outputs, each of which can issue events to an event connection, depending on the execution of algorithms;

· a set of data inputs, which may be mapped to corresponding input variables;

· a set of data outputs, which may be mapped to corresponding output variables;

· internal data, which may be mapped to a set of internal variables;

· an execution control chart (ECC), consisting of states, transitions and actions, which invokes the execution of algorithms in response to event inputs;

· a set of algorithms, associated with the execution control states.

 

The algorithms contained within a FB are, in principle, invisible from the outside of the FB. Additionally, the FB may contain internal variables or state information or both, which persist between invocations of the FB algorithms, but which are invisible from the outside of the FB.

The execution of algorithms is invoked by the ECC (which is basically a Moore automaton) of a FB instance, in response to event inputs. This invocation takes the form of a request to the scheduling function of the associated resource to schedule the execution of the algorithm's operations. Upon completion of execution of an algorithm, the execution control part generates zero or more event outputs as appropriate.

Three kinds of FBs are defined by the IEC 1499 standard: basic FBs, where the execution control is specified by the ECC, and the algorithms to be executed are specified using appropriate extensions to the means specified in the IEC 1131-3; composite FBs, where algorithms and their execution control are specified through event and data connections in one or more FB diagrams; and service interface FBs, whose external interfaces have the same general appearance as basic FBs, however, the inputs and outputs of these FBs have specialised semantics, since these FBs provide one or more services to an application, through the mapping of service primitives to the FB event inputs, event outputs, data inputs and data outputs.

As for the event connection among FBs, the IEC standard does not provide sufficiently rigorous information for formal modelling and analysis. Thus, the following hypotheses are made [1]. If an event occurs while the receiving FB is executing an algorithm, then the information related to that event is stored in appropriate variables, in order to be used immediately after the end of the execution of the current algorithm. In addition, the information related to events may be stored in a (theoretically) infinite buffer (buffered-event connection), or in a buffer with a unitary capacity, and with the overwrite of events (overwrite-event connection).

By properly connecting more FBs an application is defined, which is a software functional unit consisting of a network whose nodes are function blocks, and whose branches are data connections and event connections (Fig. 3).

An application specifies the operations to be performed on variables, as a consequence of events. The consequence of performing such operations may include the generation of additional events, as well as the modification of the values of variables. Applications are here defined by FB diagrams specifying event and data flows among FB instances. The event flow determines the scheduling and execution (by the associated resource) of the operations specified by each FB algorithm(s).

As regards the configuration, an application can be distributed among several control system devices. The part of an application which is implemented on the same control system device, is here defined an application module. A device uses the causal relationship specified by the application to determine the appropriate responses to events, which may include communication and process events. These responses may include: scheduling and performance of operations, modification of variables, generation of additional events, and interactions with communication and process interfaces. The model for a control system device is depicted in Fig. 4.

A device must contain a process interface, which provides a mapping between the physical process and the applications. Information exchanged with the physical process is presented to the applications as process data or process events, or both. Moreover, communication interfaces provide a mapping between devices and the information exchanged via a communication network. Services provided by communication interfaces may include: presentation of communicated information to the device as communication data or communication events, or both; additional services to support programming, configuration, diagnostics, etc.

With the given definitions the architecture of an industrial process control system can be modelled as a collection of devices interconnected and communicating with one another by means of one or more communication networks. While the functions performed by the control system are modelled as applications.

Back to Index ---- Last update : 22 Jan 1998 ---- Creator : Roberto Fabbri