Embedded Software Is Everywhere: Potential Implications

Chad Jackson
|  Created: May 13, 2019  |  Updated: March 16, 2020
Implications of Embedded Software Everywhere

The amount of smart, connected products is increasing faster than ever. It was only very recently that IoT technology jumped from our phones and computers to our refrigerators, our lighting systems, and our vacuum cleaners. It's starting to seem like nothing is excluded from this extensive digital overhaul. In 2016, the smart home market was worth about $24 billion. By 2022, it's expected to reach $53 billion. Smart homes and robots are no longer the stuff of sci-fi. They're becoming part of our everyday lives.

Not only are software and electronics showing up in everything, but they’re replacing traditional mechanical aspects of products. For example, mechanical components no longer control aircraft control surfaces or cars. It is a combination of software and electronics. Instead of the user pressing on Part A, which connects to Part B, which activates Part C, you have a bunch of sensors that tell Part C to do its job when conditions X, Y, and Z line up.

In the past, something that differentiated an everyday car from a sportier one was the mechanical hardware, and its use in creating the suspension system. The system was physically different, and your options were Car A or Car B. Today, they're making electronically-controlled suspension systems that are the same across different types of vehicles. All you have to do is set different software parameters to change from drive mode to sport mode. Electronics and software settings affect the stiffness of the suspension.

Anti-Lock Brake Example

Of course, the suspension system isn't the only part of the car becoming less mechanized and more electronic. For some, there may be a certain nostalgia for a time where cars felt less like computers. But one excellent thing that these electronics have brought us is anti-lock brakes.

Fifty years ago, brakes were purely mechanical. Calipers would squeeze the brake disc when you pressed on the pedal. A mechanism connected the brake pedal to the calipers in your brake system. If you found yourself driving on a patch of ice, you'd press the brake pedal, and the wheels would lock up. It would be a slippery slope after that.

In new cars today, no mechanism connects the calipers to the pedal. Instead, there's an embedded system which is software running on a circuit board. When you push the brake pedal down, a sensor measures just how far down it has gone. The embedded system uses that reading to determine how hard to squeeze the brake disc.

That's not all software and electronics can do for a brake system, however. Sensors and embedded systems enable anti-lock brakes. In this application, there are two sensors: one for how fast the wheels spin, which can calculate the car's speed, and another placed underneath the vehicle that calculates speed by looking at the road. So if you're sliding, one sensor thinks you've stopped, but the other one doesn't. There's something called a custom integrated chip that can very quickly compare both speeds from the sensors. If they don't match, that's when the brakes kick in.

Control Systems Demand ICs

The time it takes to go from car-driving-safely to car-now-sliding is very short. You want to detect whether or not the car is sliding so you can enable some kind of safety system, like an anti-lock brake system. You need to detect it really fast. Comparing two sensor readings and determining if they are different several times per second takes a lot of compute power.

That’s why many of these control systems require incredibly powerful compute resources. Generic processors won't get the job done. They simply can’t crunch the numbers fast enough in real time. So you have to use custom ICs or FPGAs (which you can program like ICs, but they're not as fast).

The price for ICs has come down dramatically, which makes their use in control systems much more viable from a cost perspective. However, they still take a lot of time to develop. An IC might take anywhere from nine months to a year and a half before a prototype is even available.

Beyond the time it takes to develop an IC, there are substantial integration issues in getting custom software to run on custom ICs. Making new software run on a generic processor that's been around forever is very hard to do without a few bugs showing up. You're talking about a custom-made, brand new chip that still has some issues to work through. Once the problems are identified, debugging also takes a significant amount of time.

Today's development schedules are dramatically compressing, and custom ICs take a long time to develop and debug. This issue leaves product development organizations in a catch-22. You want to make quality products, but everything has to come together quickly because of these shortened schedules.

With software going into so many everyday products, engineers have to find a way to deliver increasingly complicated products under tighter and tighter schedules. Soon generic computer processors won’t be able to cut it, and organizations will need to look to manufacturing more integrated chips. The cost has come down, but they take a lot of time to make. This is an issue that needs to be solved going forward.

About Author

About Author

Chad Jackson is an analyst, researcher and blogger providing insights on technologies used to enable engineers. He has surveyed thousands of engineering organizations.

Related Resources

Related Technical Documentation

Back to Home
Thank you, you are now subscribed to updates.