The Embedded Frontier

#010 - Top Trends in Embedded Systems for 2025

Jacob Beningo

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 36:38

In this episode of Embedded Frontier, Jacob Beningo discusses the top trends in embedded systems for 2025. He highlights the increasing role of AI and machine learning, the dominance of open-source software, the critical importance of security, and the ongoing relevance of programming languages like C and C++. Beningo also emphasizes the rise of simulation technologies, the integration of DevOps and observability, and the expansion of edge AI, providing insights into how these trends will shape the future of embedded systems development.

Takeaways

·      AI will enhance embedded systems development.

·      Machine learning applications are still underutilized.

·      Open-source software is becoming increasingly dominant.

·      Security is a top priority for embedded systems.

·      C remains the most widely used programming language.

·      Simulation technologies will modernize development processes.

·      DevOps practices are essential for improving software quality.

·      Edge AI will allow for local data processing.

·      Modern programming languages will see increased adoption.

·      2025 will bring significant changes to embedded systems.

Keywords

embedded systems, AI, machine learning, open source, security, programming languages, DevOps, edge AI, simulation technologies

Jacob Beningo (00:00.514)
Hello and welcome to the Embedded Frontier, the podcast where we dive deep into the ever evolving world of embedded systems. Whether you're an experienced engineer looking to stay ahead of the curve, a newcomer eager to learn, or a director looking to understand the latest industry trends, this podcast is your gateway to understanding the intricate world of embedded systems. I'm Jacob Benigno, CEO and founder of Benigno Embedded Group. We're an embedded software consulting and education company.

dedicated to helping teams and developers modernize their processes and enhance their skills. Our goal? To empower you to succeed in your career and projects by developing affordable, reliable, and secure products efficiently and on time. Happy New Year. I hope that you had a wonderful holiday season and had the opportunity to take some time off and relax and recharge. I know certainly I had the opportunity to do some of that.

and came up with all kinds of interesting things of where I think the embedded systems industry is going to be headed over the next year in 2025. There's a lot of exciting things happening. And if you look at individual industries, there's just so much going on. But what I thought we would do to have a little bit of fun here on our first episode back for the year, is to look at what I think are going to be the top seven embedded software trends that we should all be watching this year in 2025.

All right. So with that in mind, let's dive in and see what I think those seven are going to be. All right. So the first one is that I of course see, and everybody sees, you could even go out to the, you know, look at wall street today. And once again, it's all AI and tech, right? And of course, even within the embedded systems industry, I think what we are going to be seen is a lot of AI this year. Okay. Now I think the future of embedded software development is in artificial intelligence. It's in machine.

learning and using those types of technologies to help us accelerate and improve the robustness of our embedded systems. Now, I know over, you know, just at the end of last year, there were interesting announcements like from Microsoft saying, hey, you know, we now have a AI employees and things like that. So just a topic of AI might be a little bit nervous, nerve wrecking for some individuals and companies and things like that. But one thing I do want to point out, I think in my experience with AI so far.

Jacob Beningo (02:25.856)
I see AI always works best when coupled with a human, right? You're not just going to tell AI, hey, I want this. And it's just going to go out and do it perfectly. What I have seen is that when I use AI and when I work with teams that are using AI, we use it to enhance and accelerate what we are already doing. It's not just going off and doing its own thing. It very much is a tool for us to use to be better developers. Okay. And in the embedded systems industry, we're going to see AI used, I think, in that way. There's actually two different ways we're going to see AI used. Okay.

First of all, I think AI is going to be used to help us debug our systems, to accelerate development. There's actually a whole bunch of cool things going on with AI agents where you can actually task them to do some things for you, generate code and do those types of things. So I think we'll see a lot more of that this year. Although I think there's going be a lot of hesitancy because AI, while it can help you accelerate your development, there are things that are going to make you go, can we actually use this? For example, with code generation,

A lot of those AIs are trained on public code, open source, right? And there's licensing associated with that. And what you will find is that companies are a little bit skittish. Can I actually use that code? Is it copyright? Am I adhering to the licenses? Are we going to get in legal trouble from using that AI code, right? AI generated code. So there's a lot of question mark of, can you really use that code in your projects? If you're just experimenting and you're a hobbyist, the answer is, yeah, of course, go ahead.

But if you're producing production systems, that might be a totally different question, right? Now, I think in those types of situations, creating your own AIs based on your own coding standards, the code that you've generated internally as a company, that I think is probably a very good approach. I'll be honest, I've used that type of approach with some of the AI code generation that I've done. I have a very specific style and way of things. I like to do things, which tends to be a little bit different than the way open source community does it. Okay.

And so what I have found is that I can train, you know, models to be able to generate that code the way that perhaps I would like to see that code generated. And because it's based off code that I've written, I know that I own the copyright for it, and then I can use AI to generate it. Okay. So that might be one way to get around one of those major concerns. Now, on top of that, we have to think about AI, you know, from a code generation standpoint, certainly, you know, you don't want to trust the code. You still want to go through code reviews. You want a human involved, but at the same time, AI

Jacob Beningo (04:51.95)
is an acceleration tool. OK. Think back to when you developed your first USART or your first I2C device, right? You wrote the driver, you learned how the peripheral on the microcontroller worked. That was really exciting, right? You got it working and it felt like you accomplished a lot. You had just written a driver. You knew the microcontroller. You knew software. You knew C, maybe C++. That was a huge milestone for you, right? But then maybe the next time you do it in your career, you you kind of polish your techniques and what you want to do.

But by the time you probably have to write a driver like a USAR or I2C for the third, fourth, fifth time or something like that, it gets kind of old, right? Which is why a lot of times we just use what the vendors provide us, right? NXP, STMicro and pick your favorite silicon vendor, they all provide us with libraries that work good enough for a lot of situations, right? Which is why we leverage their code rather than writing it from scratch ourselves every single time. Well, AI is going to provide that type of level of...

Support for us, right? Now, while we might sometimes look at what the vendors provide and say, well, this isn't really what I want, we can always take that code, maybe augment it with AI, right? And again, oversee it. OK? So AI, think, really has the opportunity to help not just write code for us, but to help us really debug our systems and even give us new ideas. I can tell you how many times I bounce ideas off of AI. Most of the time when I get back, to be honest, it's not necessarily the greatest thing. OK?

but it might spur some other idea that allows me go down a path or it might allow me to test my thinking. Hey, I'm thinking about going down in this direction based on this set of inputs. Does this seem like everything? What am I missing? Right? Or you can have a chatbot that you tell it to challenge your expectations or to challenge your core assumptions with some idea or concept that you're working on. And what you'll find is that you can get a pretty good back and forth where it helps you think

a little bit more qualitatively and quantitatively about what is going on in some project that you are working on. Okay. And so I think AI from that perspective is going to be a major technology for us to watch, especially as teams learn how to automate and create agents that will be able to automatically carry out tasks for you. Okay. know, a perfect example within a business is, you know, if you're an embedded software developer, maybe you want some AI agent to be able to manage your email for you, right? We all get so much email.

Jacob Beningo (07:11.484)
How do know what is worth you looking at? What isn't? Organize it, all that stuff. You could spend hours every single day just managing your email. But pushing that kind of thing off to let an AI agent do it frees you up to do more embedded systems development, more software, more research, and of course, more innovation for your products, right? Because at the end of the day, what are we trying to do? We're trying to deliver a product for our customers to make their lives easier, to perform useful work and that sort of thing. Okay?

Now, that's the first area of AI that I think there's going to be a lot of impact. OK. The second one that I'm still I still think it's extraordinarily important, but I for some reason see it struggling to catch on is machine learning. Machine learning isn't where we're using these large language models to try to automate work or make our development processes better or improved or anything like that. Right. What we're trying to do is use artificial intelligence, specifically machine learning to

write algorithms for us to actually run on our embedded systems. Examples like keyword spotting, or detecting an object within an image. Those types of things are extraordinarily important. And while I say I don't see a lot of that happening within the systems that maybe I'm working on with my customers, there are lots of applications for that type of thing to be happening in embedded systems like door locks, security systems, and all kinds of other things like that.

I have been seeing some experimentation being done in some of the systems I work on in the space systems industry and in defense where we're using those types of things. But some of the general consumer electronics, I've been surprised to see not as much machine learning happening on our microcontroller based devices, at least for production based systems. I suspect in 2025 that is going to change. OK, there are a lot of great tools out there today that you can use to make creating your own models extraordinarily easy. You know, one of the ones that comes to mind is Edge Impulse.

I think those types of tools make it very easy for you to collect data, generate a model, train it, and then deploy a very robust or at least a very efficient model to your embedded target. Okay. So those are, think, two really big areas, AI, machine learning. It's a major trends for you to make sure that you keep your eyes on them as the year progresses. Okay. So I think that's going to be really important. The second is

Jacob Beningo (09:32.948)
something that is a trend that has been going on for a very long time. OK. And this trend is, think, open source dominance. know, open source software has been something that many companies have looked to to help accelerate development. Lots of companies get involved in open source software development. I think it's actually a great, know, it's a great thing for developers and companies to do. It produces a lot of very good software that people can use without having to continue to reinvent the wheel, essentially. Right.

Who wants to create their own RTOS internally in their company? Well, it would be very fun. There's a hundred or more RTOSes already out there that are open source that people have already put the work and the money into that you can just go and use to develop your systems. For example, FreeRTOS is out there, ThreadX is out there, Zephyr as well. So there's lots of different open source solutions out there.

Now, I actually think one of the ones that kind of make me say open source dominance in this particular case for us embedded software developers this year is I actually think while commercial RTOS is very much outperform in an open source RTOS. And you can say, hey, Jacob, wait a minute. We love open source. What are you talking about? Commercial is better. Well, if you've been following my LinkedIn feed at all, you saw that last year at the end of the year, towards the end of the year, I released an RTOS performance report.

where I actually went out and I analyzed Zephyr, FreeRTOS, ThreadX, and then a commercial RTOS as well, PX5. And from there, I looked to see which ones had the best scheduling cooperatively, which ones had the best performance for preemptive scheduling, what about for queue and memory management, and so on and so forth, right? And what I ended up finding was that the commercial RTOS is performed better than the open source ones, okay?

They just, you know, they were tuned better to work on a microcontroller. so PX5 ended up being the best one, performance wise, followed by ThreadX, which at one point was commercial. And, you know, they were both written by Bill Lamey, right? So he had the experience and the knowledge to be able to develop a very efficient and robust real-time operating system. Right. And so we saw those. And then from there, we saw kind of a flip-flop back and forth between

Jacob Beningo (11:54.08)
FreeRTOS and ZephyrRTOS. OK. Now, what exactly does that mean? Well, in general, I think that's a good, you know, let's put our fingers on the pulse again, right, of open source software versus commercial software. There's always this battle of do you buy it or you just use open source software? And I'm not saying that open source software is bad by any means. I'm saying the trend you should be watching is that it is the it's dominance, I think, is here for good and to stay right.

You know, we're seeing a lot of people jumping on the bandwagon for Zephyr Arthos. There's a lot of buzz around it. It's one of the most popular projects for commits and updates, you know, supporting something like 300 plus boards. So there's a lot of momentum behind it. Right. But one thing that I always want to stress for you as a developer, even though open source is going to dominate, I think our headlines and the, you know, even the code bases that we develop.

and use where we're going to be using these external components that are open source. It reminds us that we do have to make sure that we do our engineering due diligence. We have to look at those code bases and understand what are their performance. What is the technical debt that I am inheriting when I put those into my system? Well, sometimes it can seem like a great idea to go and, you know, post some open source code into your software and you deploy your product and it helped you accelerate and save some money and you didn't have to pay for it and all that fun stuff. It can add technical debt like security.

It can add maintain maintenance problems, right? Long-term that does affect delivery schedules and cost of your overall product. So you have to keep those types of things in mind. Okay. And when you evaluate a piece of software, you know, is it, does it match what you actually need at the end of the day? Okay. Now I'm not saying one way or another that, you know, commercial is better or open source. It really depends on what it is that you're doing. Right. And that's probably, you know, the response that we all.

hate as engineers always get are when we have a question and we want it answered. It depends. It's probably the most frustrating yet most realistic or correct answer to give folks. So open source, it's going to continue to dominate. think we're actually going to see Zephyr RTOS continue to gain market share. I think you're going to see a lot more people using it, experimenting with it. And it's going to be extraordinarily interesting to watch and see where that goes. I'm so convinced that we're going to have a lot more people using it that I'm actually

Jacob Beningo (14:19.836)
I'm going to be running a Zephyr webinar here on January 22nd. So if that's something that you're interested in, can check out my newsletter or go over to Beningo.com and sign up for my newsletter. And what you'll find is I'll be sending out and reminding people about that here shortly. And I'll try to put actually the registration link with the notes here so that if you are interested in attending and learning a little bit about Zephyr RTOS and open source development, then we'll do that then. It's very interesting.

There's a, it's actually kind of a combination of, and I digress now, right? But we are talking about open source. So it is very interesting because it very much has a Linux style to it. You have a device tree, you have Kconfig. Someone who is working with Linux typically would feel very comfortable developing applications using Zephyr. Okay. Now what's interesting about that is that you end up with the ability for Zephyr to open up the, you know, the number of people that can develop with it.

We have traditional embedded developers and you have Linux developers who can now do real-time stuff using Zephyr RTOS. But there is a learning curve for us embedded folks who aren't used to the way Linux does things. We're not used to the device tree. We're not used to KConfig. So there is a learning curve there. And that's what you're going to find over 2025. You'll find me doing several webinars and workshops trying to help us, typical real-time embedded developers, learn how to get past that learning curve so that we can be efficient and effective at.

I'm using Zephyr RTOS. Okay. So again, digress there a little bit. Sorry about that, but I think it's useful information for you to have. Okay. Now the third trend that I think you need to keep an eye on, which we all should have been keeping an eye on probably for the last decade or more, to be completely honest, is that security will be king. I think the biggest headlines last year have all been associated with security breaches, security issues of pushing firmware.

to devices that then crashed, right? We saw all kinds of issues going on with the Windows update that took down millions of devices, took out Delta Airlines, even though that wasn't a security issue, to some degree it was a process-related issue, right? They were doing updates and managed to have one that kind of broke the machine, right? So what we're gonna find here, especially as many...

Jacob Beningo (16:47.862)
developers are starting to adopt open source software and put them in their embedded systems, which we already are, right? Security is absolutely critical. And while we've generally been able to ignore it, there are a lot of, there's a lot of legislation from Europe, from the US that is forcing regulatory compliance. Okay. And those types of things are not going away. This year we're going to, I think, find that security is a high priority for a lot of teams.

And so, you know, security and open source, while they might seem like they contradict each other, they actually do go hand in hand. Okay. So when you have open source code, typically there's more eyes on it. You know, hopefully that leads to fewer vulnerabilities, you know, over time, more robust detection of issues. Certainly some of the things I'm seeing coming out of open source, out of the Linux foundation, out of the Zephyr RTOS project are things like SBOMs. Okay.

Software Bill of Materials. So we're all used to normal hardware-based bill of materials if we're developing an embedded product, but there's also a software bill of materials. And so this is where you can actually keep track of what third-party software you're integrating into your embedded systems. You can actually create an SBOM. Sometimes you'll have to have these types of things if you're doing medical devices and you're trying to go through the FDA compliance, you have to have a bill of materials for your software. This is the software we have. This is what we're tracking. We're keeping track that if...

some software stack that you're using that uses MQTT has a security vulnerability that's discovered, right? You want to be look at your SBOM and be notified that, there's an update to this library because of a bug that was found, okay? So I think you're going to find that, you know, adopting SBOMs is going to be very important. Secure firmware updates. I know a lot of times developers don't think about their firmware over the air updates. They don't think about, you know, very early, for the moment they start designing their system about the security threats.

about how they're going to manage their device through the entire device lifecycle. Those are things that I think are going to come into a much higher focus this year. Okay. Along with the tools to help us validate the security of our systems a lot sooner. DevOps is a great opportunity to leverage those tools, analyzing your software to make sure there aren't security vulnerabilities, right? Constantly, right? In addition to making sure that you have secure open source stacks,

Jacob Beningo (19:13.81)
and that they meet requirements from regulations like the Cyber Resilience Act. So security is really important. It's actually a foundation of all embedded systems development. So make sure that you don't ignore security this year. Okay? I don't want you or your team or your company to end up as a headline on the front page of whatever news app you're using because you didn't pay attention to security and bad things happened.

you know, don't allow obscurity or the fact that you only have a few thousand devices out there, make you not look at security. Okay. Because that is almost a sure fail safe sign that you should get, you know, that you're going to get yourselves into trouble. Okay. Just to give you, share a little story one time about a security incident that, that I happen to see. We were, was working with a company one time and we had this Linux based machine. Okay. This is part of like a flight computer for some system that we were working on.

And I was going to be traveling for a week or something. And we was like, oh, well, I want to be able to work while I'm on the road. And they're like, oh, yeah, no problem here. We'll open up the port and make the device available so you can log in and continue to test some software and stuff like that. Pretty standard. All right, cool. Well, they ended up exposing the Linux flight computer publicly on the internet for about 24 hours. Not a very long time. It was over the weekend when they first opened it up.

And what ended up happening was that even though this was just an obscure Linux machine amongst billions and billions of devices on the internet, within 24 hours, some Chinese botnet discovered it and that it had its default root password. And what happened, of course, you know, it was hacked. became part of this botnet and it was just amazing how quickly that device was found. Okay. It was a one-of-a-kind device. Yes, it was using, you know, generic Linux and stuff and certainly security, the right.

proper security procedures weren't followed, but that's why obscurity or just thinking, oh, I'm just one device out of billions, no one's going to see or find my device. It's not true. You will be found in 24 hours. Okay. So keep security at the forefront of your mind. Okay. Now, another trend that I am seeing in our industry that is to me, extraordinarily fascinating. When I graduated from high school in 2000 and it kind of

Jacob Beningo (21:42.06)
between 2000, 2004, when was in college and learning my embedded system skills and stuff like that, right? C was the dominant language, right? And there was all this talk about how C++ was gonna dominate the embedded systems industry, okay? And we fast forward 20 years now, okay? I've officially been in the industry for 20 years as of December professionally. And what I ended up finding is that C going away,

is not something that has happened by any means at any accelerated rate. Okay. Well, I think many of us can argue that a modern programming language like C++ or Rust can dramatically help us improve efficiency, help us improve the robustness of our systems. I don't see a fast transition within our industry. Okay. We'll see web apps, we'll see Linux, we'll see all kinds of things move to Rust or C++ long before I think most embedded devices do. Okay. Now, while I say that,

There's probably still about 60 % of systems today that are using C as their programming language. And that's fine. If you know how to use C, I'm not saying that that's a bad thing, right? We know where all the problems are with C. It makes it a well-known problem, right? As long as we're following the right processes, we can continue to use C. The transition from C++ to C over the last 20 years has actually been extraordinarily slow. When I started in the industry 20 years ago, there were probably 85 % of systems were actually built using C at that time.

And there was something like 10 % was in C++. Today, 20 years later, those numbers are more like 62 % are in C and something like, you know, let's say 23 % are in C++. And then, you know, the rest is kind of a scatter of languages like Python, MicroPython, and a little bit of Rust and stuff like that. Okay. So what the trend that I think is happening, I think there's going to be a little bit of an acceleration away from using C into languages like C++ or Rust. Okay.

And I think that there's going to be an accelerated rate. We could say over 20 years, C has lost market share by about 1 % per year. I think it's going to start to accelerate. We might start to see 2 % and then 3%. While Rust is a very interesting language, it's not mature enough yet. Okay. I see a lot of cool things going on. Last year we saw, you know, safety critical compilers that were released for the first time. We see working groups for ISO standards for Rust and things like that. But at the same time,

Jacob Beningo (24:07.638)
You know, I've worked with teams who have experimented with Rust. I've played with Rust a lot and kind of generally everyone's very excited. It's very cool. But between the learning curve and some of the problems with the language and trying to apply to embed it and you you still end up with issues that you have to figure out how to work through. Okay. And the problem is, is you don't know what issues you're going to have because those haven't all been figured out yet. Unlike when you're using C or C++. So I actually think you're going to see a rise still this year of a trend of the rise of modern.

languages, although I think there'll be more of a transition from C to C++ and perhaps even the rise of modern languages where C forms the foundation of our device. OK, it's our low level drivers. It perhaps we bring in legacy code that's in C, but we actually start to build our application code in C++ and Rust. So the future, I don't think is going to be a single programming language. I think it's a combination of using multiple languages in the domain.

of our embedded system where it makes the most sense. So instead trying to use Rust at the low level, we use C. Then we expose it through safe APIs that allow us to write our application code in Rust. That's kind of the idea. Or we are writing our applications in C++, and maybe we still let our drivers be written in C. Because we're not going to go rewrite all of our code in C++ and Rust for low-level drivers. The vendors are providing a C code. And it looks like they're going to be doing that for a very long time yet.

So from there, you know, I think we're going to see that. And keep in mind, our processors are getting faster, right? There's things like Cortex-M23s out there, the M33s, the M55s, the M85. There's all kinds of very fast real-time embedded processors out there that, you know, we're not working in these little resource-constrained devices anymore. So even using a little bit more of a modern language that maybe has a little bit more overhead than C, you may not notice the difference, okay?

So keep that in mind. An interesting trend to be watching. I actually think we'll see Rust enter into the top 10 most popular programming languages this year. I'm not going to say when I think that will be, but it will be, think, sometime in 2025. So if you haven't started to learn Rust, now might be a good time to put it on your list. As in embedded, we won't adopt it, obviously, probably for several years yet, but it gives you a little bit of time. OK, so one more, another trend.

Jacob Beningo (26:30.436)
My fifth trend that I see for 2025 is an increase in simulation technologies. Now, the reason I see this trend, I really see the development of embedded systems, especially since all of our systems are becoming so much more complex, right? There is a trend of modernization, okay? And part of that modernization trend is leveraging simulation. Now, simulation can be using technologies such as Renaud.

or, you know, arms hardware, you know, virtual hardware. It can be as simple as creating your own little models using web technologies to interact with your embedded system. Okay. One of the simulation technologies that I use a lot is I don't go out and try to simulate the actual hardware, you know, or run like I'm simulating on chip or things like that. What I actually do is I write my code and let's say I'm writing in C. I'll write my code in C and I'll create a nice architecture.

I'll create a nice layered architecture that decouples the hardware from the actual application code that I'm writing. And you can do this in C, C++, Rust, whatever. And behind that hardware abstraction layer, what I do is I have the option to use my build system so that I can successfully compile for the target on hardware. But I also have it so I can create a simulation build. And in that simulation build, I might replace behind that hardware abstraction layer, I might replace a, let's say, a USART

driver or let's say I have a driver that talks to a, let's say it's a sensor, let's say it's a temperature sensor. Okay. So instead of talking, you know, instead of having to have physical hardware there to go out over I squared C and then, you know, talk to this device and then, you know, pull the temperature data. I look at the application code and the data it's getting from the hardware as just, it's just data, right? And so what I do is I try to look at the data flow for my software architecture, but when I implement it,

I can build it in such a way that when I make a call to that sensor in my application code, it goes through the hardware abstraction layer and then maybe it uses web technology. Maybe it's MQTT or maybe it's a, you a lot of times I like to use socket communications. They're relatively real time that you can get a response to and from a server and a submillisecond timing, which emulates a lot like you're going out and talking to a, you know, an I squared C device or, you know, something on an external bus. And so,

Jacob Beningo (28:53.976)
I'll have often set up a WebSocket communication with a server that will feed the temperature data that I want to the device over a WebSocket, and then the application code gets it, and then I can test for interesting error conditions or boundary conditions that are very hard to simulate and create in hardware. I can very easily do through socket communication. Okay? So I think the use of any type of simulation technology, you're going to start to see increasing over 2025.

There's great open source tools, QMU, Renode, things like that. And like I said, just leveraging web technologies can really help you simulate your device a lot faster. And one of the advantages to doing that is that it actually, you architect your software properly, if you want to use simulation technology, it forces you to architect your software properly. It forces you to adopt a modern build system. forces, you know, from that, just from those things, it allows you then to have a system that's actually more testable, right?

Because if I have nice abstract abstractions like that, good hardware abstraction layers, then I can actually test the software using unit tests. I can have different hardware and loop builds. And it really, you it allows a lot of modernization of how you develop your systems. OK. And so I suspect that we're going to see a huge increase in the use of simulation technologies. OK. And we've been using them, you know, in tools like MATLAB and in state machine type simulation scenarios. Right.

But I think we're going to really start to see some of that expand this year and adopted by a lot more teams. The kind of leading into that is probably what I consider to be, you know, the overarching trend is that there's a modernization going on, right? A lot of software developers, I think, are modernizing how they do things. And the sixth trend to watch is DevOps and observability. Okay. These are trends that I think were really being pushed. And I saw we're very loud in 2023.

and into the early part of 2024. And then I kind of saw it kind of a quieting down, okay, in the back half of last year. But I suspect that we're going to see a big push of, again, leveraging DevOps appropriately in the embedded systems industry, automating tools, building in security, all those types of things. I think one of the big pushes for this year is actually maybe not so much setting up the DevOps pipelines. I think that's why maybe things got a little bit quieter in the back half of last year.

Jacob Beningo (31:19.94)
But I think observability is going to be an important trend for this year. Now, when it comes to observability, we're talking about the ability to deploy a device in the field and observe its behavior, to collect data, to get that feedback pipeline. If you think about DevOps, there's the... You can think of it at the top, maybe on your left-hand side is you as a company and the right-hand side is you trying to deliver to your customer. And you have a pipeline that runs from you on the left to your customer on the right where you're delivering software to them.

And that's your DevOps delivery pipeline, right? This is where you have for more of the air updates. You're pushing through a build server, you're running tests, you've got a metrics dashboard set up, you're improving the quality of your software and you have incremental releases to the customer, right? Well, that's a one-way pipeline. We really need the feedback from the customer to us to also be there so that we can have, so we can deliver what the customer actually needs, right? And so that...

Feedback pipeline is the observability pipeline. It allows us to monitor the device in the field, understand how it's behaving, how the user is using the devices. This is something that's done by large companies, by companies that are building devices that aren't so embedded. They're using full on operating systems. So we don't see a lot of that maybe with RTOS based systems or bare metal systems today. But I think this is going to be a very big trend for this year.

Okay. Where we're going to see a lot more resource constrained devices, adding observability into their development processes so that they can get that feedback. So they can see what bugs are happening in the field. See anything that's happening that's not right on their devices, getting that feedback so that they can then complete the feedback loop and push higher quality software to their customers. Okay. Now, know, don't know that DevOps and observability will necessarily be

you know, giant buzzwords for this year, but I think they're going to be those practices that a lot of companies are going to be adopting. And it may just be kind of a quiet revolution in adoption, right? So keep your eyes open for that. think that's going to be an important trend for us this year. And then I think the last trend that I'll talk about, and I kind of already talked about this trend a little bit when I talk about just normal AI, is I think we're going to see an expansion of edge AI.

Jacob Beningo (33:44.42)
Okay. Today, lot of embedded systems will push their data up to the cloud to get it analyzed. I think you're going to see a lot more edge AI work. Instead of pushing the data up to the cloud, we're actually going to have that data pulled, that data stay locally on those edge devices. I think, again, when you look at how powerful the ARM Cortex-M parts are becoming, you see the release of parts from like NXP and ST. They're including neural processors.

and other technologies that allow them to process neural networks on chip. As those parts become more more available to us, I think we're going start to see those types of, a lot more AI running at the edge on these resource constrained devices. Okay. So with that in mind, what will 2025 look like for embedded, the embedded systems industry? Honestly, it'll probably look a lot like it did last year, right?

We're still relying on very similar tools like we did before, very similar types of processes. And honestly, the languages that we're using will probably continue to be C and C++ with some cutting edge teams playing around with deploying Rust-based applications. But I think overall, forward-looking organizations are going to be looking at these trends that we just talked about, leveraging simulation, improving their processes, using modern techniques.

And I think really modernizing the way that they build embedded systems. OK. And that modernization can start happening in your software architecture with the use of architectural caddas, architectural design records, you know, that just keep track of your design decisions versus trying to maintain lots of documentation. Right. All the way through, you know, different language support and getting DevOps and observability really integrated into your entire

development processes and systems. So, so with that in mind, I think that we are going to see a lot of interesting things happening this year. Now, you know, the only question I think you have to maybe be asking yourself is whether you're going to continue to develop your systems the way that you always have been for years and years, or whether these emerging trends are going to be something that you adopt and allow them to help transform the way that you develop embedded systems. So take a little bit time to think about these trends I've talked about.

Jacob Beningo (36:10.2)
Do they apply to you and what you're doing? Can they help you develop better embedded systems? If they can, I highly encourage you to start investigating them, start building them into your development processes, or at least get them on a list to start looking at how you can use them and leverage them this year to improve the way that you develop embedded systems. So, all right. So with that in mind, I look forward to speaking with you again next time.