“福瑞泰克智能系统沈骏强：ADAS软件架构的设计和演进”

由爱因斯坦汽车、奥托组织、上海车展共同主办的2021第二届软件定义汽车峰会论坛暨奥托中国成功举办，本届论坛也是第十九届上海国际汽车工业展览会的同期活动。 在这次会议上，邀请了福瑞泰克智能系统首席技术官沈骏强博士，进行了以“adas软件架构的设计与发展”为主题的演讲。 以下是他这次演讲的主要复印件。

瑞泰克智能系统首席技术官沈骏强博士

早上好。 今天，我将向大家展示一个主题: adas软件体系结构的设计和发展。 福瑞克是adas和自动驾驶维修处理方案的第1级供应商。 我们拥有强大的当地工程能力和服务能力。 在企业的产品开发中，第一代相机fvc1于2019年7月实现了前期批量生产。 第二代fvc2将于今年7月实现预装量产，进入国内主流主机厂。 毫米波雷达cvr10于去年11月预装量产，域控制器到今年年底实现预装量产，自动停车系统dcu到今年年底实现预装量产。

今天，我们将讨论软件定义汽车的观点，我们企业在这方面的想法和方法。 直观地理解，软件实现的功能比硬件更经济，这是sdv最基本的价值。 二是增值服务。 通过ota升级的方式，售后也可以享受增值服务。

在协同价值方面，软件的灵活性可以在不同的产品平台上移植，提高软件的灵活性、效率，实现oem和不同供应商之间较为有效的协同。 由于软件能力已成为oem和第1层供应商成功的重要因素，今后软件能力和软件在adas和自动驾驶行业的重要性越来越大。 对sdv的想法:

第一个是如何快速落地，基于sdv的开发比以前流传的开发要卓越，存在着新的开发方法和大量的legacy软件系统之间如何共存的问题。 我们认为，软件定义汽车的过程需要一定的开发节奏，需要从以前流传下来的开发方法中顺利实现软件定义汽车的过渡。

关于商业化的第二种模式。 软件定义汽车后，将产品和服务作为今后产品商业化思路的要点，因此服务将在今后的整个产品开发和销售过程中发挥越来越重要的作用。

第三个是产品定义的观点。 定义一辆汽车的功能多由主机工厂或供应商从功能本身或性能的角度进行定义，今后随着sdv概念落地，产品定义的观点多从顾客体验或顾客诉求的角度进行。 从顾客体验和顾客诉求的角度来看，不同的客户群诉求不同，对某些功能的体验也不同。

有这样的诉求，为了满足不同顾客的诉求和对他们功能的体验，要求有一种产品开发方法，使我们宣传的产品适应不同的顾客群体，从原来的千人一面变成千人千面。

4第四个是研发过程。 这个过程也会有一些变化。 以前流传下来的开发过程中，软件和硬件密切相关。 在sdv的背景下，硬件开发和软件开发相对独立，软件在不同的平台上运行，独立于硬件平台。

5第五个是供给关系。 软件定义汽车的概念一出现，以前流传下来的主机厂、第1层的垂直关系就是主机厂及合作伙伴之间交叉、合作的关系，形成开发的生态集团，大家合作制造产品

第六是差异化新功能的迭代，随着我们对受众群诉求的研究，ota软件的升级将提高对车辆的提升，对顾客的各种诉求的满足，从而也增加了车辆功能和对应的价值，

简要介绍福瑞克智能驾驶中对软件定义汽车的理解和方法。 软件定义我们认为汽车的核心是体系结构的定义，需要良好的体系结构。 该体系结构包括系统体系结构、功能体系结构、软件体系结构、硬件体系结构等，并按产品体系结构定义分层进行。

最上层是统一的功能体系结构，功能体系结构下有子系统和功能模块的定义，硬件平台化、软件模块化，以及其支撑的是功能安全平台化和开发工具的平台 不仅是产品本身，开发工具和开发环境也需要平台化。

目前，福瑞克正在开发涵盖从l2.5到l3.0的功能进化，未来两三年量产的智能驾驶产品。 l2.5以hwa功能为代表功能，系统结构包括1v5r+hd map，目前oem已经有很多量产车辆具备这样的功能。 中间的是superhwa(L2.9 )，可以放手，低速可以摘下眼睛，典型的配置包括6v5r1d+hd map+外观。 目前存在包括国产长安uni-t在内的部分量产车，我们福瑞泰克也参加了uni-t系统开发。 右边是hwp(L3 )，这是偷工减料的东西，典型配置为1l6v5r1d+hd map+外观，量产型号还很少，但为了能在未来两三年上市，正在加紧研发。

这是福瑞克的dcu产品路线图支持前三个不同阶段的功能的产品。 第一代域控制器dcu1于今年11月量产sop，中间是dcu2明年4季度变成sop，右侧是2023年q2 sop的dcu3，可以提供l3功能。 对比上述三个不同阶段的功能，我们福瑞泰克拥有相应的域控制器产品和附属的传感器组成完善的系统处理方案，提供给oem主机厂。

比较并简要介绍dcu3的体系结构。 首先，让我们来看看dcu3的ee体系结构。 包括中间adas控制器和以太网交换机。 解决器具备发生故障时的主备份冗余性，正常情况下为负载分担。

从系统的功能体系结构来看，具有冗余主备份的adas控制器1和adas控制器2在各自的控制器中被细分为功能分配。 一些重要功能具有主备份冗余性，而另一些功能则是负载分担。

与摄像头、雷达、激光雷达等各传感器对应的接口分别通过lvds、以太网和can-fd访问域控制器。 域控制器中除了相互冗余的2个adas控制器1和adas控制器2以外，还搭载了负责控制功能和系统整体的诊断和对外通信功能的mcu，对功能的安全性也进行了更详细的考虑，对系统故障的安全路径也进行了详细的分解 我知道l3系统有各种各样的解决方案和传感器，包括很多部件。 系统失效并不是在同一时间某个备份的所有部件都失效，而是要考虑前置雷达失效了怎么办，前置摄像头失效了怎么办，侧射雷达失效了怎么办 因此，我们与各种零部件的故障进行了比较，进行了故障安全途径的分解。

l3功能会因故障模式而降低功能，有时l3会降低到l2，有时也会完全终止。 这取决于系统故障模式的分解和安全路径的明确。

域控制器功能软件框架大致上与行业中的其他公司相似。 如果再仔细看看，我们对所有的功能分区和模块化设计做了更细致的工作。 adas智能驾驶分为感知子系统、融合子系统、决策子系统、控制子系统、安全子系统、通信子系统。 各个子系统可以进一步划分。 例如，在感知子系统中比较并划分照相机、雷达、激光雷达、超声波雷达等软件功能。 有了这样的软件功能框架，这个框架可以比较好地支持算法，提高软件相对于硬件的独立性，提高软件的一致性和今后的功能升级和迭代。

ee架构包括soc和mcu，与mcu软件架构进行了进一步的定义。 从autosar到上层有各种各样的APP。 上层APP包括安全性、融合、数据观察、数据存储、决策和控制，并在每个子模块中进一步细分了以下子功能: mcu基于autosar框架。

soc软件架构包括操作系统及相应的各种驱动程序和中间件，中间件上有各种app的应用。 中间件的作用是底层和上层之间的数据交换接口，还承担着各种功能安全性和诊断服务。

让我们来看看中间件框架。 基于classical autosar、adaptive autosar和其他平台构建。 比较服务、比较数据解析和比较通信系统也定义了连接基础和上层APP的各种子模块。

总而言之，我这里展示的福瑞克认为在如何支持软件定义汽车方面，体系结构的定义是最重要的一步。 因此，在定义平台化的体系结构方面做了非常多的工作，提高了域控制器的开发效率，提高了域控制器产品开发的质量和性能。

与ots升级能力相比，对于产品的开发阶段和产品的售后服务也有不同的计划。 在开发阶段，我们收集数据，通过迭代算法提高性能，增加高速偷工减料巡航和有限场景的停车、低速场景的l3等功能和性能。 随着后续数据的积累和算法的迭代，我们升级到hwp允许在40km/h的速度下逃生。 为此，需要收集一定数量的高精度地图和众包的高精度地图。 这些车辆投放市场后收集大量数据重复我们产品的性能，系统能力就会逐渐提高，功能和性能的定义也会越来越明确。 到了那个阶段可以达到l3级，所以不增加传感器的能力，提高算法的能力，通过收集大量的众包数据来定义我们的系统能力，从而挖掘足够多的corner cases，最终只局限于odd

对比adas市场的前景，这是我们福瑞泰克的构想，在此与大家分享。 目前，l2 adas系统毫无疑问是最大的市场。 初级L2+(HWA )可以在控制价格的前提下提高体验。

体验式l3 (包括低价avp )增加了hdmap、dms等附加输入，提供了更高层次的功能。 但是，系统的安全性没有车辆系统的完全保障，需要客户随时介入，体验有限。 体验式l3在其他条件还不成熟的情况下，在判断驾驶员是车辆驾驶责任主体的基础上，提供l3的功能体验。

l3/l2.9系统在odd范围内可以长时间放手，转移视线，但传感器的配置和价格会增加。 必须在价格和系统性能之间取得平衡。

最后就量产化提出几个问题供大家讨论。

1，/ S2/ L2-L4是否需要集成的体系结构？ 从大的层面来看，l2和l4一定要有统一的体系结构，但从更细分的体系结构定义来看，从价格和性价比的角度来看，l2、l3和l4体系结构比较一下等级的阿迪， 我提出这个问题的背景首先想和大家讨论一下，关于l4架构的降维设计满足了l2的功能诉求，目前正在提供给最大规模的l2市场。 虽然单纯从技术上来说是足够的，但考虑到商业化，l4维化并不一定是优化架构设计考虑的设计出发点。

2、是进行加法还是减法运算？ 是上升还是下降？ 我认为要自动驾驶，需要从低级向高级逐渐进化。 在这个过程中，我们将在优化和发展我们的架构设计的同时，实现产品的商业化落地。 另一方面，l4架构对高阶传感器和计算平台的计算力依赖度较高，减法不容易，如果舍弃其中的一点传感器和解决模块的配置，则有可能重新设计一点的主要模块。

3，如何优化硬件嵌入和造车的价格呢？ 这也需要综合考虑，首要看客户对功能和性能的诉求。 我知道一辆车的寿命是10年左右，你如何把握这10年左右的生命周期，明确初始硬件嵌入价格和之后的软件升级带来的计算力和对传感器的诉求？

4，/ S2/] OTA 的最初目的是什么？ 第一，是对软件版本的迭代，是对当前版本某些不完整功能和性能的迭代。 第二，添加新功能。 oem在车辆sop时，需要已经具备主要功能。 ota升级的规模和迭代的频率，我想这也需要我们大家一起考虑。 即使嵌入了各种计算能力和各种传感器，产品最初销售时也需要基本的功能，如果这些基本功能不足，则之后的产品升级可能会有问题。

5，智能驾驶的软件增值功能的价值和时间点在哪里？ 车辆10年的生命周期要追求软件的附加值，到底需要几年？ 车辆本身是10年左右的生命周期，但其价值逐年减少，另外，智能驾驶软件通过ota增值功能提高车辆价值这两条曲线的交点到底在哪里，也就是要考虑几年后的软件升级功能吗

这些问题没有确定的答案，所以我们抛开来和大家讨论，也分享了我们福瑞泰克对这些问题的基本观点。