Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC TR 62795: Field Device Integration — EDDL for Industrial Automation
A technical review of Electronic Device Description Language (EDDL) for interoperable device integration in process and factory automation
IEC TR 62795, published in 2013 as a Technical Report, provides comprehensive guidance on the application of the Electronic Device Description Language (EDDL) for field device integration in industrial automation systems. EDDL, standardized in IEC 61804-2, is a text-based description language that enables the integration of intelligent field devices — such as transmitters, actuators, and analyzers — into host systems (DCS, PLC, asset management tools) without requiring custom driver development for each device. As industrial plants continue to grow in complexity, with thousands of intelligent devices from dozens of manufacturers, EDDL provides a vendor-neutral mechanism for device interoperability that reduces engineering effort, simplifies maintenance, and ensures consistent device behavior across different host platforms.
The Industrial Internet of Things (IIoT) and Industry 4.0 initiatives have further amplified the importance of standardized device integration. IEC TR 62795 addresses the practical engineering aspects of implementing EDDL-based device solutions, covering the device description lifecycle from authoring and validation through deployment and runtime operation. The report serves as both a technical reference for device developers creating EDDL descriptions and a guide for end users evaluating device integration strategies for greenfield and brownfield automation projects. With its focus on practical implementation rather than theoretical concepts, the report bridges the gap between the formal language specification in IEC 61804 and the real-world requirements of industrial automation engineers.
EDDL is an ASCII text-based language (similar in style to C) that describes device parameters, methods, menus, and communication mappings. A single EDD file typically ranges from 50 KB to 500 KB and can support all operating phases: commissioning, configuration, diagnosis, calibration, and maintenance. The same EDD file works across any host system that supports the EDDL standard, eliminating the need for platform-specific device drivers.
EDDL Architecture and Device Description Lifecycle
IEC TR 62795 describes the complete EDDL ecosystem. The core component is the Electronic Device Description (EDD), a structured text file that defines all device parameters — including their data types, ranges, units, and default values — as well as methods (procedural sequences), menus (user interface organization), and communication mappings (how parameters are accessed over the fieldbus protocol). The EDD is authored by the device manufacturer using standard text editors or dedicated EDD development tools, typically requiring 2-8 weeks of engineering effort depending on device complexity. The report emphasizes the importance of rigorous validation before release, including syntax checking against the EDDL grammar, semantic checks for consistency across parameter interdependencies, and interoperability testing with reference host implementations.
The report also covers the EDD application process within a host system. When a device is connected to the network, the host’s EDD application reads the EDD file, interprets the language constructs, and dynamically builds the device-specific user interface, parameter database, and communication stack. This runtime interpretation approach means that the same EDD file works across Windows, Linux, and embedded host platforms without recompilation. The standard defines three application process levels: Basic (parameter access only), Extended (with methods and procedures), and Full (with persistent data, communication blocks, and advanced UI features). The level of support required depends on the device complexity; simple temperature transmitters may only need Basic level, while complex multivariable flow meters with diagnostics require Full level support for complete functionality.
| Level | Supported Features | Typical Device Examples |
|---|---|---|
| Basic | Parameter read/write, range check, unit conversion | Simple transmitters, temperature sensors |
| Extended | + Methods, procedures, calibration sequences | Pressure transmitters, valve positioners |
| Full | + Persistent data, communication blocks, advanced UI, graphics | Multivariable flow meters, gas analyzers, radar level gauges |
EDDL files are case-sensitive and strictly formatted. A missing semicolon or incorrect block nesting can cause the EDD to fail parsing, preventing device integration entirely. Device manufacturers must implement thorough validation procedures, including grammar checking and simulation testing, before releasing EDDs to the field. End users should request validated EDD files and maintain version control as device firmware updates often require corresponding EDD updates.
Communication Protocol Mapping and Engineering Design Insights
The report details how EDDL maps device parameters to communication protocols including HART, PROFIBUS PA, FOUNDATION Fieldbus, and PROFINET. Each protocol has unique addressing and data access mechanisms. For HART, EDDL uses the universal command structure (commands 0-127 defined in HCF_SPEC-183) and implements device-specific commands (128-253). For PROFIBUS PA, the EDDL maps parameters to slot/index addressing and uses the PROFIBUS DP-V1 acyclic communication channel for parameter read/write operations. The report provides practical guidance on handling protocol-specific timing constraints: HART devices typically require 300-500 ms per command, while PROFIBUS PA can achieve cycle times of 10-50 ms for cyclic data. These timing differences directly affect the EDD method design, as calibration procedures that involve multiple parameter writes must account for the communication latency of the underlying protocol.
A critical engineering insight from the report is the importance of method design for device commissioning and diagnostics. EDD methods are procedural sequences written in a C-like scripting language within the EDD file. Well-designed methods can reduce device commissioning time by 60-80% compared to manual parameter-by-parameter configuration. For example, a pressure transmitter zero-trim method should: (1) verify the device is at atmospheric pressure, (2) check the current zero value as a baseline, (3) execute the trim command, (4) verify the new zero reading, and (5) report success or failure with diagnostic codes. The report recommends that manufacturers include at least three essential methods: a quick startup method, a full calibration method, and a diagnostic health check method. Each method should include appropriate error handling, parameter range validation, and user prompts with progress indication for long-running procedures.
| Method Type | Purpose | Key Steps | Error Handling |
|---|---|---|---|
| Quick Startup | Commission device with default configuration | 4-8 steps, < 30 seconds | Abort with error code on failure |
| Full Calibration | Execute complete calibration procedure | 8-20 steps, uses trim commands | Rollback to previous values on abort |
| Diagnostic Health Check | Run device self-test and report status | Execute self-test, read diagnostics, generate report | Report all errors, continue testing |
Interoperability testing is a recurring theme in the report. While EDDL standardizes the language syntax, variations in implementation across host systems can lead to inconsistent behavior. The report recommends that device manufacturers obtain EDDL certification from fieldbus organizations (FieldComm Group for HART and FOUNDATION Fieldbus, PI for PROFIBUS/PROFINET), which includes testing against reference host implementations. For end users, the report suggests maintaining a device integration test facility where new EDDs are verified on the target host system before plant-wide deployment. This testing should include parameter read/write verification, method execution testing, diagnostic functionality validation, and user interface rendering checks across different host platforms.
When comparing EDDL with alternative integration technologies — FDT/DTM (IEC 62453) and FDI (IEC 62769) — the report highlights that EDDL offers the lowest implementation overhead for device manufacturers, as no compiled code is required. FDT/DTM, which uses Microsoft .NET or Java components for device integration, provides richer graphical capabilities but at the cost of increased development effort and platform dependency. FDI combines the strengths of both approaches by using EDDL for core device description and optional FDT-like components for advanced functionality. For brownfield plants with existing HART infrastructure, EDDL remains the most practical choice due to its minimal bandwidth requirements and broad host system compatibility. For greenfield projects with complex devices requiring advanced visualization, FDI represents the recommended path forward as it builds upon EDDL while adding enhanced graphical and communication capabilities.
A well-designed EDD can reduce the average device commissioning time from 30 minutes to under 5 minutes per device. For a typical chemical plant with 2000 field devices, this translates to approximately 800 engineering hours saved during commissioning, with additional savings throughout the plant lifecycle during device replacement and maintenance operations.
Using devices without proper EDD files creates a “black box” situation where the host system cannot access advanced diagnostics or configuration parameters. In critical safety-instrumented functions (SIF) per IEC 61511, this lack of visibility can compromise the ability to perform proof testing and diagnostic coverage calculations required for the safety integrity level (SIL) verification. Device manufacturers must provide complete, validated EDD files to ensure the functional safety lifecycle requirements can be satisfied throughout the plant operating life.
Engineering Design Insights for EDDL Deployment
From an engineering design perspective, several factors determine the success of an EDDL-based device integration strategy. First, the EDD file management infrastructure is often underestimated. In a large plant with 10,000+ devices from 50+ manufacturers, maintaining the correct EDD versions for each device type and firmware revision requires a systematic asset management approach. The report recommends using an EDD management system (EDDMS) that tracks device types, firmware versions, EDD versions, and installation status across all host systems. Version conflicts — where the installed EDD does not match the device firmware — are a common source of integration failures that can be avoided through automated version checking during device commissioning and replacement. The EDDMS should also maintain a backup of all EDD files and their revision history to support plant modification and expansion projects.
Second, network bandwidth considerations are important for EDD methods that transfer large amounts of data. A full device upload/download operation can involve 100+ parameters, requiring multiple communication cycles. For HART multidrop networks where multiple devices share a single 4-20 mA loop, the effective communication rate drops from approximately 2-3 parameters per second per device to less than 0.5 parameters per second as devices take turns accessing the bus. The report recommends using PROFIBUS PA or FOUNDATION Fieldbus for installations where extensive device configuration upload/download is expected, as these protocols support much higher data rates (31.25 kbit/s for FF, with deterministic scheduling) and can complete a full device upload in 10-30 seconds compared to 5-15 minutes for HART multidrop configurations.
Third, the report emphasizes the importance of backward compatibility in EDD design. When a device firmware is updated, the new EDD should remain compatible with the previous version’s parameter interface to avoid disrupting existing host system configurations. The report recommends that manufacturers implement strict version numbering following semantic versioning principles (major.minor.patch), where major version changes indicate parameter interface incompatibility requiring host system re-engineering. Field experience shows that EDDs following these compatibility guidelines experience 70% fewer integration incidents during firmware upgrade campaigns compared to those that introduce arbitrary parameter changes between versions.
Q1: What is the difference between EDDL (IEC 61804) and FDT/DTM (IEC 62453)?
A: EDDL is a text-based description language interpreted by the host system at runtime, requiring no compiled code from the device manufacturer. FDT/DTM uses compiled software components (DTMs) that run on the host platform, offering richer graphical capabilities but requiring more development effort and creating platform dependencies. EDDL is generally preferred for simple-to-moderate devices, while FDT/DTM is chosen for devices requiring complex user interfaces or proprietary communication algorithms. FDI (IEC 62769) combines both approaches by using EDDL as the core with optional FDT-like components.
A: EDDL is a text-based description language interpreted by the host system at runtime, requiring no compiled code from the device manufacturer. FDT/DTM uses compiled software components (DTMs) that run on the host platform, offering richer graphical capabilities but requiring more development effort and creating platform dependencies. EDDL is generally preferred for simple-to-moderate devices, while FDT/DTM is chosen for devices requiring complex user interfaces or proprietary communication algorithms. FDI (IEC 62769) combines both approaches by using EDDL as the core with optional FDT-like components.
Q2: Can EDDL support device diagnostics and predictive maintenance?
A: Yes, EDDL supports comprehensive diagnostic data through variables, methods, and alerts. A well-designed EDD can expose device status information, diagnostic counters, and health indicators that feed into asset management systems for predictive maintenance. The REPORT_STATUS_CTRL mechanism allows the host to periodically poll device health status without disrupting normal operation. Many modern DCS and asset management platforms use EDDL diagnostic data to implement condition-based maintenance programs that reduce unplanned downtime by 30-50% compared to time-based maintenance approaches.
A: Yes, EDDL supports comprehensive diagnostic data through variables, methods, and alerts. A well-designed EDD can expose device status information, diagnostic counters, and health indicators that feed into asset management systems for predictive maintenance. The REPORT_STATUS_CTRL mechanism allows the host to periodically poll device health status without disrupting normal operation. Many modern DCS and asset management platforms use EDDL diagnostic data to implement condition-based maintenance programs that reduce unplanned downtime by 30-50% compared to time-based maintenance approaches.
Q3: How does IEC TR 62795 relate to the FDI standard (IEC 62769)?
A: IEC TR 62795 provides foundational guidance on EDDL that is directly applicable to FDI, since FDI uses EDDL as its core device description technology. FDI Package technology combines an EDD file with optional user interface plug-ins and communication components in a single package. Understanding EDDL principles as described in TR 62795 is essential for creating FDI Packages. The TR helps engineers understand the underlying EDDL constructs that form the foundation of the FDI approach, including parameter definitions, methods, and communication mappings that remain unchanged in FDI.
A: IEC TR 62795 provides foundational guidance on EDDL that is directly applicable to FDI, since FDI uses EDDL as its core device description technology. FDI Package technology combines an EDD file with optional user interface plug-ins and communication components in a single package. Understanding EDDL principles as described in TR 62795 is essential for creating FDI Packages. The TR helps engineers understand the underlying EDDL constructs that form the foundation of the FDI approach, including parameter definitions, methods, and communication mappings that remain unchanged in FDI.
Q4: What tools are available for EDDL development and validation?
A: Several tools exist for EDDL development. FieldComm Group provides the EDDL Development Toolkit and EDDL Interoperability Test Kit for HART and FOUNDATION Fieldbus devices. PROFIBUS International offers the EDD Tools Suite for PROFIBUS and PROFINET devices. These tools include syntax checkers, semantic validators, simulation environments, and interoperability test suites. Open-source tools and text editors with EDDL syntax highlighting are also available, though the report recommends using certified development tools for production EDD files. The validation process typically includes: (1) syntax checking, (2) semantic verification, (3) host emulation testing, and (4) interoperability testing with reference host platforms from major DCS vendors.
A: Several tools exist for EDDL development. FieldComm Group provides the EDDL Development Toolkit and EDDL Interoperability Test Kit for HART and FOUNDATION Fieldbus devices. PROFIBUS International offers the EDD Tools Suite for PROFIBUS and PROFINET devices. These tools include syntax checkers, semantic validators, simulation environments, and interoperability test suites. Open-source tools and text editors with EDDL syntax highlighting are also available, though the report recommends using certified development tools for production EDD files. The validation process typically includes: (1) syntax checking, (2) semantic verification, (3) host emulation testing, and (4) interoperability testing with reference host platforms from major DCS vendors.
