<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=317588&amp;fmt=gif">

Inside Nauto with Newfel Harrat, VP of Systems

As Vice President of Systems, Newfel Harrat leads systems engineering at Nauto, where he brings extensive domestic and international experience in R&D, project management, and software systems architecture. His passion for solving end-to-end problems has led him to organizations ranging from startups to Fortune 100 companies. Prior to Nauto, Newfel led the hardware, firmware, and software development teams at Analog Devices, Intel, and Qualcomm. Before that, he built and led the teams that developed and mass-produced Intel’s first branded Android smartphone.

 

You lead system engineering for Nauto. Tell us what role your team plays in the development of Nauto’s products?

Harrat: I oversee Nauto’s hardware, firmware, software, QA, and manufacturing teams. The hardware team is responsible for the entire hardware solution—our camera device, power supply, and all mounting hardware. The software team develops the real-time safety algorithms on the edge that are integrated into the embedded software powering our devices. The manufacturing team plays a critical role in making sure that the quality of our products fit the industry requirements before going to market.

 

What inspires you most about the technology you’re developing at Nauto?

Harrat: My son is about to get his driver’s license, so I feel a personal connection to Nauto’s mission. When you look at the most common cause of collisions today, more than 70% involved distracted drivers. With a lifesaving device like Nauto’s, there’s a huge opportunity to improve driver safety. It’s inspiring to be working on technology that’s not only addressing an important problem but already having an impact today.

 

One aspect of Nauto’s technology that’s unique is the ability to detect distraction in real-time. What do you mean by ‘real-time’ and why is getting this right so important?

Harrat: When we talk about real-time distraction detection, we’re referring to the physics of the event that we are trying to capture—and how fast we’re able to do so. Generally speaking, if the event you’re trying to capture has a dynamic that exceeds your ability to process it, then it’s a mischaracterization to call it real-time.

In Nauto’s case, we’re dealing with events that are happening very fast—be it a collision, a driver who makes a sudden, sharp maneuver, or a distraction—so our primary concern is catching an event that’s real-time to what is happening on the device, as opposed to the distant cloud, where it needs to be processed before generating a result.

The ability to capture and process an event the moment it occurs is essential. We have to have a high degree of accuracy, particularly for something as high-stakes as driver safety.

 

Nauto combines both hardware and software. Does that present any interesting challenges for your team?

Harrat: Working with both hardware and software is very complicated, but it’s a fun challenge. Because we have a finite compute power on the device, there’s a constant balancing act. Unlike the cloud, which has virtually infinite storage and compute power, once you make a device and start shipping to customers, the hardware is fixed. You can update the firmware and software, but you can’t alter the basic parameters of the device.

Determining the right system partitioning—in other words, what you run on the device versus the cloud—is a big part of the work that we’re tackling on the Systems team.

 

Does using artificial intelligence (AI) for something high impact, such as preventing collisions, change Nauto’s approach to testing/validation in any way?

Harrat: Absolutely. Many cloud-based AI companies follow the standard methodology for cloud deployment and testing. Because we have a device that performs real-time critical functions, we take a more rigorous approach.

For example, many cloud based companies release software and test and fix as they go. We don’t have that luxury because the safety of drivers is at stake, so we can’t as easily recall a software fix. On top of that, it’s common practice for companies to factor in a margin of error into their algorithms. We can’t afford to take that approach.

The algorithms we develop not only need to be able to capture and process triggered events in real-time, but they also have to work reliably in different cities and road conditions. Having a high degree of recall and precision—and how to balance the two—is something we look at very closely.