| As described above, the OSACA communication system
allows the transparent exchange of information between client and server applications. In
order to enable an unequivocal interpretation and use of the exchanged data additional
definitions are required. These definitions cover first the logical classification
of functionality in so-called functional units, which in most cases are identical to the
Architecture Objects (AO). Examples of functional units are: Man Machine Control (MMC),
Logic Control (LC), Motion Control (MC) and Axis Control (AC). Second,
for each of the identified units the functionality and behaviour for external modules has
to be described. This is done by using communication objects which form the data interface
and the process interface of an application module.
The data interface provides the read and write access to data
located inside an AO. The access is enabled by the use of communication objects of the CO
class "variable". Each internal variable, which should be accessible by the
outside environment, must be mapped to an instance of that CO class. The couple of the
internal variable and the CO is called attribute of the AO. From the outside these
attributes can be accessed by calling appropriate services of the communication system.
The process interface defines the dynamic behaviour of an
application module. It allows to trigger and control the functionality which is provided
by an AO. The call to an internal function is initiated by an "action" service
via the communication system to the corresponding CO of the class "process". To
bring the functions into a logical relationship with necessary preconditions state
machines are used. The figure below gives an overview on a subset of communication objects
that are defined for the AO "Motion Control".
The decription of the single COs is done by using formal templates.
With these templates all the necessary information is provided to implement and use the
specific communication objects in the different AOs.
|
