如今，增加功能性是大多數駕駛輔助（ADAS）功能，甚至包括SAE 1級至4級自動駕駛系統的研發趨勢，但這同時也會將讓車輛所處的軟件環境和相應的研發流程變得更加復雜。這是為什么？
簡單來說，這是因為隨著功能性的不斷增加，牽涉的 ECU 數量也會增加。由于現有功能和系統架構在設計之初大多并未考慮 SAE 3 級和 SAE 4 級自動駕駛的需求，因此，盡管各級自動駕駛系統在功能方面的重復性較高，但真正想要在不同級別系統之間實現功能模塊的復用卻并不容易，甚至是完全不可能的。
各代車型間的軟件模塊復用也有類似的問題，傳感器、促動器、融合模塊、功能模塊及控制模塊等，都必須從軟件和硬件角度進行重新整合。這些問題都會導致此類項目中功能復雜度的非線性增長。
模塊復用的挑戰還不止于此。比如，當涉及多方研發時，不同團隊之間的銜接和協調也會不可避免地產生額外開銷。此外，商業戰略方面的考慮也必不可少：自動駕駛系統離不開“環境模型”和“精準定位功能”等基礎軟件，但這些功能本質上很難實現差異化。因此，即便OEM推出各式各樣的駕駛輔助系統或操縱系統，但在環境模型和定位上，它們無法與競爭對手真正拉開差距。
但盡管如此，廠商仍需要不斷投入資源，對這些基礎模塊進行不斷完善，而這些資源本可以被用來開發差異性更高的組件，比如人機接口。這其實讓廠商陷入一種兩難境地：隨著 SAE 3 級或 SAE 4 級自動駕駛系統的推廣，駕駛員將駕駛任務交給汽車后將有大量時間使用 HMI 功能，因此 HMI 研發的重要性毋庸置疑。但與此同時，“環境模型”和“定位功能”等基礎模塊又對汽車廠商需要全權負責的車輛安全性和可靠性至關重要。正因如此，廠商也必須高度嚴肅對待安全性和可靠性問題，基礎模塊的完善不能忽略。
使用軟件框架加速研發
在此背景之下，軟件框架應運而生。這種軟件框架可以被視為一組自動駕駛系統設計與開發的基本構件，可在自動駕駛系統研發中發揮顯著優勢。Elektrobit 公司的 EB robins 即為這樣一種非常典型的軟件框架，其基本架構可見圖 2。
EB robins 參考架構可以支持 SAE 1 級到 SAE 4 級等全部自動駕駛級別，在未來 SAE 5 級自動駕駛解決方案的開發中也將發揮重要作用。當然，在 SAE 5 級自動駕駛解決方案的研發中，動態情景的數量將顯著增加，相應的系統和軟件架構也需要經過重大改動。
這種軟件框架具有模塊化設計的特點，可以在最大范圍內實現靈活復用和規模化。標準化的模塊和接口定義可以降低復雜開發項目的開銷。此外，這些軟件模塊在應用時并不區別具體的硬件和傳感器，因此可以輕松、快速地應用至不同廠商選擇的不同硬件平臺上。
正如上文所示，軟件框架的應用不受具體硬件影響，而且還可以支持一些類似傳感器融合等必要功能。這種標準化、模塊化的措施，不僅清晰定義了一種功能性的架構，并讓軟件之間、以及軟件和外部接口之間的開放交互成為可能。所以從這些方面考慮，軟件框架又可以進一步降低研發復雜度、投入和成本。
除了“環境模型”、“傳感器融合”和“精準定位”等基礎模塊，軟件框架還包括“安全檢測”等診斷模塊，可以對傳感器和軟件模塊進行不間斷監測，確保其正常工作。此外，框架中的“監管模塊”還可以管理算法冗余，監督關鍵功能的執行情況，比如在碰撞發生后檢查路線規劃情況，或檢查運動管理模塊的正常運行等。
自動駕駛汽車差異化功能和非差異化功能的研發對軟件框架的要求是不同的。對于差異化功能，廠商可能更愿意倚靠內部研發力量，并著重于品牌特有的外觀和體驗，而“環境模塊”等非差異化功能則更容易從標準化和規模化研發中受益。通過軟件架構，研發人員可以在電腦上快速構建原型設計，并隨后在 Adaptive AUTOSAR 或 Linux 等環境中開始運行。
此外，設計人員還可以根據客戶需求，輕松增加/移除特定構件，真正利用最少的研發、應用和測試資源，實現軟件構件的復用。
供研發人員使用的模塊構件
全面了解各種特定功能模塊還可以協助研發人員更好地理解特定模塊構件的應用范圍和交互。
舉例而言，“環境模型”（如圖 3 所示）共包括 4 個主要組成部分。“目標融合”可基于各種追蹤邊界框模型（bounding box model），將雷達、激光雷達、攝像頭及更多傳感器捕捉的目標進行融合，從而更加完整地進行目標描述，提供包括目標相對位置、尺寸、活動、分類（比如車輛、自行車、行人）等各類信息。
“空地和障礙物融合”則主要基于一種多邊曲線，描述車輛周圍的空地及欄桿和交通信號燈等靜態障礙物。出于這個目的，“空地和障礙物融合”模型主要使用環境傳感器提供的原始和建模數據，確定車輛可選的行駛路線。“道路融合”則可以利用攝像頭信號（識別的道路標記）和“空地和障礙物融合”信息（道路靜止設施等），確定道路的幾何形狀。此外，“道路融合”還可以結合道路移動目標軌跡信息和數字地圖數據，更加全面地描繪道路的幾何形狀。
“交通規則融合”則可以處理從攝像頭或數字地圖獲得的交通標志、信號燈、人行橫道等信息，并輸出類似限速標準、禁止通信或先行通過等規則信息。
“環境模型”采用模塊化設計且支持升級，可以靈活應用至從基礎 SAE 1 級到先進 SAE 3 或 SAE 4 級自動駕駛系統（圖4）。大多數情況下，“環境模型”的應用僅需適配傳感器等少量硬件設備，即可在不同系統中進行實現。
“定位模塊”的工作則與“環境模塊”緊密相關，該模塊可基于測距法、回轉儀、加速表和 GPS 信號，提供非常準確的車輛位置和軌跡信息，因此也是所有基于“地理位置”功能的基礎，比如路線規劃和自動停車等。此外，“定位模塊”還可以為車間通信、車載通話和導航等應用提供必需的位置信息。
“外推組件”也是“定位模塊”的另一個重要組成部分，可以基于車輛的當下運動情況，預估車輛的未來位置，在一定程度上對“融合功能”等其他應用進行補充，從而避免延遲可能帶來的影響。此外，系統中還有一個“電子地平線模塊”，可針對前方道路，為預測性的駕駛員輔助功能提供高度準確的實時信息。這也將促進過彎超速預警、自適應彎道照明、交通標志顯示、里程判斷、道路跟隨、節油駕駛等功能的集成，并為一些 SAE 3 級和 SAE 4 級自動駕駛功能提供更多有用信息。
軟件框架中的各類構件，通常都是在基于多工處理控制器的車輛網絡架構上工作。Elektrobit 公司 EB corbo 軟件套裝集成了運行多工處理控制器的所有必備元素，可以進行安全快速的高性能運算，且能提供運行環境、軟件功能和一些內置安全功能。該套裝專門設計了一個非常高效的管理程序，可支持多操作系統的運行，比如針對自適應應用的AUTOSAR Runtime (簡稱AUTOSAR Adaptive) 或 Linux 操作系統。
自動駕駛級別的進化及相應的標準化
為了促進現有系統架構中的集成，EB robinos 自動駕駛軟件架構還包含一款軟件工具鏈，可在項目的前期調研、預先設計、概念構設、實際研發和最終量產等不同研發測試階段，輕松進行軟件模塊的配置和適配。
這種集中式功能框架支持各類以服務為導向的安全項目研發，也可以用于研發人員的培訓。采用模塊化功能設計，可支持 SAE 1 級到 SAE 4 級自動駕駛系統，還能在車輛功能與設計提升方面發揮明顯作用。此外，值得一提的是，為了真正實現靈活集成，行業內必須形成一套通用的標準接口定義，用于軟件架構中不同功能模塊之間，以及與外部模塊的通信與交互。
值得高興的是，汽車行業已開始進行多項旨在建立明確標準化的接口定義與規格的工作。Elektrobit 公司也一直積極配合相關標準化組織的工作，長期致力于相關標準的建立。
軟件框架的進一步推廣，有助于研發人員和廠商縮短產品上市時間，推動非差異化組件的規模化處理，顯著降低研發復雜度、投入和成本，從而提高品牌競爭力，在保證 SAE 5 級駕駛功能的基礎上，為消費者提供更多更好的功能。
When the development of ADAS functions or even automated driving up to SAE Level 4 strives for increased functionality, it also increases the complexity of the software environment—and the related development processes. Why?
Typically, the number of involved ECUs is growing. Existing functional and system architectures were in many cases not defined with Level 3 or 4 automation in mind. Although functions targeted at different automation levels basically need the same or very similar features, a reuse is often difficult or even impossible.
Similar problems arise when existing software modules should be reused over multiple generations of models of vehicles. Elements like sensors, actuators or components for fusion, function, and control, need to be incorporated from a hardware as well as from a software perspective. All of this leads to a non-linear growth in the functional complexity of such projects.
There are additional obstacles. For example, when multiple partners are involved in the development, the necessary interfacing and coordination causes additional overhead. Consider also the strategic aspect: Automated driving requires software components like an environment model and a highly precise positioning function. But both only allow for a relatively low degree of differentiation over competitors. The actual driver assistance systems and their handling may differ between OEMs, but the underlying basics such as the environment model and the positioning do not.
Still, efforts to bring these components to perfection tie up resources that could otherwise enable development of components that allow for much more differentiation, such as the HMI. This poses a dilemma, especially as the HMI’s functions are of increasing importance in cars with Level 3 or Level 4 automation because the driver will actually spend more time with these functions when handing over the driving task to the vehicle.
But the environment model or positioning functions play an important role for the safety and reliability of automated vehicles—aspects for which the OEMs are directly responsible. So, functional safety as well as security must be respected with an extremely high commitment.
Speeding development within a framework
All described parameters speak clearly in favor of using a software framework in the development of automated driving functions. Such a framework can be viewed as a set of building blocks for system design and development. The typical architecture of such a framework, shown in Fig. 2, is known as EB robinos.
The reference architecture shown supports all automation levels from SAE Levels 1 to 4. The according concepts will also play an important role in developing future Level 5 solutions. However, for full Level 5 solutions questions like system and software architecture might need heavy changes and the number of highly dynamic situations will substantially increase. Additional technologies must then be refined and facilitated before such projects can become a reality.
The framework is characterized by a consistent modular design which extensively supports reusability and scalability. Standardized modules and clearly defined interfaces also help to reduce the overhead of complex development projects. As these modules are designed to be hardware- and sensor-agnostic, they can be easily and quickly adapted to an OEM’s chosen hardware platform.
Independently from the actual hardware, the software will support necessary functions such as sensor fusion. This standardized and modular approach defines a functional architecture and open interfaces between software components as well as to external interfaces. This again can greatly reduce complexity, effort, and costs.
In addition to off-the-shelf modules like the environment model, sensor fusion, and positioning, the framework typically includes diagnostic components such as a safety monitor that will constantly check the sensors and software modules and ensure that they are functional and deliver sensible values. Also, a super-visor module can provide and control algorithmic redundancy and oversee the execution of vital functions—for example checking planned trajectories for freedom of collision or checking the correct operation of motion management.
Software building blocks for AVs can be distinguished between differentiating and non-differentiating functionalities. For the former, OEMs will most likely leverage in-house know-how and their specific look and feel. On the other hand, non-differentiating software elements such as parts of the environment model can greatly profit from standardization and scaling factors. New components can be rapid proto-typed on a PC and subsequently be run in environments such as Adaptive AUTOSAR or Linux.
Also, components can be added or removed depending on customers’ needs. This makes the reuse of software building blocks possible, while minimizing development, application and testing efforts.
Building blocks for developers
An overview of some typical functional modules will provide a better understanding of the functional scope and interworking of the particular building blocks.
The environment model (Fig. 3) consists of four main components. Object fusion combines objects recognized by the radar and lidar sensors as well as the cameras and possibly additional sensors based on tracked bounding box models. It outputs modeled objects with their relative position, size, movement, a classification (for example other cars, cyclists, and pedestrians), and additional information.
Freespace and obstacle fusion describes the free space as well as static obstacles such as guardrails or traffic signs around the car based on a polygon curve. For this purpose, this module works with the raw data and modeled objects of the environment sensors and extracts information about where the car could drive. Road fusion extracts a road or lane geometry both from the camera signals (identifying lane markings) as well as from the road “furniture” delivered by the free space and obstacle fusion. It combines this information with the trajectories of dynamic objects on the road as well as data coming from digital maps in order to deliver an overall representation of the road and lane geometry.
Traffic-rules fusion takes care of traffic-rules-related information like traffic signs, traffic lights, or pedestrian crosswalks recognized by the camera(s) or available from digital maps. It outputs rule-based information such as speed limits, no passing, or right-of-way rules.
As the environment model is modular and upgradeable, its implementations can be adapted from Level 1 functions up to the more advanced Level 3 or 4 functions (Fig. 4). However, regardless of the supported automation level, it can be used mostly off-the-shelf—this model requires only few adaptions to specific hardware such as sensors as well as other elements of the system.
The positioning module works closely together with the environment model. It provides highly accurate information about the vehicle’s position based on odometry, gyroscope, accelerometer, and GPS signals. It outputs the local position of the car and trajectory information and thus is the base of all geo-referenced functions such as lane following, path planning, and automated parking. This module also delivers the required positioning information for other applications such as vehicle to vehicle communication, eCall, or navigation.
An extrapolation component is another important part of the positioning module. It estimates a position in the near future based on the current vehicle movement. This position can be used to compensate for delays in the fusion itself as well as in the application. These basic functions can additionally be complemented by an electronic horizon which provides highly accurate and up-to-date information about the road ahead for predictive driver assistance functions. This allows the integration of features like curve-speed warnings, adaptive curve lights, traffic-sign display, range determination, lane keeping, or fuel-efficient driving and provides useful information for SAE Levels 3 and 4 functions.
The described software modules of the framework will typically run on a vehicle network architecture that is based on multi-processing controllers. Elektrobit’s EB corbos software suite combines essential elements for running multi-processing controllers enabling safe high performant computing. Further, these elements provide a runtime environment, software capabilities, and embedded security. It consists of a hypervisor that permits running multiple operating systems such as the AUTOSAR Runtime for Adaptive Applications (AUTOSAR Adaptive) and a high-performance Linux based operating system.
Evolutionary levels and standardization
In order to facilitate an easy integration into existing or newly designed system architectures, the EB robinos software framework for automated driving includes a software toolchain. It permits the easy configuration and adaption of its software blocks in various development and testing stages including research, pre-development or concept work, the development process, and mass production.
The centralized functional architecture of the framework supports service oriented and security-supporting development, as well as training of the development staff. With its modular and functional design focusing on the increasing automation levels starting at Level 1 and currently extending to Level 4, the framework also distinctly supports the evolution of functions and designs in the same or multiple generations of vehicle models over time. Another important aspect of providing easy integration mechanisms and interfaces is the formation of industry-wide standards of interfaces between the functional models of a software framework as well as with external components.
Currently, several standardization initiatives in the automotive industry are targeted at establishing and defining these interfaces and specifications. Elektrobit intensively supports these efforts and participates in the according standardization bodies and organizations.
The further spread of software frameworks will help developers and OEMs to reduce time to market, enable scaling factors for non-differentiating components of automated driving, greatly reduce complexity, effort, and costs, and allows higher competitiveness and thus better functions for the consumer while enabling Level 5 driving capability.
Author: Sebastian Klaas
Source: SAE Automotive Vehicle Engineering Magazine
自動代客停車是軟件框架的實際應用的一個例子。
用于自動駕駛的 EB robinos框架的總體架構。
環境模型由四個主要部分組成：對象融合，自由空間和障礙融合，道路融合和交通規則融合。
該框架還允許從1級功能升級到更高級的3級或4級功能。
