Introduction-
Automated vehicles have drawn increasing attention in recent years, where certain companies are pushing automated vehicles into consumers’ hands. However, these vehicles are not fully automated, and to reach higher levels of automation, more sensors and systems must be implemented to control the vehicle in all real-world circumstances. The addition of advanced driver assistance systems (ADAS) to a vehicle is a task in itself.
A vehicle has limited space for sensors, wiring, power supplies, and computer processors. Additionally, all these new components, added to make a vehicle automated, consume power while individual sensors might not be large loads, the power drawn by a multitude of sensors can compound to be significant. Most new studies about automated vehicle systems use an electric vehicle (EV) instead of an internal combustion engine (ICE) vehicle. EVs are inherently easier to control using automated driving sensors and systems, because control is accomplished electrically rather than mechanically. Furthermore, EVs have fewer moving parts than ICE vehicles, which can lead to improved reliability, and government regulations and policies in the U.S. are leading towards an all-EV future.
POWER AND RANGE OF VEHICLE:
Sensor power requirements for an automated vehicle
Diagram of the sensors and wiring paths required for an automated vehicle.
The total power required for a mid-size sedan to reach a high level of automation with the setup shown in is almost 200 W, as shown in Table I. Although only one design is shown here most other automated vehicle sensor layouts are around 200 W and only make minor adjustments, such as replacing RADAR with LiDAR on the front and rear of the vehicle and utilizing different cameras. The main additional electrical load for an automated vehicle is the computer, and the computer is one of the main stepping points between levels 3-5 of automation, due to the need to handle more real-world circumstances and also be fail-safe. Most companies do not release the electrical power requirements of their computer packages, while others speculate the power demand will be at least a few kilowatts, thus making comparisons difficult. Therefore, this section will focus mainly on the sensors and the total estimated power consumption of an automated EV from the data provided. Passenger entertainment loads are also expected to increase for fully automated vehicles. For higher levels of automation, when a person is not responsible for monitoring the environment or fall-back performance of the automated vehicle, it isreasonable to assume passengers will want to be on electronic devices while they are waiting to arrive at their destination. These additional loads, such as a laptop or entertainment system, can range from 50–100 W in some cases. Therefore, two or three of these passenger-induced loads could double the amount of power calculated in this paper to have a highly automated vehicle.
LiDAR circuit schematic and waveform of one laser pulse. When the threshold voltage is applied to the FET, the small capacitor is shorted to ground causing a current spike that emits a laser pulse via the laser diode.
A. CENTRAL POWER AND COMPUTING SOURCE :
The first and simplest power architecture contains the computational power and electrical power within a single space in the vehicle. In this configuration, the high voltage battery, low voltage battery, and computation hardware all lie in the same general space within the vehicle. The configuration could allow for redundancies within the localized computing and power space; however, this design falls short of being fail-safe due to the central positioning of all critical power, computing, and control resources while not providing power and control redundancies to the sensors.
Diagram of the sensors and wiring paths required for an automated vehicle.
DISTRIBUTED POWER SOURCES:
Another solution that could be implemented to distribute power to the automated vehicle sensors is to have two separate 12 V batteries on either end of the vehicle. General Motors has mentioned using this technique and shows multiple power sources for sensors in their automated vehicle the topology could function similarly to the grid. A few power sources are scattered across a region with multiple loads assigned to each energy source. In the event that an energy source is no longer operational, redundancies are in place to allow the other sources to compensate for the dysfunctional power source or wire. To be complete, there would also need to be a redundancy in communication lines between a centralized or distributed computing system and the automated driving sensors. Power sources are scattered throughout the vehicle, which would require additional costs and wiring. However, this configuration is more fail-safe than the centralized configuration due to its redundancies.
Diagram of the sensors and wiring paths required for an automated vehicle with two separated power sources and backup power sources located with each sensor indicated by yellow lightning bolts.
Another approach is to have two separate low voltage power sources, as in the last approach, with a small amount of energy storage located next to each sensor, as seen in Fig. 5. This would enable the sensors to operate even if there is a wire fault in the immediate vicinity of a sensor. A sensor could then operate independent of any physical connections for a short amount of time while the vehicle could divert to a safe location to further analyse a disturbance in the vehicle. Powering the sensor is only part of the challenge— data must still be transferred between the central computer and the sensors in order to obtain positioning information. This could be accomplished by wireless communication. The additional power sources, along with wireless communication, would add to the cost of the system; however, it would make the system more fail-safe.
SENSOR POWER MEASUREMENTS:
To confirm the data sheet power consumption values for the sensors shown in previous table, a test bench platform was built to test the power requirement for some of the automated driving sensors and determine if they had any effect on the 12 V bus. The results are shown in this table.
sensor power requirements data sheet vs measured results
LiDAR was initially discussed as a concern due to its high sampling rate and fast, high current pulses. However, experimental results show that the voltage harmonics on the DC bus did not pose an issue. This was likely due to a good filtering system designed by the manufacturers. Other measurements showed slightly lower power consumption compared to data sheet values. In addition, measurements taken on RADAR and LiDAR sensors indicated their power consumption does not vary significantly when objects are moving around them. For example, the power is constant if there are multiple moving objects or if all objects are stationary around the LiDAR sensor. Moreover, the IMU with GNSS did not vary significantly while the vehicle was moving.
Find out more about Arm Automotive Enhanced Solutions
Challenges to deployment
1. Price of autonomy
It has been suggested that if produced in 2020, grade 4 and Level 5 car could cost between an additional $75,000 to $100,000 compared to a daily car. Truthfully, this figure may even be too low because the total cost is probably going to exceed $100,000 when considering the quantity of sensors needed to realize Level 4 and Level 5 autonomy. to create the purchasing of those vehicles feasible, the worth will need come down dramatically to form it affordable for consumers. it's likely that this high price will mean that the primary real deployments of autonomous vehicles are a part of Mobility-as-a-Service (MaaS), ride-sharing or robotaxi fleets. By replacing the price of somebody's driver, and by driving a far higher utilization of the vehicles than consumers, these entities could build a business model that may support these costlier vehicles.
2. Is Level 3 a deployable reality?
Levels of Autonomous Cars diagram
As shown within the diagram above, Level 3 is that the commencement within the move from ADAS to autonomy. However, there's currently some debate over Level 3 autonomy and also the requirements placed on both the vehicle and therefore the driver. Successfully deployed Level 3 autonomy requires the driving force to still be alert when the vehicle’s self-driving functions are active. This raises a stimulating issue because we as drivers will instinctively assume that as soon as we take our hands off the wheel, we now not must concentrate, and may quite happily do our email, send texts etc, which takes both our eyes and our minds off the road. However, with Level 3, the car can ask you to require back control of the vehicle at any time. This raises the difficulty of how quickly a distracted driver can come to the wheel and take back control of the vehicle to alleviate matters that the autonomous car couldn’t handle. Some car manufacturers are currently discussing skipping Level 3 as the simplest way to beat this challenge. Also, from a liability perspective, skipping Level 3 would make it easier to work out if the motive force is controlling the vehicle or if the vehicle is self-driving. There are discussions about advanced driving monitoring systems using in-cabin cameras and advanced software algorithms to see whether the motive force is alert, and fit take back control, and it not, activate the acceptable warning to bring the motive force back to full readiness. whether or not car manufacturers commit to skip this level, the technology complexity required to urge from Level 3 to Level 4 is way greater.
This question was recently posed to a panel of automotive industry experts, and their answers is viewed in our blog, delivering future autonomous systems.
3. Processing needs of dramatically increased sensor complexity
Autonomous car LiDAR camera and radar sensors
The move from ADAS to autonomous demands a far greater awareness of everything round the car. so as to accomplish this, the amount of sensors on the car are dramatically increasing, with multiple LiDAR, camera and radar sensors required to essentially replace and enhance human sight and situational awareness. Not only are these sensors expensive, but the processing required to know what they're “seeing” and therefore the situation evolving outside the car is dramatically different to the compute required by simpler ADAS functions like adaptive control or emergency braking.
4. Increased software complexity
The majority of autonomous vehicles being prototyped straight away are essentially testing the increased sensor complexity and therefore the software algorithms needed to process the big amount of knowledge coming into the car, make the proper decision about what to try and do then action it. This processing requires a considerable amount of software, with the present estimate we've got being 1 billion lines of code to power a totally autonomous car. The compute requirements to execute this huge amount of software are more adore server performance than traditional automotive embedded processing. this is often driving a trend towards a consolidation of far more powerful clusters of application processors and accelerators in additional performant multicore SoCs instead of discrete CPUs. This consolidation requires a dramatic change within the software architectures, and may also cause a dramatic increase within the software footprint.
The software application complexity is way greater than even the foremost advanced passenger jets already brimming over with autonomous functionality, because autonomous cars will should cater to highly chaotic roads stuffed with unpredictable human drivers and pedestrians vs. the relatively empty skies filled with professional pilots. This results in an outsized amount of algorithmic processing that must happen in real time to grasp everything that's happening round the car so the large software stack that's required for all of the autonomous compute components to form the correct decisions and execute them safely. This greater complexity lends itself to a typical and unified platform architecture on which to create an easily upgradable and portable software stack.
5. Safe deployment of autonomous vehicles
Cars driving on city freeway
As stated earlier, recent statistics have shown that 73% of yank drivers are too afraid to ride in fully self-driving vehicles and, astonishingly, 63% folks adults would feel less safe sharing the road with self-driving vehicles while walking or cycling. This raises a brand new and interesting challenge of how we gain consumer trust, both as a passenger in an autonomous car, and someone sharing the identical environment with the car.
Safety may be a key a part of many automotive systems, and rigorous safety standards and certifications are applied to any functions that require to figure reliably when requested by the motive force, like brakes, steering etc. after we increase autonomy during a car, we are essentially replacing the safe deciding of an individual's driver with a fancy computing system comprising many heterogenous compute elements and, as discussed earlier, a billion lines of code. How can we guarantee that this hugely complicated compute system will execute to the very best levels of passenger and environmental safety?
With the consolidation of functions onto powerful multi-core SoCs, there'll even be the requirement to support mixed-criticality applications on one SoC. this is often where some applications would force the best levels of functional safety as they're executing life critical functions, mixed with applications operating at a lower criticality level. it'd be impossible to undertake to require all the software to the very best level of functional safety, then a compute and software architecture is required to support these different safety levels without having to dedicate a separate SoC for every application.
6. Prototype to production
The compute systems going into today’s autonomous prototypes are typically supported off-the-shelf server technology. The challenge with server technology is that the scale, power consumption and thermal properties aren't suitable for cars. There has to be a major reduction all told of those current attributes. The common belief is that the facility consumption has to reduce by 10x, the dimensions by 5x, and if both of those is achieved then there'll be a major reduction in cost and dissipated heat, which also ends up in simpler and more reliable cooling methods. These improvements will cause truth deployment of self-driving cars, both within the consumer space and robotaxis.
7. Enhanced in-car passenger experiences
Autonomous Car cockpit interior
There is an increasing trend within the cabin where consumers need a more enhanced and enriched in-car experience. As we get to higher levels of autonomy, the occupants of vehicles will turn from drivers to passengers and their requirements for information, entertainment and connectivity are more resembling their home and office.
Before we make full autonomy, there'll be a remarkable hybrid of driver and environmental information being fused with entertainment and productivity features. this can pose the interesting challenge of blending safety into the prevailing feeds, and ensuring that the driving force safety information isn't compromised by the opposite styles of information being displayed.
As we move to the following 5-7 years, to a more autonomous world, there'll show a discrepancy forms of information delivered to the screens including driver information from autonomous systems, media experiences, driver monitoring systems, sensors facing inside the car, all of which can be helping to deliver a more personalized in-car experience. this may require high throughput capability for delivering data to screens, high bandwidth connectivity, and enhanced safety, especially for critical information like driver warning information.
Find out more about Arm Automotive Enhanced Solutions
How is Arm helping to beat these challenges and enabling the mass deployment of autonomous vehicles?
Automotive OEMs and Tier 1s increasingly recognise the requirement for a robust technology partner to assist them address these challenges and consider Arm and its broad automotive ecosystem because the right partnership to create this happen.
Arm has been working closely with the automotive industry to grasp each of the challenges outlined above and is now providing new solutions which will help power the assembly of fully autonomous vehicles at scale.
1. All processing needs are covered
Arm autonomous cars solutions
The unparalleled range of Arm CPUs and other IP elements like GPUs, ISPs and NPUs allows Arm-based solutions to be used throughout the full vehicle, with the broadest set of automotive-grade SoCs being offered by Arm’s semiconductor partners. This range of application processors (Cortex-A), real-time processors (Cortex-R) and little, low-power, micro-processors (Cortex-M) fits across all the phases of an autonomous system, as shown above. As Arm’s semiconductor partners bring more of those compute elements onto single heterogeneous SoC platforms, this may help to fulfill the processing requirements, and at the identical time help reduce the ability, price, size and thermal properties.
2. Safety Ready technology from Arm
The Arm Safety Ready program encompasses Arm’s existing and future products that are through a rigorous functional safety process, including systematic flows and development in support of ISO 26262 and IEC 61508 standards. Safety Ready may be a one-stop buy software, tools, components, certifications and standards which is able to simplify and reduce the price of integrating functional safety for Arm partners. By taking advantage of the program offerings, partners and car makers may be confident their SoCs and systems incorporate the best levels of functional safety required for autonomous applications. Read our recent blog to search out out more about the Arm Safety Ready program.
3. Delivering performance and safety
Arm has also taken another huge discovery in meeting the innovation needs by adding automotive enhanced features to a number of its key technologies. one among these features is Split-Lock which enables clusters of processors to be either split for performance or locked together for higher levels of safety.
Autonomous car split-lock safety function
First introduced within the Cortex-R52 real-time processor, this feature has now been brought into two of Arm’s application processors targeting the high-performance safety requirements for autonomous sensing and perception processing. While Split-Lock isn't new the industry, Arm is that the first to introduce it to processors uniquely designed for top performance automotive applications like autonomous drive.
Split-Lock delivers:
CPU clusters in an SoC are often configured either in ‘split mode’ for prime performance, where up to eight independent CPUs within the cluster are often used for diverse tasks and applications
Or ‘lock mode’ where CPUs are in lock-step, creating up to four pairs of locked CPUs during a cluster, checking against one another for higher safety integrity applications
The CPU clusters may be configured to work during a mixture of either mode, post Silicon production
Flexibility not available in previous lock-step non-Cortex CPU implementationssp
This innovation will enable Arm’s semiconductor partners to make safety-capable SoCs which will be configured at deployment to possess mixed-criticality elements on one SoC, and also use the identical SoC for multiple applications during a vehicle. this may greatly help with the deployment of mixed-criticality systems, like an european running both ADAS and IVI functionality and also help keep the prices down as single parts are often used across a good set of automotive applications.
For more information on Split-Lock, read our blog: Evolving safety systems: Comparing Lock-Step, redundant execution and Split-Lock technologies.
4. Performance, safety and reduced power
The first Automotive Enhanced (AE) application processor was the Cortex-A76AE which was launched in September 2018. This processor offers the performance required for autonomous compute, but at a way lower power level than traditional server chips. including the Split-Lock capability, this processor will afford truly deployable safe autonomous compute.
Arm Cortex-A76AE processor features
The latest Automotive Enhanced application processor, the Cortex-A65AE, is aimed toward safe sensor and data processing and was announced in December 2018. The Cortex-A65AE is Arm’s first multithreaded processor and therefore the industry’s first with integrated safety that has been designed for prime throughput applications like sensor processing in autonomous vehicles. Its multithreaded capability is layered on top of Split-Lock, allowing you to configure and prioritize safety or performance, and it delivers 3.5x higher throughput than prior generations with better power efficiency. Historically, a separate processor would be needed for every sensor stream, but now with the Cortex-A65AE two streams of sensor information is processed per core, improving efficiency and latency.
Arm Cortex-A65AE processor features
Both of those new application processors are often not to mention one another, and with other compute elements to finish a really deployable autonomous computing complex, all supported a standard architecture. this can help automakers build their ideal compute topography and optimize their software stack across these elements without having to alter tools or architectures, and because the safety locking of cores is now being drained hardware, no software changes are required to accommodate it.
Ubiquitous processing with Arm processors
5. The broadest group of ecosystem partners
Arm has always relied on a broad and healthy ecosystem to bring key technologies to promote, and this can be particularly true within the automotive industry where multi-vendor ecosystem support for both hardware and software could be a key factor for deployment for both OEMs and Tier 1s.
Of the highest 20 semiconductor suppliers to the automotive industry, 15 are Arm licensees. The breadth of Arm’s support allows ecosystem partners to make SoCs for all parts of the car, from powertrain and body through to cabin and connectivity and eventually within the move from ADAS to autonomous systems.
However, as noted previously, one in all the broadest challenges for deployment of latest complex automotive innovation is that the software that permits it. No company can write a billion lines of code to win the race to full autonomy, and hence automakers are wishing on a software ecosystem to supply them with the building blocks to induce there. Those building blocks may be supported open source, except for much of the real-time and safety-critical software stack, commercial offerings are preferred for his or her safety pedigree.
Arm has undertaken to support both our open-source communities and commercial software entities to form a broad range of software solutions available across all the vehicle systems, optimized for the Arm architecture. The may be a place where these companies can thrive and make their products easily available to the automotive industry.
As the autonomous software stack grows, there's a brand new collection of software companies that specialize in providing solutions for various applications running on Arm architectures. At this year’s CES there have been variety of key partners showing demos of their different software solutions running on Arm-based hardware. Everything from deep-learning neural networks for perception processing (See how an Arm partner tackles this issue) through to HD mapping applications GPS localization stacks for accurate autonomous positioning. Read our recent CES blog to search out the most recent automotive innovations that are powered by Arm.
CONCLUSION:
Automated vehicles are now being rapidly pushed into consumers’ hands. However, there are still many steps that need to be taken before full automation will be implemented on roadways. This paper reviewed some of the major requirements for a vehicle to reach a high level of automation. The basic sensor requirements have been discussed and presented for different levels of automation, as well as the impact vehicle automation could have on the auxiliary power, reliability, and range of the vehicle.
Comments
Post a Comment