MQTT Sparkplug for Digital Transformation in Manufacturing – Industry 4.0 Talks

Welcome to our new episode of Industry 4.0 Talks where industry experts Kudzai Manditereza, Developer Advocate at HiveMQ, and Frédéric Desbiens, Program Manager for IoT and Edge Computing at the Eclipse Foundation, take us on an enlightening journey through the world of MQTT Sparkplug. In this riveting conversation, they explore the ins and outs of this transformative technology, covering topics from its fundamental principles and its pivotal role in enabling digital transformation within the manufacturing sector to its cost benefits, security measures, and impact on operational efficiency and productivity.

Expert Quote From the Podcast

Adapted Transcript

Here's the adapted transcript of the above video.

Kudzai Manditereza: Welcome everyone. Today I’ve got a special guest, Frederic Debian, who’s the program manager of Eclipse Foundation. He’s visited us here, so we’re going to be talking about, SparkPlug. I’ll let Frederic introduce yourself, Frederic.

Frédéric Desbiens: Thank you so much for having me, Kudzai. It’s a real pleasure to be here. I’m the program manager and evangelist at the Eclipse Foundation for everything about IoT and edge computing. And, of course, HiveMQ is a member in our Eclipse IoT working group, so we have plenty to talk about today together.

Kudzai Manditereza: Yeah, absolutely. What I want us to do is to kind of like talk about Sparkplug like at a high level, and maybe a good place to start here is to give us a definition of Sparkplug in like layman terms.

Frédéric Desbiens: Essentially, when you think about, industrial automation IoT types of use cases, there are plenty of solutions, and protocols in the market, but one that emerged in the, in the last few years, been around for a while, but now it’s got real momentum is MQTT, right? And now everyone is doing MQTT and that’s great. And the fantastic thing about MQTT is that you can publish anything, anywhere.

The bad thing about MQTT is that you can publish anything anywhere. So out of the box MQTT devices and software components, they don’t interoperate. So the goal of Sparkplug is to fix this lack of interoperability in MQTT. That’s the value that it delivers to its users.

Kudzai Manditereza: Awesome. How does SparkPlug support digital transformation initiatives?

Frédéric Desbiens: Essentially, the way Sparkplug works is that it defines three things in order to, to support the digital transformation. The first one is a set of standard payloads so that you know in advance what kind of data you are getting. The second one is, of course, what we call the topic name space. In other words, you define, hierarchy, like a folder hierarchy on a hard drive, for example, which is predictable and structured.

So you know in advance where the information would be. And this namespace provides context about the data that you are about to publish. And the third one is stay full session management so that you know at every given time if the devices are online or not. So from a digital transformation perspective, Sparkplug is really transformative.

Because, out of the box, devices and software components will work together, so you don’t have to tweak the payloads, you don’t have to parse or to write additional code in order to get the data out of the messages, and you get access to a set of products that have been certified using, you know, the Sparkplug official, official compatibility kit, Okay.

So on our website, we have a list of products that pass the compatibility kit. And HiveMQ broker, of course, is one of them. You can test products that you know in advance will work together with Sparkplug. No questions asked. And that’s a big difference because in most typical industrial automation projects, you do proof of concepts and you pick the components that fulfill the requirements, but after that, you have a lengthy phase of integration and changes and tweaks to really adapt this to your own organizational environment. You don’t have to do that with Sparkplug because out of the box, everything works together. So really, Sparkplug is an accelerator for digital transformation from that perspective because you spend more time on solving the actual problem and less time on whipping the infrastructure into shape.

Kudzai Manditereza: Absolutely. One of the reasons really why a lot of companies are looking to digitally transform is really kind of like to gain a competitive advantage. So at a business level, perhaps, what competitive advantages would you say companies that adopt Sparkplug are afforded?

Frédéric Desbiens: So one is certainly that you free up resources to innovate by simplifying the problem of infrastructure and picking from a stable of products that have been certified to work with the Spark Plug specification, then you spend more time to build new products or deliver services to your customers. And that’s certainly one big dimension out of it. The other, of course, is that by leveraging Sparkplug, you join a whole ecosystem, which is completely open in the sense that if you think about OPC UA, a great technology. But it’s developed behind closed doors. You have to be a member of the OPC Foundation to get access to the specs. And of course, if you want to submit new ideas for new versions, you have to be a member of the club as well. So that’s really, the old approach to industrial automation, where you have to be a member of the club and things happen behind closed doors.

In the case of Sparkplug, we just published Sparkplug version 3. We started to work on Sparkplug version 4, and everything is happening in public. So the new changes to the spec is on GitHub. If you have ideas for Sparkplug, you can submit them, open an issue on GitHub, and discuss directly with the people working on the spec, or on its open source implementation. And, you know, you don’t need to be a member of Eclipse or anything like that. You just come with your ideas, and the team will decide to take your idea or not. There’s no guarantee. But, there is an open conversation. And this is a game changer.

Because what we’re trying to build here is a successful ecosystem, and a successful ecosystem is always an open.

Kudzai Manditereza: Sparkplug is a relatively new specification. So a lot of Industrial installations or implementations currently have some older protocols. Maybe one of the questions that companies could be asking is if we were to move to implementing Sparkplug or using an equipment that is Sparkplug compliant, what would be the cost implications of making that shift?

Frédéric Desbiens: Of course any change has a cost, nothing is really free in life. I won’t pretend that Sparkplug magically solves every problem for free. But, it is less expensive than you would imagine to transition to Sparkplug. First, Sparkplug is not there to supplement or completely replace anything that you currently have and that works. It can work with that, and that’s one of its strengths, especially when you think, let’s say, OPC UA, which is fairly common in organizations nowadays. Now, if we dig deeper a bit on this topic of OPC UA, for example, most deployments don’t have necessarily OPC UA implemented at the level of the device.

A robot or even microcontrollers in a smart building or things like that. You don’t have OPC UA somewhere in the architecture converted to a MODBUS, CANBUS, backnet whatever you have, and translate that to OPCUA at some level, maybe in a gateway, maybe in a standalone converter.

Essentially, switching to Sparkplug means that you can replace OPC UA with a specific converter with one which is Sparkplug compatible. So the cost is less because of that.

Progressively, your current infrastructure will stay as is, but connect to Sparkplug enabled gateways, or edge nodes. And on the other hand, you will deploy newer things that will speak Sparkplug natively.

So, progressively, your legacy, applications and deployments will get surrounded by this SParkplug goodness. And when you are ready, you will be able to migrate the last pieces to Sparkplug eventually when it makes sense for your organization. And this is the goal of Sparkplug, not only to be interoperable, at the MQTT level, really to be able to work with whatever you have right now.

And our members are working on solutions that integrate. I mean, you have a number of plugins for your broker, for example, that speak various things, and some of those are more legacy things, so to speak. So our other members do the same, and so overall our ecosystem is able really to make sure that if you enable digital transformation with Sparkplug, you can do it at a reasonable cost without having to rebuild everything from scratch.

Kudzai Manditereza: Would I be correct to say that the benefits of implementing Sparkplug will outweigh the cost of really laying that foundation?

Frédéric Desbiens: Absolutely. And Sparkplug is an enabler for new things. Things that will enable you to compete more and things that will enable you to really focus on your customers and partners rather than solving IT problems because no one, there’s no value in that to just, you know, getting the things working. And we’ve got a number of examples already that are documented in white papers and deliverables from our members.

Kudzai Manditereza: One of the big questions that we get is, do you have an example of a company that saw benefits from implementing Sparkplug?

Frédéric Desbiens: Absolutely. The example of Waterford Township, which is a municipal government, I think in the state of Michigan in the U. S. It is a small. local government with about a population of 72000 people over a fairly large territory. This is North America and there’s plenty of space to expand. And the drinking water distribution system on their territory with water pipes and pumping stations over a fairly large territory, of course, and in their case, they had a legacy solution that wasn’t fulfilling the bill anymore.

Every time that something was happening on their network equipment. in the field, they were getting notifications after three or four minutes. Now, if you have a water leak, you know, a serious one at a pumping station, knowing it four minutes late is already thousands of liters of drinking water have been wasted and could damage the equipment at the pumping station on the top of that.

So you need to be more proactively and to learn them in nearly real time if you want to be able to effectively manage the infrastructure. So they decided to replace this legacy system that they were having with one based on Sparkplug, including groove devices from OPTO 22, one of our members, and then a software solution from inductive automation called Ignition that support Sparkplug and all of that.

With Sparkplug solution, they spoke about it in a prior Eclipse webinar from from a few years back – the benefits that they got out of this implementation are really incredible. Now they have sub second latency across their entire system.

So, in less than a second, they will know when something happens somewhere. And Sparkplug, by the way, is reporting by exception. So, this means if a value doesn’t change, or if a value is the normal threshold, you don’t get bombarded with useless messages. You will get an updated value if it changes. And really, this means the second benefit, that Sparkplug decreases bandwidth usage a lot.

And in their case, they were relying on LTE or some other cellular type of connectivity in the field. Telcos are happy for you to consume lots of bandwidth because they can voice you, but you don’t want to do that. So, they were able to send less data over the wire, so they were able to significantly decrease their bandwidth consumption, which is good from their perspective.

Of course, when a system action is needed, when there are alarms or notifications, they don’t miss them anymore because everything is near real time. Of course. Given large territory at work there, you wouldn’t be able to get actual real time up, you know, from, from every point. And then this means that ultimately the system is really better in terms of fault tolerance and disaster recovery.

Because once again, they were able to deploy redundant nodes in key places. And of course, the central broker in the system is as failover capabilities and fault tolerance and things like that. So overall, you know, it’s been really a huge success for them because yes, they have to invest some money.

But now, instead of having a 20th century system to manage their infrastructure, they have a 21st century. They can build on top of that to now bring additional values to their constituents as well.

Kudzai Manditereza: Other big question around Sparkplug is how does it helps organizations comply with security regulations or how does security work with Sparkplug?

Frédéric Desbiens: Sparkplug follows a bit the same philosophy as MQTT. When you read the MQTT spec, there is a section on security, but it’s non normative in the sense that they document best practices but it’s really up to you to decide what makes sense for your use case. The one thing that’s really well supported in MQTT, and that’s the most fundamental thing for the integrity, is of course, the encryption. So the same that you use to connect to your bank and your browser.Of course you have that in base MQTT and you have that when you use Sparkplug because Sparkplug uses MQTT as the transport protocol underneath.

Enabling TLS on whatever broker you will be using. The key thing here is to have a look at the security feature set of. The brokers that are available to you and certainly have a very, very good choice and they are, of course, open source options that offer, for example, in the case of Eclipse Mosquito, a lightweight broker available in it’s got the principle access control lists and ACLs that you can leverage in order to segregate topics that are security sensitive over some that needs maybe less security. So really, if you are a business person, the key thing here is to give your IoT architects the mandate to evaluate broker options.

Kudzai Manditereza: One of the key things really that business executives really look at as far as adoption of a technology is concerned is how that impact could be tied to improving things like operational efficiency or productivity, things that they could actually look at and see this actually improving. Can you talk to us about how Sparkplug can actually impact efficiency and productivity in industrial operations?

Frédéric Desbiens: Yes, absolutely. So, as we have seen with Waterfruit Township that they were able to have a type of system where they were doing polling and response in order to know if devices are online. And then after that, you know, they were getting those updates in three or four minutes for their infrastructure in the field.

So switching to Sparkplug in this case meant that because of the very low latency of the infrastructure, they were getting near real time data and were able to make better informed decisions. Options when the situation required it. Essentially, when you think about Sparkplug, the key thing to remember there is that by having a performance and duty broker in the middle.

You know, and some of them are able to literally process millions of messages a second. Okay, this is really incredible. So you have essentially basic infrastructure that then enables near real time decision making. And of course, Spotlight is just a piece of the whole solution there in the sense that maybe you will need big data types of mechanisms in order to keep an up to date data lake for AI and things like that, right, in order to make predictions or predictive maintenance and things like that.

And on the other end, you will probably have an analytics dashboard that will keep an eye on real time on metrics that are key to operations and that kind of stuff. But Sparkplug is this low latency, low bandwidth enabler for all of those things. So by itself, you know, because you have Sparkplug, you won’t, let’s say, save 10 million dollars or 10 million euros.

But without Sparkplug, you wouldn’t be able to save those because you wouldn’t get the data in time to make better decisions. And that’s where it fits overall in the architecture. And in one way, this is why Sparkplug is open source. Open source makes sense when you have something that is either a commodity or something where the ecosystem needs to be built around, and that’s what we’ve been doing at the Eclipse Foundation.

We are vendor neutral. We work with every member in the same way, and so it’s a level playing field. And you, as a Sparkplug adopter, if you are a business person, essentially, you can trust us to manage this ecosystem in the name of the community, to be good stewards of the community, from a vendor neutral perspective.

So, once again, Sparkplug is an enabler and we at the Eclipse Foundation are the enablers of Sparkplug in one way.

Kudzai Manditereza: Can you speak to us about how MQTT and Sparkplug can affect sustainability and environmental goals of the company?

Frédéric Desbiens: Absolutely. One common misconception about digital technology is that it’s green somehow, but even the cloud is not really green because all of those servers. The cloud is actually a set of data centers somewhere and they consume a lot and a lot of electricity, right? And of course, depending on the source of this electricity, this means that your cloud is actually contributing to global warming and things like that.

Now, of course, one potential thing you can do is to use renewable energy sources. So that’s great. But you can go further and Sparkplug helps from that perspective in two ways. The first way is really the focus of Sparkplug is really to reduce bandwidth consumption. Right? The payloads are lightweight. The lack of polling response means that you will get updated data whenever you need them, but otherwise you are not sending useless messages all the time just to keep a connection alive or something like that. So all of that means that you consume much less bandwidth, which means that ultimately you consume much less power and, on the top of it, Sparkplug encodes everything in binary. So essentially, it’s an efficient way to take even less space on the wire, so to speak.

And so this translates once again to energy savings. The second dimension is something that people don’t really realize about open source. Sparkplug is an open specification, and it’s got open source implementation at the Eclipse Foundation, which means that People that leverage Sparkplug are not busy reinventing the wheel with their own solution to the problem.

And by doing that, what they do is to contribute to sustainability in circular economy. In the sense that, by using and leveraging an existing technology, You build whatever you need to build to address a problem, but you use proven building blocks that have already been debugged, that have already been developed.

And that, once again, is a more effective use of resources. You focus your resource on the new stuff you need, and you leverage the building blocks that are available in the ecosystem. And this makes the whole solution greener, for sure.

Kudzai Manditereza: Now, one of the things that I would like to talk to you about before we close this session is the issue of culture change, training and culture change within industrial companies, because Sparkplug really is a new paradigm of communication, right?

We’re used to a situation whereby software systems and components are really stacked up into like a silo based on the ISA 95. Now, this distributed approach of putting together a system through a PubSub really is a new way of thinking. So what should organization do as far as training or cultural change?

Frédéric Desbiens: The fundamental step is to break the reflex of request response. In OPC UA and other request response protocols, you need to poll regularly the devices in order to know if they are online. And then you need to pull them in many cases to get their data updates. If the central location in the system or the scalar system in the case of industrial automation doesn’t do that, then you will not get the updated values.

So getting into MQTT and specifically into Sparkplug means that you have published and subscribed. So it means that you have complete decoupling between the publishers and the subscribers. So a publisher will publish, Whenever it needs to publish, and doesn’t have to care. If there are consumers or if there are subscribers to that information.

So you publish and you are confident that any interested stakeholder will subscribe to that particular topic in order to get the data. And the best way to enter the transition is, is I think really to focus on the basics. If you are to do this transition. Then get acquainted properly with MQTT experiment with it and see how different it is.

And then you add Sparkplug on the top. But Sparkplug uses all of the standard MQTT behaviors and techniques, so you won’t have to learn anything new in order to leverage it. In fact, it’s a bit simpler in the sense that Sparkplug defines things for you, so you don’t have to make those decisions for yourself like you would do with plain MQTT.

So, the key here is education. You know, as a former teacher myself, maybe I’m a bit outdated or a bit biased here. But really, you need to take the time. See what MQTT can do for you. And how different it is. But the good news is that there are people like you producing good content. And there’s my book, if people care about the Eclipse IoT ecosystem.

And, you have a whole series of blogs about MQTT fundamentals and things like that. And another whole series about Sparkplug. So, there are things to do for your self education, I think. And plenty of videos, of course, on YouTube and all of that. So take the time to learn.

Expect that you need to break a few old behaviors. But the one thing to keep an eye for is polling response. If you find yourself saying how do I determine that a device is online? Or how do you I implement things. In order to pull a device to get an immediate data update, then you are doing it wrong.

You’re just trying to replicate what you were already doing. And that’s a recipe for disaster. So be aware of that. Be mindful of that. Educate yourself. And if you need help people like Kudzai and myself are there to help. That’s the power of an ecosystem.

Kudzai Manditereza: Yeah, absolutely. Could you describe to us in detail how MQTT Sparkplug functions within an industrial IoT network?

Frédéric Desbiens: Of course, we say MQTT Sparkplug because essentially Sparkplug uses MQTT. So you need an MQTT broker somewhere at a minimum, and maybe several depending, of course, of the kind of architecture that you have, or maybe a clusterware or highly available broker, depending on the functional and non functional needs that you have.

Okay, so you’ve got your broker. What Sparkplug adds on the top of plain MQTT, so to speak, is essentially three things. One, a standard payload format. Two, a topic namespace, in other words, a structure for your MQTT topics, which is predictable and customizable up to a point. But we have pretty strong opinions about the structure.

And third is what we call stateful session management. In other words, we use some of the features available in MQTT like the Last Will to see if a device is online or not. And the same for the SCADA system. So if the SCADA system goes down, then we use the Last Will message. On a specific topic that is defined just for that purpose that will be sent to every node.

That’s at a high level of how it works. Now, if we dig a bit on each of those dimensions. Focusing on the payload format, the way Sparkplug payloads are structured is not the same, let’s say, as OPC UA information models in OPC UA, they try to invent the perfect model for water pump or something like that.

And then you can add your own attributes, so we don’t care about that in Spark Cloud. The payload is generic in the sense that it can represent any metric. which is relevant to you. So, what we provide is a way to express those metrics, but it’s up to you to define. I want water pressure in psi, or I want the number of liters in a specific reservoir, or something like that.

That’s where Sparkplug shines in the sense that because the payload format is standard than any Sparkplug enabled device or software component will be able to parse it and understand it. But at the same time, whatever data you put in there is up to you and you’ll get flexibility because of that.

So in order to simplify things, we provide developers a schema for the payloads, and this schema is expressed in Google protocol buffers or protobuf. There are many language implementations for that. So whatever type of environment you have, you can use protobuf. When you have this schema, which shifts with the spec, you can generate skeletons for your code and this simplifies development.

That’s how it works for the payload. The topic namespace is then structured in a specific way. We start with the version of the protocol and the payload encoding. Currently, for Sparkplug version 3, this is /SPB. So that’s payload format B, V10. And so this can get confusing because it’s version 3 of the protocol, but it’s version 1 of that particular payload encoding.

The next version of Sparkplug, Sparkplug version 4, will likely introduce payload format C. So you can run both Sparkplug 3 and Sparkplug 4 with the same MQTT broker, because at the root you have Sparkplug B or Sparkplug C from version 4. So you won’t mix up messages from a different version.

So that’s the first step. After that, you add the group ID. The group ID is something arbitrary that you decide. If you want to segregate things by country or by locations for your various factories, you put it there. Then you have the ID of the edge node. And the edge node in Sparkplug is really a node that speaks Sparkplug natively. And in some cases, you have non Sparkplug devices connected to that edge node. Maybe over Modbus or BACnet or whatever. And then, what happens is that those devices can still be part of the namespace.

So you will have a device ID after the node ID for those cases. And the device ID matches whatever is connected to the node. So, a Sparkplug native device, will maybe not have those devices attached. It would be considered an edge node. That’s how things are structured. And then there is the message type. There are various message types in Sparkplug.

The first one is the birth or death certificate. So you send that when you have a new device joining and you send the birth certificate saying, I’m device XYZ, I will report about those metrics. So every other node, which is interested knows what this device will report about. And the death certificate is much simpler, say, I’m going out.

Then there are data messages for both edge nodes and devices. Those are the regular metric updates that you send when there’s a change. Don’t forget that Sparkplug is report by exception. So if a message value is not changing, then you use retained messages on a specific topic, according to whatever makes sense for your use case.

And you don’t send other messages until the value changes, or maybe you want to refresh it for some reason, but ultimately it’s up to you to decide. Those data messages are much simpler than the birth certificate because you don’t repeat some of the information about the metric.

Typically the messages will be sent as last will and testament in the case of disconnections so that if there’s a technical issue with the infrastructure, then at least the other nodes know that something is happening in the environment. That’s how the topic structure or the topic namespace is built in Sparkplug.

And then the stateful session management. This is the notion that I send my BIRTH certificate, and then I set my last will and testament as part of the original so that relevant information is sent when there’s an accidental disconnect. And that’s how it works.

Between the two, you don’t need to pull the device. Because of the properties of MQTT, the device is actually online, so you save on bandwidth.

Kudzai Manditereza: One of the fundamental requirements while building an industrial high tech solution is that it be scalable. Scalability is really a critical factor as far as industrial high tech is concerned. Can you talk to us about how MQTT’s backlog allows for building scalable systems?

Frédéric Desbiens: Of course. When we say scalability, what we really mean is can this system absorb millions of messages alternately? When my business grows and I have so much business that I would need to run my factory 24/7 at a huge scale in order to fulfill the demand.

Scalability, of course, is tied closely to extensibility in the sense that I must be able to add capacity in a way that won’t break the applications that use infrastructure and Sparkplug accommodates. The key to scale Sparkplug is to pick a highly available, highly scalable MQTT broker. HiveMQ is a good commercial example of that. Sparkplug optimizes the bandwidth consumption as much as possible. So the payloads are small. We try messages not to repeat information that has already been shared. That’s why our birth certificate gives lots of context about the data and then the data updates after that.

We save on bandwidth in multiple fashion with Sparkplug, including the fact that by using Google Protocol buffers for the payload. Essentially the payload is in binary, but then it is in a structured format where you serialize or deserialize. This brings high performance. This requires less resource to parse or to serialize, and at the same time, it takes less space on the wire. So it makes overall your network infrastructure more scalable because we use as little networking resources as possible in order to shuffle the data around. So from that perspective, Sparkplug makes a difference from a scalability standpoint over plain MQTT. It is really optimized in various ways to minimize network traffic.

And the combination of MQTT and Sparkplug together really make a huge difference in terms of scalability.

Kudzai Manditereza: How does Eclipse Foundation support the community of developers and companies while working with SparkPlug?

Frédéric Desbiens: We create an environment where the people that are the actual masterminds of Sparkplug are able to work on an equal and level playing field. We are a vendor neutral non profit organization. Anyone on this planet can have an Eclipse open source project if they desire to do so, and membership is not even required in that case. We have our members that come and pay annual fees to us, and with this fees, we build servers for the project, and we have a number of staff members like myself. And what we do is to deliver services to our open source projects, and to what we call our industry collaborations. Essentially, it’s gathering of organizations that work on a common plan, on common objectives. So Sparkplug Working Group is one of those ndustry collaborations.

Various members come together and set the strategy, the technology vision, and we execute on that. We provide a development process to open source projects, and our specification process for our specification projects. We are there as the vendor neutral and we make sure that everyone plays by the rules and respects the three core values of openness, transparency, and meritocracy. We ensure that no one is taking Sparkplug away from the community. So we hold the trademarks on SparkPlug, for example.

And, anyone can submit ideas and try to influence Sparkplug. Ultimately it is a thing that we at the Eclipse Foundation administer on the behalf of the community. And my role in this as the staff member dedicated to IoT and Edge is really to sit down with HiveMQ and the other members that we have to understand, okay, what are the ideas, what are the needs, what needs to happen in this ecosystem for it to grow. And then together, we establish a program plan, we execute on that, integrate the ideas of everyone, and I make sure that we do that publicly, transparently, and according to the principles of meritocracy. If you are interested in Sparkplug, you start proposing ideas or even making pull requests on the spec or on the open source implementation in Eclipse Paho, then after some time you become eligible to be a committer. And this means you will be treated in exactly the same way as the current committers, and that your organization will derive the same benefits from your membership and your participation in Sparkplug as every other one.

In my nearly five years of experience, all I’ve seen around the table is a willingness to contribute and an openness.

What we provide is this environment where everyone can work on common goals, on things that are shared, and for the rest, we are happy for the commercial successes of our members. We provide the governance layer at the bottom, where everyone is treated in the same way.

And if you want to do open source, there are ways to run Sparkplug with a pure open source stack, and no strings attached as well. So it’s up to you, ultimately, to determine as a Sparkplug adapter, what’s the best product strategy for your organization. But in any case, whatever you do, you’re welcome in the Sparkplug community.

Kudzai Manditereza: How do you see the role of MQTT Sparkplug evolving within the next few years?

Frédéric Desbiens: This brings us to the topic of Sparkplug version 4. Sparkplug goes back to 2016. In version 2.2, the version before it was given to Eclipse, the fundamentals of Sparkplug were fairly well defined at that point. So Sparkplug version 3 was the first version under the Eclipse process. And, we require every device and software to comply with our compatibility kit. Use it to validate that any implementation is fully compliant with the spec and to adapt the Eclipse Paho open source implementation to the last version of the spec. And that took more time than expected, because writing a comprehensive test suite to exercise something with so many features as Sparkplug takes time. In November of 2022, version 3 was ratified and officially announced. At that point, we decided that the time was right to go to ISO/ IEC and proposed Sparkplug as an international standard. And, the process is still underway, so this will take some time. Essentially the national body that represent standard organizations should soon approve Sparkplug as an international standard. That was in May, and congratulations to the community. It’s their efforts that brought us there. So Sparkplug will be also known as ISO/IEC DIS 20237 after the approval. This is a official recognition by the international standardization community. So that’s a fantastic step forward.

By the end of 2023, everything should be complete. I hope it would be officially published. There are some administrative steps that we need to take care of. This brings us to Sparkplug 4. Once done, we will communicate. During fall, we will start communicating more about the scope of the release. What you will see there is really a renewed focus on lightweight messages and improvements that would make it easier even for developers to leverage it and things like that. Sparkplug is intentionally very simple. Currently version 3 is about 130 pages. So the plan is not to make thinghs complex and get it into thousands of pages, certainly not with version 4. Simplicity is still a design goal. So, stay tuned for a more detailed explanation of what the team has in mind for version 4.

So my expectation for the next five years is that we will see an acceleration of innovation in Sparkplug and certainly that we will see major players in the market adopt it. Right now, we have plenty of devices in the field in real world applications. My expectation five years from now is that we will be talking to industry giants, because Sparkplug is simple. It’s lightweight. It solves actual problems. And, I’m expecting that we’ll have lots of major equipment makers and various verticals and even maybe connected cars and things like that. That’s without Sparkplug built in.

Kudzai Manditerza: Certainly! Love to have you here at Landshut. It’s always a pleasure talking to you, Frederic. Thank you so much for coming through. And thank you so much for taking the time to talk with me today.

Frédéric Desbiens: Thank you so much for having me. And I’m already looking forward to my next visit.

Kudzai: That brings us to the end of this session. Thank you so much for watching and goodbye.