The Architecture for Autonomous Driving: A domains-based approach

By Lars Reger, Automotive CTO, NXP Semiconductors 

(A version of this was originally published December 2017 ATZ elektronik (www.springerprofessional.de)

The era of self-driving cars places semiconductor companies at the center of important discussions about standards, methodologies, and design approaches. Traditional automakers and new auto disrupters ask, “How would a semiconductor company build a self-driving car?”

Long standing companies need a way to maintain business continuity and incrementally build their portfolios in areas like autonomy. Disrupters want to build from the ground up with an all new approach. Both of these vantage points seek to make sense of extremely complex and interconnected design issues that present themselves in a high pressure competitive environment.

NXP’s unique position in working with traditional car makers and disrupters, as well as automakers in every part of the world, brings insights into how design considerations and global trends are changing the shape of mobility. Many have thought about how a car should be conceptualized and built and it all comes down to a domain-based architecture.

This paper presents a systems architecture approach based on domains (see Figure 1, Figure 2), and explains how this new architecture will help carmakers master the complexity of autonomous driving.

Why ask a semiconductor manufacturer?

How a semiconductor company approaches a self-driving car doesn’t seem intuitive until you consider how vital electronics have become to present-day automotive architectures. In fact, most of what’s new and innovative in the automotive industry has to do with electronics, software and IT.

Today’s cars are safer, more efficient, and smarter than ever before, and semiconductors are a big reason why. The vehicles rolling off of today’s assembly lines are more like robots on wheels, and the very high degree of electronic sophistication is largely due to semiconductor technology. As this trend toward electrification continues, semiconductor companies will play an important role in vehicle design.

Semiconductor companies like NXP offer expertise that extends to processing, security, and mobile technologies that are at the core of autonomous innovation. As a result, when people ask how to build a self-driving car, NXP has a clear answer: a streamlined approach to system design through Domain-based Vehicle Architecture.

The Domain-based Vehicle Architecture

The Domain-based Architecture reflects the work of NXP’s automotive innovators and their collaboration with key industry stakeholders. It organizes and groups together the functions that let cars sense, think, and act on our behalf, and helps to manage complexity and support scalability.

?Figure 1

The bottom three domains – In-Vehicle Experience, Body & Comfort, and Powertrain & Vehicle Dynamics – have been part of vehicle architectures for a very long time. The top two – Driver Replacement and Connectivity – are new and relate specifically to the functions required for autonomous operation. Taken as a whole, the Domain-based Architecture delivers an optimum level of autonomy while ensuring the highest degrees of safety and security. Four of the most significant advantages are:

1. Modularity

Dividing functionality into separate domains helps highlight the functional safety and cybersecurity requirements for each subsystem, simplifies the development and implementation of robotic algorithms, and makes it easier to scale features within each subsystem.

2.Easier optimization

The Domain-based Architecture groups similar functions together and isolates them, so it’s easier to design the right levels of safety and security based on the common requirements within each domain. In the Connectivity domain, where the car communicates with the outside world, security is paramount, because external interactions need to be protected from tampering. In the Powertrain & Vehicle Dynamics domain, security is less of an issue since the domain operates away from external factors. What’s more important here is functional safety and reliability, since components need to function while exposed to extreme conditions.

3.Simpler scalability

The modular approach makes it much easier to scale, within each domain, from baseline performance to high-end operation. That means it’s easier to create a range of features to meet various market requirements. The In-Vehicle Experience domain, for example, which includes infotainment features, might include fewer options for a budget model and many more for a luxury model. The Domain-based Architecture enables this kind of scalability in each section of the car, and makes it simpler to create individual building blocks that are both compatible and reusable. Development becomes more efficient and cost-effective, and manufacturing becomes more flexible and more responsive.

4. Reusability

NXP is a strong proponent of the design-reuse philosophy, FIGURE 4. By aiming to use the same building blocks across every automotive domain, it’s easier to add or subtract functionality and evolve designs as new technologies become available. In particular, NXP’s microcontroller portfolio supports design reuse by employing a common architecture and a common software platform across the portfolio. Whether working on a radar system, an electronic control unit (ECU) for braking, or an automotive gateway, the one-chip microcontroller architecture means that customers can start with the same basic microcontroller hardware, and finalize their design using a familiar set of tools, IP libraries, and software code.

A Closer Look at the Domain-based Vehicle Architecture

The Connectivity Domain

The Connectivity domain is an overarching domain that covers a number of operations. It governs all the wireless interfaces that connect the car to the outside world.

The Connectivity domain seamlessly and securely deploys and collects information from all of a vehicle’s externally connected interfaces. That includes familiar interfaces used by passengers and their devices, including radio, cellular, Wi-Fi, Bluetooth Low Energy (BLE), and GPS, as well as newer interfaces that relate more closely to vehicle operation, such as vehicle-to-vehicle (V2V) and vehicle-to-everything (V2X) communication. In the ideal setup, all these external interfaces are housed in a highly integrated smart antenna module that makes it easier to add or subtract interfaces as needed.

Top requirements for Connectivity

-ASIL B

-Security

-Reception robustness

-Co-existing multi-standard Transmission

The Driver Replacement Domain

The Driver Replacement domain lets the automotive “robot” take over the task of driving. It provides the capabilities of sensing and thinking, and uses safeguards to ensure proper operation. The Driver Replacement domain is where a lot of the car’s “smarts” reside, making it possible to interpret the environmental observations produced by various sensors and cameras. The “sensing” components include radar, cameras, laser-based LiDAR, and components for positioning and other types of environmental information. The “thinking” components include situational assessments, path planning, sensor fusion, safety-related algorithms, and more.

In today’s automatic-transmission driving involves turning the steering wheel and manipulating two pedals, one for acceleration and one for braking. By just about any measure, the Driver Replacement domain is better at doing these things than we are. The driver substitute reacts more quickly and more consistently, without the influence of human emotions, and is always on alert. It also doesn’t drink coffee, eat snacks, talk to passengers, answer phone calls, or otherwise get distracted while doing its job.

The Driver Replacement domain functions like the car’s brain. And, like human brains, it can take on new knowledge gained from experience. One way to “teach” self-driving cars is to use cloud connectivity. While a self-driving car is parked in a garage overnight, for example, it can connect to the cloud and upload data accumulated during the day. That data can be aggregated with data from other cars, and can be used to optimize driving algorithms. The “sleeping” car can download these new functions when it “wakes” in the morning, and start the new day with added capabilities.

Top requirements for Driver Replacement

– ASIL D

– Automotive qualification

– Smart sensing

– Cost/form-factor/performance trade-off

Figure 2

The Powertrain & Vehicle Dynamics Domain

Governing motion and speed, this domain is what makes the automobile move. In self-driving cars, the movement is based on inputs from the driver or the driver substitute, and can be modified and optimized based on personal preferences and environmental constraints, such as road conditions.

The powertrain has been present in cars since the earliest days of vehicle design. Whether it’s part of a traditional combustion engine, an electric engine, or a hybrid of the two, the powertrain portion of this domain converts the original fuel source into power and delivers that power to the road surface. It traditionally covers the engine, transmission, drive shaft, axle, and wheels. Operating conditions in the powertrain are harsh, with high temperatures and near-constant vibration.

In automobiles, dynamics refers to the effect that forces and torques have on motion. The Vehicle Dynamics portion of this domain is where supporting subsystems, such as suspension and steering ensure stability and a smooth ride. This is also where you’ll find many of the car’s various sensor technologies, including those based on sophisticated MEMS and MR technologies.

Top requirements for Powertrain & Vehicle Dynamics

– ASIL D

– Cost/form-factor/performance trade-off

– Software enablement personalization & upgradability

– Data fusion (between vehicle sensors and driver inputs)

The Body & Comfort Domain

The Body & Comfort domain supports basic functions for the driver and passengers, and follows behavior to learn preferences. This is also where passive safety mechanisms (seatbelts) and access mechanisms (door locks) are typically managed.

The settings you like to have in place when you’re in the car – the seat in a certain position, the mirrors just so, the climate control at the right temperature – can be tailored for automatic adjustment each time you use the car. These functions often rely on traditional auto electronics, like window controls and seat adjusters, and typically convert hardware operations into software for easier management and modification.

Sensors, microcontrollers, and new illumination techniques can work together to create smart lighting functions that increase safety and match personal preferences. With exterior lighting, headlights can automatically adjust for weather conditions or the presence of oncoming traffic. With interior lighting, programmable zones can make it easier for passengers to sleep or read or watch a video, and dashboard settings can be adjusted automatically based on time of day or who’s in the car.

Top requirements for Body & Comfort

– Upgradable functionality

– Low maintenance

– Energy efficiency

– Monitoring and learning abilities

The In-Vehicle Experience Domain

This is the domain that lets the car support the entertainment, productivity, and well-being of everyone onboard.

The In-Vehicle Experience domain can recreate the same experiences you have in your living room. It offers seamless access to digital content, and gives you the ability to create and manipulate that content. It’s also a smart learning environment that adjusts to your preferences. The software used in this domain needs to be both flexible and easily upgradable, to ensure access to content via any existing hardware infrastructure. At the same time, there also needs to be an advanced, barrier-free Human-Machine Interface (HMI), able to support voice commands, gestures, augmented reality, and advanced personalization.

Top requirements for Experience

– Over-The-Air (OTA) updates

– Monitoring and learning abilities

– Software upgradability/flexibility for content Access

– Advanced HMI

Gateway & In-Vehicle Networks

The Domain-based Architecture is connected by a sophisticated communication network that lets the domains operate in tandem and share information. Acting as the architectural glue that holds the domains together, the internal network ensures data is shared at the right bandwidth and in a secure, reliable manner. The internal network uses many of the same technologies used in today’s most advanced IT setups, including Ethernet connectivity and secure gateways.

The In-Vehicle Network (IVN), which includes traditional automotive technologies such as CAN, LIN, and FlexRay, as well as Ethernet, securely connects the domains. The IVN lets the domains share relevant information and works with the onboard gateway to ensure proper distribution of car-generated data.

The onboard gateway keeps information inside the car, protecting it from external access and outside hacking. The gateway serves to protect (firewall) the subsystems, keeping them separated from one another to avoid unwanted interactions. That way, safety-critical systems are shielded from the actions of other systems, such as infotainment. The gateway also ensures that the high amounts of data used by each domain are routed efficiently and reliably.

Top requirements for Gateway and In Vehicle Networks

– ASIL D

– Security

– Reception robustness

– Low electromagnetic emissions

– Co-existing multi-standard transmission

Conclusion

As part of their definition of the Domain-based Vehicle Architecture, NXP has underscored the importance of three underlying concepts that guide decisions throughout the development process according to simplicity, reusability and scalability.

The Domain-based Architecture is a logical way to break down and group the hardware and software components associated with vehicle design, but it’s also a way to organize the design team itself. NXP uses the domains to guide their internal structure. This helps focus efforts and gather expertise, and makes it easier to maximize the collaboration and technical crossovers needed to spark innovation.

In part of NXPs domain-based approach, NXP recently announced a completely new concept for control and data processing in the vehicle of the future, whether electric, connected or autonomous. The NXP S32 platform is the world's first fully-scalable automotive computing architecture and will soon be used in premium and high-volume vehicles alike. The unified architecture of microcontrollers (MCUs) and microprocessors (MPUs) possesses identical software environments across different application platforms.