Tammy Noergaard is chief specialist in embedded systems at Terma, Denmark and has a wealth of professional experience. She is the author of several books on embedded systems, including Demystifying Embedded Systems Middleware, which provides a detailed overview of embedded systems middleware that includes theoretical discussions, practical advice, and technical examples from real-world cases. We recently got the chance to ask Noergaard a few questions about her book and about middleware for embedded systems.
What's the most interesting thing you learned while writing "Demystifying Embedded Systems Middleware"?
I guess what I learned is to not make assumptions about having seen every possible way to do it, because every time you think you've seen it all - bang - there's a new way to do it that's opposite everything you've seen before. So I had to rewrite parts of the book with the understanding that I could never cover every possible way of doing it. I ended up starting chapter one with "Just know that there are so many solutions out there, there's not one that's perfect for every embedded system."
Sometimes middleware can be seen as the blob that connects this with that. In the book, you talk about middleware in terms of "core" middleware with more complex middleware built on top of that. What's the advantage of dividing middleware up this way?
If you've had a chance to go to any of the embedded shows and listen to the embedded gurus, a lot of them haven't spent a lot of time on defining it for the rest of us, and I think that's a shame. So what I did was take a practical approach. "A device driver is this. An operating systems kernel is this. An application is this." And then I set about defining that blob in the middle. And that's how I came up with these two types. It's based on my own experience.
I said, "Okay, what is middleware?" and that's when I divided it into core middleware and the more complex middleware on top of the core. I asked "What's the type of middleware you usually find in most embedded systems?" And that's what I call core middleware.
Then I took a step back and looked at the stuff that's not so usual, that people attempt and that sometimes succeeds quite well. There's more on the core middleware than on the more complex types, because the complex types require a lot more processing power and a lot more memory and a lot more expensive hardware.
What is the most prevalent myth about embedded systems middleware?
That depends on if you're talking about the people trying to define what middleware is or if you're talking about the folks that are actually trying to build something with middleware. I guess I could point out something for both instances.
For the folks trying to build middleware I can only say what I've seen and heard is the biggest myth is that somehow those trying to build middleware solution -- whether it's a component they want to sell to engineers who are building the device or they are the ones building the device -- is that they think that they can get away with looking at it really abstractly like a PC programmer. That somehow just because it's on top of an embedded operating system that it isn't necessary to understand what drivers are there and what the hardware is, and I think that shoots a lot of folks in the foot.
On the flipside, the biggest myth for those defining middleware would be that a lot of folks see middleware as being just complex messaging middleware, you know, MOM and so on. I think a lot of the underlying core middleware as well as some of the more specific middleware gets missed. They say there's the networking stack that's above the data link layer, there's embedded JVMs, or there are file systems and databases and those are kind of blobs floating around, but in the scope of my book, and until some guy or gal a lot smarter than me comes along, I define all of that as embedded middleware.