由盖世汽车、AUTOSAR组织、上海车展联合主办的2021第二届软件定义汽车高峰论坛暨AUTOSAR中国日在上海成功举办，本次论坛也是第十九届上海国际汽车工业展览会的同期活动。本次会议邀请到了福瑞泰克智能系统首席技术官沈骏强博士进行题为《ADAS软件架构的设计和演进》的主题演讲，以下是他本次演讲的主要内容：
福瑞泰克智能系统首席技术官 沈骏强博士
大家早上好，今天我给大家分享的题目是ADAS软件架构的设计和演进。福瑞泰克是ADAS和自动驾驶完整解决方案的Tier1供应商。我们有强大的本地工程能力与服务能力。公司产品开发包括，第一代摄像头FVC1在2019年7月已经实现前装量产。第二代FVC2在今年7月能实现前装量产，进入国内主流的主机厂。毫米波雷达CVR10在去年11月已经前装量产，域控制器在今年年底前实现前装量产，自动泊车系统DCU在今年年底之前实现前装量产。
今天跟大家探讨一下关于软件定义汽车的一些观点，我们公司在这方面的思考以及做法。直观理解，用软件实现的功能比硬件更经济，这是SDV最基本的价值。第二个是增值服务，用OTA升级的方法，即使在售后也能获得增值服务。
协同价值方面，软件的灵活性可以在不同产品平台上进行移植，增加了软件的灵活性、高效率，实现OEM和不同供应商之间的有效协同。软件能力成为OEM和Tier1供应商成功的关键因素，所以今后软件能力以及软件在ADAS和自动驾驶领域的重要性变得越来越大。对于SDV的思考：
第一个是如何快速落地，基于SDV的开发跟传统的开发相比是比较颠覆性，存在新的开发方法和大量legacy软件系统之间如何共存的问题。我们认为软件定义汽车的进程还需要一定的开发节奏，实现平稳的从传统开发方法到软件定义汽车这样的一个过渡。
第二个关于商业化的模式。有了软件定义汽车之后，把产品加服务作为我们今后产品商业化的思考重点，所以服务在今后整个产品开发和销售进程当中会起到越来越重要的作用。
第三个是产品定义的视角，原先定义一辆汽车的功能更多是主机厂或者供应商从功能本身以及性能角度定义的，今后随着SDV概念的落地，产品定义的视角更多会从用户体验以及用户需求角度来做。从用户体验和用户需求角度来看，不同的用户群有不同的需求，对某些功能的体验也会有所不同。
有这样一个需求存在，要满足不同用户的需求以及他们对功能的体验，就要求我们的产品能够做到适应不同的客户群，从原先的千人一面变成千人千面这样产品开发方法。
第四个是研发流程，这个流程也会发生一些变化，传统的开发流程是软件和硬件紧密关联在一起的，在SDV背景下，硬件开发和软件开发相对会独立, 软件能够在不同的平台上运行，独立于硬件平台。
第五个是供给关系，软件定义汽车的概念出现后，传统的主机厂、Tier1的垂直关系会变成主机厂以及合作伙伴之间相互交叉，协同和合作的关系，形成一个开发的生态群，大家一起协同把产品做好。
第六个是差异化新功能的迭代，随着我们对用户群体需求的研究，通过OTA软件升级来提高对车辆，对用户各种需求的满足，这样，车辆功能以及对应的价值也会不断地增加。
我简单介绍一下福瑞泰克在智能驾驶方面对软件定义汽车的理解以及做法。我们认为软件定义汽车的核心是架构的定义，需要有一个好的架构，这个架构包括系统架构，功能架构，软件架构，硬件架构等等，对于产品架构定义是分层来进行的。
最顶层是统一的功能架构，在功能架构之下有子系统与功能模块的定义，再分成硬件平台化，软件模块化，再底层支撑的就是功能安全的平台化以及开发工具的平台化。除了产品本身，我们的开发工具以及开发环境也需要做到平台化。
目前福瑞泰克正在开发以及今后两三年会量产的智能驾驶的产品，涵盖从L2.5到L3.0的功能演进。L2.5以HWA功能作为代表性功能，系统配置包括1V5R+HD Map，目前OEM已经有不少量产车辆具备了这样的功能。中间的是Super HWA（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控制器以及以太网Switch。处理器具备在故障情况下的主备份冗余，在正常情况下是负荷分担。
再看一下系统功能架构，主备份冗余的ADAS控制器1和2，在每一个控制器里面对功能的分配做了比较细致的划分。有些重要的功能是有主备份冗余的，也有好大一部分是做了负荷分担。
每一个传感器所对应的接口，包括摄像头，雷达和激光雷达，分别通过LVDS、以太网及CAN-FD来接入到域控制器。在域控制器里面除了两个相互冗余的ADAS控制器1和ADAS控制器2之外，还配备了一个MCU来承担控制功能以及对整个系统的诊断和对外通讯功能，我们对功能安全也做了更加细致的考虑， 对于系统失效的安全途径做了一个很细致的分析。大家知道L3系统里有不同的处理器和传感器，包含了很多部件。系统失效并不是说同一时间，某一个备份的所有部件都失效了，而是需要考虑前雷达失效了怎么办，前摄像头失效了怎么办，侧边雷达失效了怎么办？所以我们针对各种不同的零部件失效做了一个失效安全途径的分析。
L3功能在不同失效模式下会有不同的功能降级，在某些情况下，L3可能会降级到L2，某些情况下可能会完全退出，这依赖于我们对于系统失效模式的分析以及安全途径的确定。
域控制器功能软件框架，从大的层面来讲我们的划分跟业界其他公司做得大同小异。如果看得更仔细的话，我们对每一个功能划分和模块化设计做了更细致的工作。ADAS智能驾驶分为感知子系统，融合子系统，决策子系统，控制子系统，安全子系统，通讯子系统。每一个子系统可以再进一步划分，比如感知子系统里面我们针对摄像头，雷达，激光雷达，超声波雷达等软件功能进行划分。有了这样一个软件功能的框架，这个架构就能够比较好地支持算法，能够增加软件相对于硬件的独立性，来增加软件的一致性以及今后功能升级和迭代。
EE架构里面包括SOC和MCU，我们针对MCU软件架构做了进一步定义。从AUTOSAR到上层各种应用。上层应用中包含安全、融合、数据分析以及数据存储、决策和控制，在每一个子模块里面又进一步细分下一层子功能，MCU是基于AUTOSAR框架来做的。
SOC软件架构包括OS以及所对应的各种驱动以及中间件，中间件上面是各种APP的应用。中间件所承担的角色是底层和上层之间数据交换的接口，同时也承担了各种功能安全和诊断服务。
我们再看一下中间件的框架，在底层构建了Classical AUTOSAR，Adaptive AUTOSAR以及其他平台。针对服务，针对数据处理以及针对通讯系统也定义了各种连接底层和上层应用的子模块。
概括一下，这里面给大家展示的关于福瑞泰克在如何支持软件定义汽车这方面，我们认为架构的定义是最关键的一步，所以我们在定义平台化的架构上面做了非常多的工作，从而来提高我们对域控制器开发效率，提高我们对域控制器产品开发的质量和性能。
针对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、 L2-L4是否需要统一架构？从大的层面来看，L2和L4肯定需要有统一架构的，但从更加细化的架构定义看，如果从成本和性价比角度，我们还是需要针对L2，L3及L4架构在下一层架构定义上有所区别的。我提出这个问题的背景主要想跟大家探讨，关于L4的架构的降维设计来满足L2的功能需求，提供给目前规模最大的L2市场。单纯从技术上来讲是完全可行的，但是如果考虑商业化的话，L4降维不一定是最优化的架构设计考虑的设计起点。
2、 做加法还是做减法？是向上演进还是向下演进呢？我们认为做自动驾驶需要从低级别到高级别逐渐往上演进的，在这个过程中，去优化和演进我们的架构设计，并且不断实现产品的商业化落地。从另一方面看，L4架构对高阶传感器和计算平台的算力的依赖度比较高，做减法并不容易，如果裁剪掉其中的一些传感器和处理模块的配置，可能会使得一些主要的模块进行重新设计。
3、如何做到硬件预埋和造车成本的最优化？这也需要综合考虑，主要看用户对功能以及性能的需求。大家知道一个车寿命10年左右，如何把握这10年左右的生命周期来确定初始硬件预埋的成本以及后续软件升级所对算力和传感器的需求。
4、OTA最主要的初衷是什么？第一，是对软件版本的迭代，对当前版本某些不尽如人意的功能以及性能上的迭代。第二，是对新的功能的增加。OEM在车辆SOP时，需要已经具备主要的功能。 我认为OTA升级规模以及迭代的频次，这也是需要我们大家一起来思考的。即使预埋了各种算力和各种传感器，在产品最初卖出去的时候还是需要具备最基础的功能，如果缺乏这些最基础的功能，后续产品升级可能会存在一定的问题。
5、智能驾驶的软件增值功能的价值及时间点在哪里？车辆10年生命周期对软件增值的需求到底要考虑多少年。车辆本身是10年左右的生命周期，但是它的价值是在逐年递减的，同时，智能驾驶软件通过OTA增值功能来提升车辆价值，这两条曲线之间交点到底具体在哪一点，也就是考虑多少年之后的软件升级功能，这也关联到最初硬件需要预埋是关联在一起的。
这些问题没有明确的答案，抛出来跟大家探讨，也分享了我们福瑞泰克对这些问题的基本思考。