Complexity Kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges, and it causes end-user and administrator frustration. Ray Ozzie
Imagine developing an automotive component for a major OEM. You might be making something as complex as an automatic lane keeping system or something as small as a tire pressure monitor. But one thing that will be in common is that you will have no way to know all the permutations of vehicles and usages of your humble engineering effort. If your component is successful then it will go on across multiple vehicle platforms that each have their own option packages and variations.
Compounding the problem is that when you are working in automotive electronics you are not making a single device. Instead multiple teams at the OEM and various Tier1s are making components that must interact in complex ways. The reality of the situation is that without assembling the components and monitoring the behavior you will never know what really happens when these components are put together. And likely you as the engineer will never talk to the engineers making the other components.
JD Powers found 189 software-related safety recalls have been issues in the US in the past five years with 141 of those reported to increase the risk of a crash. As the industry breathlessly anticipates ceding more and more of the driving task to the machine it is important to remember this – our machines can kill us.
Cars are like giant black boxes that hurtle down the road with dozens and dozens of microcontrollers all sending messages back and forth though a Byzantine labyrinth network. We think we are in control and driving but in reality below the surface the interdependent vehicle systems are deciding what should happen next. Keep driving down the road or slam the brakes and blow the airbags? Think that is your choice?
When IOactive hacks vehicles, they often are able to simply exploit system vulnerabilities. The software designer always expects the other modules to play nice. For example the Prius brake module has a safety feature where if the car is in park you can’t bleed the brakes. If you haven’t watched the video of the reporter suddenly losing brakes because IOactive was able to force an unknown state then you should.
A diagnostic trouble code (DTC) may tell you what is going wrong, but it could also just be a component raising a white flag saying it didn’t know what to do when some other device went off the rails. The software equivalent of huh?
A way for carmakers to improve systems design is to gather real-time data and compare that data to how the system was expected to behave. Not just for a small number of vehicles, but all the vehicles. This data could avoid a large recall by identifying issues early or correcting wrong assumptions in the code.
This is where eSync comes in. The eSync system is designed to both gather the data for analytics plus manage updates. eSync is a holistic end-to end system designed from the ground up to update the entire vehicle. Because if you are going to improve the system, really improve the system, then you need to be able update everything. Don’t just poke and prod at one or two modules.
This Article was first published in Embedded Computing Designs.
