What is Embedded Systems Design?
One of a series of informational articles by the experts at Konsulko Group
“Embedded Systems” is a term that often draws blank stares from professionals in other fields. Before we can discuss their design, we need to ensure that we understand what embedded systems are.
Fortunately, such systems are all around us, so let us start with some examples of embedded systems with which most (if not all of us) are familiar.
The WiFi router in your house, anything with internet/cloud connectivity, such as that Bluetooth or WiFi-controlled light switch you might have, a smart garage door opener, a smart door lock that allows you to open or close the door and even share access with guests, a blood pressure measuring device, or even a smart TV are all embedded systems that most people have in their homes.
But the list doesn’t stop there. Airplanes have perhaps hundreds of different embedded systems. Various medical equipment in hospitals is also embedded systems of different complexities. What do these vastly different products have in common, and what makes them “embedded systems”?
They are all purpose-built devices that have electronics in them and software. There is some type of microprocessor just like there is one in your laptop, and that microprocessor runs the software that has been written for the device. But unlike your laptop or PC, which is a more general-purpose computing machine, these systems are built for a specific purpose.
Note that the examples given are of systems with very different levels of complexity. A smart light switch may have a tiny microcontroller in it and may run software that is highly optimized for size (“bare metal”), or it may use a small RTOS.
Your smart TV, on the other hand, is a very complex embedded system with a high-power processor, a lot of memory and storage, and a very large software stack which is usually, if not always, built on top of the Linux operating system. Thus, it is not the technological complexity of a product that puts it in the embedded category vs, say, enterprise computing, data centers, or “PC”.
How Does Embedded Systems Design Work?
We will assume that the Product Requirements Document (PRD) phase has been completed because that is when customers usually come to Konsulko Group for help with their hardware design or software development.
Let’s look at a common definition of a PRD, taking one from the atlassian.com website: “A product requirements document (PRD) defines the requirements of a particular product, including the product’s purpose, features, functionality, and behavior. It serves as a guide for business and technical teams to help build, launch, or market the product.”
The PRD is a collaborative effort between the business and engineering teams, but certain input, such as the target market and cost of the device, comes from the business team and sets certain design constraints, which are all business-driven.
Based on these requirements, the engineering team has to develop the technical specification, which includes decisions such as what processor will be used, the type of size of memory, the type of I/O that the device will need, whether the product will be powered by a constant power supply (plugged into the wall) or battery powered, etc.
Engineers love to play with hardware and software and build devices that might be overkill for the use cases in mind, but many of the design decisions are ultimately business decisions.
That is why understanding the customer’s business needs and the use cases of the new product they are designing is critical during the consulting/design phase that Konsulko Group engages.
Characteristics and features of embedded systems
Embedded systems are ultimately constrained in the amount of processing power they have and features, and the higher the volumes (number of systems sold per year), the more important the cost becomes, and thus the more the design is “squeezed” to lower the cost.
Beyond the cost of the hardware, which is what customers spend a lot of time and energy optimizing, the cost of the software development and maintenance is probably just as important.
When we help customers make design decisions, one of our criteria for selecting a component is the software support for it. Whether it’s an embedded Linux system or one that uses one of the popular Open Source Real Time Operating Systems (RTOS), we always evaluate the existing software support in order to lower the overall cost of the software development and the future maintenance.
Let’s run quickly through some of the fun engineering phases of the product development because ultimately, at Konsulko Group, we’re engineers who love helping customers build products.
Once the hardware design requirements are finalized and approved by the customer, our hardware team starts the schematic capture of the Printed Circuit Board (PCB), followed by the board layout. The layout files are then sent to the PCB manufacturer, and when we receive them back, the PCB assembly is done.
Depending on the complexity of the hardware design, going from schematic capture to having the PCBs assembled could take just a month or several months. During the hardware development process, Konsulko Group software engineers typically start the software development on reference hardware with the same or similar System-on-Chip (SOC) that has been chosen for the design.
What comes after the PCBs are assembled is a phase that many customers sometimes either ignore or are unaware of its complexity: the “hardware bring-up”. There is usually no complex hardware design that works out of the box in its first revision.
The process of getting software to run on the device, from low-level design verification software to then running the bootloader and finally the Linux kernel and device drivers, is all part of this hardware bring-up phase, which requires skills that straddle the software and hardware domains.
Using scopes and analyzers, soldering wires to the PCB in order to look at signals, understanding at least basic electrical engineering concepts is all required in order to be able to debug the problems that arise when you try to run software on new hardware, and something doesn’t work.
The next phase in the project is completing the Board Support Package (BSP) work, which includes the Linux kernel (in the case of an embedded Linux system), porting the existing device drivers, and writing new ones if necessary.
Note that a lot of this work will have been completed by the time the hardware bring-up is done. These are not two independent phases with hard borders; they are interrelated.
Then comes the integration of the software stack that sits above the BSP. Let’s call that the middleware. At Konsulko Group, we typically do this large-scale software integration using the Yocto Project as the build and integration system.
In addition to the large number of open-source packages that comprise today’s embedded systems software stacks, there are commercial cloud and other technologies that we typically have to integrate and get working before delivering to the customer.
The final piece is the actual application, the thing that users ultimately see and use. This is almost always done by the customer as they are the experts in the particular market, whether it’s consumer, medical, large equipment (like tractors or mining), military, networking, or just about any other industry.
Applications of embedded software
We need to underscore again the fact that these embedded systems design phases are not serial. If executed serially, most companies would miss their opportunities to place a certain product on the market.
Even while the hardware engineers are working on the schematics capture and board layout, the software engineers are typically already integrating the middleware and testing it on similar reference boards. The UI/UX engineers are designing that user experience, and the application developers are working on coding the main application.
If you need help with your next embedded systems project and need expert guidance and quality support through each step of the process, please contact us.