Measurement-Bus

Short Description of the Application Services according to

DIN 66348-3

The OSI-layers 1 and 2 for the Measurement Bus described in DIN 66348 Part 2 were laying down until now, how data is read or written by the master, in which way the bus is accessed, and how the safety of the data transmission is ensured.

The content of a protocol data unit is laid down there only by its start- and end-characters:

<STX>

Content: 0 - 128 Byte

<ETX>

<BCC>

In Part 3 of the series of standards DIN 66348, the 'services' are described now, which are required for the communication between two devices on the application layer.

It is now to be described as a short overview, which services this standard makes available, how the communication between two application-processes takes place, and how the corresponding protocol data units (PDU) are constructed

The 'Manufacturing Message Specification' MMS (ISO 9506-1/-2), internationally standardized since 1990, is the basis for the application services of the Measurement Bus. It provides a so-called client-server-communication, i.e. an application association exists independently from the actual way of data transport between two bus-participants. One (the requesting user) of the two requests a service (e.g. Read), which the other participant in this association executes (as responding user). Figure 1 shows this basic structure.

A Request-PDU, a Response-PDU and an Error-PDU are thus described for each of the individual application services. Besides these 'confirmed' services, there are several 'unconfirmed' services, e.g. for status reports or exceeding of limits.

The establishment of an application association by an Initiate (services: Initiate, Conclude, Abort) is requirement for the exchange of PDUs. By allocating a connection identifier with two digits (CI1, CI2), connecting exactly two systemwide definite application-processes logically with each other, all following PDUs are assigned definitely to two participants in any net (bus, tree); only the bus-management (e.g. the master or the sub-masters for the DIN- Measurement Bus) need to know the hardware addresses of the devices involved. New participants may obtain the connection identifier for an intended association from the management-station above (service: LLI - Connection - Identifier). Therefore, the content of a PDU according to DIN 66348-3 with its provided start- and end-characters looks like:

<DC4>

VN1 VN2

<DC2>

Application Protocol Data Unit

<FS>

Each protocol data unit (PDU) is determined by a PDU-Type and - depending on the kind of PDU - by several parameter, each of them described in a table in the standard.

The considerable extent of the MMS-standard has been reduced heavily for DIN 66348-3, the descriptions of the service parameter and PDUs have been combined, a description of the service procedure explains the functional connection. Only ASCII-characters are transmitted, so that maintenance and search for errors are easy with a simple character monitor.

29 services have been chosen altogether, which are especially important and suitable for measuring and testing applications. Tables 1 and 2 show these services.

Basic PDU-Type PT
RequestPDU
Confirmed- ResponsePDU
ErrorPDU
<0>
<1>
<2>
Unconfirmed-PDU <3>
RejectPDU <4>
RequestPDU
Cancel - ResponsePDU
ErrorPDU
<5>
<6>
<7>
RequestPDU
Initiate - ResponsePDU
ErrorPDU
<8>
<9>
<A>
RequestPDU
Conclude - ResponsePDU
ErrorPDU
<B>
<C>
<D>
AbortPDU <E>

Table 1: Basic PDU-Types (PT = PDU-Type)


Confirmed Application Service ST1 ST2
Status
GetNameList
Identify
<0>
<0>
<0>
<0>
<1>
<2>
Read
Write
DefineNamedVariableList
DeleteNamedVariableList
<0>
<0>
<0>
<0>
<4>
<5>
<B>
<D>
InitiateDownloadSequence
DownloadSegment
TerminateDownloadSegment
InitiateUploadSequence
UploadSegment
TerminateUploadSegment
DeleteDomain
<1>
<1>
<1>
<1>
<1>
<1>
<2>
<A>
<B>
<C>
<D>
<E>
<F>
<4>
CreatePrograminvocation
DeletePrograminvocation
Start
Stop
Resume
Reset
Kill
<2>
<2>
<2>
<2>
<2>
<2>
<2>
<6>
<7>
<8>
<9>
<A>
<B>
<C>
TriggerEvent <3> <4>

Table 2 : Confirmed Application Services (ST1 and ST2 : Service Types)

The Basic PDU-types are used for the environment (3 services), reject and the report of events (2 services), and the program management (2 services). They are indicated in the PDU only with one ASCII-character 'PT'.

It is to be distinguished, whether individual services shall be implemented in the role as requesting and/or responding user, since this affects the future usability of the device.

Only the services

- Initiate (as responding user)

- Abort (as sending and receiving user)

- Reject (as sending and receiving user)

- Identify (as responding user for the service

execution)

are laid down as compulsory services.

The chosen application services are given in table 2 with the corresponding Service Types ST1 and ST2. The PT of the Confirmed PDU is always preceding these application services as basic PDU-type, i.e. each application service knows a Request-, Response- and Error-PDU.

The application services can be divided into the five groups: the general management services, the variable access services, the domain management services, the program invocation management services and the event management services.

A simple measuring instrument for example, will need only the service Read apart from the compulsory service Identify, a device with loadable measuring programs will also need the domain management services, and a device with controllable program flows will contain services from the group of program invocation management service in addition. It is up to the user to which extent he implements the provided services and whether he wants to support each of them in the role as requesting user, as responding user or in both of them. The number of services that can be executed at the same time may vary between 1 and 63; this number is being exchanged between the peers at the Initiate.

Below, the actual structure of some PDUs is to be described with examples, making clear that the description of the service primitive and service parameter, first appearing rather complicated, leads to relatively simple and, above all, short PDUs. At the same time, this structure is so powerful that even long variable lists or extensive files can be transmitted trouble-free.

First of all, an association between the two application processes with the two systemwide valid names 'P1' and 'P2' is to be established. 'P1' may be the requesting user. The number '1' (coded as '@A') is given as connection identifier in the requesting user, the number of outstanding services (coded as ASCII-character of the decimal value + 64) may be requested as '4' and '3', respectively, and answered with '2' and '1', respectively. '66348.3/V100' is the given 'Version', stored in the responding user. Therefore the RequestPDU for the Initiate is:

DC4 @A DC2 8 P2 US P1 US D C FS

in which the characters DC4, DC2, US and FS are represented as one character according to the IBM-character set on a PC-screen (e.g.DC4 = ¶).

The ResponsePDU when accepting the Initate-Request is:

DC4 @A DC2 9 B A 66348.3/V100 FS

An Initiate is only to be done once, e.g. when switching on the system or connecting a new device, and is valid until the Conclude or Abort, which can be triggered by both peers.

Next, 'P1' is to request an Identify as requesting user from device 'P2', the consecutive Invoke Identifier preceding each confirmed service shall be '1' (coded as 'A'):

DC4 @A DC2 0 A 0 2 FS

The responding user answers with Vendor Name ('Measurement Ltd'), Model Name ('Transducer 4711') and Revision ('SW-Rev.08-15'), using the same InvokeID:

DC4 @A DC2 1 A 0 2 Measurement Ltd US Transducer 4711 US SW-Rev.08-15 FS

Assuming the Variable Names of 'P2' are known to 'P1' (or 'P1' has inquired the names of all Variables of 'P2' with the service GetNameList), 'P1' asks its peer now (with the InvokeID '2', coded as 'B') to transmit the content of Variable 'Var_1'. The RequestPDU for this service to Read Variables (for one or more Variables or Variable Lists, of which the names and compilation can be agreed and deleted) is (with some data type- and access-parameter described in the standard in more detail):

DC4 @A DC2 0 B 0 4 0 0 Var_1 FS

This Variable in the device 'P2' may have the value '23.64 mm' and the data type 'visible string' (coded by the Data Type 'A'). Then the Response is:

DC4 @A DC2 1 B 0 4 A 23.64 mm FS

There is also the possibility to transmit events, like exceeding a limit, unsolicitedly from device 'P2' to device 'P1' with an Unconfirmed-PDU by means of the InformationReport. This may be done as a boolean for the state of a measuring channel, as measurement, as text output to be shown on a display, or in any other permitted form of data for one or more Variables; by previously writing a provided switch variable, this report service can be 'programmed' freely for events, conditions or regular reports. The Unconfirmed-PDU for the case of a temperature measurement '81.2 deg' in 'Var_2', which is stored in a Domain called 'Domain1', is:

DC4 @A DC2 3 0 0 1 Domain1 US Var_2 GS A 81.2 deg FS

As an example for an ErrorPDU, it may be assumed that the peer 'P1' has no right to Read the Variable 'Var_1' in device 'P2'. Then, 'P2' sends, instead of the Response with the Access Result, the ErrorPDU:

DC4 @A DC2 2 B 7 3 FS

The evaluation of the error statements reveals: Error Class 7 indicates an access problem, Error Code 3 means that the access to an object has been denied due to missing access rights.

The association should be concluded orderly before switching off a peer so that outstanding or partly executed services do not remain in a peer. This takes place with the Request for a Conclude using the agreed connection identifier:

DC4 @A DC2 B FS

The Response is:

DC4 @A DC2 C FS

'P1' and 'P2' have in principle equal rights in their application association after the Initiate, i.e. 'P2' can also Read or Write Variables at 'P1' or request other services, if this ability (for services as requesting user and responding user) is implemented in 'P2' and is required by the application-process. It may be provided as well that an application-process has connections with several other processes. Each of them are managed and dealt with separately.


Carsten Sperlich
Dr. Wagner

9.3.98