如今，增加功能性是大多数驾驶辅助（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