Embedded software patterns for more than just embedded systems

Embedded systems design and development can sometimes seem worlds apart from traditional application development on general computing devices and maybe even more so from Web development on the server side. But embedded systems don't run without software and that software still needs to be developed in accordance with design principles that are remarkably similar to the principles that govern even cloud application development. Elecia White, the founder of Logical Elegance and author of the book Making Embedded Systems from O'Reilly Media, explains that there may not be a definitive line between "embedded systems" and "general computing devices," but that embedded development patterns are highly useful whenever there are serious systems constraints.

TheServerSide: How is embedded software development fundamentally different than other software development? What are the major differences?

Elecia White: Often times it's about requiring more information as you're developing. In addition to whatever the project needs – what the goal of the application is – there's another set of goals to worry about. Whether it's what the processor is and how to interface with it, or that there's only 32k of RAM and you can't use garbage collection or even use Matlab. These constraints may mean you can't do whatever it is the application is supposed to do.

So the difference is mostly using that additional information to implement the code. On the server side development there's a whole different set of requirements. Embedded systems usually have the requirements and resource constraints, but on a server you have the difficulty of having to deal with all sorts of different users trying to access your server with i.e. 6 and FireFox and Chrome. But with an embedded system that's a little easier because you don't have to worry about that. You work on this hardware and maybe no other, or maybe some limited subset of hardware versions. So there are harder bits and there are easier bits, but the real difference is after you're done with [the core functionality of the application] what are your [runtime] constraints.

Which is the more interesting of the two?

White: [laughs] How do I stay politically correct on this one? … Of course I find embedded more interesting or else I would be a server programmer. But it's a question of what you want to do, of what draws you. I do think embedded systems are a little bit more difficult, not innately, but because of the way we learn them.

If you go through a CS [computer science] program, you learn about software, and you learn about the larger scale and you learn about infrastructure. If you go through an electrical engineering program you learn about hardware. An embedded systems engineer needs to know both CS and electrical [engineering], so they come out of school with only half the information you need. Whereas a CS person going into servers may get almost all the information they need from an education perspective, embedded engineers often have to learn half their job on the job, as they're going. It makes their job a little more difficult than if they had degrees designed more for developing embedded systems.

I, of course, find that more interesting because I like to be challenged in that way and I love to learn new things. But I could see how attractive it could be to spend that energy on getting things done, especially for new graduates. On the other hand, making gadgets – making something that touches the world, instead of providing information – has a real attractiveness. The first time a motor moved under my control it was just really awesome. Having a sensor that monitors what's going on, all of that server information has to come from somewhere and most of it comes from embedded systems.

Have you seen changes in the way embedded systems are designed or the way they run with the emergence of cloud computing?

White: Yes. I have. I worked on a couple of projects that ended up putting their data in the cloud where they were then taken out. Embedded systems are becoming more wireless-enabled and it's becoming more of the grand scheme of the Internet of Things which has been around for a long time. But now as WiFi chips get to be cheaper, embedded systems become Web servers which can be aggregated into cloud designs. I am very excited about that trend.

 Looking at products like Fitbit where you have what is essentially just an accelerometer like you would find in your Wii and a Wi-Fi chip and now it can monitor your exercise patterns all day and your sleep patterns and put those into a cloud. Not like the Amazon cloud – it's more the Fitbit cloud – but they can track things from a big perspective. I don't know that they actually are tracking aggregate data, but there are companies that certainly could provide the aggregate data of how fit all of the people are instead of an individual tracking.

There's a lot going into the cloud. As we get more Wi-Fi for our embedded systems – or just more network capability – the cloud will be even cooler.

In your book you talk about object-oriented programming and about modularization. Do you have some general advice on those topics?

White: Think about it before you write it. So often it is fun to solve a problem or fix a bug, but we're more than people who type things. We're engineers who need to think about how it will look as part of the big picture. And that's where the modules come in. If you end up with a file that's 15,000 lines long, it may be exactly what it needs to be. Or… it may be 3 objects that need to be broken apart so that you can reuse them later or so that you can test them individually.

I'm a big believer in modularization and in object oriented programming. Just because you don't have enough memory to use Matlab doesn't excuse you from thinking about how your system should be designed.

Another thing that caught my eye was the Model-View-Controller pattern. Could you discuss the pattern and how it applies today?

White: The Model-View-Controller has been around for a long time. In fact, it might have been one of the very first identified patterns where we had the words to say "This is what you want to implement," and had the ability for computer scientists to talk to each other and discuss what would be a good way to implement an application that has a display or a user interface.

It separates out the display aspects of it, which is the view, from the knowledge of what's behind the view. The knowledge behind the view is the model and how they interact is the controller. That's kind of simplified but it is incredibly powerful compared to the days where every button was hardcoded. Not just in embedded systems, but if you go back to the days before Windows XP, you could find plenty of applications where you push a button and it implements the code right there, which means that if you ever want to change the way it looks, you have to rewrite the whole code. So Model-View-Controller became a really exceedingly popular idea.

As we put it in the book, one of our viewers said, "You know that's sort of outdated, a lot of people don't talk about it that way anymore," but in embedded systems we're a little behind the latest, most sophisticated design patterns. Model-View-Controller works really well for us because a lot of what embedded systems are doing is "Push button, do action," and it's hardcoded in a giant switch plate.

In embedded systems a lot of times you don't have a view; you don't interact with the user. Those signals that we monitor, we push straight to the cloud. So, why would you use a Model-View-Controller? In my book I discuss using it as a way of testing. To take out the real-life view, which is the way you interact with something – it might be a user or a sensor – and instead read from files.

This allows, for example, a gunshot location system, with a sensor that would normally sense the environment all the time. Now, instead I can run that code using a file that I either created or acquired from going to the gun range and shooting guns, and be able to replay that data. If you can separate out how you talk to things from what you do when you talk to them.

Sounds similar to HTML 5 server-side environment where there is a focus on using a client-side user interface that is built with JavaScript and has hooks that you can use to make it talk with your application on the server.

White: Yes, and I don't know if they call that Model-View-Controller, because in the Web browser world, it's actually an ingrained habit. But if you go to iPad programming, there actually is something called a view. And if you know what Model-View-Controller is, you understand a lot more about how they've broken up how you set up an iPad program. Like I said it was one of the first ones and it was probably around before the gang of four Design Patterns book. Which is why you may never have heard of it. It was used for then and now we've gone beyond.

Related Resources:

Making Embedded Systems: Design Patterns for Great Software by Elecia White
Cloud Connectivity and Embedded Sensory Systems
Design Patterns for Embedded Systems
Design Patterns: Elements of Reusable Object-Oriented Software
Head First Design Patterns