Image Processing Reference
In-Depth Information
20.5.5 Communication Paradigms
It was stated before that there are many diverse types of traffic to be considered in fieldbus systems,
andtherearemanydiferentservicesthataieldbusshouldprovidetotheuserapplication.Apartfrom
basic functions like reading and writing variables, management of objects is required. his includes
updates of device configurations, starting and stopping tasks running on nodes, up- or downloading
of programs, triggering and synchronization of events, establishment and termination of connections
between nodes, access control to node data, to name just of few. In general terms, fieldbus services
need to handle objects by identifying them, the actions to be performed on them, as well as the
appropriate parameters for the actions. These services must be defined and provided by the upper
layers of the protocol stack, in most cases by the application layer.
Communication and cooperation between different application layers and applications in a field-
bus system are based on a basic set of two or three different models []. These models again
represent different philosophies of the type of information that is exchanged between two or more
entities. One approach is to build the cooperation on actions or functions into which a more complex
process is decomposed. The responsibility for interpretation of the information is largely concen-
trated on the sender's side. his is the philosophy behind the client-server model. he other approach
is a data-oriented one. Here, not actions but data are exchanged, and the responsibility for their inter-
pretation is with the receiver (which then might take according actions). This is the idea behind
the publisher-subscriber model and the producer-consumer model. he most relevant properties of
thesethreearesummedupinTable..
The overview shows that communication paradigms need to be supported by the medium access
mechanism of the data link layer to achieve optimal performance.
20.5.5.1 Client-Server Model
In the client-server paradigm, two entities cooperate in the information exchange. The entity pro-
viding a service or data is called server, the one requesting the service is called client. In general, the
server may become active only upon request from the client, which means that this model is better
suited for state-based data traffic handled in some scheduled manner. Events, i.e., spontaneous traf-
fic, can be handled only if they occur at the client (which may solely initiate communication). If they
occur at the server, they cannot be handled in a spontaneous way at all; the server has to postpone
the transmission until it receives an appropriate request from the client.
Client-server communication is based on confirmed services with appropriate service primi-
tives (request, indication, response, confirm) as defined in the OSI model (Figure ., left side).
This is the classical implementation used by many fieldbus systems which derive their application
layer protocols essentially from the MMS standard. Examples are PROFIBUS-FMS (DP and PA in
reduced form as well), WorldFIP, INTERBUS, or P-NET. he MMS model proposed comprehensive
services that are usually only partly implemented in the fieldbus application layers. For the example
TABLE .
Properties of Communication Paradigms
Client-Server
Producer-Consumer
Publisher-Subscriber
Model
Model
Model
Communication
relation
Peer-to-peer
Broadcast
Multicast
Communication type
Connection oriented
Connectionless
Connectionless
Master-slave relation
Monomaster, multi-master
Multi-master
Multi-master
Communication
service
Confirmed, unconfirmed,
acknowledged
Unconfirmed,
acknowledged
Unconfirmed, acknowledged
Application classes
State changes, event-oriented
signal sources (e.g., switches)
Source:
Sauter, T., in
TheIndustrialCommunicationHandbook
,CRCPress,BocaRaton,FL,,.-..(Withpermission.)
Parameter transfer, cyclic
communication
Event notification, alarms,
error, synchronization
