Embedded Systems Do What Embedded Systems Do

When we are asked what an embedded system actually is, we have a standard answer: It’s a computer no one cares about. Why? Well, Embedded Systems are supposed to constantly work. They do what they are designed to do — day in, day out. In general, it is quite easy to explain what they do:

Embedded Systems consist of hardware (like a microcontroller) and software and are integrated into a bigger system. Within this bigger system, they fulfill specific tasks. Usually, they would get some kind of input. Then they would process this input and deliver some kind of output. A simple example would be a thermostat: it gets input from temperature sensors, processes that data by comparing it to the optimal temperature and then sends a signal to the heater, either increasing or decreasing it in power. As long as the thermostat keeps your room cozy, you are happy and you will rightfully forget about it being there. The only time you would care about the thermostat is if it stops working. So you only care about Embedded Systems when they don’t do what they are supposed to. Which means the job of an Embedded Systems Engineer is to make sure you never have to worry about Embedded Systems. That’s a bit of a marketing problem right there…

‍

‍

What Do We Need Them For?

Although we should never have to care about them, it would be foolish to think that Embedded Systems are useless.

Let’s look at some history:

The first famous job that an Embedded System had was to help conquering the moon. The Apollo Guidance Computer led Neil Armstrong, Buzz Aldrin and Michael Collins to the moon and made history. Mostly, the AGC was responsible for providing guidance interfaces, spacecraft control, and navigation.

Today even our washing machines rely on Embedded Systems. Pretty much every fancy tech-gadget and every single electronic thing we never really think about is dependent on them. This dependency has increased even more ever since they started to wirelessly link to other systems, driven by the emergence of cheap wireless chips.

For us, this is great since it enables us to build even cooler stuff. For example, we built smart poles for Dubai and an indoor localization system using wirelessly connected chips.

All of this suggests that Embedded Systems will play an important role in future technologies. Does that also mean that we will start to care more about them?

‍

Will We Care More About Embedded Systems in the Future?

Well, not as long as they do their job! If anything, we should care about them less and this mindset will even spill over to other forms of computing. There are many systems which today rely on user input and need to be managed by a user. Wouldn’t it be better if they did their job on their own, without us having to babysit them? Consider automated driving: ideally, you just get into the car and tell it where you want to go. Or even better, the car knows your schedule and drives you to the dentist, while playing some soothing music on the radio because it senses that you are nervous. I guess a more diabolical car would start playing drill sounds…

Even our current tech-features like automatic brakes, distance control or parking assistance are designed to be invisible, automated helpers that you can forget about being there. Without them, our current and our future projects would not even be feasible. So by now, we know what Embedded Systems do, what they are used for and why they are important. But we still need to talk about how they are actually created. The first step on the way to a product is prototyping. So let’s dive in and explore how to prototype.

‍

A Reminder on How to Prototype

Every prototyping process starts with identifying the basic requirements of the given project. You want to make sure that you know the exact problem you are trying to solve. If, and only if that is the case, you can choose the right hardware and firmware.

But wait, that doesn’t sound very agile, right?

True! The target conflict between being agile and delivering high-quality output is pretty big when it comes to Embedded Systems, or any project that requires hardware, really. Agile works so great for software because software can be changed easily. Software is also very modular, so even if the product vision changes over time, it doesn’t mean that you have to throw away all of your old code.

This, however, doesn’t mean that you can’t develop Embedded Systems in an agile way: Instead of starting to prototype with an exact idea of what you want, you start prototyping to explore your possibilities and slowly develop from a rough vision to the exact specifications. The result of this first prototyping phase often prominently features a proof-of-concept, made from off-the-shelf hardware, which shows that your idea actually works. But more importantly, the actual result is that you figured out what your product really has to be. From this point on, you can go the classic route of development, but it still makes sense to keep agile ideas close to your heart. First of all, you can design your system in a modular way. Don’t immediately design your finished product, design the building blocks for it. This way, you always have some opportunities to replace and reshuffle the parts. Go play some LEGO with your kids to get in the mood.

The second principle is even simpler: Can you do it in code? Now, don’t take this as a blanket advice to always try to solve anything in code — sometimes a simple piece of silicon added to your PCB can save you from hundreds of lines of code (and all the possible bugs in there) — but keep in mind that changing code is cheap, while changing hardware gets exponentially more expensive towards your deadline. So we figured out what we need and we got the right idea about how to do it. Now it is time to develop the first real prototype, our version 0.1. Your most important goal here is to make sure that your prototype can actually be tested. Next, you want to actually test and then review the test. Pull out as many learnings as you can and make sure to document them properly. Afterwards, go ahead and take action — revise and enhance your prototype according to your learnings. From now on, this is the cycle you follow until the prototype is not a prototype anymore. Test, review, build — until you have what you set out to build in the first place. The smaller your steps, the less headache.

By the way, this whole process is somewhat similar to the Design Thinking processes. In both processes, it is important to continuously learn and enhance the process itself, thereby creating your own way of doing things. Design Thinking is also what you use for that very first proof-of-concept, to help you define your idea.

‍

Prototype Embedded Systems – The Motius Way

At Motius, we developed some patterns when it comes to Embedded Systems prototyping. They are based on the diverse experiences that we have made in projects over the years.

Before the process even starts, we make sure that there is a Systems Engineer assigned to the project. Why? Interdisciplinarity. Most Embedded projects combine software and hardware. The software can range from real-time control loops to specialized user interfaces and the hardware can include complex mechanical systems instead of just a PCB with some chips on it.

A Systems Engineer coordinates that interdisciplinary through:

• Communication: talks to all parties involved, makes sure that they know what is going on at any time; very important at the beginning when hardware and software are chosen and/or designed

• Documentation: makes sure to document everything there is, sticks to high-quality documentation during the course of the project

• Responsibility: is the contact person for everything regarding the project; knows about internal responsibilities, i.e. who is responsible for what

‍

Getting the Hardware Right or Getting the Right Hardware

‍

The first thing you really need to think about is which hardware is able to fit your needs. Often enough, people get lost in some kind of grand vision of what they want to achieve, only to realize that there is no appropriate hardware that can possibly support that vision. When we talk about hardware, there are also different levels to talk about: Hardware can mean a ready-made Embedded Computer that comes in a nice, industrial casing and with a stable, well supported Operating System. But it can also mean a bare microcontroller, for which you still have to design a PCB, case and a lot of software. Generally, you will want to buy the ready-made hardware that fulfills your needs — but unless your needs are really boring, this might not exist. At this point, you have to drop down a level and build your own — and be aware of how that changes your risk and cost estimates. Going down a level however doesn’t always have to increase those two! When the ready-made solution is not a perfect fit, but has to be shoehorned into solving your problem, the home-grown system has a good chance of beating it. By now you might be sure that you have the right hardware. But do not forget that the hardware needs to be tested. So the hardware has to be testable in a way that fits the project. Additionally, you already need to consider if the hardware can be manufactured in a high-quality and fast manner as soon as the prototype works out as you want.

One more point. Imagine you complete the prototyping process and want to go into mass production. But then one of your suppliers tells you that the component is not available anymore, so mass production is not possible. And right there they flush all your hard work down the toilet. Lesson learned? Make sure that the manufacturer will keep producing the required components. In the Embedded market it is not uncommon for vendors to give you a guarantee to keep the product around for 15 years or more.

‍

Putting in the Magic: Develop the Firmware

The first thing that you need to take care of in the firmware prototyping process is the tool-project-fit. Your essential toolbox includes: a programming language, a build system and a framework. The framework (and I’m sorry, we don’t have a better word for it) can for example be a set of libraries to abstract the hardware. The companies who make the microcontrollers usually provide libraries like that, but these often are not the best choice. Third-parties, like FreeRTOS, Mbed or even Arduino provide abstraction libraries that often work across different microcontrollers. Using those means that your code stays portable and makes it possible to switch to a different microcontroller later. The build system is another important key to your project. This is the tool that takes your code and turns it into a program which can run on your hardware. It takes care of all dependencies, the libraries that you are using in your project, and the compiler you need to target your specific microcontroller.

The most important task is however to make sure that your project builds everywhere. If the project only compiles on the computer of the lead developer, because it’s the only machine that has all the right tools installed and nobody knows which tools are needed, you effectively don’t have a project. Also, be aware that there are operating systems other than Windows and many Embedded Developers are using Linux. If your build system does not work on Windows, OSX and Linux, it is a bad build system and you should not use it. A good tool that I can recommend for this task is PlatformIO, although for bigger and more complex projects you will probably need to move to a more powerful tool. It also depends on the programming language that you are using.

Programming languages are one of my favourite topics to talk about, but sadly for microcontrollers, there isn’t too much choice. The most common languages are C and C++, but please do not just default to them. Both are great languages, but both are also simply old and hard to use. Especially C++ is complex and big, so it takes a lot of discipline to make it work well. A new option that is emerging at the moment is Rust. This language effectively eliminates a whole class of errors that are common in C and C++ — memory bugs. It also has extremely good tooling and a standard build system that makes dependency management a breeze. It’s the legitimate successor to C++ and includes everything we learned from years of using it. Especially for rapid prototyping and exploration, it’s worth to consider MicroPython — which allows you to use the popular Python language on microcontrollers. You will be much faster in developing your software using this language, but be aware that you are paying for it in performance and resources: you will need to use more powerful (expensive) microcontrollers and the program will run slower. But to be honest, this is much less often a problem than people think…

Next, you need to design your firmware. What does it have to do? Think about all the inputs you will need to read, all the outputs you will have to drive and all the data processing you will have to do. Make sure you have a plan to fulfill all the required functions before you start smashing that keyboard. Just like the hardware, your firmware needs to be testable. If it is not testable, then you can’t really know what you are doing. Especially when the system becomes more complex, you will need to have fully automated tests. You not only need to test the components by themselves, but also integrated into the bigger system. Thinking about all of this beforehand will save you a lot of time and obstacles.

Last but not least, do not forget to make sure that your firmware fits your hardware. This is very important when it comes to Embedded Systems because the hardware usually restrains the firmware in some way. For example, microcontrollers have limited memory and speed. Batteries are not infinite either. While these things are not as important in the proof-of-concept phase, the earlier you can make good estimates about them, the smoother your project will go.

‍

Is There More to Prototyping?

For now, this is all you need to get started. Make sure you care a bit more about Embedded Systems than most people do. They keep the bigger systems running and they must be near to perfect to fulfill their function. If you consider our tips for the prototyping process then there is a good chance that you will have a relatively smooth and successful process.

If you want to get more Motius-like insights on prototyping processes, stay tuned for our next blog post. There we will dive deeper into rapid hardware prototyping and show how it can take your game to the next level. In the meantime, check out our Cheat Sheet to find out more inside tips about building an embedded system.