# Native driver for IEC 60870-5 101/104

**URL:** <https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672>\
**Category:** Ignition\
**Created:** [March 1, 2024, 12:46pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672 "2024-03-01T12:46:41Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![Martin\_Esping](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/martin_esping/32/58944_2.png) [@Martin\_Esping](https://forum.inductiveautomation.com/u/Martin_Esping)\
**Post date:** [March 1, 2024, 12:46pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/1 "2024-03-01T12:46:41Z")

</div>

Im in need of a driver for IEC 60870-5 101/104. In Sweden it is widely used within communication with switchgears and other electrical devices. Our biggest competitor within the area is Citect and they have this driver and it’s a clear argument from the customers to not introduce more products in the line of communication, i.e. OPC. Also, the whole backbone of the Railroad administration uses 104. Here we compete with Zenon who has the driver also. I post this to be able to vote for it in [https://ideas.inductiveautomation.com/](https://ideas.inductiveautomation.com/).

So, if you see the same need as I do, please vote for it😊

I know its solvable with Kepware and such solutions, but native drivers are most often heavy arguments.

#IEC104, IEC104, native driver

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [March 1, 2024, 12:55pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/2 "2024-03-01T12:55:43Z")

</div>

This post (and every other request I get like it) makes me sad.

It's not too late for the industry to embrace open, multi-vendor, interoperable solutions that assemble the best available pieces for the job...

But as a whole you continue to sleepwalk towards a walled garden / single-vendor lock in, all for the mild convenience of having one phone number to call for support instead of two or three ☹

---

<div class="post-metadata">

**Author:** ![Martin\_Esping](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/martin_esping/32/58944_2.png) [@Martin\_Esping](https://forum.inductiveautomation.com/u/Martin_Esping)\
**Post date:** [March 1, 2024, 1:02pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/3 "2024-03-01T13:02:31Z")

</div>

I really understand what you are saying, but there are quite a few other aspects of it…one is that you have situations with an installed base that goes 20-30 years back that covers all installations of a whole country or a whole hospital, etc. It requires quite a rework to changes those things…..and we want Ignition to handle everything, both green- and brownfield.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 1, 2024, 1:18pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/4 "2024-03-01T13:18:11Z")

</div>

> [@Kevin.Herron](#):
>
> walled garden / single-vendor lock in

That's a bit over the top, for an IEC standard. There's no question OPC UA and MQTT are the future in the IT space, but I doubt they will ever completely replace dedicated protocols in the OT space.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [March 1, 2024, 1:21pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/5 "2024-03-01T13:21:22Z")

</div>

I'm referring to Ignition as the walled garden / single vendor 😬

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 1, 2024, 1:26pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/6 "2024-03-01T13:26:35Z")

</div>

Snort! 😆

---

<div class="post-metadata">

**Author:** ![Martin\_Esping](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/martin_esping/32/58944_2.png) [@Martin\_Esping](https://forum.inductiveautomation.com/u/Martin_Esping)\
**Post date:** [March 1, 2024, 3:30pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/7 "2024-03-01T15:30:39Z")

</div>

ok, then I misunderstood you, although what I wrote still applies. But connected to what you wrote, it's about adapting to what the industry looks like in order to be included in the game. 2 or 3 phone numbers are probably ok, but when you get up to 20-30, it's a different matter. You increase the risks of ending up in the classic blame game situation and that you will find it difficult to get help with your possible problems.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [March 1, 2024, 3:59pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/8 "2024-03-01T15:59:51Z")

</div>

> [@Martin\_Esping](#):
>
> and it’s a clear argument from the customers to not introduce more products in the line of communication, i.e. OPC.

A point of clarification - _every_ Ignition "native" driver is actually just a plugin for Ignition's OPC UA server. If you are using an Ignition driver, then you already have OPC in the line of communication. It's just not an OPC server from another vendor.

---

<div class="post-metadata">

**Author:** ![Martin\_Esping](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/martin_esping/32/58944_2.png) [@Martin\_Esping](https://forum.inductiveautomation.com/u/Martin_Esping)\
**Post date:** [March 1, 2024, 4:16pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/9 "2024-03-01T16:16:20Z")

</div>

Yeah, I know, I guess its not regarding the name of the communication, it's all about third-party products. At least in Sweden, which is quite Citect heavy, native drivers are seen as very important by most customers.

---

<div class="post-metadata">

**Author:** ![Peter\_NL](https://avatars.discourse-cdn.com/v4/letter/p/d9b06d/32.png) [@Peter\_NL](https://forum.inductiveautomation.com/u/Peter_NL)\
**Post date:** [May 13, 2024, 5:49pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/10 "2024-05-13T17:49:02Z")

</div>

In our industry there is a huge installed base with IEC 60870-5 101/104 so I can imagine why it could be useful.

---

<div class="post-metadata">

**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\
**Post date:** [May 13, 2024, 7:30pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/11 "2024-05-13T19:30:04Z")

</div>

> [@Peter\_NL](#):
>
> In our industry there is a huge installed base with IEC 60870-5 101/104

There is nothing stopping an interested party from developing a third party module to achieve this.

---

<div class="post-metadata">

**Author:** ![jose.granero](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jose.granero/32/11190_2.png) [@jose.granero](https://forum.inductiveautomation.com/u/jose.granero)\
**Post date:** [June 3, 2024, 4:04pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/12 "2024-06-03T16:04:29Z")

</div>

Take a look at [IEC 104 Client | Monitor, Control, and Enhance Communications](https://n3uron.com/iiot-platform-modules/iec-104-client/) and [IEC 104 Client](https://docs.n3uron.com/docs/iec-104-client)

---

<div class="post-metadata">

**Author:** ![christofer.dutz](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/christofer.dutz/32/76634_2.png) [@christofer.dutz](https://forum.inductiveautomation.com/u/christofer.dutz)\
**Post date:** [February 3, 2026, 6:29pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/13 "2026-02-03T18:29:07Z")

</div>

Is there still interest in this? IEC 60870-5 is one of the drivers I’m currently working on rewriting and possibly making plugins for Igntion out of:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/8/0832f367b92a40248658b4ee1bba3fbcfac7bf71.png)

Chris

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [February 3, 2026, 6:30pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/14 "2026-02-03T18:30:53Z")

</div>

We've had a little interest in this, so you might get some takers for it... depends on the appetite for using third party modules.

This one is on our radar to do eventually, though. It's a simple protocol that shouldn't take very long.

---

<div class="post-metadata">

**Author:** ![oskar.bolin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/oskar.bolin/32/83331_2.png) [@oskar.bolin](https://forum.inductiveautomation.com/u/oskar.bolin)\
**Post date:** [February 6, 2026, 8:37am UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/15 "2026-02-06T08:37:59Z")

</div>

We have a strong need for an IEC 60870-5-104 driver. There has always been a strong demand for this capability, and adding it would unlock substantial opportunities for Ignition within the power generation sector. Fingers crossed this driver will be added.

---

<div class="post-metadata">

**Author:** ![Marco\_Keller](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@Marco\_Keller](https://forum.inductiveautomation.com/u/Marco_Keller)\
**Post date:** [June 3, 2026, 12:49pm UTC](https://forum.inductiveautomation.com/t/native-driver-for-iec-60870-5-101-104/86672/16 "2026-06-03T12:49:14Z")

</div>

We also have a strong need for this protocol. It is widely used in the European energy sector. It is nearly impossible to achieve broad acceptance in the European energy distribution sector if this protocol is not supported.
