Image Processing Reference
In-Depth Information
1
Local service user
4
Remote service user
2
3
(N)_service.req
(N)_service.con
(N)_service.res
(N)_service.ind
Local layer N
Remote layer N
(N - 1)_service.req
(N - 1)_service.ind
(N - 1)_service.req
(N - 1)_service.ind
Local service provider
Remote service provider
FIGURE .
Answered service.
side. From the indication, layer N can conclude whether or not the service requested by
layer N
was executed without error. If necessary (i.e., if errors have occurred), this ser-
vice is used again. his depends on the protocol used in layer N. In all cases, the service
user is informed of the output with a suitable confirmation (positive or negative). From
this confirmation, it is possible to derive whether or not the originally requested service
has satisfactorily been fulfilled by layer N.
.
Answered service
. This represents the fully fledged use case of all service primitives
(Figure .). Here, after an indication on the partner side, a response is generated by
the remote service user. he response is transmitted via a service primitive of layer N
−
andpassedonasaconirmationtotheserviceuserfromwhichtheoriginalservice
request came. This mechanism permits data traffic in both directions. Contrary to the
other two services, an answered service always consists of request, indication, response,
and confirmation.
−
In short, request and response are always called up by the service user, the resulting confirmation
and indication originate from the corresponding layer. he interaction between the individual layers
is best understood if one imagines that the layers lying on top of one another are primarily inactive.
The service provider is only “awoken” after a request from the service user. To perform this service, it
in turn activates the underlying layer by calling up the appropriate service primitive. his interaction
continues down to the lowest layer, which then accesses the transmission medium. On the remote
side, the indication of a low lying layer informs the layer lying directly above that a service is to be
executed. This indication is then processed in accordance with the service type—it causes either a
confirmation or a response.
20.4.3 Quality-of-Service Parameters
Fieldbus systems are to a large extent concerned with process control. The respective data are thus
in many cases critical in terms of timing, security, reliability, or the like. This in turn means that
the network has to provide services that take this criticality into account. In other words, network
services must have a certain quality. The network behavior can therefore be described by so-called
quality-of-service (QoS) parameters. The origin of QoS definitions was the usage of the Internet
to transport multimedia services, specifically the difficulty of using a packet-switched, statistical
multiplexing network to transmit stream-based data that normally require directly switched con-
nections. In automation systems, the situation is quite comparable. Formerly direct connections are
