During the Zephyr Developer Summit 2023, I had the pleasure of sitting down with Henrik Brix Andersen, Lead Embedded Software Engineer at Vestas Wind Systems.
Vestas has been using Zephyr to help streamline the development of the various control systems in their wind turbines, and our conversation was a great opportunity to learn more about some of the areas that Brix is particularly involved in such as CAN (and yes, I too was surprised to hear that CAN is not just an automotive thing!).
Benjamin Cabé (BC): Hi Henrik! To kick things off, can you tell us a bit about yourself?
Henrik Brix Andersen (HBA): Sure! I’m Henrik Brix Andersen, although I generally go by Brix. I am with Vestas Wind Systems and spend a lot of my time working on the Zephyr Project.
BC: Judging by your activity on the project’s Github and Discord, it seems you are very active in the Zephyr community. How did it start?
HBA: At Vestas, our journey with Zephyr started back in 2018. We were doing a product line refresh, specifically one of our microcontroller unit (MCU)-based product lines. We needed something new to address an obsolescence issue, so we started looking around. Traditionally, we had been using an in-house RTOS, or at least a scheduler, but as we always try to adopt what the commercial and IoT industry is looking into, we decided to do a pilot project with Zephyr on a new microcontroller, and this went really, really well.
The time to market was amazing compared to what we were normally capable of, since we were able to reuse so many parts of the Zephyr ecosystem. We also got help from the chip vendors themselves, directly through the Zephyr project, and it really helped us speed things up.
This pilot product laid out the road to switching to Zephyr going forward, and we’ve been using it for all the products that we’ve been doing since 2019–at least in the embedded space.
”The time to market was amazing compared to what we were normally capable of, since we were able to reuse so many parts of the Zephyr ecosystem. It really helped us speed things up.
Henrik Brix AndersenVestas Wind Systems
BC: Your transition to Zephyr seems to have gone smoothly, but did you face any cultural challenges within the company? Was open-source new to Vestas at the time?
HBA: Vestas was already using Linux on its larger Cortex-A based systems, and open-source really wasn’t a problem. We had buy-in from our legal team and product management to actually start out with a very “upstream-first” mindset. This really helped, and this is in my opinion the best way to use Zephyr–having an upstream-first approach. You get things in, get consensus on the APIs you’re trying to add, and because there are so many players you get lots of reviews, and it really saves a lot of time down the road. This actually was a selling point internally: we have a lot of software developers working on our internal products, and getting a fresh set of eyes on what we do is really beneficial.
BC: That’s truly impressive, and I am always amazed to hear how some industries that could be perceived as lagging behind actually are at the forefront of open source.
HBA: Well, it’s actually one of our pillars at Vesta: we want to make things better, and this doesn’t limit us to making the green energy sector better. We want to make the world a better place and, well, the software world, that’s my ballpark, right? That’s where I can make a difference.
BC: Speaking of your ballpark… on a more personal level, in which Zephyr areas are you the most active?
HBA: Right. The products that we started out porting to Zephyr are all CAN-based. We use the Controller Area Network infrastructure to watch these devices, and connect them to the rest of the control system via CAN and CANopen. At the time, Alexander Wachter was maintaining CAN support in Zephyr, and I took over the maintainer role in 2022.
While CAN is definitely one of the areas I’m the most involved in, we at Vestas use so many subsystems throughout the ecosystem that we cannot just concentrate on one area. So I also maintain the EEPROM subsystem, for example, but this one is way less complicated!
BC: I thought CAN was mostly used in the automotive industry, but it looks like it’s a thing for wind turbines too? Can you tell me more about the story there?
HBA: CAN buys us a cheaper alternative to most of the other industrial protocols and buses out there, like EtherCAT or Modbus. And it has built-in priority, built in collision detection, … it’s a real-time protocol. We can rely on it to relay the messages of the highest priority, no matter the system load. In a regular system, we actually don’t have a very high load on the CAN bus, but in case of a failure, we cannot lose the frames that would help us identify the root cause. We need the emergency frames on the CANopen stack to be delivered with a higher priority than, say, the regular sensor readings, and CAN gets us this. It also gives us a lot of flexibility as we can “mix and match” commercially off-the-shelf modules and our in-house developed modules on the same bus, as they all adhere to the same standard.
BC: As a maintainer of CAN, among other things, what are some of the challenges that you are facing?
HBA: It’s definitely getting better now, but at least when we started, it seemed like we were the only ones using Zephyr for Industrial Internet of Things scenarios. We actually don’t refer to what we do as “Internet of Things”, but I guess that in the context of modern terminology, that’s pretty much what it is, right?
So we don’t always get a lot of reviewers on the CAN subsystem, and we don’t have a lot of industrial buses supported. I think this is one of the areas that we could improve in. If we want to attract more participation from the automotive and industrial sector, we need to up our game in supporting, upfront, the likes of IO-Link, LIN, industrial Ethernet protocols, etc. This requires quite an effort, and we’re not there yet—we have CAN, Modbus, and a couple of others, but going forward this is one of the areas I’d like to concentrate on.
BC: Right. This actually brings me to ask if you would have any tips for people who might actually be interested in contributing, maybe around these industrial protocols you just mentioned, and who may not know how to do so?
HBA: I think what works for me is finding a small area of interest, looking out for bugs and low hanging fruits. When you get your first pull request in, keep it simple. Don’t rush to get your first full protocol stack in, and just start slowly. Zephyr is a steep learning curve, at least for some, so start slow, get some samples going on one of the many supported development boards, find something that interests you, and take it from there.
BC: Zephyr 3.4 was released a few weeks ago, and the amount of features and improvements that get added with each release is staggering. Where do you see Zephyr 5 years from now?
HBA: Hopefully even more industrial involvement. We’re here at the Zephyr Developer Summit in Prague–and I’ve been going to these events for years–and this year it’s mostly Zephyr content, right? Frankly, if you had asked me back in Dublin, less than a year ago, I would have said: “Oh, we’ll be pretty much at the same pace in five years.” But now, I’m not so sure! I think we’re actually heading in a really good direction.
The involvement here at the conference is amazing, and a lot of people I met are asking very technical questions. I think we’re finally starting to nail this, and to get the community involvement we need to bring Zephyr to the next level.
BC: Thank you so much for your time and the great chat, Brix. Enjoy the rest of your week in Prague! ⬛
If you enjoyed this article, don’t forget to subscribe to the Zephyr newsletter to receive insightful quarterly updates about all things Zephyr! You can also follow us on Twitter and LinkedIn.
