Windows or Mac? EDDL or FDT/DTM?
What’s up, gang? Let’s talk about integration today! We live in an inclusive society now, or at least we try. The instrumentation world needs inclusion too, because we have to integrate our field devices into our systems and platforms, regardless of the brands or their languages. Of course, in this case when I say languages, I mean protocols like HART, FOUNDATION Fieldbus, PROFIBUS, and more.
EDDL and FDT/DTM come in to translate data from the field devices into information we can understand. Do you know the differences between them? Okay, suppose that EDDL is Windows and FDT/DTM is Mac.
Let’s discuss the pros and cons of each.
Start from the beginning
First, we need to know why we should care about EDDL and FDT/DTM before we dive into the details and draw conclusions. EDDL means Electronic Device Description Language. And as with most instrumentation, we have standards for it. The International Electrotechnical Commission (IEC) maintains the IEC 61804-3 standard, and we’ve used this text-based language for more than a decade. Yeah, you could call this article way late. We just got here, okay?
FDT/DTM means Field Device Tool/Device Type Manager. I’ll explain FDT and DTM later, but the DTM provides the same function as EDDL, more or less. The DTM is a little more powerful, but it’s based on Windows, which you might consider a weak point.
Speaking of, we wage a legendary war in the shadows. Okay, not really. But to this day, people still disagree about the best way to integrate a device to read configuration, operation, and diagnostic data. Some will tell you EDDL and DTM systems complement each other, and each system has its die-hard “my way or the highway” fans. What do I think? Sooner or later, you’ll find out!
EDDL in less than 2 minutes
Once upon a time (the 90s, actually), somebody smart created files to integrate field devices into control systems. We call these files device descriptions (DDs). They outline all the parameters a control system needs to understand a device. So without the DD, you can’t integrate your field device into the control system. Got it?
Later, more smart people created EDDL, based on DDs. EDDL gives you graphics, math libraries, data storage, dialogs, and more in your plant asset management (PAM) system. Yep, you’ve probably seen an EDDL file in action by now. Also, you can use EDDL in the same tools where you used to have DD technology, which makes shifting to EDDL easy.
Best of all, you can use EDDL on different platforms, no drivers needed, even if you don’t have Windows because it’s a text-based language. Now, I’ll buy a beer at Hannover Messe for the first person who shows me a PAM system for a non-Windows PC. Happy hunting!
No matter how useful or popular a system is, you’ll find people out there who don’t like it and want something different. In this case, they created the FDT/DTM. Well done, dissenters!
FDT tech standardizes communication between field devices and control system, asset management, or engineering platforms. Moreover, it allows device configuration or maintenance in an interface called FDT Frame Application. Last but not least, the DTM provides all the data from the field device, like the device structure, diagnostics, communication, and more.
You have two different classifications of DTMs, standard DTMs and CommDTMs. The first presents all the data from the device, and the second refers to communication components, like remote I/O, gateways, and such.
Which should you choose?
It’s up to you! Like anything else, each comes with pros and cons as well as fans, haters, and “can’t we all get along” types. Yes, even here some will argue that these systems complement each other rather than competing. In any case, most devices support both, so you can choose either or even both. In fact, we already have other peeps doing just that. The Field Device Integration (FDI) group has built a combined system on a basic client-server concept, using OPC Unified Architecture (IEC 62541).
Going back to EDDL, let’s talk about those pros and cons. EDDL doesn’t depend on a Windows platform, so you can have the file in a different operational system or even your handhelds. Furthermore, with most of the control system based on DD files, you’ll have less trouble adopting EDDL than a DTM.
On the other hand, if you need to archive and display a lot of data, EDDL can’t help. You’ll need some sort of “snap-on” DTM-based solution, which will cost more.
As for DTM tech, as a Windows-dependent system, you’ll run into problems with upgrades. You’ll have to upgrade all your files to maintain compatibility. However, its simple setup and standardized files make installation a snap. Just click next, next, next, and done!
Furthermore, the DTM file is more powerful than an EDDL file. You can have complex math functions and graphics, and you can archive it all without any problems.
Some companies use only EDDL systems, with snap-ons to access advanced diagnostics and such. If you have an FDT/DTM platform, you can’t access that data unless you have the FDT/DTM solution or a standalone version of the software. Really annoying. However, most vendors provide files for both platforms in their basic applications, which leaves only the small details to trouble you.
You remember I compared DTMs to Macs? With EDDL systems, you can do a lot of things but they have limitations, like Windows. I’d rather have the more powerful system, myself.
But think about this. Why do you need two platforms to read a file that you could have in only one? You know the answer, don’t you?