Inside Cummins and Portainer: Modular IoT for Software Defined Vehicles

In this episode, I have a special guest for you: the company Cummins. The industry is vehicle manufacturing from Indiana, a global power solutions leader for diesel engines, electrified powertrains, and power generation. They have approximately 70,000 employees, so there is a lot of expertise and of course active projects in industrial IoT. They work with hundreds of OEMs, and their vehicles are extremely configurable. That’s why they need a modular software architecture. Today we’ll learn how they use connectivity devices and container architecture to build a standardized and modular software system. We want to understand how they did it, what obstacles they encountered, and what you should keep in mind when implementing similar projects. We’ll also talk about the results. To answer these and other questions from the community, I’ve invited Carlton Bale, Director of Software at Cummins, and Martin Brown, Software Architect at Cummins. Their chosen IoT partner is Portainer.io, represented today by Neil Cresswell, CEO and Co-Founder.
They are based in Auckland, New Zealand. And as always, you can find implementation details on iotusecase.com and learn more about our community there. With that, let’s start this episode.

Hello and welcome, Neil, Carlton, and Martin. Neil, how are you today? How’s your week going?

Neil

Very good. I’ve spent the week in Germany, which I love, so yes, very good.

That’s nice. By the way, are you normally in New Zealand, or where are you based?

Neil

Honestly, for the last four years I’ve spent most of my time in seat 14A and in hotels around the world. I travel about 270 days a year. But as of this year, I’m now based in Phoenix, Arizona.

Right, cool. And Carlton, Martin, how was your week? And where are you right now?

Carlton

It’s been a great week talking to some of our OEM partners, and we’re going to continue working on what we’ll discuss here today. I’m based in Carmel, Indiana, in the US.

And Martin, are you in the same place or somewhere else?

Martin

I’m close enough. I’m in Columbus, Indiana, about an hour to an hour and a half away from Carlton.

I see. Okay. So where’s your corporate headquarters located?

Martin

In Columbus, Indiana.

Columbus, okay. Greetings to everyone listening and joining us today. Maybe we can start with a short introduction from all of you. Neil, I already introduced you as CEO and co-founder of Portainer. You have more than 25 years of experience in IT and cloud consulting, and you built Portainer to make container management simple and accessible. To begin, how long have you known Carlton and Martin in this project, and how important is this project for Portainer?

Neil

Martin and I go back to the very beginning of the project. I still remember the very first Zoom call with about 20 people asking detailed questions about the product and how it works. I think I met Carlton for the first time last year.
How important is Cummins to Portainer? Incredibly important. Portainer has evolved from a data center tool to an industrial and IoT tool, and the scale increases dramatically along the way. Having hundreds or thousands of devices in a data center is a big number, but in an IoT fleet, thousands of devices are a small deployment — you’re talking about hundreds of thousands or even millions of devices in large IoT projects. Working with Cummins as our co-design partner to make Portainer reliable and scalable at that level has been extremely valuable for us.

That’s great. I’m looking forward to learning more about how you’re doing that and to explore Portainer in detail. To close the round, Martin, let’s continue with you. You’re the lead IoT software architect. Your background is in edge computing, embedded systems, and containerization, and you’ve been at the center of designing Cummins’ software platform. For today’s discussion, would you say you’re the lead architect of the solution — the techie in our conversation — or how would you describe your role?

Martin

Yes, I’m the lead architect for the application side of the software. We’ve divided our work into the application side and the middleware plus the operating system. My manager leads the middleware and OS and oversees the entire solution, but I’ve been leading the application software aspect for the IoT project.

Perfect. And Carlton, you’re leading the future generation of software-defined vehicle development. Your focus is to ensure that the complex and highly configurable engines can be managed through software. Would you say you’re more the visionary, driving the future of software-defined vehicles at Cummins, or how would you describe your role in this project?

Carlton

Yes, that’s a great description. I feel lucky to be in a position where I can come up with these ideas — like running containers on edge devices — and then work with Martin and others to make them a reality. We’re talking about back in 2019. Coming up with the vision of where things need to go is the easy part. The real challenge is driving adoption once the direction is clear.

What should we know about the company? I gave a short introduction to Cummins, but could you tell us more about your core business, your customers, your products, and what we should understand about this project and the company behind it?

Carlton

Sure. The background of our company and this project is focused on commercial vehicles. We work with a large number of OEMs — more than 20 — but we primarily focus on our four biggest ones. The issue we faced was that when we wanted to offer connectivity and telematics features, there were no suitable options available from the equipment manufacturers back in 2012 when we first launched the initiative. So we had to partner with aftermarket telematics providers and write our software for their specific hardware and software environments. That worked fine at first when we had only two partners, but over the following years, the number grew to 35. That meant maintaining 35 different versions of the same edge and connectivity functionality.
When we launched this project in 2019, the goal was to simplify everything dramatically. We wanted a “write once, run anywhere” approach. The best way to separate the application layer from the operating system layer was through OCI containers. So we took a bold step at the time to move away from our legacy embedded architecture and proprietary telematics devices toward a more modular setup, where the application runs inside an OCI container and the application interfaces are clearly defined. We successfully demonstrated that it’s viable to run software this way and began to see industry adoption of the same approach beyond our own company.

Okay, just to clarify the keyword: when you talk about OCI, you mean the Open Container Initiative, right?

Carlton

That’s right. It refers to the Open Container Initiative, a group of companies that define standards for how software can be containerized and run in an abstracted environment. This is very common in the cloud. It was not as common for edge applications, especially in automotive, which adopts new technologies more slowly.

Okay. You mentioned your OEMs. Do you have examples you can share to make this more tangible?

Carlton
Sure. PACCAR DAF is one of our largest OEMs. I am sure everyone is familiar with Daimler Trucks, which has a presence in Europe and the US, and the TRATON GROUP, which includes Scania and International Trucks.

I see. You mentioned connectivity and telematics features and the effort to maintain them. So you have had a lot of maintenance work.

Carlton

In the past, yes. We had 35 different versions of our software. Going forward, we provide our partners with an OCI container. They deploy it to their connectivity device. This solves many problems for everyone. We no longer need multiple versions of our software, and our OEM partners no longer have to coordinate with so many different suppliers that all provide different software packages.

I see. That is also where the business case comes in, I guess. We will talk about this in a second. Can you take us back to the beginning of the project? What is the project about, and how did the partnership between Cummins and Portainer come about?

Martin

Yes, as Carlton mentioned, he had the vision to use OCI container technology on these devices. I was fortunate to be selected to lead the architecture for it. About five years ago, when we decided to use this software and technology, it seemed like all the necessary components were already in place — standardized container packaging, standardized formats, cloud container registries, and local container orchestration and execution. But we discovered one major gap: we had no way to remotely orchestrate containers on the devices. Once these devices are manufactured, we don’t want to touch them physically again.
I demonstrated a proof of concept and a test run with Portainer. Their solution checked almost every box we had. That made their technology the obvious choice. To top it off, when we reached out to other suppliers, they were mostly hands off — saying things like, “Here’s the product, there’s an open-source version you can test, and if you want to use it commercially, come back to us.” Neil and his team, however, were engaged from the start. They acted as if they were part of our team, working through the solution with us even before we had an official agreement in place. That made them the clear choice.

Neil

In the beginning, both Cummins and Portainer didn’t fully know what we didn’t know. We both understood that we wanted to run application containers for telematics and other software, but the question was: how? Once a device is out in the field, physically touching it again is like a product recall — it’s expensive and time-consuming. So the challenge was, how do you make sure you never need to touch a machine again? How do you ensure an application update never fails and is fully atomic? That was a fascinating challenge, and we were excited to dive deep with Cummins to build the future together.

I see. And that’s where you, with Portainer.io, come in — using your technology to enable over-the-air updates in a standardized way, making the process faster, more secure, and scalable for OEMs.

Neil

There was a long list of ideals, and a long list of constraints. It is easy to say you want over the air updates that are atomic, with no other limits. In reality we faced bandwidth limits, data transfer limits, and power supply limits. Most of those issues were present. We had challenges from both sides. How do you deliver a very feature rich solution, and how do you operate it in a highly constrained environment with security, network, and device limits?

Before we dive into how you solved this and share best practices, Carlton, can you summarize the main goals when you started this project? What was important for you, and what had to happen to call it a success?

Carlton

Our number one objective was to prove that this approach to running software is viable. To do that, we had to take something into production. We also had to launch on time. We had a program timeline. Internally there were concerns, because our legacy telematics device used a fully proprietary stack and a proprietary application platform based in Java. We decided to replace the entire stack, including the operating system, build it ourselves, and work with partners like Portainer, while still hitting our timelines. There was skepticism that this amount of work was possible. So we had to prove the concept and rely on our partners to deliver. One interesting outcome was how we used container orchestration through Portainer to control other software in the vehicle. We asked how to update the Linux operating system on our edge device and how to update software in our ECUs. Martin and the team created a novel solution that uses one orchestrator, designed for containers, to update the rest of the vehicle as well.

I see. So the whole vision behind this is to simplify the maintenance process for your OEMs, customers, and stakeholders across the supply chain. Is that right?

Carlton

Exactly. We serve two sets of customers. One group is our OEM customers — we sell our powertrains to them. But ultimately, these OEMs deliver the complete vehicles to fleet operators, and we also provide them with solutions to gain insights into vehicle performance and detect potential failures. Our goal is that no matter how a customer experiences our powertrain, through whichever OEM, they get the same features and the same user experience. To achieve that, we must be able to deploy our software across a wide range of platforms and keep it updated to the latest versions so that customers always have the features they expect.

All right. Martin, how would you describe the technical use cases you’re addressing in this project?

Martin

We started by enabling software containerization and running it on a Linux embedded device mounted on the engine. This Linux device communicates with our engine control unit. One of the main use cases, as Neil mentioned, is how we remotely manage software updates for these Linux devices deployed in the field.
Another key use case is updating the engine control unit itself, which operates alongside the embedded Linux device. The engine control unit doesn’t have direct connectivity, meaning it can’t reach out to the internet to download its own software updates. It relies on the embedded Linux device to handle that process.
So the two major use cases are: updating the telematics software running on the embedded Linux device, which performs the business logic and higher-level features, and updating the engine control unit software through that same device.
As Carlton mentioned, we even published a paper on this topic on IP.com titled “Updating Embedded Linux OS Using OCI Container Technology.”

Okay, that’s great. By the way, is this paper official? Can I link it in the show notes, or is it an internal document?

Martin

Yes, it’s official. It’s published on IP.com.

Perfect. Then I’ll include the link in the show notes so everyone can take a closer look if they want more details. Neil, one question that comes to mind when hearing these use cases: you work with many different customers. Are these typical use cases you solve with Portainer technology, or was this a unique project?

Neil

When we first started, it was completely unique to Cummins. They were clearly taking a market leadership position. Now, similar use cases are becoming more common, but at that time, Cummins was definitely leading the way.

That’s cool. When I hear about all these technical aspects and the scope of the project, it’s clear that this is also a significant technology investment. Carlton, can you explain a bit about the business case behind it? Maybe not necessarily a return-on-investment calculation, but perhaps the business challenges and reasoning behind the project.

Carlton

Sure. One of the biggest differences in the commercial vehicle industry is that it’s extremely cost driven. Fleets operate on small margins and look for every possible efficiency. Most of our decisions are therefore focused on cost reduction. Our edge software can help improve fuel economy or increase uptime so that vehicles stay in operation longer. Both directly reduce operating costs for the fleet.
We approached this project as a cost reduction opportunity. It was clear that maintaining 35 different software versions across multiple partnerships was not sustainable and very expensive. So even though it required a significant upfront investment to create this new software stack, it was part of a broader strategy — to open source some of the interfaces we designed so that they could be adopted by other platforms.
One of our biggest challenges was internal: convincing leadership that we could switch to an open architecture and still achieve adoption. For context, our previous proprietary platform had been in production for two years and still hadn’t delivered all the planned features at launch. There was understandable skepticism. The risk was that if we didn’t meet our production timeline with this new architecture, it would look even worse than before. Fortunately, through partnerships with companies like Portainer and by integrating various open-source solutions into our platform, we were able to accelerate development, reduce risks, and actually meet our production timeline.

Okay, I see. Neil, how do you view that? Do you have anything to add, or does that already explain the business side?

Neil

What I can say is that the time pressure had a big impact on our engineering team. We were constantly iterating and improving the product just ahead of what Cummins needed at each stage. Every time we reached a milestone, new requirements appeared that were worth implementing. So we kept developing version after version to stay aligned with Cummins’ needs. We worked to very tight deadlines. It took about two years to move from the initial idea to a ready, usable solution, but those two years went by quickly with continuous iteration.

Sure. Do you have some best practices? Or can you name some technical challenges you came across in this project?

Neil

We had to create a new version of our agent. Portainer uses a server-and-agent architecture: the server handles management, while the agent runs on the devices and receives instructions. For this specific use case, we had to redesign the agent to handle bandwidth constraints and network uncertainty. These devices are moving at high speed on highways, constantly going in and out of cellular or network coverage. We needed to ensure that unreliable connectivity wouldn’t affect product reliability, software deployments, or anything else.
That was a key challenge for us. In addition, the project had extremely strict security requirements — as you can imagine, for a system that operates in vehicles carrying human lives. Meeting those security standards while keeping everything reliable was a major technical challenge.

That’s really interesting. Many listeners are probably wondering about scaling — how to ensure the solution can actually scale as you mentioned earlier. You have hundreds or even thousands of devices in the field that need to be managed simultaneously.

Neil

Scaling is hard. The main challenge is concurrency. When you have a hundred devices and send instructions, you can randomize the timing to avoid network storms or collisions. The chance of several devices acting at the exact same moment is low. But when you have a hundred thousand devices, the probability of simultaneous actions rises dramatically. Then you face questions like how to manage database writes and locking mechanisms when many devices act concurrently.
As Cummins deployed more and more devices, this challenge kept growing. We had to redesign several elements of our internal architecture to support IoT deployments at that scale. The benefit was that these improvements made the entire product much more robust for all our customers, not just for Cummins. Portainer is now far better equipped to handle concurrency and large-scale operations.

Right. And from Cummins’ side, do you have any practical comments on that? Would you agree, or are there other aspects you would add?

Martin

The scalability of Portainer directly affects our devices because if Portainer can’t scale, it can’t manage them. Portainer aims to be completely atomic so that if something goes wrong, it’s not due to Portainer.
Once Portainer sends the software updates, the rest is up to us. We want our software to recover automatically from failures or update issues.
This adds another layer of complexity because when developing software without considering hardware, you don’t face these types of problems. But when security, hardware, and remote accessibility all come into play, you must ensure that you can still reach the devices and push updates. If you can do that, any problem that occurs can be fixed remotely.

I see. Neil or Carlton, what kind of product are you using from Portainer here? How does Portainer ensure that the solution works not only on a single asset but also scales efficiently across thousands of vehicles and different OEMs? What is the product behind it, and how does the solution work in practice?

Neil

Portainer has two main products: our open-source version and our commercial version. The open-source product is designed for experimentation and is community supported. It’s built and maintained by us, but it’s meant for the community rather than for official enterprise use.
The commercial product, called Portainer Business, includes a much higher level of quality assurance, testing, and security compliance — everything required for proper enterprise-grade software management. Portainer Business is the server component, and then we have agents, which are small pieces of software that run on the devices in the field — in this case, on the powertrains. These agents enable secure communication between the Portainer management server and the devices. They ensure that the software is correctly deployed and running, while also sending back status and health information to keep the server up to date.

Cool. And when you talk about the community, do you have any KPIs on how large it is or how many people are using it, just to get a sense of scale?

Neil

That’s getting harder and harder to measure. We have some analytics built into the product, but most users disable them. Based on the ones that remain active, there are around 1.4 million Portainer Community Edition users logging in every month, and over its lifetime, there have been roughly 3.4 billion downloads. So it’s quite large. In the paid enterprise version, we don’t track analytics at all because customers pay for full privacy and operate in secure networks.

I see. To conclude, why did you choose Portainer, and what are the results so far? Could you share a bit about the outcomes and where you’re heading next?

Martin

Yes, I can talk about why we chose Portainer, and maybe Carlton can go into the results since he has a broader view. As I mentioned earlier, our decision was based on both the technology and the people behind it. Technologically, Portainer did exactly what we needed. Neil mentioned there were some gaps early on, but at a higher level, the software was exactly what we were looking for once we tested it.
It was actually hard to know what we truly needed before trying these tools, because we didn’t yet know what was possible. We didn’t want to spend time designing everything ourselves, so we test drove several solutions that claimed to manage OCI containers on edge devices remotely. Once we tested Portainer, it was clear how well it fit. We quickly narrowed it down to two options, and after speaking with Neil and his team, it was clear that Portainer was the right choice.

Carlton

As for the results, it’s far more convincing to show partners what we have running in production rather than just presenting a PowerPoint concept and promising it will work. Having a successful production launch, achieving the scale we aimed for, and realizing the software reusability we wanted all demonstrate that this open solution is viable.
We’re now seeing significant adoption of OCI containers across the industry as a standard way to deploy software on diverse hardware platforms. We’re also contributing our experience and developments to the Eclipse Software Defined Vehicle Working Group, sharing interfaces, APIs, and transport mechanisms as open source. This helps build a broader ecosystem that extends even beyond commercial vehicles.

And since you mentioned this ecosystem, you’re building partnerships not only with Portainer but also with others. Is part of your strategy to work more closely with your OEMs and other partners in this way?

Carlton

Yes, absolutely. We’re taking two parallel approaches. One is open collaboration with peer companies such as Bosch, ETAS, Elektrobit, and Allison Transmission to co-develop these capabilities through open source and demonstrate their maturity and viability as they evolve. Some of our OEM partners are already joining this open collaboration initiative as well.
The second approach is working privately with our OEM customers on specific implementations. That includes advising them on their own adoption journey, sharing lessons we learned, and helping them integrate and run our OCI or Docker-type containers on their devices.

That sounds like a strong vision for the future. This leads me to the last question for today’s session. Looking ahead to the next four or five years, what do you expect for this project?

Carlton

Of course, we have ongoing implementation plans with our OEM partners, which will continue to expand as new products are introduced. But in terms of broader collaboration, as I mentioned, we’re working through the Eclipse Software Defined Vehicle Group and COVESA, the Connected Vehicle Alliance.
We’re contributing to projects like uProtocol and S-CORE, which are developing ways for applications to communicate seamlessly across all the different domains within a vehicle. We’re not only contributing but also adopting these technologies for testing and, eventually, production use.
The goal is to build a shared infrastructure layer for IoT — a common framework that’s not unique to any one company but can be used across the industry. That allows us to shift our focus from infrastructure to the applications that run on top of it, because that’s where the real customer value lies. So in the next few years, I see the industry moving from building the foundation to creating value through applications and services built on that shared framework.

Perfect. And for everyone listening, I’ll include all the links in the show notes — the initiatives, working groups, and further information mentioned today. If it’s fine with you, Carlton, Martin, and Neil, I’d also like to include your LinkedIn profiles. That way, anyone who’s working on a similar project or wants to discuss a related approach can easily reach out to you directly. Is that okay?

Carlton

That would be fantastic.

Neil

Absolutely.

Martin

Yes, that’s fine.

Great. So, Neil, my final question goes to you. What can we expect from Portainer.io in the future? What’s next for you over the next five years?

Neil

Well, we never really stop developing. Software projects are never truly finished — there’s always something new and exciting to improve or add. Scaling remains a major focus. Right now, we’re confident in our ability to handle the scale that Cummins requires, but we want to reach ten times that in the future. Our goal is to build an architecture that remains reliable and secure even when managing millions of devices. We’re currently exploring the container runtimes used at the edge and how we can optimize them for even greater scalability and robustness.
Historically, Docker was used at the edge. More recently, Podman has gained traction, and now Kubernetes is also appearing in edge environments. As the ecosystem evolves, we’re asking ourselves what this really looks like in practice. Kubernetes was originally designed for data centers, not for very small, resource-constrained devices. So how do we make it work reliably in that context?
We’ve already started a project called KubeSolo.io, which is our first iteration of bringing Kubernetes to small devices — still Kubernetes, but adapted for constrained environments. We’re also working on simplifying the Portainer UI for the actual end users. In Cummins’ case, that means the internal business users who simply want to deploy software and make sure it runs. Currently, the interface still exposes too many technical details, so we’re creating a more focused version that fits the needs of those internal users better.

That sounds amazing. Maybe we can plan another episode in a year to get an update on these developments. There’s clearly a lot happening and much more to come. For now, thank you all for this session. From my side, I’d like to say thank you again for joining today, and with that, I’ll hand it over to you for the final word.

Neil

 If you think back to the start of this project, the foresight and vision it took to take a technology that was still quite new in data centers and bring it to the edge — into vehicles — was incredible. For a company like Cummins to even consider that idea was impressive. And for the individuals involved, it was a personal leap as well, trusting and believing in what this technology could become. Hats off to Cummins. You really caught our attention with that vision, and anything we can do as a company to support you, you’ve got it. It was a bold move.

Martin

Yes, and it’s good to see you again, Neil. We’ve been working together on and off for the past five years, and Portainer really took that leap of faith with us. You helped us develop this solution, and we’re looking forward to continuing the collaboration with you and your team.

Neil

Thank you for the opportunity.

Carlton

Thank you.

Thanks for this session and have a great rest of the week. Bye-bye.

Martin
Goodbye.