임베디드 시스템 및 펌웨어를 위한 마이크로서비스 아키텍처

### 임베디드 시스템에서 마이크로서비스 수용하기: 컴포저블 소프트웨어 아키텍처
* 👋 임베디드 디바이스 및 마이크로컨트롤러용 마이크로서비스에 중점을 둔 클라우드 디바이스 관리 플랫폼인 Goliath의 펌웨어 엔지니어링 리더인 **샘 프레드먼은 자신을 마이크로컨트롤러용 펌웨어 엔지니어링 리더**라고 소개합니다.
* 🔍 그는 마이크로서비스는 일반적으로 클라우드 컴퓨팅과 연관되어 있지만, **모듈형 소프트웨어의 개념은 유지보수성과 속도를 향상시키는 소규모의 독립적인 작업**을 허용함으로써 임베디드 시스템에도 상당한 이점을 제공할 수 있다고 설명합니다.
* 핵심 아이디어는 재사용 가능한 작은 구성 요소로 펌웨어를 분해하면 전체 코드베이스를 다시 작성할 필요 없이 쉽게 업데이트하고 수정할 수 있는 **레고 브릭에 비유할 수 있는 구성 가능성**입니다.
* 🔗 Fredman은 잘 정의된 IPC 메커니즘을 통해 통신하는 느슨하게 결합된 작업의 중요성을 강조하며, **이는 펌웨어 전반에서 변경 사항을 격리하고 종속성을 줄이는 데 도움이 된다**고 말합니다.
* 📊 그는 가볍고 많은 리소스를 소비하지 않고도 작동할 수 있어 **독립적인 소프트웨어 기능을 효율적으로 처리**할 수 있는 이벤트 작업의 개념을 소개합니다.
* 🚀 이 강연에서는 이 아키텍처를 활용하는 콜드체인 자산 추적기의 실제 사례를 통해 **전체 시스템에 미치는 영향을 최소화**하면서 **새로운 기능을 추가**하거나 **기존 기능을 제거**하는 방법을 설명합니다.
* 💡 Fredman은 직접적인 종속성 없이 작업 간의 통신을 용이하게 하여 펌웨어 아키텍처의 전반적인 유연성과 성능을 향상시키는 **퍼블릭/서브 시스템인 Zephyr의 zbus** 사용에 대해 설명합니다.
* 🤝 그는 청중의 다양한 질문에 답하면서 **초기화 우선순위와 잠재적인 멀티코어 사용 등 다양한 시나리오에 대한 이 아키텍처의 적응성**을 강조하며 마무리합니다.

샘 프레드먼은 임베디드 시스템의 구성 가능성과 유지보수성을 향상하기 위해 펌웨어의 모듈식 마이크로서비스 아키텍처를 지지합니다.

uh thanks for coming everybody. Sorry for the uh delay there. It's early; everyone's waking up. Um, my name is uh Sam Fredman. I lead firmware engineering for Goliath. Goliath is a uh Cloud device management platform for embedded devices. Uh, we work on Zeper, which is why we're here. Uh, we also work on a couple of other platforms. Um, my talk today though isn't about gas; it's about microservices for microcontrollers, composable software architecture for embedded systems. Um, oh, also I wanted to mention this is my first conference talk ever, so thank you for being here for this momentous occasion for me. Um, all right, so if you've heard of microservices, you probably are wondering, like, Isn't that a cloud thing? Why are we talking about them at an embedded conference? Um, and it's true that as microservices, the term is like mostly known; it's a cloud thing. And it's also true that I chose that term to make my talk sound a little bit more interesting, but we're really talking about here are just really

modular software, uh, in the Cloud World, um, microservices are like very small individual pieces that can be deployed very quickly and very independently, and it's designed so that really large teams, like, you know, the big companies, don't need to coordinate thousands of engineers to release, you know, their web app every time they need to release it. They can release small pieces of it all the time, um, that's not usually a problem. Firmware, you have to update the whole firmware all the time anyway, and our teams tend to be smaller, um, but we can still gain, uh, a lot of the benefits from, or a lot of benefits from using, uh, a sort of microservices-like architecture. What it looks like in firmware is, again, just very small, very loosely coupled independent tasks, is, uh, we'll talk more about what a task is, uh, communicating through, uh, well-defined IPC mechanisms, and so the analog there would be like, you know, through a lightweight, uh, API in the cloud world, where just using IPC here in firmware, um, the benefits you get from that are

similar to the cloud world, you can move faster because smaller things are easier to test, they're easier to understand. Things that are easier to understand, they're easier to maintain, um, and they're more isolated. So, if you need to make a change into one part of your firmware, you're less likely to have that impact the rest of your firmware, um. That's just good software architecture, software practice, I think, for any software that you write, um. But the part that I want to stress is actually composability, and we're going to talk about that more here just in a minute. This is really why I think this architecture shines for firmware, um. So, what is composability, right? You can think of it basically, you have a bunch of Lego bricks, a bunch of small pieces that you can assemble to create something bigger. Just like with Lego, if you have, you know, just a very simple brick, you can combine them to create, um, very complex, very beautiful things, right? It's the same way of thinking of that for your firmware, right? You want to break things down into the

smallest pieces so that you can pick and choose them. The reason they need to be small is that having smaller pieces makes them more reusable. If they only do one thing, then you can pick it up and use it. You don't have to worry about, you know, is it going to bring in a feature I don't need? Is it going to have a dependency on a piece of hardware that I don't have because it's trying to do too many things? This little guy in the corner, we call him Echo, he's pointing right here because this is why that's really important for firmware in the cloud world. When you deploy your new web app, the old version is basically gone, right? It's deleted. No one's ever going to use it again. All of us who make embedded devices know that's not how firmware works, right? Once you deliver a product into the field, that product needs to be supported until it's no longer being used, right? Even if you can update the firmware, your users may not choose to update.

it and uh as you release new hardware versions, right? Adding hardware, changing hardware, removing hardware, adding features, removing features. You still need to support the old versions of your product. Having uh composability allows you to use the same code because what you're doing now instead of rewriting your firmware, which I've been part of a lot of teams who have changed one little thing in their hardware and rewrote the entire code base from scratch. Instead of doing that um, you're now just adding a piece, adding a software module, adding a task, removing a task. Uh, the configurability of it, the composability is what allows you to reuse your code faster, better, while also getting all of the other uh benefits that we talked about earlier, including you know, better testability and maintainability. Um, all right, so what does that actually look like? Um, we talked about tasks a little bit earlier. Tasks are these independent actors in a system. They need to communicate through IPC. Uh, one thing that I mentioned, lots and lots of small tasks, which if it might have made some of you think like

why I don't have memory for like a thousand threads running. Um, so we're also talking a little bit about event tasks, which are a way of having really small pieces of independent software functionality, but without using up all the resources of like a heavyweight thread for them. Um, so tasks, like I said, they are fine-grain, many, many small tasks. You want your tasks to be as simple as possible. They should really just do one thing and should think about them as we call, I'm calling them business functions here, but essentially either a feature or hardware support to do one of those things. Um, and they should be loosely coupled, um, which is something you've all heard before. The way I like to define it is, uh, no public interface, so there are no header files for tasks. You cannot call into them. They have no APIs at all. Um, instead, everything, all communication is through IPC, excuse me, uh, through indirect IPC. So this means you, you know, they're not exposing a queue that you put things into, but instead there's some

other, uh, in a process, uh, mechanism that allows these threads to communicate with each other without actually knowing with whom they're communicating with. And we'll get into that in a minute, uh, and then these tasks, because in order to ensure that they can be added and removed at will, um, they all need to sort of be on the same footing, right? You can't have um a main task which is trying to coordinate those tasks because then you'll have to change your main task every time you add or remove a task. Uh, doing Hardware initialization in the task itself becomes difficult because you know if you have three tasks that are using the same driver and one of them sets it up but then that's the one that you want to remove. Now you have to figure out where else to initialize that driver. Um, so the uh I guess these are a lot of like prohibitions which I think is uh maybe the main takeaway from how to think about this. It's how do we keep everything really self-contained. How do we keep everything as concerned with its

one function as possible so that when that function is no longer needed, we can remove the entire software component, or similarly, when we add a new software component because it's only concerned with its one function, we don't really need to make changes or the minimal set of changes to the rest of the firmware. Um, and as I mentioned, uh, tasks, uh, we have this event task as well. So all threads are tasks, but not all tasks are threads. Um, for IPC, there are a couple different ways you could do this. I, uh, prefer pubsub, or, and this is not like a product, so I've capitalized it. Um, this is just generally a, um, a communication paradigm that you can think about. Um, I'm sure many of you are familiar with the basic concept, but, uh, you have topics and devices published to them, or sorry, tasks published to them. Tasks can subscribe to them and receive messages. The important thing about it is that the focus here is on identifying that data, so naming the topic like accelerometer, you know, or temperature, or

GPS or whatever um sensor data is like the easiest one to think about. So, probably going to over-index on that um and what the form of that data is rather than on how modules are interconnected um. There are going to be more concrete examples later, I promise. Right now, it's a lot of talking um and and that's the important thing, right? So, modules are communicating without knowing what the other party is and that's important because now you can remove, change that party, add a new one without needing it. It's also important to note that this is many to many and that's also important for like when you want to add a new feature that can like hook into an existing data stream, right? Like that's just naturally supported um. This removes the intertask dependency. So, we mentioned that there's no public API. The reason why that's important, right, is again because like if you stop compiling in a function that another module is calling then that you're going to fail to link um. So, these TPS don't communicate with each other, their

dependency is on Pub/Sub, so Pub/Sub has to be there. Whatever your Pub/Sub bus is, needs to be there in the system. But that's pretty much the only direct dependency for the system. Another advantage of this, and again I want to stress that for me, the main point of this is composability and being able to port multiple firmware products with one set of code, but there are a lot of other benefits too. One of them is removing developer dependencies, development dependencies. So if you are developing a module that communicates to and from Pub/Sub, right, this kind of gives you a built-in abstraction barrier where you can easily inspect or inject data in order to test a module before the rest of the whole software is ready. And what's great is not just doing that when you are in development, but in testing later too, because these injection points basically don't go away. They're part of the actual core system. You can use them throughout the life of the product. So where I've

used this in the past is like if you have any kind of UI on your device, and that UI is triggered based off of events. Those events are Pub/Sub messages triggering your screen. It's really easy. You a little CLI command that can just like fire off a pub/sub message and trigger any screen you need, any animations, things like that. Similarly, with pulling off data, you can just write a really simple application that just like opens up the accelerometer topic, reads it, prints it, and that becomes really easy to interact with. And then finally, the last tasks we be talking about are events. I think there's another corollary to the cloud here, which is Cloud serverless functions are pretty similar. So, I'm calling them threadless functions. It's multiple tasks, they run one thread. These are essentially callbacks that execute in response to a pub/sub message. So, you register them against a particular message. They run on a shared thread, so they run to completion, right? And it's important to note that

they are not tasks, so um, you need to be careful, think about them, maybe not quite as uh, you know, as uh performant as interrupts need to be, but kind of in that vein, right? They can't block for a very long time, right? Any sort of oper like that is going to prevent other events from running um, and so actually this is probably a good point to talk about like how do you choose what is an event or a thread um. Generally, anything that needs to like directly interact or wait on hardware is going to have to be a thread like uh, most flash rights are going to uh, you know, they can take a long time, so you don't want to do those network operations, even some sensors you need to read from um, you know, in maybe like a polling manner. If there's any kind of delays in there, tend to be threads, and then more like pure business logic tend to be events um, and again, these events, things you would use for events are probably not things that would have been their own thread or

their own task in uh like a traditional system that that you might have built before um because we're trying to really create a lot more tasks than you would normally see uh in order to create uh the small little Lego blocks and keep everything composable and again concrete examples coming all right this is uh the Zephyr developer Summit so how do we do this in Zephyr um zebus is I think still relatively new maybe about a year old um it's really great this is zephyr's implementation of a pub sub bus the uh um terminology that they use a little bit different than what I was using before um topics are channels um messages can have data associated with them which is great um the uh threads uh okay sorry so you can have what they call thread subscribers which are subscribers which are the thread tasks that we talked about um it's not shown here that they can actually have a couple of different kind of messages you can either like receive a copy of the actual message into uh your own queue or you can

receive a reference to a message as far as like the architecture part of this. It's not really so important. Um, they also implement what they call listeners, which is what I was calling events earlier. So, that's really nice. You don't have to implement your own event thread or anything like that. Um, that's already built into zbus. Um, and this takes a lot of the work and complexity for you. Um, I highly encourage you to go listen to the Z Tech talk on zbus. Um, I think it was actually phrased or like positioned as kind of like a debate, like should you use zbus, should you not use zbus. Um, all the different Tech talks are great. This one's particularly relevant for this talk. Um, the last thing, or sorry, the next thing is iterable sections. This is maybe a little bit like non-obvious about how important this is. Um, I mentioned before that there's no public interface and there's no main thread coordinating which tasks they're running, right? So, how do these tasks actually get put into the

system um essentially including a task is the same thing as compiling it, right? If you compile a task, then it gets into your build, and it will run. The way that works is using iterable sections in ZR. What this is, is basically um, you place a struct into a particular Linker section at build time, and then the Linker grabs everything from that build section and puts them packed into um, you know, into an order, and that essentially creates an array in Flash. And then Zephyr has um, facilities to like iterate through that. What this means is you can create basically modules, can register themselves, they can place themselves into Global arrays uh, without there having to be any kind of like central registry in your source code um, just by compiling it. The linker or make Ur is that's place there. So, Zephyr uses this for registering channels for zbus, for registering The Listener events, it uses it for um, task or for thread creation um, and uh, again, the importance of this right is that it allows, it prevents you

from having that central piece of code that is orchestrating everything. Things you need to change every time that you want to create a new version of your firmware. Instead, all you do is you set a K config option or maybe change something in your CMake file to include or exclude a component, and that becomes the entire building of the application, right? And then the last part of it is system initialization. So this also uses iterable sections, but I mentioned before, you can't rely on any task to do the initialization because you may remove that task. Zephyr has a really robust initialization system, which a lot of different levels. One of the things where in other systems actually this can get pretty hard is if you don't have a main pass to ensure that you know like you initialize things in the right order. You know, maybe your display needs the power regulator, you know, initialized first, things like that. If you're just kind of relying on like which threads run or like, you know, it can be pretty difficult. Zephyr has initialization

levels. They have initialization priorities within levels. All of this, again, done through those like section strs that get placed in the Linker, um, and this allows you to, uh, pretty, uh, fully specify the initialization order and what hardware and libraries need to be initialized, initialized, um, in those libraries and, uh, and dri themselves, so your application doesn't need to do it, uh, so by the time all of your tasks run, they're all ready to run, and they're all able to, uh, um, leverage the full capabilities of your system, uh, and again, this is important because if you remove a task or if you add a task, uh, you uh, could be changing your station, which could cause complexities when you're building the various products on your one code base. Okay, real-world example. That was a lot of talking, and I apologize. It's not how I like to, uh, do my presentations normally, um, but hopefully, this will make everything feel a little bit more concrete. Um, I want to talk about a cold chain asset tracker. Um, this is actually a cold chain. This happens to be a reference

design that my company Goliath makes. But I mostly chose that because I know there are no copyright issues with this photo. So, it's not important that my company makes it. What this is, is it's a little GPS device with a temperature sensor and a cellular modem. And you put it in your frozen food shipment, you know, in the back of a refrigerated truck, and it ensures that throughout the process or throughout the shipping of your food, it never goes above freezing so it doesn't spoil, right? So, this is a little block diagram here on the right side of that screen. The sort of rounded rectangles are tasks, and the U diamonds are Pub sub topics or zbus top channels. This is obviously simplified; there would be a lot more going on in the system normally, but for the purposes of this, I think this is a good example. So, the GPS thread, these are actually all four of these tasks right here are threads.

in this contrived example, uh, because I mentioned, right, like if you're dealing with hardware, you're generally going to need a thread, something that can block. So, the GPS task is publishing to the position topic. The sensor's task is publishing to the temperature topic. Both are being consumed by the network thread, um, that's one of the simplified things that would probably be a couple of different tasks, but both are being consumed by the network uh task in order to upload that data to some, you know, uh, cloud database where you are tracking this, or maybe a visualization tool, uh, and then also to display. So, we can display um, you know, that data locally, uh, so that's sort of the base. But let's say, uh, you know, your product manager uh, comes back to you. They say, Hey, we talked to the customer um, their TTI of like, you know, the driver's in the front. They're not looking at the screen. They have no idea uh, when the temperature rises. We want to add a new feature that plays an alarm whenever the

uh, the temperature rises above a set limit. Uh, so we can add a new task. This task is actually going to be an event task, or again, a listener in the zbus nomenclature. Um, what this task does, it just uh, runs every time there's a temperature message, and it compares that to uh, some threshold, right? And if there, if it passes that threshold, um, then it publishes the message to the overtemp uh, topic. So I just described to you the entire task, right? You can imagine that's probably like four lines long, um, just to like emphasize that like task should be really, really small. That is a feature, that's a piece of functionality, um, that's all it should be. It's in its own C file, it has no public API, it's just that one function, um, but it is a task because it is that independent piece of functionality, and it's not going to take any extra resources on your system because it's going to run on that event uh, processor thread. Uh, so it publishes to the overtemp uh, topic, and then um, that over

attempt topic will uh is oh something I should have mentioned about this. So, the arrows that show the data going, you know, like position pushing data to the network, it's sort of describing the flow of data. But remember that these tasks subscribe to that data, so they're actually calling into zbus or your Pub subsystem to say, Hey, I'm interested in position data, right? Um, so the display, we do have to change the display a little bit because we are changing the display. We're adding a new screen, so we have it register onto the overtemp topic, and uh, we create a new screen that puts up, you know, maybe one of those little warning uh symbols. We also add a new audio task, um, which, you know, maybe plays a tone or a buzzer or something to audibly alert uh the driver. Um, so that's great. Uh, that's how thre we had to change the display a little bit, but we changed it because we actually are changing it, not because it needed to be changed in order to support some other um change, right? We're the

sensor three is now sending data to the alarm task, but we didn't have to change anything in the sensor task. We didn't change a single line of code there, so that's kind of like where this architecture shows its value. But I think it's even better when you delete something. So let's say, you know, the product manager comes back and they say, Hey, you know, like these are really expensive. We don't need a display. The driver's in the front. He can't read it. Why do we need a display? Let's delete it. Let's save some money. That's it. You delete it. Like, you just delete the display task, and the rest of your firmware will still run. The all these topics no longer subscribed to by the display task, so they're no longer getting data. You no longer have to... So yeah, it's just... It's not running anymore. I actually spent quite a while trying to see if there was like more to talk to on this slide, but I think that's like kind of the point.

right is once you've separated everything into these very um distinct pieces of functionality and uh once you've ensured that they are loosely coupled you can remove things and it doesn't affect anything else right. I've had the experience in the past of trying to remove a a screen uh you know like like a piece of the UI and uh when I hit build the file system recompiled so somewhere there's some weird dependency where the file system is depending on the screen um. I never figured out what that dependency was uh but when you build it up like this and through this system um that doesn't happen anymore um. So that was it pretty quick we have about I think 10 minutes left uh are there any questions yes I don't know if we have a oh m in the mic yeah hi um thank you for the talk um just a question on how would you manage um like dependency initialization especially if you have to initialize services at different times uh sorry could you repeat the first part of the question yeah how

would you manage um initialization priority MH. So, for example, if you're the task you want to implement uh has several dependencies and you're not very sure uh when these dependencies will finish initializing. Yeah, that's a really good question. Um, so there actually has built-in support for this. There are different initialization levels. Uh, I'm not going to like get them all off the top of my head, but there are several different levels you can do before the kernel boots, several after the kernel boots, uh, some at like what they call the application Level, and then within that level, there's also um, you can set like a numerical priority, which I think is like 0 to 99 um, or some other, you know, quite large range where if you need more than that, you're probably uh, building a very complex system. Um, and so you set those uh, initialization priorities according to your system. A lot of them, you know, may not be in code you can necessarily like control, like there might be um, modules in that are like in the zeph.

tree itself a lot of those have uh cake and fig options that you can set in order to change the priority if you need to. Thank you. Hey, great talk. Um, for thought, did you think about mixing the system with linkable loable extensions so it could even like just have a small piece you can like push system or like small functionality? Yeah, um, in relation to this kind of architecture, I haven't uh thought about it till right now. I think um, I think that's actually a really great question because this can kind of enable that, right? Because it sort of um, uh, once you load that module, it can subscribe to these topics and that doesn't necessarily need to happen at build time, right? Um, so yeah, I think that provides um, I guess yeah, I think those would work really well together. Um, you'd have to be careful to like when you unload a module to make sure that you unsubscribe from all the channels that it was connected to. Um, but that's more of an implementation detail. You may not know the answer but um

performance of zbus for example. Uh, the products I'm re-architecting right now, we deal with sometimes, say, uh, 6,000 messages per second going out of the device. And so, we have to do all of the work to gather the data and collect it. So, we're dealing with a higher rate than that internally. Um, do you think zebus can keep up with that? Um, well, I won't give you a definitive answer because I don't know how fast you process it is and things like that. Um, I will say that, uh, there is some overhead. It's pretty small. Um, so, I mentioned briefly that, uh, there are two kinds of ways you can subscribe to zbus. And one is, um, where zbus will copy messages into your queue. And another one where it passes it by reference. I imagine if you're, you know, sending around 6,000, you're probably doing it by reference. So, that is pretty performant. Um, I've implemented, uh, a pub-sub architecture in the past where we used strings to describe the topic. So

you had to do some string compares, which aren't the fastest. They're not too slow, but zbus doesn't use that. They're using integer channel IDs that are defined at compile time to the linker, so that's pretty fast. So essentially, another thing that I would say, and actually I'm not sure exactly how zbus is implemented here, so take that with a caveat. The way I've implemented systems like this in the past is using linked lists. So if you have the performance there, it grows with the number of topics and number of subscribers you have. So if it's a high volume of messages going between a small number of tasks, that probably is not an issue. But if you have 6,000 tasks, then sending a message could take iterating through 6,000 subscribers. And again, I don't know how zbus is implemented. Obviously, there are ways you can speed that up, sorts and searches and stuff. So the reusable logic part

is is great. Um, I'm wondering how with like the iterable sections part, how that sort of handles um reusing the same task. So, say you had three temperature sensors and you've got a task which reads the temperature sensor and pushes it somewhere. If it's all sitting in the one C file, that doesn't like you can't create that three times, for example, right? Um, so most of the uh entries in interal section have like a name or so basically the way this works is there like a macro. One of the arguments of the macro is a name. Um, so you could actually like instantiate uh that struct that describes that test multiple times. You would, you know, it would be like uh temp one, temp two, temp three, but they would all have the same um, they would all use the same function. So, you could at least reuse that function call uh, and then uh most of these um aable sections also take like a context argument, right? Like a user void Star, right? And so, you could pass context in there to say like hey

you're actually reading from, you know, this temperature sensor, that temperature sensor, that's one big room for you. Hi, yes, I'm very new to Z, so I don't know all of its capabilities. Um, I was curious about your architecture concepts in relation to possibly multi-core usage. Is that of a play there, or uh, that is a great question that I do not have the answer to. Fair enough, but you wouldn't knock it out of the park. You wouldn't say it's a no or something like that. I correct, I wouldn't. Um, I most uh, like inter-core IPC mechanisms, kind of work with like hardware mailbox anyway, so uh, you could, I could definitely see uh, extending Z bus to like use that as sort of like a backend um, but I've never like, honestly, I've never really worked with like an SMP very much uh, myself. Right, when I've used two ques, it's been like this core does a very specific thing, so gotta, yeah, yeah, I work inc's all the time, so it's always how do you get them.

to work together, so yeah, it's interesting. Okay, thank you. Thank you. Hello, um, thank you for your presentation. Um, if I understand well, the pub-sub, you have a module or a task that is the publisher and another one that subscribes to it. So, every time a publisher publishes something, the subscriber will be notified and do something with that information. But sometimes, um, the subscriber doesn't want to be notified or the subscriber wants to get the information when it's needed. For example, uh, the over-temperature alarm that you mentioned. That could be a situation where, Oh, there's an over-temperature. I want to know the position where it happened. So, I'm interested in position now. I don't want to be getting events all the time. A new position is published. So, does uh, zebus support that as well? That's a really good question. Um, that was some slides I took out of the presentation, actually. Uh, I don't believe zebus supports it, and I'm actually not aware of like a built library in Z that does it. Um, although

anyone please feel free to correct me. Um, but what I usually refer to that is um shared State. Essentially, is what you're asking for there um. And you can do something similar where you create um a central module that can like hold shared State um. And where it you basically similar to zbus, you refer to that state by like an ID. So, you're like calling into this module and you're saying like hey give me the uh you know the current state of this identif um. Rather than like directly accessing the memory itself uh. There are a couple advantages of that. One is that this system can know whether or not that data exists or not. And that's important for like let's say you know you remove the task that sets location right. You no longer you just care about the temperature. You're not doing position anymore um. Well, you don't want to just you know display junk data right. You need a way to say well there is no position information actually um. The other thing is that uh it allows you to

uh abstract away concurrency protections so you can do all of the current concurrency protections, your mutexes, whatever kind of lock you're using, uh within that module. Um, so you don't need that in all of the tasks, uh, which in my experience, you know, some of the hardest bugs to track down are around concurrency. So if you can reduce the surface area of where those bugs can pop up, that's really helpful. Thank you very much. Hi, I actually have a follow-up on that question. Um, what that sounded like was an RPC between two modules, um, with a command and response, and I'm wondering, you mentioned not defining APIs for these modules, but typically a function-like API surface is a great way to define an RPC. Uh, can you speak to that, uh, trade-off of not defining an API for this or how you go about that? Yeah, um, so I will say, uh, to be, I was not trying to describe an RPC before, um, more of like a file system, which I hesitate to say because it's not really anything at

all like a file system but saying like give me the contents of, you know, food. Tex right more like that um for an RPC I think um you could do it like rpcs can be uh couple you generally still need to know sort of like who you're sending that request to um which can create a little bit more of a tight coupling um it's certainly less than if you're doing like a function call right um it also I think there's benefit in thinking of like the the data flow right rather than like the execution flow of of a function or of a of a program um and this gets into things like inversion of control right where it's like rather than um like asking something to happen you just say that like this thing exists and wait for somebody else who cares about it or not so um it's certainly I I would say rbcs are possible uh for sure I'm not sure that like in an embedded system though where where uh you can link everything together anyway that there's as much

benefit from it as you get in like a cloud system, where the main benefit of RPC is, you know, being able to, like, pretend that something very far away is actually very close to you. I think we're still running out of time, so perhaps one more question, and that's it. And I also look at the Discord if we have any questions there. Thanks. Um, we've implemented something sort of similar in an architecture with that, and we use sort of shared states to sort of share between different things. But my question was about the, I guess, the channels. Is there a way that a channel can know when you're publishing to a channel? You can actually know how many subscribers you've got, because if you've got dynamic tasks that are being switched off, you know, suddenly you don't need the temperature or the accelerometer data anymore. It'd be great to be able to have that sort of problem is about to go, Okay, well, no one subscribed to me, so I'm just going to go.

down into low power mode and wait until somebody subscribes again. Does Zephra channels allow for the publisher to know how many subscribers it has? That's a really great question, and I agree that'd be a really useful feature, but I don't know the answer. Sorry. Okay, right, thanks. All right, so I think formally that's the end of the session, but of course, I assume that you might have more questions. You can just ask them privately. I think we have a little break now before the next talk, so if we could just thank the speaker. Great.

Microservices for Microcontrollers: Composable Software Architecture for Embedded De... Sam Friedman

Zephyr is a small, scalable real-time operating system (RTOS) for use on resource-constrained systems supporting multiple architectures.  Developers are able to tailor their optimal solution.
As a true open source project, the community can evolve the Zephyr RTOS to support new hardware, developer tools, sensor and device drivers.

The Zephyr Project

마이크로컨트롤러용 마이크로서비스: 컴포저블 소프트웨어 아키텍처

임베디드 시스템용 펌웨어에 마이크로서비스와 같은 아키텍처를 적용하는 방법에 대해 Goliath의 샘 프레드먼이 설명합니다.

그는 빠른 테스트, 손쉬운 유지보수, 컴포저빌리티를 통한 코드 재사용 등 모듈식 소프트웨어의 이점을 강조합니다.

이 강연에서는 유연하고 효율적인 펌웨어 아키텍처를 구현하는 데 있어 독립적인 작업과 잘 정의된 IPC 메커니즘의 중요성에 대해 강조합니다.

소프트웨어 개발의 효율적인 작업 관리

태스크는 리소스를 많이 사용하지 않는 작고 독립적인 기능 단위로, 느슨한 결합을 유지하기 위해 간접 IPC를 통해 통신합니다.

게시/서브 통신 패러다임을 사용하면 태스크가 서로의 신 identities를 알지 못해도 데이터를 공유할 수 있으므로 태스크를 쉽게 추가하거나 제거할 수 있습니다.

이 접근 방식은 컴포저빌리티와 개발자의 독립성을 촉진하고 제품 수명 주기 전반에 걸쳐 테스트를 위한 인젝션 포인트를 제공합니다.

Zephyr의 이벤트 중심 아키텍처는 게시/서브 메시지를 사용하여 UI 작업과 데이터 풀링을 트리거하여 상호 작용을 원활하게 만듭니다.

또한 이 프레임워크는 공유 스레드에서 메시지에 대한 응답으로 작업을 실행하는 서버리스 함수 또는 '스레드리스 함수'를 제공합니다.

Zephyr의 Pub/Sub 버스 구현인 zbus는 이벤트 처리를 위한 스레드 구독자와 리스너를 제공하며, 빌드 프로세스의 반복 가능한 섹션을 통해 동적 작업 등록과 전역 배열 생성이 가능합니다.

효율적인 펌웨어 버전 관리 및 시스템 초기화

펌웨어 버전 관리 프로세스는 K 구성 옵션 또는 CMake 파일 변경을 사용하여 간소화되므로 중앙 코드 조각이 필요하지 않습니다.

여러 수준과 우선순위를 갖춘 Zephyr의 강력한 시스템 초기화 기능은 작업 실행과 관계없이 하드웨어와 라이브러리가 올바른 순서로 초기화되도록 보장합니다.

실제 사례로 콜드 체인 자산 추적기를 들 수 있는데, GPS 및 온도 센서 작업은 데이터를 네트워크 스레드에 게시한 다음 클라우드 데이터베이스에 업로드하여 로컬에 표시합니다.

온도 이벤트 및 작업 종속성 관리

임계값을 초과하면 온도 메시지를 처리하고 과열 주제에 게시하는 새 이벤트 작업이 추가됩니다.

이 작업은 이벤트 프로세서 스레드에서 실행되는 작고 독립적인 작업으로 설계되었습니다.

이 아키텍처는 시스템의 나머지 기능에 영향을 주지 않으면서 디스플레이와 같은 작업을 쉽게 제거할 수 있도록 해줍니다.

ZBus에서 초기화 우선순위 및 성능 관리하기

시스템의 초기화 우선순위는 0에서 99까지 다양한 수치 범위로 설정할 수 있어 작업 실행 순서를 제어할 수 있습니다.

시스템을 연결 가능한 확장 프로그램과 혼합하면 모듈을 동적으로 로드하고 토픽을 구독할 수 있어 기능의 유연성을 제공할 수 있습니다.

ZBus는 메시지를 큐에 복사하거나 참조로 전달하는 두 가지 구독 방법을 제공하며, 후자가 더 성능이 뛰어나며 토픽 정의에 정수 채널 ID를 사용하면 메시지 처리 속도를 높일 수 있습니다.

Z의 작업 재사용 및 멀티코어 사용량

Z의 반복 가능한 섹션을 사용하면 각 센서마다 다른 이름으로 구조체를 인스턴스화하여 동일한 작업을 재사용할 수 있습니다.

또한 이러한 섹션은 컨텍스트 인수를 받아 특정 센서 정보를 전달할 수 있습니다.

Z의 아키텍처가 멀티코어 사용을 직접 지원하지는 않지만, 코어 간 IPC 메커니즘은 잠재적으로 Z 버스와 함께 작동하도록 확장될 수 있습니다.

모듈 내에서 동시성 보호를 추상화하면 버그가 발생할 수 있는 표면적을 줄여 관리가 더 쉬워집니다.

발표자는 모듈 통신을 위한 RPC와 파일 시스템과 유사한 접근 방식의 차이점을 강조하며 긴밀한 결합의 장단점을 강조합니다.

또한 공유 상태와 동적 작업 관리의 잠재적 이점에 대해 논의하며, Zephra 채널이 퍼블리셔에게 구독자 정보를 제공할 수 있는지에 대한 불확실성을 표현합니다.