Incidents like what happened to the Toyota Prius makes us take a second look at how secure the code running in our cars are. With the IoT paradigm steadily making its way from fabs into embedded systems in every vertical, seeing them in the automotive sector is not a surprise. How can engineers ensure safety in a car that has enough code to virtually have a mind of it’s own?

Shinto Joseph, operations and sales director, LDRA Technology Pvt Ltd, speaks with Dilin Anand of EFY about the changing face of embedded software testing in the automotive sector.


Shinto Joseph, operations and sales director, LDRA Technology Pvt Ltd
Shinto Joseph, operations and sales director, LDRA Technology Pvt Ltd

Q. What is the biggest design challenge faced here while implementing safety solutions?
A. The challenge is beating the memory limitations. When you look at a car manufacturer, every penny counts for them. When someone suddenly asks a car manufacturer to follow all new international safety standards, they will have to innovate and reuse whatever is available. Why? Be

cause if you plan to redo everything there is going to be millions of dollars in cost overruns. As far as the vehicle manufacturer is concerned, he has to work within these limitations with the available limited memory. Ideally when we are testing these sorts of car systems, the code will become bulged because of the instrumentation that we do within the code. As we begin writing code for instrumentation, the original code will be bulged by anywhere between 20 – 30 per cent depending upon the nature of the code. Eventually the code will not to sit into existing hardware. Now, this is where the car manufacturers will start scratching their head.

Q. Interesting. So what’s the solution for this issue?
A. Well, we have faced similar problems in aircrafts before. In the olden days, the kilobytes (KBs) used to matter because the memory was packaged in electronically programmable read-only memory (EPROM). Today’s universal serial bus (USB) and similar standards were not available those days. The test cases also used to account for the KB based scenario. Today, the semiconductor-based concepts came and brought solid-state electronic devices with them, enabling us to do all these tests within their limited memory requirements.

Q. Could you give us an example of a technique followed while doing this?
A. The engineer could for instance, could tackle the testing partially instead of doing fully at one go. Engineers can look for the limits at which they are operating — that means if you have a constraint of 30 per cent, then we need to make sure that at any point of time the code you are building should not exceed the upper limit (30 per cent in this case). In some cases you really need to know the limitations of the hardware and do partial instrumentation tests, which eventually should fall within the international safety guidelines else the car will not get a pass through the safety- security tests. This is known as limited memory testing.

Q. How good are the automotive standards for which manufacturers are going through all this trouble for?
A. While current solutions of the automotive industry have not thought in this direction mentioned above, the sector does have a new standard ISO 26262, which is actually a subset of the aerospace safety standard. In the olden days the enforcement of these standards were limited to aerospace and nuclear. Later, other domains like railways started using it because anything involving public life got people worried. Then you had medical devices following this with industrial things like lifts, elevators and automotive. We are now reaching a level where the forecast is that cars will have more code running than aircraft — a scenario with the IoT-enabled car.

Q. What do we need further tests on cars like this, if the code runs well within the design parameters set for it?
A. Let us take a scenario, where I want to see how a code is running inside an embedded device. The code might run well within the design parameters in the host system. However, the behaviour could be slightly different in a target device due to various reasons. When you are using it in the target system like a car, you have actual environmental factors coming into the picture. You might have seen automatic wipers in operation. There are external factors that are coming in, and some times you will come across a one-in-a-lakh situation. Cases like where you are running a car at a very high speed and at the same time you are seeing an iced patch on the road. It is a very rare combination, but you can’t say it would not happen. It may be a one-in-a-million combination but there is still that one chance. The car should be tested for that scenario. The only way you can predict such a situation is by doing a thorough test on the actual target situation using instrumentation.

LEAVE A REPLY

Please enter your comment!
Please enter your name here