Achieve business success by bridging the gap between software and hardware in embedded systems

The design and prototyping phases of technological solutions are usually long and critical for business success. Initial capital investments can be high in these projects. Consequently, stakes and expectations are high! Since we are still suffering the consequences of the pandemic in terms of shipping delays and electronic components shortages, in many cases companies are experiencing a tremendous amount of pressure to reach the market and send committed inventory on time.

There is also the constant battle for hardware resources because applications often require increasing processing capabilities. This means that hardware will probably be oversized at the beginning and obsolete with time. You will, therefore, need to revise your design to constantly add more hardware capabilities to your technological products and unnecessarily escalate costs and investments.

Finally, finding experienced staff knowledgeable in embedded systems, hardware, and software at the same time is not always easy. In some companies, engineers without experience in embedded systems lead and develop technological projects. As a result, they might choose developer kits (Jetson Nano, Arduino, Raspberry PI) due to the familiarity with those systems and the standard features that facilitate integration with other systems. Developer boards have unique industrial applications, and you can read more about them in this blog post. But this might not be the case for mass-production.

All these factors can negatively influence the decision on language programming, algorithm architecture, and overall application software development. Sometimes the decision comes down to using a standard operating system instead of a customized or specialized one with a Stack Overflow collage code instead of a proprietary algorithm. This leads to untapped resources, oversized hardware components, unnecessary delays, additional redesign or recertification costs. So, at the beginning, this might seem the cost-effective solution, but you might find out it was not the most cost-efficient solution down the road. What’s worse, during regular operation, hardware working at full capability can lead to heating, reduced mean time between failures, and greater repairing costs.

Algorithm Architecture

Let’s analyze the common path companies take towards algorithm architecture. Unfortunately, some engineers working with embedded systems sit down to program without any plan or design. The problem is that you will only find out after the fact if your algorithm is effective or inefficient.

We are going to describe two examples of ideal algorithms: lineal and logarithmical. Let’s assume that each basic operation takes a second. In the case of lineal algorithms as inputs increase, execution time does as well, as seen in Table 1. If this algorithm behaved logarithmically, as we had more inputs, their execution time would remain stable (Table 2). For example, Binary search algorithms exhibit a logarithmic behavior.

Table 1. Relation between inputs and execution time of a lineal algorithm.

Table 2. Relation between inputs and execution time of logarithmic algorithm.

These two examples are not usually found in real life because algorithms hardly behave lineally or logarithmically. The “Stupid sort” algorithm can be used as an example of the results when no planning or designing was performed before you start programming. This is a structuring algorithm based on a random test in a group of cards with factorial behavior (Table 3). In which if we have 100 inputs, we have 3.2E+183 years to solve it. According to NASA, the Universe’s age is 13,7E9 years, which implies that if we executed the algorithm the date the universe was created, it would still be running with no solution. You want to stay away from factorial algorithms, like the “Stupid sort” Algorithm, to avoid wasting hardware resources.

Table 3. Relation between inputs and execution time of a factorial algorithm.

In fact, hardware has its limitations. In general, embedded systems time scales are difficult to grasp by humans. For that reason, we are going to define a scale easier to understand for this analysis. For the typical 3.9 GHz processor included in 2014 regular computers, we can say that one CPU cycle takes 1 second with the times shown in Table 4. In those cases, reading a file in the hard drive could take in the worst-case scenario 1.5 years, or reading a file in the RAM memory could take 32 seconds. As you can see, a poorly designed algorithm will waste resources. Consequently, you might think that you need more robust hardware with increased capabilities when you need to review how you are developing the software.

Table 4. Execution times of regular processes in a computer in a scale that is easier to understand.

How do you achieve business success when developing technological products?

With careful algorithm architecture. You need to assemble a team that includes at least one experienced engineer in embedded systems. This professional will be best equipped to architecture algorithms that will run in a specific hardware. This person will basically improve software to best match hardware (not the other way around), which in turn will provide a better return on investment and save you a lot of operational and manufacturing headaches.

An embedded system engineer will strategize, plan, and program to avoid common mistakes when developing software and will be able to predict hardware capabilities. This means that the challenges can be reduced, and it will be easier to achieve business success. Who knows! You might even become the hero of Industry 4.0, Internet of Things, Robotics, or Image Processing in your company.

If you want to continue reading about this topic, you can check out this blog. You can also check out this page for more information on Embedded Systems.