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:
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?