Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
PD IEC TR 62453 — Field Device Tool (FDT) Interface Specification Technical Report Series (CLI Object Model Integration and Styleguide)
Part 42: Object model integration profile — Common Language Infrastructure (CLI); Part 62: Field Device Tool (FDT) styleguide for common language infrastructure
🔧 PD IEC/TR 62453 is the UK adoption of technical reports from the IEC 62453 family, developed under IEC TC 65 through the AMT/7 committee (Industrial communications: process measurement and control, including fieldbus), and adopted in the UK through the same committee. IEC 62453 is the international standard series for the Field Device Tool (FDT) interface specification. This batch contains two technical reports: Part 42 gives the object model integration profile — Common Language Infrastructure (CLI), and Part 62 gives the FDT styleguide for common language infrastructure. The FDT technology lets field devices from different manufacturers (transmitters, actuators, valve positioners, etc.) be integrated, configured and diagnosed uniformly through device type managers (DTMs) within engineering and maintenance tools.
💡 FDT (Field Device Tool) is one of the main technologies for industrial field device integration: device manufacturers provide DTM (Device Type Manager) software components, which engineering tools (FDT Frame Applications) load through a standard interface, enabling uniform configuration, diagnosis and maintenance of field devices of different brands independent of bus type (HART, PROFIBUS, FOUNDATION Fieldbus, etc.). IEC 62453 standardises this technology.
1. Scope and Series Structure 📌
The IEC 62453 family includes the FDT interface specification body, various object model integration profiles (OMI, such as CLI, C++, COM), and accompanying technical reports such as styleguides and service descriptions. This series contains two documents:
| Document | Subject | Content | Year |
|---|---|---|---|
| PD IEC/TR 62453-42:2016 | Object model integration — CLI | FDT interface specification — Object model integration profile — Common Language Infrastructure (CLI) | 2016 |
| PD IEC/TR 62453-62:2017 | CLI styleguide | FDT interface specification — FDT styleguide for common language infrastructure | 2017 |
⚠️ Part 42 is technical/implementation-related, describing the implementation profile of the FDT object model on the CLI platform; Part 62 is more of a design guideline, governing the appearance and usability of DTM user interfaces. They are used together: implement the functionality per Part 42, then standardise the interface per Part 62.
2. Part 42 — Object Model Integration Profile (CLI) 🧩
Part 42 (2016) specifies the integration profile for implementing the FDT object model on the Common Language Infrastructure (CLI, i.e. the .NET platform). Core content includes:
- Object model and interface mapping: mapping the FDT object model (device database, communication channels, DTM interaction, etc.) to CLI platform language and runtime facilities;
- FDT types and communication services: specifying the CLI implementation of data exchange, device access and communication services between DTM and frame application;
- Namespaces and structure: namespace, class library structure and programming interface conventions in the CLI implementation;
- Conformance requirements: specifying conformance checkpoints to ensure interoperability of DTMs from different vendors in FDT frames.
💡 The CLI profile lets DTMs be developed in managed code (C#, VB.NET, etc.), leveraging .NET type safety, garbage collection and application domains, thereby reducing development cost and improving component reliability — a third mainstream integration approach besides C++ and COM.
3. Part 62 — Common Language Infrastructure Styleguide 🎨
Part 62 (2017) gives the FDT user interface styleguide for CLI-based implementations. Core content includes:
- Fundamentals of designing DTM user interfaces: principles of usability, consistency, readability and brand presentation in DTM user interfaces;
- DTM user interface categories: classifying DTM interfaces into dialogue-type, synchronous device interface (SDU) and asynchronous device interface (ADU), with design recommendations for each;
- Appearance: governing control sizes, spacing, layout, colours and typography for visual consistency between different DTMs;
- Benefits from the FDT user’s point of view: explaining the benefit of a unified style to end users — a consistent interface lowers the learning curve and misoperation risk, improving engineering and maintenance efficiency.
✅ The direct benefit of a unified styleguide is “predictability”: operators switching between device tools of different brands and buses find the same interface structure, navigation and operating logic, significantly reducing training costs and field misoperation.
4. Engineering and Application Practice 🛠️
- 🔍 Development choice: choose the development route among CLI, C++, COM and other integration profiles that matches the technology stack and target platform; projects based on the .NET ecosystem should prefer the CLI profile.
- 🎨 Styleguide first: establish the interface design specification and component library early in DTM development based on the styleguide, avoiding later rework and style inconsistency.
- 🤝 Interoperability verification: validate DTM loading, device access and communication service interoperability against conformance requirements with multiple frame applications;
- 📋 Documentation and maintenance: record interface versions, namespaces and dependencies, and maintain DTM compatibility as frames and platforms evolve.
5. Frequently Asked Questions ❓
❓ Q: What is the relationship between FDT and DTM?
A: FDT is the technical specification system for field device integration; a DTM (Device Type Manager) is the software component provided by the device manufacturer that runs in the FDT frame application and is responsible for configuration, diagnosis and communication of a class of field devices.
A: FDT is the technical specification system for field device integration; a DTM (Device Type Manager) is the software component provided by the device manufacturer that runs in the FDT frame application and is responsible for configuration, diagnosis and communication of a class of field devices.
❓ Q: How do Parts 42 and 62 differ?
A: Part 42 specifies the technical implementation profile of the FDT object model on the CLI platform; Part 62 specifies the DTM user interface style and usability guide. The former governs “how to implement”, the latter “what the interface looks like”.
A: Part 42 specifies the technical implementation profile of the FDT object model on the CLI platform; Part 62 specifies the DTM user interface style and usability guide. The former governs “how to implement”, the latter “what the interface looks like”.
❓ Q: Why are multiple object model integration profiles needed?
A: Different vendors have different development environments and technology stacks (C++, COM, .NET/CLI, etc.). Multiple profiles let DTM developers choose the language and environment suited to their platform while keeping the FDT object model and interoperability semantics unified.
A: Different vendors have different development environments and technology stacks (C++, COM, .NET/CLI, etc.). Multiple profiles let DTM developers choose the language and environment suited to their platform while keeping the FDT object model and interoperability semantics unified.
🔍 Q: What kind of development team suits the CLI profile?
A: Teams using managed languages such as C#, VB.NET on the .NET platform. CLI provides type safety, garbage collection and other features, giving high development efficiency; for deep system-level control, consider the C++ profile.
A: Teams using managed languages such as C#, VB.NET on the .NET platform. CLI provides type safety, garbage collection and other features, giving high development efficiency; for deep system-level control, consider the C++ profile.