IEC 62453-309 pdf download – Field device tool (FDT) interface specification – Part 309: Communication profile integration – IEC 61784 CPF 9

IEC 62453-309 pdf download – Field device tool (FDT) interface specification – Part 309: Communication profile integration – IEC 61784 CPF 9
1Scope
Communication Profile Family 9 (commonly known as HART@1) defines communicationprofiles based on lEC 61158-5-20 and lEC 61158-6-20.The basic profile CP 9/1 is defined iniEC61784-1.
This part of lEC 62453 provides information for integrating the HARTR technology into theFDT standard(lEC 62453-2).
This part of the IEC 62453 specifies communication and other services.
This standard neither contains the FDT specification nor modifies it.
2Normative references
The following relerenced documents are indispensable for the application of this specification.For dated references, only the edition cited applies. For undated references, the latest editionof the referenced document (including any amendments) applies
IEC 61158-5-20，Industrial communication networks – Fieldbus specifications – Part 5-20:Application layer service definition – Type 20 elements
IEC 61158-6-20，Industrial communication networks – Fieldbus specifications – Part 6-20:Application layer protocol specification – Type 20 elements
IEC 61784-1，Industrial communication networks – Profiles – Part 1: Fieldbus profiles
IEC 62453-1:2009, Field Device Tool(FDT) interface specification – Part 1: Overview andguidance
IEC 62453-2;2009，Field Device Tool(FDT) interface specification – Part 2 Concepts anddetailed description
3Terms, definitions,symbols, abbreviated terms and conventions3.1 Terms and definitions
For the purposes of this document,the terms and definitions given in lEC 62453-1 andlEC 62453-2 and the following apply.
3.1.1
burst mode
mode in which the field device generates response telegrams without request telegram fromthe master
3.2Abbreviated terms
For the purposes of this document, the abbreviations given in IEC 62453-1,IEC 62453-2 andthe following apply.
BACK
Burst ACKnowledge
UML
Unified Modelling Language
3.3conventions
3.3.1 Data type names and references to data types
The conventions for naming and referencing of data types are explained in IEC 62453-2,Clause A.1
3.3.2vocabulary for requirements
The following expressions are used when specifying requirements.
Usage of “shall” or
No exceptions allowed.
mandatory”
usage of “should” or
Strong recommendation. It may make sense in special
“recommended”
exceptional cases to differ from the described behaviour.
Usage of “can’ or “optional”
Function or behaviour may be provided, depending ondefined conditions.
3.3.3Use of UML
Figures in this document are using UML notation as defined in Annex A of lEC 62453-1.
4Bus category
IEC 61784 CPF 9 protocol is identified in the protocolld element of structured data type’fdt:BusCategory’ by the following unique identifier (Table 1):
Table 1 – Protocol identifiers
ldentifier value
Protocolld name
Description
036D1498-387B-11D4-86E1-00E0987270B9
“HART”
support of lEC 61784 CPF 9 protocol
5Access to instance and device data
5.1 Process Channel objects provided by DTMThe minimum set of provided data shall be:
. the first four provided process related values (PV,SV，…) – if available – are modeled as
channel references.The referenced channel shall include ranges and scaling.
5.2DTM services to access instance and device data
The services InstanceDataInformation and DeviceDataInformation shall provide access to atleast to all parameters of the Universal and Common Practice commands (as far as the devicesupports the function).
Furthermore,the Response Byte 0 and the Response Byte 1 for each command shall beexposed.
The services InstanceDatalnformation and DeviceDatalnformation may also provide access todevice specific parameters (e.g. diagnostic information).
6 Protocol specific behavior
6.1overview
There is only one protocol specific sequence defined for lEC 61784 CPF 9:. burst mode subscription.
This sequence explains how the sequence “”, defined in Part 2 of this standard, is applied incontext of burst telegrams as defined by lEC 61784 CPF 9.
6.2Burst mode subscription
A subscription to device initiated data transfer can be requested by sending a transactionrequest with SubscribeRequest content (see Figure 2). The Communication Channel maydetect if the device is already in burst mode.
NOTE In HART 5 this can be detected only when burst frames are received from the device. In HART 6 the burstmode can be detected using command 105.
The Communication Channel answers to a SubscribeRequest with a SubscribeResponsecontent. lf burst frames are received,the device is in burst mode and burstModeDetectedvalue is set to TRUE.This means that Device DTM will start to receive burst messages via thetransaction response mechanism. In the case that no burst messages were received,burstModeDetected value is set to FALSE. lt is up to Device DTM to set device into burstmode.Then Device DTM may call a transaction request with SubscribeRequest content againin order to receive burst messages.
In order to unsubscribe,the Device DTM sends a transaction request with aUnsubcribeRequest. The Communication Channel answers with a SubscribeResponse whereburstModeDetected value is set to FALSE.The Device DTM will not receive any more burstinformation via the transaction response mechanism. The Communication Channel does notswitch off the burst mode in the device.The Device DTM may switch burst mode on or off byusing normal transaction requests (command 109).This is independent of the subscription.