Measurement bus DIN 66348-3

GERMAN STANDARD Draft April 1995

Interface for Serial Measurement Data Communication

Part 3: Application Services, Messages (Protocol Data Units) and Protocols
(Proposal for a European Standard)

DIN
66348-3

ICS 35.200 / Objections til 31 July 1995

Teil 3: Anwendungsdienste, Telegramme und Protokolle
(Vorschlag für eine Europäische Norm)

Application warning note

This Draft Standard is presented to the public for checking and statement.

Since the intended standard may differ from the version on hand, the use of this proof is to be agreed particularly.

Statements are requested to the Normenausschuß Länge und Gestalt (NLG) im DIN Deutsches Institut für Normung e.V., 10772 Berlin, (address: Burggrafenstr. 6, 10787 Berlin).

Foreword

This Draft Standard has been elaborated in the subcommittee NLG 2.9 "Schnittstellen" (interfaces) of the Normenausschuß Länge und Gestalt (NLG) im DIN Deutsches Institut für Normung e.V. It forms together with DIN 66348-2: 1989-09 a proposal which has been submitted from the German part to the CENELEC/TC 65 CX for inclusion in an European standard about bus-systems for the metrology. In case of the successful conclusion of the discussion in the CENELEC/TC 65 CX, the standard intended with this Draft Standard will probably not be published under the standard number DIN 66348-3 but under a DIN-EN-number.

Normenausschuß Länge und Gestalt (NLG) im DIN Deutsches Institut für Normung e.V.
Deutsche Elektrotechnische Kommission im DIN und VDE (DKE)

Summary of the Contents:


1   Field of Application and Purpose         9
2   Terms and Abbreviations                  10
3   Model of Communication                   14
4   Coding Rules                             24
5   Environment Application Services         40
5.1 Application Service Initiate             40
5.2 Application Service Conclude             45
5.3 Application Service Abort                47
5.4 Application Context                      48
6   Domain Management Application Services   49
6.1 Model of Memory Organization             49
6.2 Download Services                        52
6.3 Upload Services                          63
6.4 Application Service DeleteDomain         72
7   Variable Access Application Services     73
7.1 Application Service
    DefineNamedVariableList                  73
7.2 Application Service 
    DeleteNamedVariableList                  76
7.3 Application Service Read                 80
7.4 Application Service Write                84
7.5 Application Service InformationReport    89
8   Program Invocation Management 
    Application Services                     94
8.1 Model of Program Execution               94
8.2 Application Service 
    CreateProgramInvocation                  95
8.3 Application Service 
    DeleteProgramInvocation                  98
8.4 Application Service Start               100
8.5 Application Service Stop                102
8.6 Application Service Resume              104
8.7 Application Service Reset               106
8.8 Application Service Kill                108
8.9 Application Context                     110


9   General Management Application Services 114
9.1 Application Service Reject              114
9.2 Application Service Cancel              118
9.3 Application Service Identify            121
9.4 Application Service TriggerEvent        123
9.5 Application Service GetNameList         126
9.6 State Services 129
9.6.1 State Model for Communication Users   130
9.6.2 Application Service Status            131
9.6.3 Application Service UnsolicitedStatus 133
10   Treatment of Errors                    135
11   Lower Layer Interface [LLI]            142
11.1 Model of the Communication System      142
11.2 Connection Identifier                  143
11.3 Service LLI-ConnectionIdentifier       144
11.4 Service LLI-ApplicationData            148
12   Test Services                          150
12.1 Test Service LLI-SetTestParameter      150
12.2 Test Service LLI-ReportTestParameter   157
Appendices:
A   Reload Operation                        160
B   Notation for the Establishment of 
    Variables and Data Types                162
C   Examples for PDU-Coding                 169
C.1 Environment                             169
C.2 Domain Management Application Services  171
C.3 Variable Access Application Services    175
C.4 Program Execution                       180
C.5 General Management Services             186
D   Data Sheet                              191
E   References                              197

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-calledclient-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.

Figure 1: Course of Communication between two Application-Processes

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)

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.

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)

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

DC2

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

DC2

66348.3/V100

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

DC2

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

DC4

DC2

Measurement Ltd

Transducer 4711

SW-Rev.08-15

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

DC2

Var_1

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

DC2

23.64 mm

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

DC2

Domain1

Var_2

81.2 deg

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

DC2

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

DC2

The Response is:

DC4

DC2

'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.

Supported by BestWeb GmbH and ADM
Last update: 03.01.1999