The changing relationship between cars and humans

Automotive companies are trying to learn how hardware and software will work in conjunction with autonomous cars. I spoke with Andrew Macleod, the director of automotive marketing at Mentor Graphics, a recent Siemens PLM software acquisition, about software and hardware operating together and his experience in guiding automotive companies seeking advice from electronic design automation experts.

Our conversation took us through some of the biggest challenges the industry faces as automation expands, as well as the areas where development is still needed, how systems of systems could come into play and how companies’ engineering culture will have to change.

Macleod highlighted the need to create a digital twin of a vehicle to reduce development time. He also touched on the market demand for “non-clunky” interfaces with the elegance of an iPad and, as vehicles reach level 4 and 5 autonomy, the importance of focusing on the entire user experience, including the interaction between car and user.

For these future vehicles, the digital twin needed for development will be more complex, as models of the human body evolve into a new type of driving experience. This may be difficult to achieve as you enter the realm of human cognitive process molding. But without some of this modeling capability, knowing if an autonomous car experience meets consumer expectations, in-car testing with the consumer will be needed during development.

Next, we discussed the relationship between humans and autonomous cars, and how the trust and communication between each party could happen.

EDWARD BERNARDON: In order for autonomous cars to become commonplace, before we’re going to jump into an autonomous car we have to 100 percent trust it. How does a passenger know if autonomous systems are operating properly in order to build the needed trust? Is there anything that’s being done to help with this aspect of autonomous cars development?

ANDREW MACLEOD: That question is related to functional safety: how do they make these cars safe?

We know how to do that. We have electronic steering systems and electronic braking systems today, and we can have dual core processors running codes and software in lockstep, so any fault that occurs in the system can be detected, which would result in a controlled shutdown. So we can just extrapolate that to the fully autonomous vehicle.

Obviously, it’s a lot more complex and the stakes are a lot higher when it’s a fully autonomous vehicle. But I think that the challenge is less about “how do we do it?” because you can build in as much redundancy into a system as you want. You can put in four sets of fusion boxes, and they are all checking each other, but how do you do that in a cost effective way?

That goes back to the point about system innovation, because it’s one thing to say, “This is safe; this will never fail.” But you’ve quadrupled the whole system cost, and car makers won’t accept that – they never would.

It’s a combination of smart hardware, multiple cores running the same type of software, checking it, and then things like hypervisors, where you can have protected, functionally safe parts of the system, and then the items that are possibly less safety critical.

A good example would be combining the infotainment system and the driver information system – so the dashboard would contain the infotainment system. There’s safety critical information that has to be protected in the dashboard like the check engine light – that can’t go down. But if the radio goes down, it’s an inconvenience, but it’s not a safety critical thing.

We know how to run those two systems using one processor, and separating it in software using a hypervisor, for example. Creative ways to try to solve that problem and make it cost effective, and make it something that the carmakers can put across the fleet, I think is going to be the challenge, and we know how to solve that.

EDWARD BERNARDON: You have an AI driven machine that suddenly figures out “Uh-oh. I’m in trouble.” Unfortunately the resident human is sleeping – asleep in their autonomous car. Do you think it is possible for a car to safely wake a person and have them take control – can this problem can ever be solved? At least in the near future?

ANDREW MACLEOD: I think when you look at ISO 26262, the automotive functional safety standard, it’s more concerned about identifying potential faults and then mitigating. And, how you manage a fault in the system if something goes down?

Or you’ve got a bunch of transistors that – the wrong signals are being sent – the system has to be designed so that it can identify that, control the fault and then shut the system down in a controlled, safe way.

I think if we ever had a system where part of that controlled shutdown was alerting the driver and telling them to steer the car over to the side of the road, I wouldn’t consider that to be a functionally safe system. That would have to be handled through electronics and software, which is part of the design process. That’s not something that you just add in at the end of the system.

It has to be designed in such a way that looks at every single part of the design process from initial SOC, to writing lines of software and making sure that all the software and the upgrading systems hardened for example, and making sure that any kind of shutdown or fault in the system can be managed safely.

This concludes part four of my conversation with Andrew Macleod. In part five, we discuss the role vehicle to infrastructure communication could play in safety systems, how these systems could accelerate the practical use of autonomous cars and how Mentor’s integration into Siemens will help Siemens deliver solutions for the future auto industry. 

About the author
Edward Bernardon is vice president of strategic automotive initiatives for the Specialized Engineering Software business segment of Siemens PLM Software, a business unit of the Siemens Industry Automation Division. Bernardon joined the company when Siemens acquired Vistagy, Inc. in December, 2011. During his 17 year tenure with Vistagy, Bernardon assumed the roles of vice president of sales, and later business development for all specialized engineering software products. Prior to Vistagy, Bernardon directed the Automation and Design Technology Group at the Charles Stark Draper Laboratory, formerly the Massachusetts Institute of Technology (MIT) Instrumentation Laboratory, which developed new manufacturing processes, automated equipment and complementary design software tools. Bernardon received an engineering degree in mechanical engineering from Purdue University, and later received an M.S. from the Massachusetts Institute of Technology and an MBA from Butler University. He also holds numerous patents in the area of automated manufacturing systems, robotics and laser technologies.