Does anyone know enough about this to comment on how the two relate? Are they competing standards? Do they complement in any way? Who uses MQTT and who uses ETSI 690? Are there market, geographic or product biases? Siemens et all seem to be talking MQTT in their Enterprise 4.0 brochures and webinars, but I don’t know enough to know what I don’t know.
Also, if one was to design a product proof-of-concept using MQTT, would supporting ETSI TS-690 be essentially new development?
ETSI M2M can use MQTT as one of several transport mechanisms. Check this video series for more details https://vimeo.com/88748371 This is really boring stuff compared to working with MQTT directly, but ETSI M2M is solving much more and in a smart and scalable way. An ETSI M2M server can be reached via many secure protocols and MQTT is just one of them.
ETSI M2M is also complex to setup and use. Last time I checked, they delivered a reference implementation on an SD card, since getting it all up and running by yourself was really hard. This is a few years ago, so I would hope it’s gotten easier to work with by now.
So unless you’re doing government/state scale stuff, it might not be worth your time exploring. Then again - knowledge of this is sparse, so understanding it may be a competitive advantage if there are customers for it.
Fun fact: some years ago, the Norwegian Government issued a law that said that anyone delivering power to a building must report realtime usage straight to an ETSI M2M compatible system. This was to ensure transparency in the power sector. Every power delivery firm in Norway had to accept the cost of updating all the meters they owned and replace them with meters that could report back…
Thanks @jensa for your perspective and video link and I really appreciate your insight. I must know twice as much now as I did yesterday!
In that case, my thinking is to continue with an MQTT-based proof-of-concept for updating our 20 year old instrumentation sensor to support “Industry 4.0” directly, leapfrogging over a product generation of gateways and man-in-the-middle boxes that Siemens and Erikson are showing now in their marketing literature (i.e. Modbus and analog 4-20 to MQTT). I’ve been searching for any end devices that support MQTT, but so far I haven’t found any actual product for sale.
The company I’m working for is a boutique mostly re-seller to the local Oil & Gas industry, but we also designed and manufacture a flow sensor which I’m wrapping up a minor update to maintain manufacturability for another 10 years (update will be invisible to the customer, but will replace an obsolete LED driver and MPU, and with new software in C instead of assembler). However, I’m wondering what’s next, given we don’t have have the resources to compete in general against the major players in the market.
My thinking is that by supporting MQTT directly (and potentially ETSI M2M), we might find interest directly from end-customers planning Industry 4.0 migrations and preliminary investigative projects, and get a couple year with no competition (the big players will move slow, and the safety certifications are a high entry bar for new small players).
Does this sound realistic at all? Have I fabricated a fantasy scenario because I hope it exists?
Adding support for ETSI M2M via MQTT shouldn’t be too hard if you have access to a server to test with. There are a few ways to do authentication if I remember correctly, but it’s primarily like using MQTT with any other server.
I only have limited knowledge of the oil sector (robotics) but I would check if there are specific standards to support. I thought most things offshore was cabled / RS485? I’ve seen crazy sized cable ducts on some platforms.
NATS.io is similar to MQTT in some respects and I think will gain traction in the IoT space – simply because their server story is quite good (simple setup, security, clustering, etc), and the system focuses on simplicity. Although the NATS protocol is working pretty well in my IoT applications, they do plan to add support for MQTT. This podcast episode provides a good overview of NATS.
The ETSI folks claim ETSI is simple, but after watching a few videos – I’m not so sure – at least compared to NATS.
I may be naive, but I think the the average IoT technology is way too complex. In needing to synchronize configuration between systems, I’ve been exploring some data structures to better facilitate this.
Thanks for commenting @cbrake and for the podcast reference (I will listen to it on my bicycle commute home tonight). Did you consciously chose NATS over MQTT? I like that NATS is in the FreeBSD software repo (but fwiw so is Mosquitto). From @jensa, ETSI M2M treats MQTT as a transport layer (and presumably NATS if it too was to be supported). It would seem NATS support for MQTT would be more of a bridge or inter-compatibility function than what ETSI is doing, hopefully the podcast will provide clarity.
IMHO the industrial world of certified equipment may be temporarily “tolerating” MQTT (and NATS) because their benefit is too big to ignore - completely bypassing the historical SCADA systems in-place and the very significant equipment-specific software development that would be needed to achieve the same results. However, eventually, I would expect (even desire?) that equipment used in high-risk safety-critical M2M systems would be required to be certificated to standards like ETSI M2M (e.g. public energy delivery infrastructure, public transit infrastructure, class III medical devices, …).
@dale good point about safety-critical systems – the systems I’ve worked on thus far do not fall into this category (irrigation, waste water monitoring, etc).
A big reason I went down the NATS path (over MQTT) is because it is written in Go, and thus integrates more easily with all the other pieces I’ve written. One of my goals with SimpleIoT is that it be easy to deploy (one binary for small systems). I don’t want separate database servers, messaging servers, etc. An embedded database like sqlite or bbolt can easily handle a moderate size system. A single server can easily service 1000’s of devices. For systems that can tolerate a few hours of outage, the time to rebuild a failed server is acceptable in the rare instances a cloud server actually does fail (it has never happened to me yet).
For larger “enterprise” projects with a team of people, operations is not a big deal, but as I maintain several IoT systems for small customers, I’m always looking for ways to simplify operations. Not having to stand up and monitor 4 services is a big savings. Likewise, configuring and integrating the various cloud IoT offerings (AWS, Azure, etc) likewise is non-trivial.
A lot of cloud development has moved to Go in recent years for various reasons. The more I work with Go (both development and operations), the less interesting C++ and Java are to me. Go has a culture of simplicity that is refreshing. (example: try configuring NGINX vs Caddyserver). So for me, the protocol itself is a consideration, but also the big picture.
Having a MQTT server implementation in Go (as part of NATS) is super interesting to me as well. I would like to eventually support the MQTT protocol once that happens and perhaps switch to that if it makes sense for device communication. But, NATS is working just fine for now.
@dale TSI M2M is already being used as the de-facto standard for highly secure setups in Europe, so I agree on that. I am however skeptical to anything that requires a setup so complex that a pre-installed SD card is the best way to set it up
@cbrakeNats.io sounds really nice? From the podcast it seems it has all the benefits of MQTT, but with solid scaling built in? Will look further into it, so thanks for posting!
I am however skeptical to anything that requires a setup so complex that a pre-installed SD card is the best way to set it up
Agreed. Installation should be as simple as copying one binary to a device. This binary can then “install” itself the first time it is run by creating systemd units, config files, etc. App updates are then as simple as updating a single binary.
Embedding assets is becoming standard practice with Go apps (examples: Gitea and Caddy) and has been working very well for both embedded Linux and cloud apps in my projects. A Go binary with embedded assets has many of the benefits of a container, as the runtime and dependencies are statically linked by default. And it is efficient enough that the binaries are still reasonable size – 2-20MB is typical. So my standard Embedded Linux solution these days is a minimal Yocto image + a single Go binary.
It is interesting that technologies designed for servers at Google scale (Linux, Go, NATS.io, etc) usually tend to work well for embedded as well, because they are so efficient (efficiency translates directly to $$ in the data center). It is the bloated enterprise middle ground that does not scale down to embedded, or up to cloud scale (example: MS Windows).
