3 Pillars of Embedded Innovation

3 Pillars of Embedded Innovation

From the Blackberry’s release in 1998, to the iPhone in 2007, to the vast array of connected and powerful home and personal devices we have today, the past two decades have seen an incredible leap in our ability to communicate, control, and interact with our world as consumers. Indeed, it is these 3 pillars of innovation – communications, control, and human machine interface (HMI) – that drove this consumer revolution, motivating many of us to stand in line for hours every two years just to get our hands on the new iPhone. Unfortunately, the non-consumer, or “embedded systems” world has been unable to leverage these technology ingredients. Yet, the pressure to bring those same pillars of innovation to embedded systems has continued to increase and is now taking the embedded world by storm. Let’s examine how these pillars are affecting the embedded systems you design.

Pillar #1 – Human Machine Interfaces (HMI)

Human machine interfaces in embedded systems have traditionally been very basic. Many industrial, medical, and similar applications today still use a simple 2×16 character display, LEDs, and a few buttons for human interaction. In the age of connected devices and the prevalence of smart phones with high resolution images and videos, many users don’t just want improved human machine interfaces but are requiring them in order to more efficiently interact with devices. As soon as a system has a graphic/touch display on it, it can dramatically transform what can be done with the product. For example, add a display to a commercial oven and suddenly you don’t just have a way to control the oven but also the ability to interact with the user and provide them with important information such as training videos and interactive manuals right on the machine. The HMI suddenly takes on a life of its own and can dramatically increase product value.

Pillar #2 – Controls

A critical component to every embedded system is how it controls and interacts with its environment. When I hear the word controls, I often imagine general purpose input and output being used to read switch states and drive relays. While this is quite common in embedded systems, controls are helping to innovate embedded systems for several different reasons. First, the types and number of sensors available to developers has skyrocketed. Next, sensors used to be big and bulky but recent advancements in sensor technology have shrunk the package sizes so that they take up almost no space in a product. Finally, with the mass production of so many sensors due to the smart phone and wearable device revolution, sensors are very inexpensive. Control applications can now use these inexpensive sensors and leverage their connections through communications and HMI’s to provide ways to interactive with the environment that were never before available.

Pillar #2 – Communications

Since the industrial IoT it is finally starting to gather steam, adding communication interfaces to a product can radically transformed how and what can be done with a product. Imagine adding Wi-Fi to an oven, washer or other industrial device. Suddenly that connectivity adds a plethora of capabilities and ways that the product can be used and innovated such as:

  • Collecting run-time and performance data
  • Performing predictive maintenance analytics
  • Adapting to user consumption and interactions to minimize waste
  • Managing device wear and tear to maximize life-time
  • Over-the-air/wire firmware upgrades for maintenance, security, and features

These are just a few examples and there is a nearly endless possibility on how a company can use communication interfaces to not just provide new capabilities to their clients but also to revolutionize the way that their business model works!


As we have seen in this post, the same three pillars of consumer product innovation: HMI, control, and communications, can bring incredible value to embedded systems. But engineering teams will have to rethink their development and technology strategies to overcome or avoid the inherent problems in adopting consumer technologies into their products if they want to bring this value to fruition. In the next several posts, we will dig deeper into each pillar and provide the reader with the knowledge and tools they need to understand and leverage each pillar successfully in their own products.

A Tip for the “Serious” Engineer

Is your company and its products leading your market as these 3 pillars of innovation appear in competitive products? Are you on a sustainable path with “embedded suitable” ingredients? Start considering today how these three pillars will change the way that you not just design your products but also run your business.


Are we Doomed to be Integration Engineers?

Are we Doomed to be Integration Engineers?

The big push for embedded systems to is to become inter-connected with local intelligence complemented by cloud-based AI and management… and exposed to the user through a gorgeous modern Human Machine Interface (HMI). These features are dramatically increasing system complexity. Increased complexity isn’t necessarily a bad thing if it allows companies to rapidly innovate and differentiate their products while reaching new markets that might not have otherwise have been available. One major problem with increased complexity in this case, is that development teams are not being provided more time or money to deal with it! Instead, best case, development timelines and budgets are staying the same but, in many cases, they are decreasing. Developers are left in between a rock and hard place and are turning to third party software stacks and hardware to help manage the complexity and give them a leg up on the timelines and budgets. This leads us to an important question, “Are we all doomed to become integration engineers?”.


When someone mentions an embedded systems and software engineer, I immediately picture an electrical engineer who is not only a master over the hardware but also understands the bits and bytes of the software that is driving that hardware. The fact is, as we move to more complex systems, those embedded systems and software engineers are becoming a rare and nearly extinct breed. There just isn’t the time or budget available to understand everything that’s happening in the system! Are embedded software engineers becoming nothing more than integration engineers taking software stacks and hardware from various third-party sources, meshing them together and then going to market? 

On the surface, it very much looks like we are doomed to become integration engineers. Control over the low-level bits and bytes will quickly become a distant memory as embedded software engineers move away from the hardware. The reliance on third-party stacks will dramatically increase as the entire system becomes nothing more than interconnected black boxes. To some degree, this all makes sense, since there is a lot of common code in an embedded system and we don’t really want to waste precious development cycles reinventing the wheel.


When we dig deeper, the truth is that while we may very well become integration engineers, if we leave behind our embedded roots, we will never be successful. The fact is, the modern embedded software engineer needs to leverage and integrate third party software but also must be fully capable of optimizing and customizing the solution. While we can’t afford to build everything from scratch like we did in the “good old days”, we can still customize and scale our integrated software solution to provide a fully differentiated product that is built upon the same building blocks as our competitors. After all, many embedded systems share a common base, components that are needed in every system. Recreating that functionality is a waste of not only time but also budget.

The key to avoid becoming only an integration engineer is to develop a product on a platform that is already fully integrated and provides developers with the ability to easily scale and differentiate their product. Such a platform would allow developers to still dive deep into the low-level software and customize it to their own applications needs. If you stop for a moment and think about this, it makes a lot of sense. You wouldn’t catch a chef spending most of his time trying to build an oven. Instead, a chef buys the oven which is nothing more than the tool that he uses to differentiate the product for his customers. 


Stop thinking that all the software in the system is software.  Start thinking that all the base firmware – OS, stacks, infrastructure – should be supplied as a tool.  If you start thinking of these as expected tools from the vendors, then it changes your idea of embedded engineering.  Using the “tools” and building an “application” take on a different level.  Don’t think of this as replacing your IP or software, think of this as leveraging a much bigger tool.  You’re the chef, use the oven, stop building the oven every time you want to cook. 


Are you wasting precious development time reinventing the wheel or building your own oven? If so, take a closer look at the SCM318 which can provide you with that baseline hardware and integrated software platform that you can use to start immediately differentiating your own products.


Two Methods for Architectural Scalability in Embedded Systems

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?