Two Methods for Architectural Scalability in Embedded Systems

Jacob has 15+ years of experience in microcontroller based real-time embedded systems. An avid writer, trainer, speaker, consultant and entrepreneur, he transforms the complex into simple, understandable concepts that accelerate technological innovation. Jacob has more than 200 published articles on embedded software development techniques and holds three degrees including a Masters of Engineering from the University of Michigan. Visit Jacob at

Two Methods for Architectural Scalability in Embedded Systems

Embedded systems developers often struggle to create a hardware and software architecture that are easily scalable across the range of products they want to deliver. This scalability is not just at a point in time across a product line but also out into time where future products may need to be higher performance or lower cost or even both. There are two different strategies used to create scalable systems; design overkill and segmentation. In this post, we’ll examine each method and evaluate if any other alternative solutions exist.


System developers will often realize that they have several different ways in which they need to be able to scale their solution. The simplest way to scale a system and ensure that it can cover current and future needs is to over design the solution. A great example of design overkill is when a simple control solution is needed, and the team decides to go with a single board computer (SBC) and throw Linux or Windows on as the operating system because they know that it will be able to do nearly anything they want. The problem with overdesigning is that in many situations, developers are using a sledge hammer for a finishing nail.

Over design results in several problems that then need to be considered such as:

  • Physical size constraints
  • Larger energy consumption
  • Increased costs

These problems can make covering customers with tighter budgets or scaled back requirements much more difficult to service.


Another way that a system can be scaled is to instead break-up the end requirements into different groupings that can handle low-end, middle-end and high-end customer needs. No single solution, other than an overkill solution can handle the different constraints whether its low cost, high-performance, low power, so the solution is broken up into different systems, each with a different architecture that can provide them with the functionality across the different design segments. This helps to solve some of the problems with overkill designs in that you only need an overkill system within each segment.

Scaling through segments is not necessarily problem free either. Developers now need to design, maintain and manufacture multiple systems that could have different processors, components and even drastically different software architectures and drivers that now need to be maintained in parallel. The on-going cost to support and maintain these systems can quickly become overwhelming when compared to an overkill solution.


The methods of scalability that we have been focusing on so far are methods that developers use for their own custom, in-house solutions. An alternative method to achieve architectural scalability is to use an existing embedded platform or set of platforms that already has scalability built into it. Just like SBC’s are often used in the application processor world to allow daughter cards to be built with scalable and custom needs for the application, an embedded solution like the SCM318 can provide similar capabilities. Leveraging an embedded platform can provide a core set of features, both hardware and software, that are ready for production that then only require a simple extension to the hardware and software to meet the specific requirements for the end application. In this case, the vendor has taken care of the scalability problem for the developer.


The way that embedded developers build systems today requires scalability such that it is either design overkill or is discrete to cover a limited number of problem domains. While this can work, we’ve seen that there are scalability issues with both methods. One potential solution is to use a scalable platform that doesn’t overkill the design or limit the problem domain but provides a foundational hardware and software set that can be easily scaled across not just product lines but also future feature needs. Partnering with a vendor that has already developed multiple hardware platforms that behaves as a single software architecture can dramatically improve the scalability and flexibility available.


System scalability is a critical factor for many embedded systems. The ability to support multiple product lines and feature scalability for years after the system is deployed can be the difference between long term success or failure. Take a few minutes to think through your own scalability strategy. Does it fall into one of the two methods we talked about today or are you designing outside the box with an embedded platform?

3 Pillars of Embedded Innovation

Three pillars of innovation – communications, control, and human machine interface (HMI) – drove a consumer device revolution.
How are these affecting the embedded systems you design?

Are we Doomed to be Integration Engineers?

Developers are between a rock and hard place managing increasing design complexity and are turning to off-the-shelf hardware and software ingredients. Are we doomed to become integration engineers?

The Top 3 Problems Holding Back Embedded Systems Engineering

Most embedded system developers don’t realize it, but they have three mindset problems that are preventing them from getting to market faster and decreasing their engineering costs: customization,
starting out too low-level, and believing that all software should be free.

How to Scope Your First HMI Project

HMI developer often under estimates the total extent of what is necessary to successfully pull off the project. In this post, we will examine what is necessary to scope your first HMI project and make it a success.

The Siren’s Call of the Pseudo Platform

An LCD and touch screen are certainly important, outward facing factors of a Human Machine Interface (HM). But behind the scenes, there is much more to a display module than meets the eye — it’s is a highly integrated real-time embedded system tuned to efficiently interact and communicate with its environment.

7 Free Resources for Embedded UI Design

Designing an embedded HMI’s User Interface (UI) and User Experience (UX) can be a daunting task. We’ve compiled seven free resources to equip you and your creative team (if you’re lucky enough to have one), with an arsenal to leverage when drafting your UI design.

The Anatomy of a Display Module: Software

there is a lot of software that is used to get a Human Machine Interface (HMI) display module up and running. To compete in today’s fast-paced and competitive market, can you leverage an existing display module to accelerate your development cycle and beat the competition to market?

The Anatomy of a Display Module: Hardware

An LCD and touch screen are certainly important, outward facing factors of a Human Machine Interface (HM). But behind the scenes, there is much more to a display module than meets the eye — it’s is a highly integrated real-time embedded system tuned to efficiently interact and communicate with its environment.