BMW for the first time has shared its Autonomous Vehicle roadmap — spanning Level 1 to Level 3 and Level4/5 — in a disclosure earlier this month at a web-based event called The Autonomous, organized by TTTech Auto. The roadmap shows a company that is making vehicle safety a priority. Given that most AV vendors […]
BMW for the first time has shared its Autonomous Vehicle roadmap — spanning Level 1 to Level 3 and Level4/5 — in a disclosure earlier this month at a web-based event called The Autonomous, organized by TTTech Auto.
The roadmap shows a company that is making vehicle safety a priority.
Given that most AV vendors remain secretive about their AV architecture, automotive industry watchers were pleasantly surprised at BMW’s transparency. BMW listed and identified both key building blocks and suppliers of major chips to be incorporated into its vehicles (see Figure 1 below).
Phil Magney, founder and principal analyst at VSI Labs told EE Times, “We have seen tidbits from BMW and Mobileye before, but this is the most comprehensive view of the HW architecture and scalability path.” He added, “It is a little bit unusual for an OEM to reveal this much information about their AV stack.”
Last week, EE Times caught up with Simon Fürst, principal expert in autonomous driving technologies at the BMW Group. We discussed basic tenets of BMW’s AV platform, its AV safety strategy and why BMW sees the upcoming ISO standard is critical to define, develop and test an automated driving system. Fürst is chair of an ISO group working to develop ISO Draft Technology Report (DTR) 4804.
BMW’s AV platform architecture clarifies the company’s AV design priorities. They are focused on scalability and reusability of software and hardware.
Across all BMW passenger vehicles, from current Level 2 to Level 4/5 cars, both hardware and software are being reused as much as possible across ECUs and cameras. BMW’s base platform is built on the AUTOSAR (Automotive Open System Architecture), using classic microcontrollers (BMW is using Infineon’s Aurix).
As it increases levels of automated driving and their features, BMW addresses those needs by deploying additional sensor systems and high-end microprocessors. The platform’s baseline uses Infineon’s Aurix and Renesas’ R-CAR SoCs to optimize its application in stereo front cameras.
For Level 3 models, BMW is adding two Mobileye EyeQ5, two Intel Denverton CPUs and another Aurix. For Level 4/5 vehicles, BMW expands the configuration to three EyeQ5, one Xeon 24C and Aurix.
Safety by design
Magney told EE Times, “First, I like the partitioning of the AV stack(s). The L1/L2 is classified as ADAS while the L3/L4/L5 is classified under HAD (Highly Automated Driving). Everything is incremental. Under the BMW architecture the L2 becomes a fallback for the L3.” He added, “These systems run separate ECUs, and both utilize Classic and Adaptive AUTOSAR. At the HAD level, you rely on dual ASIL-B channels… so collectively the safety of the system is greater than the sum of its parts.”
For many car OEMs, “Safety First” has become a key talking point as they push AV development efforts. But how carmakers are going about building safety-by-design AVs remains an issue rarely revealed or openly debated.
BMW, however, has diverged by disclosing both its AV roadmap and safety-first strategy in a highly automated driving architecture.
As presented at The Autonomous, Fürst explained that BMW has installed a dual processing architecture — a main and a fallback computer – to ensure safety for L3, L4 and L5 vehicles. Under the architecture, with a primary and secondary ASIL channel, the primary channel calculates the main trajectory for the vehicle. The secondary channel is there to supervise the primary channel.
Whenever the secondary channel detects that the primary channel is generating a trajectory that will result in an accident or crash, it will alert the selector, which switches to a safety trajectory provided by the secondary channel. Fürst confirmed this is a classic doer-checker approach: “Yes. These two channels are constantly cross checking.”
Notably, however, the primary ASIL channel also cross-checks with the secondary channel. When the channels find themselves in disagreement or “misfit” on a trajectory, the system goes into a degraded mode. This is handled by yet another processing block, driven by an independent power supply. This allows the car to continue running in a degraded mode, even with a major power failure. Put simply, BMW is using a level 2 stack as a fallback for the Level 3.
This fail-degraded channel running on separate power is designed to execute the minimum risk maneuver calculated as a fallback trajectory. This channel functions independently from the main system. It can drive a redundant braking/steering system, bringing the vehicle into a safe position. But as Fürst pointed out, this redundant unit cannot perform full functions. “It only has a limited capability.”
AV: Bringing Standards Together for Safety
‘Modern and classic’
Asked about BMW’s overall platform architecture, Magney observed, “To me this looks like the best of both worlds. You have an architecture that is both modern and classic. A system of systems whereby the lower-level systems become fallback for the higher-level systems. You also have a combination of classical and AI approaches. The AI is used mainly for perception while the fallback is based on classical deterministic algorithms.”
Magney called BMW’s system “very pragmatic from a functional safety standpoint.” He explained that having multiple ECUs is best to ensure freedom from interference. And in terms of complying with the ISO 26262 standards for vehicle functional safety, Magney called BMW’s safety architecture “more or less state of the art.”
That’s BMW. What about other auto makers? Magney said said what BMW is doing is “likely similar to what others are doing.”
ASIL B or ASIL D
Fürst noted that the principle advantage of this kind of system design is that “major parts of a system are only ASIL B. Only small parts are required to be ASIL D.”
Those small parts include vehicle dynamic ECU (motion control), trajectory following control and motion control in fail-degraded ECU, and selector, trajectory following controller in Nominal ECU.
Sensor fusion conundrum
Various sensors address a number of different functions. One major part of sensory evaluation is to detect objects on the road, including passenger vehicles, trucks, motorcycles, cyclists and pedestrians.
Critical here isn’t just object detection but “to calculate trajectories of those objects” and understanding of “free space.”
While the AV system offers some mechanisms to monitor the road based on computer vision, it can also use other inputs from radars and lidars to detect the curvature of the road. The system can also use data from other vehicles. It can use a map to generate a trajectory for the car to do some localization. Localization is important for the system figure out where it is with respect to the global map, and to properly calculate a route.
Sensor fusion isn’t as simple as it sounds. Levels of data range from raw to classified data and high-level data. Raw data coming out of radar, lidar and a camera, for example, all vary in appearance. While different algorithms must be applied to different sensors, the levels of data add further complexity. The goal, however, is to find “a clever way to combine these different data to achieve a certain redundancy within the sensor evaluation,” Fürst explained.
Asked to explain “a clever way,” Fürst said, “A lot of scientific research papers are being generated in this sensor fusion area.” The industry still needs to build a fundamental understanding on how different algorithms should apply to different sensor modalities.
Magney noted that there may be nothing inhibiting sensor fusion “other than there are so many ways to utilize the data. You have the static world and the dynamic world to deal with and this requires different processes and different sensors.”
Safety Fürst — why a new ISO standard?
There are multiple standards for vehicle safety, but the one that Fürst is currently helping to define, DTR 4804, is seen as the first step toward ISO standardization specifically for autonomous vehicles.
Last year, 11 industry leaders (Aptiv, Audi, Baidu, BMW, Continental, Daimler, Fiat Chrysler Automobiles, HERE, Infineon, Intel and Volkswagen) got together to publish a white paper called SaFAD (Safety First for Automated Driving).
The same group is now pushing SaFAD as the foundation for ISO DTR 4804. The group held a kickoff meeting in February in Paris, said Fürst. The expanded international group includes Toyota, Nissan, Denso, Mazda, Valeo and others. It plans to publish its technical report by the end of July.
Fürst acknowledged that it will be two to three years before this draft becomes the ISO standard. But by starting now, the industry has an opportunity to work the state-of-the-art technical development for the AV safety standard.
Several auto industry sources told us they find the scope of the new ISO standard “too broad” and “too generic.” EE Times asked Fürst why he think this standard is so important. What would be the fallout if the automotive industry develops no safety standard?
He said, “If we don’t have a standard, every car OEM is on its own… Different OEMs, different technology suppliers will end up developing vehicles with different risks.” The goal of an AV safety standard is “to minimize overall risks,” he added. “The [safety] standard shouldn’t favor one vehicle model over another. Consumers can’t have one car that’s safer than others. Every car must be safe.”
Further, when car OEMs want to update the current generation of sensors, they need a common interface that it eases the transition. Similarly, if the data structure is standardized, “it helps us improve sensor fusion a lot, as a new level of classification and pre-processing data start coming into play.” Fürst believes that the standardized interface and data structure are critical.