From ADAS to ADS: Key to Rapid Upgrades in Architecture Design
Join the senior engineering group for intelligent vehicles (autonomous driving, connected cockpit, commercial vehicles) via WeChat:17157613659 show your business card, limited to intelligent networked hardware and software suppliers and OEMs.Under the trend of “new four modernizations”, the automotive industry is restructuring its division of labor, and the electronic and electrical architecture of vehicles is undergoing transformation, with software-defined vehicles becoming an industry consensus.Software and service capabilities will become the core advantages of future intelligent driving, also sending a clear signal — the future vehicle architecture will determine the development of software to some extent.In the early 1990s, the automotive electronic and electrical architecture quickly developed after the bus represented by CAN became mainstream, with the number of ECUs increasing by two orders of magnitude within 20 years.Currently, high-end models have hundreds of ECUs. In traditional distributed electronic and electrical architectures, the vehicle’s functions are detailed down to individual ECUs, with OEMs defining the functions of each ECU and the data flow between ECUs. This facilitates the division of labor between OEMs and suppliers.However, with the rapid growth of vehicle functions, the number of distributed architecture modules increases, and the interaction between ECUs becomes more cumbersome and complex, severely affecting development efficiency and cost control.Recently, Meituan CEO Wang Xing stated on social media, “It is said that there are 300 million lines of code in a BMW X5, while a Tesla only has 10 million lines. This is a truly despairing gap, similar to the difference in code lines between Symbian and iOS in 2008.”
Dr. Wang Haowei, chief architect of Furitek, believes that fundamentally, the efficiency of 10 million lines of code is higher than that of 300 million lines of code. “With 300 million lines of code distributed across so many ECUs, each ECU must redefine its requirements. Any change in requirements will involve communication between several ECUs.”The electronic and electrical architecture of vehicles has clearly shifted from distributed to centralized in recent years. In the latest vehicles, multiple domain controllers have emerged, such as autonomous driving domain controllers, intelligent cockpit domain controllers, vehicle control domain controllers, and chassis domain controllers.Ultimately, if all functions are integrated into an onboard supercomputer (Vehicle Computer), it will truly achieve “software-defined vehicles”.At this point, upgrading the software within the supercomputer can change the vehicle’s functions. This includes not only entertainment functions like Douyin but also traditional vehicle functions such as dynamic model updates.Dr. Wang Haowei predicts that achieving a centralized architecture to control vehicles purely through software will take at least another 5 to 10 years.The road to centralized EE architecture still requires time. However, software developers cannot wait until all vehicles on the road are equipped with supercomputers to start development.Currently, the difficulties in software development have already emerged.How to improve software development efficiency within existing systems? How to ensure the quality of software development? How to meet the increasingly frequent demand changes from OEMs?Four Factors to Improve Software Development EfficiencyAccording to Dr. Wang Haowei, achieving true high productivity requires a good architectural framework to assist developers in software and algorithm development. “For software developers, there are several key elements; the first is abstraction.”Specifically, abstraction means freeing software development from dependence on hardware.“If one does not rely on a specific ECU or a specific microprocessor to run the system, it means that automotive manufacturers can reduce development costs,” Dr. Wang Haowei stated.Secondly, standardization.Standardization means that engineers hope to have a mature platform while developing software. This includes operating systems, standard hardware support packages (BSP), system basic services, standard communication components, software download and installation services, etc.This platform’s supported hardware is not limitless. Just like Android is open, but it has requirements for supported hardware platforms.A mature platform means that once you have the platform, you can develop functions.Previously, Android and iOS could defeat Symbian primarily because they provided a standard development platform and environment, allowing software developers to develop apps without needing to consider underlying detailed issues or handle scheduling, communication, storage, and other “basic operations”.“Currently, the most mature foundational component for vehicle software is AutoSAR. However, in the future, we may need more comprehensive components,” Dr. Wang Haowei mentioned, especially since we still need to do a lot of configuration work when developing with AutoSAR, as it is designed to adapt to different hardware platforms.In Dr. Wang Haowei’s view, we hope to eliminate this work in the future. As the vehicle architecture gradually centralizes, the hardware platform will also gradually unify to a degree that allows for the existence of an “automotive version of Android”.Thirdly, reuse.Compared to hardware, reuse is a significant advantage of software. Unlike hardware, once software code is written, it can be executed many times. Therefore, leveraging the ability to reuse is a crucial factor in improving development efficiency.Fourthly, creativity.Dr. Wang Haowei emphasizes, “The development of software itself should be a pleasant process. However, we often find that developing embedded products is very painful, and changing two or three lines of code may require re-integration multiple times. Therefore, rapid iteration in software development is also an important factor in improving development efficiency.”In the design of autonomous vehicles, OEMs may choose to personally control core aspects such as planning and decision-making. However, in the areas of sensor hardware, components, and software, OEMs tend to delegate to Tier 1 suppliers.Therefore, for Tier 1 suppliers to win more orders, they must possess full-stack hardware and software capabilities, along with more flexible product forms to meet OEM demands. Flexible hardware and software capabilities, along with responsive service capabilities, are among Furitek’s greatest advantages.Dr. Wang Haowei stated, in software, for L2-L4 architecture design, Furitek uses a unified functional software framework as a general guideline, breaking down all functional modules and packaging them into unified modules with fixed interfaces.These modules will be reassembled across different product lines, combined with unique modules and foundational software modules from each product line, forming a complete software architecture for a product.How to Design the Development System and Software Architecture for L2-L4?Dr. Wang Haowei introduced that the ADAS products that Furitek will gradually launch to the market include three forms: L2.5, L2.9, and L3.Among them, the L2.5 level is still in a state where the driver cannot take their hands off the wheel, with a sensor configuration of 1V5R1D (i.e., 1 forward-facing camera, 5 millimeter-wave radars, and 1 driver detection system) plus ADAS maps, with the core domain controller being ASDM2, which is also Furitek’s definition of the most basic domain controller.
To ensure the safety of the system, ASDM2 integrates system management algorithms and control algorithms. Its algorithms are inherited from the L2-level forward-facing camera algorithms but include expanded content.Compared to L2, L2.5 adds the capability for hands-free lane changes and fixed-route valet parking, possessing certain autonomous driving capabilities, and is currently the product most OEMs are preparing for mass production.“From a software design perspective, L2.5 retains all algorithms from the previous L2 forward-facing camera, but we have changed the control algorithm to a backup route. This is primarily to prevent ASDM2 from failing, allowing the backup route camera to control the vehicle as well,” Dr. Wang Haowei explained.For L2.9, Furitek’s designed controller is ASDM4, which can completely achieve safe hands-free driving and automatic lane changes during the entire autonomous driving process, and can achieve hands-off driving at low speeds. The entire system can fully benchmark Tesla’s AutoPilot for autonomous driving.The standard sensor configuration for this system is 7V5R1D, expandable to 10V5R1D (adding surround-view cameras and rear-side cameras on top of the L2.5 system) plus high-precision maps. In terms of algorithms, the entire software design, in addition to ASDM4, will also include perception algorithms for surround-view and side-view.“To ensure safe automatic lane changes, relying solely on side and rear corner radars is insufficient; we also need lateral perception redundancy, so two additional cameras must be added for lateral sensing,” Dr. Wang Haowei emphasized.Additionally, since this level allows for hands-free but not eyes-off driving, DMS is also a crucial component for ensuring safe hands-free autonomous driving. DMS will monitor the driver’s gaze in real-time, ensuring that in the event of a system failure or misjudgment, the driver can take over.Compared to L2.9, the software framework for L3 is more complex.Although both levels are very close in planning decision-making and perception capabilities during the R&D process, the software architecture can be largely reused, but in terms of the vehicle system, significant upgrades are required for the electronic and electrical architecture, functional safety certification, and backup redundancy for the entire vehicle’s execution systems.“For L3, we have added dual-redundancy SOC chips, with the sensor configuration including 1 LiDAR, 12 cameras, 5 millimeter-wave radars, and 1 DMS,” Dr. Wang Haowei introduced.The reason L3 requires so much additional work is primarily because, in the eyes-off condition, the system will fully assume safety responsibilities. 99% must be nearly 100% to release L3 functionality to consumers.Overall, Furitek adheres to the software design principle of maximizing the reuse of high and low configuration products, achieving the development of all software from L2 to L4 using the same framework.The greatest advantage of high software reuse is that it allows the work of software and algorithm developers, architects, and integration engineers to be independent, maximizing the strengths and capabilities of each responsibility.From an abstract perspective, the core code of algorithms and functional modules is completely static. This means they can be easily ported to any hardware and operating system. Platform-based architectural design ensures the success of the porting.“We will use standard platforms such as AutoSAR, Linux, Vxworks, DDS, and QNX as much as possible for development, which is beneficial for sharing the same software technology across different platforms, further reducing development costs,” Dr. Wang Haowei explained.A unified platform architecture not only facilitates joint product development with customers and partners but also standardizes the toolchain. A highly automated toolchain can truly enhance the work efficiency of software developers.For Furitek, while focusing on and developing L2+ products, it is also essential to think about how to achieve L3 autonomous driving.In Furitek’s view, selling L2.9 level autonomous driving mass production vehicles to end consumers can undertake data collection and validation of algorithms, accumulating a large amount of data required for L3 autonomous driving.As the OEM’s electronic and electrical architecture, functional safety, and steering and brake backup redundancy are synchronously implemented, and sufficient validation data is collected, L3 vehicles will ultimately be validated and released to vehicle owners via OTA.
