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?”.

IS THE UBER-GEEK EXTINCT?

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.

RUMORS OF DEATH GREATLY EXAGGERATED

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. 

CONCLUSIONS

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. 

A TIP FOR THE “SERIOUS” ENGINEER

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.