Iec tr 62453 41 2016

I E C TR 62 453-41 ® Edition 2.0 201 6-04 TE C H N I C AL RE P ORT colour in sid e F i el d d evi ce tool (FD T) i n terface s peci fi cati on – IEC TR 62453-41 :201 6-04(en) Part 41 : Obj ect m od el i n teg rati on profi l e – C om m on obj ect m od el Copyright International Electrotechnical Commission TH I S P U B L I C ATI O N I S C O P YRI G H T P RO TE C T E D C o p yri g h t © I E C , G e n e va , S w i tze rl a n d All rights reserved Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IEC or IEC's member National Committee in the country of the requester If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local IEC member National Committee for further information IEC Central Office 3, rue de Varembé CH-1 21 Geneva 20 Switzerland Tel.: +41 22 91 02 1 Fax: +41 22 91 03 00 info@iec.ch www.iec.ch Abou t th e I E C The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes International Standards for all electrical, electronic and related technologies Ab o u t I E C p u b l i c a ti o n s The technical content of IEC publications is kept under constant review by the IEC Please make sure that you have the latest edition, a corrigenda or an amendment might have been published I E C C atal og u e - webs tore i ec ch /catal og u e E l ectroped i a - www el ectroped i a org The stand-alone application for consulting the entire bibliographical information on IEC International Standards, Technical Specifications, Technical Reports and other documents Available for PC, Mac OS, Android Tablets and iPad The world's leading online dictionary of electronic and electrical terms containing 20 000 terms and definitions in English and French, with equivalent terms in additional languages Also known as the International Electrotechnical Vocabulary (IEV) online I E C pu bl i cati on s s earch - www i ec ch /s earch pu b I E C G l os s ary - s td i ec ch /g l os s ary The advanced search enables to find IEC publications by a variety of criteria (reference number, text, technical committee,…) It also gives information on projects, replaced and withdrawn publications 65 000 electrotechnical terminology entries in English and French extracted from the Terms and Definitions clause of IEC publications issued since 2002 Some entries have been collected from earlier publications of IEC TC 37, 77, 86 and CISPR I E C J u st P u bl i s h ed - webs tore i ec ch /j u s u bl i s h ed Stay up to date on all new IEC publications Just Published details all new publications released Available online and also once a month by email Copyright International Electrotechnical Commission I E C C u s to m er S ervi ce C en tre - webs tore i ec ch /cs c If you wish to give us your feedback on this publication or need further assistance, please contact the Customer Service Centre: csc@iec.ch I E C TR 62 453-41 ® Edition 2.0 201 6-04 TE C H N I C AL RE P ORT colour in sid e F i el d d evi ce tool (FD T) i n terface s peci fi cati on – Part 41 : Obj ect m od el i n teg rati on profi l e – C om m on obj ect m od el INTERNATIONAL ELECTROTECHNICAL COMMISSION ICS 25.040.40; 35.1 00.05; 35.1 ISBN 978-2-8322-3337-5 Warn i n g ! M ake s u re th at you obtai n ed th i s pu bl i cati on from an au th ori zed d i s tri bu tor ® Registered trademark of the International Electrotechnical Commission Copyright International Electrotechnical Commission –2– I EC TR 62453-41 :201  I EC 201 CONTENTS FOREWORD I NTRODUCTI ON Scope Normative references Terms, definitions, abbreviations and conventions Terms and definitions Abbreviations 3 Conventions I mplementation concept Technological orientation I mplementation of abstract FDT object model 2.1 General 2.2 FDT Frame Application (FA) 2.3 Device Type Manager (DTM) 2.4 Presentation object 2.5 FDT-Channel object Object interaction 3.1 Parameter interchange via XML 3.2 Examples of usage 21 4 I mplementation of DTM data persistence and synchronization 23 4.1 Persistence overview 23 4.2 Persistence interfaces 24 DTM state machine 24 General concepts 26 General 26 Overview of task related FDT interfaces 26 Return values of interface methods 29 Dual interfaces 29 5 Unicode 29 Asynchronous versus synchronous behavior 29 ProgIds 30 I mplementation of DTM, DTM device type and hardware identification information 30 8.1 Device identification 30 8.2 Protocol-specific transformation style sheet (xsl) 33 8.3 Semantic identification information 33 8.4 Device assignment 33 8.5 Regular expression specification 34 I mplementation of slave redundancy 34 9.1 General 34 9.2 Topology import/export 35 I mplementation of FDT services: FDT interfaces 35 Overview of the FDT interfaces 35 FDT objects 35 2.1 FDT object model 35 2.2 Avalability of interface methods 38 Copyright International Electrotechnical Commission I EC TR 62453-41 :201  I EC 201 –3– Device Type Manager 42 6 3.1 I nterface IDtm 42 3.2 I nterface IDtm2 51 3.3 I nterface IDtmActiveXI nformation 52 3.4 I nterface IDtmApplication 54 3.5 I nterface IDtmChannel 56 3.6 I nterface IDtmDocumentation 57 3.7 I nterface IDtmDiagnosis 58 3.8 I nterface IDtmI mportExport 60 3.9 I nterface IDtmI nformation 62 3.1 I nterface IDtmI nformation2 63 3.1 I nterface IDtmOnlineDiagnosis 64 3.1 I nterface IDtmOnlineParameter 65 3.1 I nterface IDtmParameter 68 3.1 I nterface I FdtCommunicationEvents 69 3.1 I nterface I FdtCommunicationEvents2 72 3.1 I nterface I FdtEvents 73 3.1 I nterface IDtmHardwareIdentification 76 3.1 I nterface IDtmSingleDeviceDataAccess 78 3.1 I nterface IDtmSingleInstanceDataAccess 81 DTM ActiveXControl 83 4.1 I nterface IDtmActiveXControl 83 4.2 I nit 83 4.3 PrepareToRelease 84 FDT Channel 85 5.1 I nterface I FdtChannel 85 5.2 I nterface I FdtChannelActiveXInformation 88 5.3 I nterface I FdtCommunication 90 5.4 I nterface I FdtChannelSubTopology 97 5.5 I nterface I FdtChannelSubTopology2 01 5.6 I nterface I FdtChannelScan 01 5.7 I nterface I FdtFunctionBlockData 03 6 Channel ActiveXControl 05 6.1 I nterface I FdtChannelActiveXControl 05 6.2 I nterface I FdtChannelActiveXControl2 06 Block Type Manager 07 7.1 I nterface I Btm 08 7.2 I nterface I BtmI nformation 09 7.3 I nterface I BtmParameter 09 BTM ActiveXControl 1 8.1 General 1 8.2 I nterface I BtmActiveXControl 1 Frame Application 1 9.1 I nterface IDtmEvents 1 9.2 I nterface IDtmEvents2 20 9.3 I nterface IDtmScanEvents 21 9.4 I nterface IDtmAuditTrailEvents 23 9.5 I nterface I FdtActiveX 25 9.6 I nterface I FdtActiveX2 26 Copyright International Electrotechnical Commission –4– I EC TR 62453-41 :201  I EC 201 I nterface I FdtBulkData 29 9.7 9.8 I nterface I FdtContainer 31 9.9 I nterface I FdtDialog 34 9.1 I nterface I FdtTopology 35 9.1 I nterface IDtmRedundancyEvents 41 9.1 I nterface IDtmSingleDeviceDataAccessEvents 42 9.1 I nterface IDtmSingleInstanceDataAccessEvents 45 9.1 I nterface I FdtBtmTopology 46 FDT sequence charts 47 DTM peer to peer communication 47 1 General 47 Establish a peer-to-peer connection between DTM and device 47 Asynchronous connect for a peer-to-peer connection 47 Asynchronous disconnect for a peer-to-peer connection 48 Asynchronous transaction for a peer-to-peer connection 48 Nested communication 49 2.1 General 49 2.2 Generate system topology 50 2.3 Establish a system connection between DTM and device 52 2.4 Asynchronous transaction for a system connection 53 Topology scan 54 3.1 Scan network 54 3.2 Cancel topology scan 55 3.3 Provisional scan result notifications 56 3.4 Scan for communication hardware 57 3.5 Manufacturer-specific device identification 58 Registration of protocol-specific FDT schemas 60 Configuration of a fieldbus master 62 Starting and releasing applications 63 7 Channel access 64 DCS Channel assignment 65 Printing of DTM-specific documents 69 Printing of Frame Application-specific documents 70 0.1 General 70 0.2 Processing a document 71 0.3 Rules for use of DTM-specific style sheets 73 1 Propagation of changes 74 Locking 75 2.1 Locking for non-synchronized DTMs 75 2.2 Locking for synchronized DTMs 76 I nstantiation and release 78 3.1 I nstantiation of a new DTM 78 3.2 I nstantiation of an existing DTM 78 3.3 I nstantiation of a DTM ActiveX  user interface 79 3.4 Release of a DTM user interface 79 Persistent storage of a DTM 80 4.1 State machine of instance data 80 4.2 Saving instance data of a DTM 82 4.3 Reload of a DTM object for another instance 83 Copyright International Electrotechnical Commission I EC TR 62453-41 :201  I EC 201 –5– Copy and versioning of a DTM instance 83 4.4 Audit trail 84 Comparison of two instance data sets 85 6.1 Comparison without user interface 85 6.2 Comparison with user interface 86 7 Failsafe data access 87 Set or modify device address with user interface 88 Set or modify known device addresses without user interface 89 20 Display or modify all child device addresses with user interface 90 21 Device initiated data transfer 91 22 Starting and releasing DTM user interface in modal dialog 92 23 Parent component handling redundant slave 93 24 I nitialization of a Channel ActiveX control 95 24.1 General 95 24.2 Supports I FdtChannelActiveXcontrol2 95 24.3 Does not support I FdtChannelActiveXControl2 95 25 DTM upgrade 96 25.1 General 96 25.2 Saving data from a DTM to be upgraded 96 25.3 Loading data in the replacement DTM 97 26 Usage of IDtmSingleDeviceDataAccess: : ReadRequest / Write Request 98 27 I nstantiation of DTM and BTM 99 I nstallation issues 201 Registry and device information 201 1 Visibility of business objects of a DTM 201 Component categories 201 Registry entries 202 I nstallation issues 202 Microsoft’s standard component categories manager 203 Building a Frame Application-database of supported devices 203 DTM registration 203 Paths and file information 204 2.1 Path information provided by a DTM 204 2.2 Paths and persistency 204 2.3 Multi-user systems 204 Description of data types, parameters and structures 205 I ds 205 Data type definitions 205 Annex A (normative) FDT IDL 207 Annex B (normative) Mapping of services to interface methods 223 B General 223 B DTM services 223 B Presentation object services 227 B General channel services 227 B Process channel services 228 B Communication Channel Services 228 B Frame Application Services 229 Annex C (normative) FDT XML schemas 232 Copyright International Electrotechnical Commission –6– I EC TR 62453-41 :201  I EC 201 General 232 C.1 C.2 FDTDataTypesSchema 232 C.3 FDTApplicationI dSchema 248 C.4 FDTUserI nformationSchema 248 C.5 DTMI nformationSchema 250 C.6 DTMFunctionCallSchema 253 C.7 DTMParameterSchema 254 C.8 DTMDocumentationSchema 262 C.9 DTMProtocolsSchema 264 C.1 DTMSystemTagListSchema 265 C.1 DTMAuditTrailSchema 266 C.1 DTMDeviceStatusSchema 268 C.1 DTMFunctionsSchema 269 C.1 DTMChannelFunctionsSchema 273 C.1 DTMOnlineCompareSchema 276 C.1 FDTFailSafeDataSchema 277 C.1 DTMTopologyScanSchema 277 C.1 FDTOperationPhaseSchema 278 C.1 DTMI nitSchema 279 C.20 FDTUserMessageSchema 279 C.21 DTMI nfoListSchema 281 C.22 FDTTopologyI mportExportSchema 282 C.23 DTMDeviceListSchema 286 C.24 DTMSystemGuiLabelSchema 288 C.25 DTMStateSchema 288 C.26 DTMEnvironmentSchema 289 C.27 FDTConnectResponseSchema 290 C.28 TypeRequestSchema 290 C.29 FDTScanRequestSchema 291 C.30 FDTxxxIdentSchema 292 C.31 FDTxxxDeviceTypeI dentSchema 292 C.32 FDTxxxScanI dentSchema 293 C.33 DTMI dentSchema 293 C.34 DTMScanI dentSchema 294 C.35 DTMDeviceTypeIdentSchema 296 C.36 DTMI temListSchema 298 C.37 BtmDataTypesSchema 303 C.38 BtmI nformationSchema 305 C.39 BtmParameterSchema 306 C.40 BtmI nitSchema 308 C.41 BtmI nfoListSchema 309 Annex D (informative) FDT XML styles – Documentation 31 Annex E (informative) FDT XSL Transformation 31 E I dentification transformation 31 E H int 31 Annex F (normative) Channel schema 31 F FDTBasicChannelParameterSchema 31 F Template for Channel Schema 31 Annex G (normative) FDT version interoperability guide 31 Copyright International Electrotechnical Commission I EC TR 62453-41 :201  I EC 201 –7– Overview 31 G G General 31 G Component interoperability 31 G FDT type library 320 G DTM and device versions 320 G Persistence 320 G Nested communication 321 G General 321 G Data exchange 321 G Communication channel upgrade 321 G Scenarios 321 G OnAddChild 322 G I mplementation hints 322 G I nterfaces 322 G Persistence 322 Annex H (informative) Implementation with Net technology 323 H How FDT supports N ET based development 323 H Microsoft NET Framework and 2.0 compatibility 323 H Side-by-side installation and related problems 323 H How to avoid compatibility issues 324 Annex I (informative) Trade names 325 Bibliography 326 Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure – Part 41 of the I EC 62453 series − Fram e Appl i cati on i n terfaces − DTM interfaces − FDT Cl i en t/server rel ati on sh i p vi a XM L − Data access an d storag e 21 − Com m u n i cati on 22 − Docu m en tati on 22 − Param eter veri fi cati on i n case of fai l safe d evi ces 23 − State m ach i n e of a DTM 24 − Devi ce i d en ti fi cati on 30 1 − Stru ctu ral overvi ew 32 − I n terfaces of FDT obj ects – DTM and DtmActiveXControl 36 − I n terfaces of FDT obj ect – Frame Application 37 − FDT obj ects – FDT-Channel 37 − FDT obj ects – BTM and BtmActiveXControl 38 − Peer to pe er connection between DTM and device 47 − Asyn ch ron ou s n ect (peer to peer) 48 − Asyn ch ron ou s d i scon n ect (peer to peer) 48 − Asyn ch ron ou s tran sacti on (peer to peer) 49 20 − System -topology 50 21 − G en erati on of system topol og y by Fram e Appl i cati on 51 22 – Generation of system topology – Participation of DTM 52 Copyright International Electrotechnical Commission –8– I EC TR 62453-41 :201  I EC 201 Figure 23 – System connection (across communication hierarchy) 53 Figure 24 − Asyn ch ron ou s tran sacti on s (system n ecti on ) 54 Figure 25 − Scan n etwork topol og y 55 Figure 26 − Can cel topol og y scan 56 Figure 27 − Provi si on al topol og y scan 57 Figure 28 − Scan for com m u n i cati on h ard ware 58 Figure 29 − M an u factu rer-specific device identification 60 Figure 30 − Ad d protocol -specific schemas to Frame Applications schema sub path 61 Figure 31 − Fram e Appl ication reads protocol-specific device identification information of DTMDeviceTypes 62 Figure 32 − Bu s master fi g u rati on 63 Figure 33 − Starti n g an d rel easi n g appl i cati on s 64 Figure 34 − Ch an n el access 65 Figure 35 − DCS ch an n el assi g n m en t si n g l e D T M 66 Figure 36 − Seq u en ce of ch an n el assi g n em en t for a si n g l e DTM 67 Figure 37 − M od u l ar DTM stru ctu re 68 Figure 38 − Ch an n el assi g n men t for m od u l ar DTM s 69 Figure 39 − Pri n ti n g of DTM -specific documents 70 Figure 40 − Pri n ti n g of Frame Appl i cati on -specific documents 71 Figure 41 − Report g en erati on (Fram e Appl i cati on styl e) 72 Figure 42 − Report g en erati on (d evi ce ven d or-specific style) 73 Figure 43 − Propag ati on of ch an g es 74 Figure 44 − Locki n g for n on -synchronized DTMs 76 Figure 45 − Locki n g for syn ch ron i zed DTM s 77 Figure 46 − I n stan ti ati on of a n ew DTM 78 Figure 47 − I n stan ti ati on of an exi sti n g DTM 79 Figure 48 − I n stan ti ati on of a DTM u ser i n terface 79 Figure 49 − Rel ease of a DTM u ser i n terface 80 Figure 50 − State m ach i n e of i n stan ce d ata set 81 Figure 51 – Persistence states of a data set 82 Figure 52 − Savi n g i n stan ce d ata of a DTM 83 Figure 53 − Copy an d versioning of a DTM instance 84 Figure 54 − Au d i t trai l 85 Figure 55 − Com pari son wi th ou t u ser i n terface 86 Figure 56 − Com pari son wi th u ser i n terface 87 Figure 57 − Fai l safe d ata access 88 Figure 58 − Set or m od i fy d evi ce ad d ress wi th u ser i n terface 89 Figure 59 − Set or m od i fy kn own d evi ce ad d resses wi th ou t u ser i n terface 90 Figure 60 − Di spl ay or m od i fy al l ch i l d d evi ce ad d resses wi th u ser i n terface 91 Figure 61 − Devi ce i n i ti ated d ata tran sfer 92 Figure 62 − M od al DTM u ser i n terface 93 Figure 63 − H an d l i n g of a red u n d an t sl ave 94 Figure 64 − I n i t of Ch a nnel ActiveX with IFdtChannelActiveXControl2 95 Copyright International Electrotechnical Commission – 31 – I EC TR 62453-41 :201  I EC 201 An n e x E (informative) F D T XS L T n s fo rm a t i o n E.1 I d e n t i fi c a t i o n t n s fo rm a t i o n I n order to transform protocol-specific XML documents to protocol independent XML documents, protocol-specific XSL transformations are to be used Syntax in this document: FDTxxxI dentTransformation xsl where xxx is the protocol identification Examples: FDTH ARTI dentTransformation xsl FDTProfibusI dentTransformation xsl Frame Application has to copy this xsl file provided by Communication DTMs into the protocol-specific schema path and perform it to get protocol independent formatted identification documents, which can be validated using DTM[Scan| DeviceType]Schema xml E.2 Hint I t is strongly recommended for Communication DTMs to use the official transformation style sheets from FDT Group Refer to best practice document for more information about tasks and rules Copyright International Electrotechnical Commission I EC TR 62453-41 :201  I EC 201 – 31 – FDTHARTIdentSchema FDTHARTScanIdentSchema HartDTMScanIdentificationInstance.xml FDTHARTIdentSchema FDTHARTDeviceTypeIdentSchema HartDTMDeviceIdentificationInstance.xml XSLT processor XSLT processor FDTHARTIdentTransformation.xsl FDTHARTIdentTransformation.xsl DTMScanIdentificationInstance.xml DTMDeviceIdentificationInstance.xml validates validates DTMScanIdentSchema.xml FDTDataTypesSchema DTMIdentSchema DTMDeviceTypeIdentSchema.xml FDTDataTypesSchema DTMIdentSchema Figure E.1 – XSLT role I n Figure E.1 the left figure describes the role of the XSLT for H ART for the scan workflow The XSLT is processed by a Frame Application See XSLT implementations in 5.8 The right figure describes the role of the XSLT for H ART for the DTM device identification workflow Such a protocol-specific transformation style sheet processes protocol-specific XML documents returned by OnScanResponse() as well as GetDeviceI dentificationInformation() and creates protocol independent XML-documents • All protocol-specific data formats are converted to strings All defined attributes with semantic meaning are transformed to defined protocol independent semantic tags The semantic tag mapping rules are defined for each protocol in the corresponding protocol-specific parts of the I EC 62453 series (parts 3xy) Copyright International Electrotechnical Commission – 31 – I EC TR 62453-41 :201  I EC 201 Annex F (normative) Channel schema F.1 FDTBasicChannelParameterSchema Channels that not have any process related data (e g a pure Communication Channel) should return a document based on FDTBasicChannelParameterSchema I t is recommended, to return instead of an empty document a document based on the FDTBasicChannelParameterSchema Used at: I FdtChannel: : GetChannelParameters() I FdtChannel: : SetChannelParameters() The XML document describes how to access a channel without process data (see Tables F and F 2) Table F.1 – Description of basic channel attribute Attri bu te gatewayBu sCategory Description U n i q ue id enti fier for a supported bus type like Profi bu s or H ART accordi ng to the FDT-speci fic CATI D Table F.2 – Description of basic channel elements Element Descripti on FDT Root tag FDTBasi cChann el Descri ption of the chann el FDTChann el Type Descri ption of the chann el component in case of channel s wi th gateway fu n ctional ity < a ttri bute type="fd t: i d " req u i red ="yes"/> < El em en tType n a m e="FDTCh a n n el Type" conten t="el tOn l y" m od el = "cl osed "> < a ttri bute type="fd t: n od eI d " req u i red ="no"/> < el em ent type="fd t: Versi on I n form a ti on " m i n Occu rs= "1 " ma xOccu rs= "1 "/> < a ttri bute type= "g a tewa yBu sCa teg ory" req u ired ="n o"/> < el em en t type="FDTCh a n n el Type" m i n Occu rs="1 " m a xOccurs="1 "/> < el em en t type="FDTBa sicCh an n el " m i n Occu rs="1 " m a xOccurs= "1 "/> Copyright International Electrotechnical Commission I EC TR 62453-41 :201 F.2  I EC 201 – 31 – Template for Channel Schema FDT-Channel objects are providing data via the interface I FdtChannel The provided data are modeled within a bus protocol-specific XML document e.g based on FDTProfibusChannelParameterSchema schema or based on FDTBasicChannelParameterSchema schema The FDTParameterSchema is defining a basic structure containing a minimum set of attributes as a mandatory guideline regarding DTM-specific channel documents (see Tables F and F 4) Used at: I FdtChannel: : GetChannelParameters() I FdtChannel: : SetChannelParameters() Table F.3 – Description of xxx channel parameter attribute Attri bu te Description gatewayBu sCategory U n i q ue id enti fier for a supported bus type like Profi bus or H ART accordi ng to the FDT-speci fic CATI D schemaVersi on Versi on of the schema (u sed to i denti fy schema, not i ntend ed to be used in XM L d ocu ments) Table F.4 – Description of xxx channel parameter elements Element Descripti on FDT Root tag FDTXXXChan nel Descri ption of the chann el where ‘XXX’ contai ns a DTM -specific part FDTChann el Type Descri ption of the chann el component in case of channel s wi th gateway fu n ctional ity < a ttri bute type="fd t: ta g " requ ired = "yes"/> < a ttri bu te type="fd t: i d " req u i red = "yes"/> < /El em en tType> < El em en tType n a m e= "FDTCh a n n el Type" conten t="el tOn l y" m od el = "cl osed "> < a ttribute type= "fd t: n od eI d " req u i red ="no"/> < a ttri bu te type="fd t: n od eI d " req u i red = "no"/> < a ttri bute type="fd ti nfo: FDTVersi on " requ i red = "yes"/> < a ttri bute type="sch em a Version " req u i red ="yes"/> < el em ent type="FDTCh a n n el Type" m i n Occu rs= "1 " m a xOccu rs= "1 "/> < el em ent type="FDT< XXX>Cha n n el " m i n Occu rs= "1 " m axOccu rs= "1 "/> < /El em en tType> < /Sch em a > Copyright International Electrotechnical Commission – 31 – I EC TR 62453-41 :201  I EC 201 Annex G (normative) FDT version interoperability guide G.1 Overview FDT is a component based standard, which is constantly enhanced to new improved versions Control system environments typically run for to years in contrast I f hardware and software components in a control system have to be exchanged, a mixture of components designed for different FDT versions may emerge This raises the question, how components based on different FDT versions can cooperate This annex goes further into this question and provides solutions G.2 General This annex mainly deals with two topics concerning FDT version interoperability Persistence: New versions of FDT components (Frame Applications and DTMs) shall be able to load project data of older versions Component I nteroperability: Components of different FDT versions shall interoperate properly DTMs of newer FDT versions shall run in older Frame Applications and vice versa Communication shall work even if FDT versions of DeviceDTMs and Communication DTMs differ A limiting condition for future FDT enhancements is to ensure maximum compatibility of different FDT versions This results in a maximum interoperability of FDT components originally designed for different FDT versions FDT takes care about version interoperability on two different levels a) Specification level: The FDT specification targets full compatibility of different specification releases (e g schemas of the newer releases are compatible with older versions) Properly designed FDT components will achieve compatibility without extra implementations b) I mplementation level: FDT provides test tools to examine the FDT compliance of FDT components Although mentioned here, this is not in the scope of this Technical report The FDT version is composed by a major, a minor, a release and a build number (e g 2.0.3 where is the major, is the minor number, the release and the build number) Compatibility is defined slightly differently with respect to the major number, as follows • Compatibility between FDT components with the same FDT major version number is • assured by the specification Compatibility between FDT components with different FDT minor, release and build version numbers can be achieved by extra code paths FDT will provide necessary information and mechanisms to support full compatibility at this level The minor or release number is increased if new functionality, dependent of its appropriate importance, is added to the FDT specification The build number is increased if a bugfix within the specification or the type library is necessary G.3 Component interoperability I nteroperability of Frame Application and DTM components is shown in Table G.1 Copyright International Electrotechnical Commission I EC TR 62453-41 :201 Tabl e G −  I EC 201 I n t e ro p e b i l i t y b e tw e e n Row / C o l u m n – 31 – c o m p o n e n t s o f d i ffe re n t v e rs i o n s F m e F m e F m e F m e F m e Ap p l i c a t i o n , Ap p l i c a t i o n , Ap p l i c a t i o n , Ap p l i c a t i o n , Ap p l i c a t i o n , F D T v e rs i o n F D T v e rs i o n F D T v e rs i o n F D T v e rs i o n F D T ve rs i o n 2.1 … 2.0     O     O     O     O O O O O  D TM , FDT v e rs i o n 2 D TM , FDT v e rs i o n 2.1 D TM , FDT v e rs i o n D TM , FDT v e rs i o n D TM , FDT v e rs i o n 2.0 N OTE O – opti on al  – assu red The FDT specification ensures that DTMs and Frame Applications of the same major version cooperate regardless of minor version, for example FDT version is compatible to FDT version In this case the additional functionality defined in the higher FDT version may not be provided The situation is different if the major version number changes A DTM with a higher major version (than the Frame Application) may not function within a Frame Application with lower major version Interoperability in this case is optional In order to function in the ‘old’ Frame Application the DTM needs to behave according to the FDT version provided by the Frame Application A Frame Application with a higher major version (than the DTM) may refuse to work with a DTM with lower major version I nteroperability in this case is optional In order to work with the ‘old’ DTM the Frame Application needs to provide both interface sets (see section ‘Design Rules’) In this situation Frame Application behaves like an ‘old’ FDT version toward the DTM (old version number, old XML schemas) To assure that containers detect only compatible installed DTMs for each FDT major version a separate category ID will be defined within the FDT specification This assures that a Frame Application is able to detect installed DTMs for specific FDT major versions DTMs supporting FDT version or higher version shall implement the IDtm2 interface A Frame Application supporting FDT version 2.1 or higher versions shall check after instantiation of a DTM instance if this DTM supports the IDtm2 interface I n this case the Frame Application shall use this interface instead of using IDtm Version information is provided by the DTM within its information document, the version of the Frame Application is set during IDtm2: : Environment2() A DTM supporting FDT version or higher version called using IDtm: : Environment shall assume a Frame Application supporting FDT version Copyright International Electrotechnical Commission – 320 – I EC TR 62453-41 :201  I EC 201 The Frame Application will always provide the schemas according to the FDT version it publishes in I Dtm2: : Environment2() For example even DTMs based on version will find newer schemas in the schema path if the Frame Application supports a newer version of FDT G.4 FDT type library COM type libraries can only use a two-part version number I f only the minor version number increases, all the features of the previous type library shall be supported in a compatible way I f the major version number changes, code that compiled against the type library shall be recompiled The version number of the type library may differ from the version number of the application The four-part FDT version number is mapped to the two-part type library version using a COM minor version consisting of digits The first digit represents the FDT minor version, the second and third the FDT release version and the fourth and fifth digit represent the FDT build number (e g , FDT 2.0.1 is represented as type library version 20001 , FDT version as type library version 201 00) According to COM rules a new FDT COM type library will be downward compatible to a previous version of the same major FDT version The FDT version (major, minor, release and build) is used also as version number of the fdt1 00 dll file This assures that a new version replaces an older version during installation G.5 DTM and device versions When providing a new DTM for a new major FDT version, it is highly recommended to use a new ClassID and ProgID A DTM handling a new major FDT version requires that the Frame Application has installed an appropriate new COM type library, typically incompatible to the previous major FDT version I t is recommended to use this new ClassID and ProgI D only to register for the category I D according to the appropriate FDT major version I f ClassI D and ProgID of a DTM have changed, FDT will provide a mechanism to upgrade to the newer DTM (see also G.6 and I EC 62453-2: −, 9) Within its device catalog information (as DTMDeviceType elements in the IDtmInformation document) a new DTM version is able to provide the same list or a subset of the devices of the old DTM version I n this case a FDT Frame Application will handle the two versions of a DTM as any other DTMs able to handle the same field device as two distinguished DTMs A DTM of a higher FDT version which does not use a new ClassID and ProgID shall support at least all DTMDeviceTypes of that were supported by previous versions of this DTM G.6 Persistence I f the version of the Frame Application or the version of DTM change, then persistence (loading of stored projects) can be a problem A Frame Application shall be able to load old datasets and to provide the unchanged dataset to the DTM even if the DTM version has changed A DTM shall be able to load old datasets as long as the ClassID and the ProgID of the DTM not change I f ClassI D and ProgID of a DTM have changed, FDT will provide a mechanism to upgrade to the newer DTM In this way it is possible to load an existing old dataset of a DTM into another DTM object The new DTM is responsible to convert the dataset accordingly Copyright International Electrotechnical Commission I EC TR 62453-41 :201  I EC 201 – 321 – The new DTM provides information (via the I DtmI nformation: :GetInformation() method) which DTM datasets it can load (compatibility of dataset) I t shall support all device types of the old DTM I f the Frame Application recognizes the new DTM, it can inform the user (e g “A new compatible DTM was installed, you want to use the new version instead of the old version?”) I f the user confirms, then the new DTM object is instantiated instead of the old one and it loads and converts the old dataset G.7 Nested communication G.7.1 General Since DTMs can be chained with respect to the FDT topology, they need to communicate properly Because the involved DTMs may support different FDT versions the following restrictions shall be considered G.7.2 Data exchange An XML document exchanged via I FdtCommunication and IFdtCommunicationEvents can contain version dependent attributes and elements U nlike attributes of a newer version, which can be defined and handled as optional, new elements in a higher version would not be recognized by the parent component of an older version and can produce unpredictable behaviour in such a component Therefore, a DTM can only use communication documents according to the FDT version of its parent component This version information of the parent component shall be provided within the I FdtCommunicationEvents2: :OnConnectResponse2() A DTM can then use only communication documents compatible with this FDT version G.7.3 Communication channel upgrade A Communication Channel shall support the older FDT minor versions if it is upgraded to a higher minor version This is due to the fact that some of its already existing children may not support the higher minor version interfaces G.7.4 Scenarios G.7.4.1 Parent component version A DTM of FDT version higher than will not get version information from the Communication Channel because I FdtCommunicationEvents: :OnConnectResponse() is called I n this case such a DTM can only use FDT compatible communication documents G.7.4.2 Parent component newer than version A DTM of FDT version higher than will get version information from the Communication Channel because I FdtCommunicationEvents2: :OnConnectResponse2() is called by the parent component Such a DTM shall use communication documents compatible with the FDT version provided by the parent component G.7.4.3 DTM version The DTM does not expose the interface IFdtCommunicationEvents2 A parent component higher than shall call I FdtCommunicationEvents: : OnConnectResponse() G.7.4.4 Nested communication Within nested communication the version number returned by a Gateway DTM depends on the functionality of its parent component Copyright International Electrotechnical Commission – 322 – I EC TR 62453-41 :201  I EC 201 I f the Gateway DTM is at a higher version number than the parent component then the Gateway DTM – can return the same version as the parent and provide the functionality according to this version or – can emulate the higher functionality, if possible Then the Gateway DTM ensures that all required functionality is provided by its parent Examples: a) A DTM of a I EC 61 784 CPF – I EC 61 784 CPF Remote I /O can support I EC 61 784 CPF FDT communication compatible with FDT version 2.1 , although its parent component supports only FDT version I n this case the Remote I /O DTM shall be able to map all FDT1 2.1 I EC 61 784 CPF transaction requests (e.g I EC 61 784 CPF burst mode) to appropriate FDT IEC 61 784 CPF compatible transaction requests b) A multiplexer DTM of version with a parent component supporting only FDT version may not be able to provide functionality of the higher FDT version (e g , because it depends on device initiated data transfer) G.7.5 O n Ad d C h i l d If a DTM of FDT version 2.1 or higher is to be connected to a Communication Channel, a Frame Application has to use the first BusI nformation element in the DtmParameter document of the DTM (regarded as primary protocol), to verify if the DTM is supported by the Communication Channel This is a requirement because Communication Channels of FDT version are unable to retrieve the additional BusInformation elements G.8 I m p l e m e n ta ti o n h i n ts G.8.1 I n t e rfa c e s Mandatory interfaces defined in a new FDT minor version may not be defined in older versions Therefore components designed for the older FDT version will not implement these interfaces Although the system runs under the newer FDT version defined by the Frame Application the components need to be aware that an interface may not be supported if the server component is based on a lower FDT version Example: A DTM for FDT version 2.1 shall not rely on the interface IDtm2 Although this interface may be defined mandatory for a DTM with FDT version , it shall be possible to connect the DTM to an other DTM with FDT version which supports only I Dtm G.8.2 P e rs i s t e n c e I t is recommended that a DTM adds version information to its stored dataset, for example as a property of the property bag Copyright International Electrotechnical Commission I EC TR 62453-41 :201  I EC 201 – 323 – An n e x H (informative) I m p l e m e n t a t i o n w i th N e t t e c h n o l o g y H.1 H o w F D T s u p p o rt s N E T b a s e d d e v e l o p m e n t Microsoft ® realized that N ET needs a way to work with the existing Windows ® COM technology Therefore Microsoft ® added support in the N ET runtime environment for interoperating with COM – called ‘COM I nterop’ For more details please refer to: N ET Framework Developer's Guide, ‘Advanced COM I nteroperability’ (http: //msdn2 microsoft.com/en-us/library/bd9cdfyx aspx) COM components can be incorporated into a N ET Framework application by using ‘COM interop’ tools in order to import the relevant COM types The FDT Group provides a primary interop assembly for the FDT COM interface description (FDT1 00.DLL) I t is distributed as part of the FDT 2.1 specification (see Redistributable – FDT_I nteropAssembly.msm) H.2 M i c ro s o ft N E T F m e w o rk a n d c o m p a ti b i l i ty The NET Framework attempts to maintain compatibility between versions H owever, changes have been detected which will raise compatibility issues These changes are called ‘breaking changes’ For more information regarding N ET Framework compatibility please refer to: http: //msdn.microsoft.com/library/default asp?url=/library/enus/dnnetdep/html/netfxcompat asp) For more information about breaking changes that might affect your application, see ‘Breaking Changes in the NET Framework’ http: //msdn.microsoft.com/netframework/programming/breakingchanges/default.aspx H.3 S i d e -b y - s i d e i n s t a l l a t i o n a n d re l a t e d p ro b l e m s There are several releases of the N ET Framework (v1 0, v1 , v2.0) These framework releases can be installed side-by-side on a single computer On Windows ® XP and Windows ® Server 2003, the N ET Framework releases run side-by-side in different processes I n other words, one process can be running an application on the N ET Framework and at the same time another process can be running an application on the NET Framework There is a limitation that within one process only one version of the framework release can run This means the started N ET Framework version depends on the order of instantiation of N ET based applications within the same process This behaviour may lead to interoperability issues, at least related to following use cases: • FDT Frame Application is not based on N ET, DTM is implemented based on NET Runtime version , NET Runtime version is installed (regardless if version is Copyright International Electrotechnical Commission – 324 – • • I EC TR 62453-41 :201  I EC 201 installed or not): In this case always the latest version of the N ET Runtime is loaded The DTM may not work correctly because of above mentioned ‘breaking changes’ FDT Frame Application is based on N ET 1 Runtime: DTM based on Runtime version may not run because of above mentioned ‘breaking changes’ FDT Frame Application is based on N ET 2.0 Runtime, DTM is implemented based on N ET Runtime 1 : DTM may not run because of above mentioned ‘breaking changes’ These kinds of problems are not FDT-specific They will appear in all applications using components based on different N ET Runtime versions H H ow to avoi d compatibil ity issu es DTMs shall be implemented based on N ET Framework 1 and in a compatible way with N ET Framework 2.0 DTMs shall be tested against the NET Framework version and version This test can be performed by using a Frame Application based on N ET as well as by using a Frame Application which is not based on NET For further information regarding test strategy please refer to ‘Testing an Application Developed Using the NET Framework against the NET Framework 0’: http: //msdn.microsoft.com/library/default asp?url=/library/enus/dnnetdep/html/netfxcompat asp According to Microsoft ® (refer to paragraph ‘Tactics for Mitigating Possible Compatibility I ssues’) it is expected that a DTM tested with N ET 1 and N ET 2.0 will run in all Frame Applications without problems regarding different N ET versions This is a temporary solution until the FDT Group publishes information how this issue can be solved based on a non limiting approach Copyright International Electrotechnical Commission I EC TR 62453-41 :201  I EC 201 – 325 – An n e x I (informative) T d e n a m e s The following trade names are used in this document: H ART ® is the trade name of the product supplied by HART Communication Foundation This information is given for convenience of users of this document and does not constitute an endorsement by I EC of the product named Equivalent products may be used if they can be shown to lead to the same results Java ® is the trade name of a product supplied by Sun Microsystems (Santa Clara, U SA) This information is given for the convenience of users of this document and does not constitute an endorsement by I EC of the product named Equivalent products may be used if they can be shown to lead to the same results ActiveX ® is the trade name of a product supplied by Microsoft Corporation (Redmond, U SA) This information is given for the convenience of users of this document and does not constitute an endorsement by I EC of the product named Equivalent products may be used if they can be shown to lead to the same results Microsoft ® is a trade name registered by Microsoft Corporation (Redmond, USA) This information is given for the convenience of users of this document and does not constitute an endorsement by I EC of the product named Equivalent products may be used if they can be shown to lead to the same results Microsoft Windows ® is the trade name of a product supplied by Microsoft Corporation (Redmond, U SA) This information is given for the convenience of users of this document and does not constitute an endorsement by I EC of the product named Equivalent products may be used if they can be shown to lead to the same results MSDN ® is the trade name of a product supplied by Microsoft Corporation (Redmond, U SA) This information is given for the convenience of users of this document and does not constitute an endorsement by I EC of the product named Equivalent products may be used if they can be shown to lead to the same results Visual Basic ® is the trade name of a product supplied by Microsoft Corporation (Redmond, USA) This information is given for the convenience of users of this document and does not constitute an endorsement by I EC of the product named Equivalent products may be used if they can be shown to lead to the same results VC++ ® is the trade name of a product supplied by Microsoft Corporation (Redmond, U SA) This information is given for the convenience of users of this document and does not constitute an endorsement by I EC of the product named Equivalent products may be used if they can be shown to lead to the same results Copyright International Electrotechnical Commission – 326 – I EC TR 62453-41 :201  I EC 201 Bibliography I EC 60947 (all parts) , Low-voltage switchgear and controlgear I EC 61 58-5 (all parts), Industrial communication networks – Fieldbus specifications – Part 5-X: Application layer service definition ISO/I EC 9501 :2005, Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version IEC/TR 62390:2005, Common automation device – Profile guideline OPC XML-DA Specification, Version 01 , December 8, 2004 Microsoft MSDN ® Library March (2000) World Wide Web Consortium (W3C) Extensible Stylesheet Language (XSL) Document: WD- xsl-19981216 (1998) XML kompakt Hanser Verlag1 999 ISBN 3-446-21302-3 XML Handbuch Prentice Hall1 999 ISBN 3-8272-9575-0 XML/XSL Examples Refer to MSDN ® Library and W3C FDT V – May 2003 – Addendum XSL Transformations (XSLT), Version 0, W3C Recommendation N ovember 999, _ Copyright International Electrotechnical Commission Copyright International Electrotechnical Commission INTERNATIONAL ELECTROTECHNICAL COMMISSI ON 3, rue de Varembé PO Box 31 CH-1 21 Geneva 20 Switzerland Tel: + 41 22 91 02 1 Fax: + 41 22 91 03 00 info@iec.ch www.iec.ch Copyright International Electrotechnical Commission