Exploring the Future of Design in Autonomous Vehicles: An Interview with Mark Forbes of Altium

December 13, 2017 by Karissa Manske

All About Circuits recently met with Mark Forbes, Director of Product and Persona Marketing at Altium, to discuss the details behind autonomous vehicles including the challenges of unifying safety standards and why embedded software is so important to this booming field.

All About Circuits recently met with Mark Forbes, Director of Product and Persona Marketing at Altium, to discuss the details behind autonomous vehicles including the challenges of unifying safety standards and why embedded software is so important to this booming field.

An electrical engineer by trade, Mark has been in the electronic design automation industry for 30 years. Within that time, he's patented concealed antenna products and configurable portable HF antennas and worked specifically with TASKING, a subsidiary of Altium that specializes in embedded software design. 

His industry article on AAC, "Who Is Driving Autonomous Vehicles Anyway?", Mark discussed the future of autonomous vehicles and where safety standards come into play.


Mark Forbes, Altium.


As a followup to that piece, he sat down with AAC's Karissa Manske to discuss what the view of autonomous vehicles is from Altium's perspective in terms of safety standards and challenges for design engineers.

All About Circuits: Safety standards for autonomous vehicles have been changing as rapidly as the technologies that go into them. What do you think are the biggest challenges design engineers face as they work to comply with all of them?

Mark Forbes: Well, you definitely hit the nail on the head with that question—these standards evolve quickly and keeping up is critically important. Let me phrase it this way: engineers I talk to view safety standards as another constraint. Each time you start a new project, you have a list of constraints including cost, time, memory, and so on. Safety standards are on that list.

In the back of an engineer’s mind who is writing the software is “if I make a mistake, I could hurt someone.” So design engineers embrace safety standards because they know that mistakes could propagate and cause injury or even death. From the outside, it can look like all of these standards are obstacles to the design process but they’re actually the points you design to.


Image from Altium.

AAC: With companies coming up with their own proprietary products for autonomous vehicles, who do you think is going to come out on top and produce the most technology that we’ll use in standards across the board?

MF: I think the main thing we’ll see is a lot of mergers and spinoffs. No one has all of the technology. No two companies have all of the technology. 

Intel recently acquired Mobileye, who created algorithms for decision making based on visual data. Then, they partnered with BMW to begin creating vehicles. We’re going to see a lot of this soon. The knowledge companies have been acquiring for decades is now being applied in a different way toward automotive applications.

AAC: As these advancements take place, what other challenges do design engineers face in regards to all of the proposals, developments, and adoptions of autonomous vehicle technology?

MF: There are several challenges. One of them is, of course, the standards we’ve already talked about. Another is (and this happens over and over again in electronics) is that different companies are coming up with different ideas, and they’re all arguing about what is necessary and what isn’t.

Things need to be closely monitored. If a company becomes too invested in one idea and the market goes the other way, they’ll find themselves in trouble. It’s so important to not only pay attention to the standards but also to the evolution of the methods to accomplish tasks with innovative solutions.

From a safety standpoint, I think the way it has to go is for certain systems to be the standard. For instance, we may decide that every car will incorporate five types of sensors to process the data in a certain way so all decisions are consistent. Then, there will be a much more concrete definition of what these systems will look like, what type of data they will exchange, and how they will make different decisions.

AAC: Do you see any holes or inadequacies in the safety standards for autonomous vehicles currently in place?

MF: At this point, no. There are certainly holes that are going to open up because every day someone is inventing a new way to do something. We all want to think that from the first autonomous car, no one is going to be injured because of some technological glitch, but—statistically speaking—that’s just not going to happen. It’s a learning process.

Take airplanes as an example. When airplanes first began flying in the 1930s, you really took your life into your own hands each time you got into an airplane. One of the first accidents that happened was one everyone had thought of but also had said, “this will never happen.” That accident was two planes colliding midair over Arizona. Up until that point, airplanes were not controlled. They just took off anytime because what are the chances of two airplanes hitting each other in the sky?

I think the same thing will happen with autonomous cars. There is going to be the possibility of something that seems so remote going wrong (though, under certain circumstances, it actually won’t be that remote at all). These vehicles will run into instances that their software may have never anticipated. Luckily, with embedded software, autonomous vehicles will learn how to handle these situations and, as they do, that proper handling will propagate to other vehicles through universal updates. As holes and inadequacies pop up, we’ll be able to solve them much more quickly than in the past.

AAC: There's a lot at stake when it comes to test and measurement with autonomous vehicles. We can't help but think of the "Pentium flaw" that was discovered back in the 1990s where a computing error in Intel transistors was predicted but unaddressed—and resulted in unreliable CPUs and a $475 million recall. Can you talk a bit about the importance of foreseeing even abstract issues in the context of automotive safety?

MF: Years ago, when I was a magazine editor, I had the opportunity to interview Dennis Ritchie. I got to go to Bell Labs and meet a bunch of the people there, including one of the fellows who had just published a book stating that the microprocessors of the time (around 25 years ago) had reached a scale that made them impossible to test. That scale has obviously been way exceeded, and so statistical methods exist, but—much like what happened with the Pentium flaw—something tiny can be overlooked.


A 66MHz Intel Pentium CPU with the FDIV bug (or "Pentium flaw"). Image courtesy of Konstantin Lanzet (CPU Collection Konstantin Lanzet) [CC-BY-SA-3.0]


The chance of something similar happening in the automotive industry is not zero. The way things are tested now in comparison to 20+ years ago has evolved so much from the days where you tested every single function of every single pin and every combination—because it’s physically impossible to do that anymore.

Could a mass-scale crisis unfold? The possibility certainly exists. But, as I mentioned earlier, the fact that so much of an automobile will be controlled with embedded software instead of mechanically, it will be much easier to correct such problems rapidly. Now, that’s not to say there will always be a software workaround because sometimes that’s just not possible.

Are we missing anything? That’s definitely a question that needs to be on everyone’s mind.

AAC: As companies like Google and Apple enter into the automotive space with autonomous and assisted driving, how do you see that affecting the future of autonomous and electric vehicles?  

MF: That’s a great question because companies like Google and Apple are what we call disruptors. They’re non-traditional companies that don’t have a set of rules they’ve been operating under for 100 years. Automotive companies produce what you expect. They’ve introduced evolutions, certainly, but they’ve always produced automobiles.

To see external companies that have never had a finger in transportation come into the arena is interesting. Google and Apple basically invented user experience. Before them, companies had never really talked about that before. In the auto industry, that’s a relatively new concept. I remember, when I was a kid, there was a thriving business that produced plastic cup holders because there weren't cars on the market that came with cup holders! How do you miss that part of the experience?​​


The Director of Growth at Voyager (a company that builds self-driving taxis) reveals one of the first images of Apple's autonomous vehicle


The development of cars has been pretty linear for decades, so this is going to be huge. I compare it to the introduction of compact discs. When CDs came out, they were so much better than vinyl records that things changed almost overnight. I remember playing my first CD and thinking that CDs would completely wipe out vinyl records in the next ten years—it wasn’t ten years. In about ten months, sales had completely flopped over to CDs and the acceptance was incredibly fast because the design and technology were so much better.

I think that’s what we’re going to see with autonomous cars. Not only because they’re autonomous, but because the whole experience is going to change and be valuable to the user. You won’t just sit there and drive for eight hours, losing out on that time. You can work, hold a conference call, or sleep while the car does all of the work.

The fact that Google and Apple, as well as a host of other companies like Uber and Lyft, are getting into this industry means that what we see in five years is going to be really difficult to predict but really exciting to see.

The fact that Google and Apple... are getting into this industry means that what we see in five years is going to be really difficult to predict but really exciting to see.

Q: Out of curiosity, how long do you think it’ll be before we have fully autonomous cars?

MF: It’s tough to say. I think the limiting factor is really how safety standards evolve. You can’t write a law for something that doesn’t exist. Uber’s recent experience in California showed us that. The state of California thought they were being reasonable and Uber disagreed. Rather than exploring options and having open communication, Uber moved over to Arizona. These things will have to evolve as they happen. Until we know we need a law covering something, it won’t happen. We’ll see growth coming in spurts and recession as we exceed our ability to control the growth. That’s generally how things come to fruition.

As far as a fully autonomous car are concerned, the numbers are out there. They change periodically as companies claim different goals, but I think between 2020 and 2023 we should see commercial autonomous driving cars available. That’s really not too far off, and I think a lot of people are thinking “hmmmm, I’ll let some other people ride in these cars first to gauge whether I want to get in one or not.”

AAC: So Altium acquired Tasking some time ago, a company that specializes in embedded software design. When it comes to autonomous vehicles, what embedded software design tools do you think are most useful for designers?

MF: Altium acquired Tasking in 2001. From that initial acquisition, we've continued to update the compilers and, in the past 18 months, we added some peripheral tools to help embedded software developers.

Take, for example, our safety checker, which analyzes your code statically and determines whether any memory violations or sections of code exist that are not supposed to be getting into the protected memory. A designer can go through the code by hand and find the same things as our tool, but the amount of time involved is ridiculous and human beings still make mistakes. Saving that time and heightening accuracy is the impetus of where our tools come from. 

The Profiler is another tool we offer, which allows users to make adjustments to the code so they can optimize for speed or size at the right mix. We've also released a standalone debugger. You can purchase additional licenses of this debugger so there isn't a bottleneck at a project deadline when everybody suddenly wants to debug at the same time. 



Linear Algebra PACKage libraries, on the other hand, have been around since 1992. They have been used and proven for a variety of compute-intensive applications like digital signal processing. Not only will these functions be more important with more sensors and fusion of that sensor data, but the fact that they have been verified correct for decades enhances safety as well. While that may not be as important immediately, as we get more and more sensors and data, LAPACK will become more essential. 

Our goal is to provide a complete set of developments tools that help accelerate the design process—and ensure it's being done safely. At this point, we have a pretty complete set of tools that cover the majority of problems design engineers run into. The reason we’ve developed a number of these tools is that customers came to us with specific problems. We work to offer tools to help designers solve problems in a more efficient way.

AAC: Last question. What are some of the most surprising change you’ve seen in this industry?

MF: The compute power of cheap memory has made so many things possible that weren’t in the past. Many of the things—such as cell phones—were thought up long ago but lacked the ability to be created without cheap, accessible memory.

You ask about the changes I’ve seen in the industry, but I think the more surprising thing is what has remained the same. The first project I ever worked on used the Intel 8051 single chip microcontroller. That is still used! Time has cemented that there are certain constraints that may always exist. This can be seen in the automotive industry where you’re limited in space, cost, and power. All three of those things are critical to think about when you’re designing.

Thank you to Mark for his time and insights!