Autonomous driving is undoubtedly a “big cake” painted by the automotive industry for users. It is too tempting to be able to take your hands off the steering wheel and turn the tedious and risky “strength work” of driving into a pleasure.
But the reality is, after many years of shouting, we seem to be quite far from true autonomous driving. If you talk to an industry insider, he may list a series of difficulties from technology to safety, from business models to laws and regulations, so as to explain to you that autonomous driving has a long way to go. But no matter how many reasons there are, the trend is there. In the face of this ultimate goal that everyone is striving for, I am afraid that there are conditions to go to it, and there are no conditions to create conditions to go to it. But how to walk on this road and how to go more smoothly requires a reasonable plan.
In fact, technically speaking, the realization of automatic driving has always faced a scalability problem, because the ultimate goal of automatic driving is achieved according to classification and stages, not in one step, so how to create a scalable It has become a very important proposition to meet the requirements of all levels of autonomous driving in terms of computing power and security. Moreover, such a scalable architecture is also of great benefit to the formation of differentiated products at the high, middle and low end in the process, to adapt to the needs of different user markets, and to monetize technology investment in a timely manner.
Classification of autonomous driving
In order to answer this question perfectly, we still have to go back to the classification of autonomous driving. According to the definition given by the American Society of Automotive Engineers (SAE), autonomous driving is divided into five levels from L1 to L5, corresponding to driving support, partial automation, conditional automation, high automation and full automation.
Classification of autonomous driving
It is not difficult to see from the figure that the difference between the various levels is defined according to the ownership of the driving control. The lower the automatic driving level, the stronger the driver’s control of the vehicle. For example, in L1, it includes several contents such as automatic cruise, automatic braking and lane keeping. They actually only allow the vehicle to do automatic control of acceleration or deceleration in one direction, but do not include steering operations. With absolute control, correct judgments and decisions must be made by personally observing the environment; while at L5, the vehicle is in a fully automated state without driver intervention, and in most cases the driver doesn’t even have a “speak” for the driving of the vehicle right”.
From this grading rule, we can also see that there is actually a very high “step” between L3 and L4. If the autonomous driving system from L1 to L3 is still a driver-oriented product, and the core essence is that people control the car, then to L4 and L5, the car is basically equivalent to a robot, in most cases it is It is in a state of being cut off from “people” and operates autonomously. It can also be said that from L1 to L3, no matter how mysterious the product advertisement is, it is still ADAS. Only when it reaches L4 and L5 is the real state of automatic driving.
This span from L1 to L5, in contrast to the scalability of the technical architecture mentioned above, is more challenging.
Scalable Technology Architecture
To solve this problem, we first need to simplify it on the basis of in-depth understanding. At present, a relatively mainstream cognition in the industry is that autonomous driving decision-making (THINK) can be divided into two parts (domains): one is Perception and Modeling, and the other is Safe Computing.
Specifically, perception and modeling is to perform feature extraction, classification, recognition, tracking and other processing on the data from vehicle sensors to obtain information such as what the target is, the XYZ coordinate position of the target, and the speed and angle of the target movement, and Output a grid graph. The output of the perception and modeling domain can be used as the input of the security computing domain. What the security computing needs to do is to fuse the grid map of the target with the environmental information, plan the best route, and dynamically predict the possibility in the next few seconds. The output of the calculation result is two control signals of acceleration, deceleration and steering of the vehicle. This calculation process is repeated to form a coherent automatic driving behavior.
Due to the different functions of the two domains of perception, modeling and secure computing, the specific technical demands are also different, which are mainly reflected in functional safety and computational efficiency.
For perception and modeling, since the front-end input comes from multiple transmitters—including three types of cameras, millimeter-wave radar, and lidar—in order to adapt to complex application scenarios, at least two sensors are required to meet comprehensive and accurate requirements. The data acquisition requirements, the diversity and redundancy of such sensors make the perception and modeling system of a single sensor only need to meet the functional safety requirements of ASIL-B, and then the overall functional safety level of ASIL-D can be achieved. In terms of computing power, fixed-point computing can meet the requirements of most perception and modeling data processing.
Safety computing is very different. After sensor fusion, there is no data diversity and redundancy, so the safety computing processor must meet the functional safety requirements of ASIL-D. At the same time, due to the high computational complexity, both fixed-point operations and floating-point operations must be used at the same time – floating-point operations are mainly for vector and linear algebra acceleration – and from a security point of view, neural networks are incompetent because they cannot backtrack, because they must Using deterministic algorithms, these requirements on computational efficiency need to be supported by a corresponding computing architecture.
Just imagine, if a single computing architecture is used to simultaneously complete the two tasks of perception, modeling, and secure computing, it is obviously uneconomical and loses flexibility. For example, when you want to expand the number or types of sensors, you have to replace the entire processor architecture. Therefore, an idea of an extensible architecture is to design different processor chips for the two domains respectively, so that the subsequent system expansion and upgrade will be easier.
In this way, one architecture can meet the technical requirements of all autonomous driving levels from L1 to L5. Whether developers are doing future-oriented technology exploration or product development for the current market demand, they can advance and retreat with ease and ease. With such understanding and technical support, on the steps leading to autonomous driving, the pace of progress will be more determined.