2022年11月8日至10日，由中国汽车工业协会主办的第十二届中国汽车论坛在上海嘉定举行作为党的二十大后汽车行业的首次盛会，本届论坛以凝心聚力，蓄势待发为主题，设置了一场闭门峰会+一场会议论坛+16场主题论坛以汽车产业高质量发展为主线，与行业精英一起落实新精神，研判新形势，共商新举措其中，11月10日上午，主题论坛十:开放，协作，软件定义汽车生态圈的新常态，科仕达管理有限公司发展部总监程辉做了精彩演讲
很荣幸能与大家分享我们在车身领域应用SDV的实践和思考。
首先请允许我简单介绍一下科士达是一家怎样的公司科达基本涵盖了全身电子产品，包括电动尾门，无钥匙系统，车身控制模块，电动车窗，电动天窗，座椅记忆，电子挡位等等这些产品在行业内拥有足够高的市场份额，其中部分产品占据了全球50%以上的市场份额
对我们公司来说，SDV对我们有什么样的影响在这个场景和这个行业的体系中能做到什么样的定位，是非常值得我们思考的
从汽车电子电气架构的发展来看，主流主机厂逐渐向两个方向发展:功能域控制器架构或中央集权+区域控制架构域控制器架构主要通过自动驾驶和智能驾驶舱控制两个域给客户带来极致体验，是对传统电子电气架构的补充但是，这种架构带来了很高的成本目前，基本上从特斯拉到蔚来和小鹏，与传统车企相比，其价格远高于传统车的平均价格区域控制器接下来会带来什么
1.它带来了SOA的可能性，SOA将逐渐集中更多的终端模块和智能传感器。
2.通过集成，包括自动驾驶和智能驾驶舱集成为一体，在车身区域将更多的ECU集成到少数功能更复杂的域控制器中，会带来最终整车成本的下降，对整个智能汽车的普及带来很大的好处。
在这种情况下我们能做什么从我们的角度来看，我们在传统的电子电气架构中处于非常强势的地位，我们可以算是行业的盈利者但是在这个新系统中我们需要做什么呢既然这个体系能给整个汽车行业带来新的改变，我们就应该拥抱它，我们应该重新思考这些原创产品给我们带来强势地位的真正原因是我们的软件开发吗硬件开发还是会被考验其实都不是
在我们中国的行业环境中，我们有这么多的工程师，这么多的大学和这么多的毕业生这些软硬件能力都是可以通过一定的方式快速建立起来的，这一点从手机行业和各种消费电子行业就可以看得很清楚但是为什么汽车行业的客户会对这些零件选择这个或者那个最终还是要看Tire1对这些产品应用场景的了解这里的应用场景不仅仅是常规工况，还有安全工况和极端情况下的应用场景
我的亲身经历是最深的刚加入我们公司的时候，我一直觉得车窗防夹是一个很简单的应用我们也可以通过大学实验室的一些简单的机架来完成这个功能，但是市面上只有两三家公司做的很好为什么有一次在漠河做冬标实验的时候发现，如果参数保守的话，在这样极寒的条件下，窗户根本升不起来，这对用户来说是致命的如果参数激进，防夹功能根本无法实现，会直接导致客户的身体伤害如何做到这种平衡，其实是非常考验我们算法的还有这样一个应用场景在颠簸的路面上，车窗会突然有一个重力加速度，导致电机承受的负荷急剧增加在这种情况下，我们如何执行控制算法这就是我们产品的竞争力和市场力
基于这种情况，我们想想SDV，不管我们现在的产品是什么，不管是卖ECU还是卖软件，只要我们保持这部分知识，积极参与整个市场环境，和所有合作伙伴一起把汽车市场做大，把智能汽车市场做大，我们的影响力还是会在的这是我们的主要认识
当前EEA的好处非常明显:
第一，可以更多的从整车系统考虑功能的开发。
二是可以有更多的纬度升级，比如OTA我们的软件，软硬件接口标准化的话，硬件可以相对标准化，硬件可以后期升级比如低端机型用什么样的性能硬件，高端是什么样的在手机行业很清楚，比如高端相机可能用1亿像素，中端相机可能用500万像素在汽车行业，快速配置不同级别的内容非常重要，我甚至可以更换整个硬件在汽车的整个生命周期中，我们可以根据不同的要求更换客户想要的内容，只要我们的设计是统一的
第三，毫无疑问，软件的这些算法是逐渐上移的，从基础ECU到区域ECU，再到中央计算单元标准化组件传感器和致动器的使用越来越广泛
当然，这些特点也会带来许多新的挑战。
第一，系统的复杂性在传统的ECU开发中，有可能一个ECU只负责一个或几个功能他可以考虑整个任务调度是什么，他面对的场景是有限的，他很容易知道我需要什么样的性能但是当它们都结合在一起时，系统的设计和优化就变得非常困难如果每个应用场景都是按照最大计算能力来计算的话，这些场景叠加起来就是巨大的计算能力需求很多时候功能互斥，资源可以复用，通过合理的设计达到价格和性能的平衡，这当然是一个很大的挑战
二是职责分工相对不明确传统架构，Tire1，负责产品的所有问题现在可能是OEM开发的一部分，Tier1开发的一部分，甚至Tier2的一部分如何平衡三者因为每个家庭的开发环境，每个家庭的工具，每个人对需求的理解都不一样，所以还是会带来很多问题
我们在哪里试过在SDV1.0和2.0开始的时候，我们针对各种ECU模块做了很多尝试将ECU软件修改为SDV标准接口，然后模拟整车场景进行测试测试的产品包括电动尾门，电动车窗，电动天窗，电动车门，座椅调节，数字钥匙，车灯控制等我们做了一些尝试我们整个设计开发过程都是通过模拟我们是一个更大平台的OEM或者供应商来实现的我们通过这种方式验证和确认了SDV定义的这套场景，实现方法和标准原则，这在大环境，大框架下是非常成功的
1.所开发产品的系统架构更加清晰。
2.通过这样的定义，硬件和抽象相对分离，一些控制逻辑更好的分离，为以后控制逻辑上移做准备。
3.基本功能的易用性大大提高复用不仅仅是整车架构的复用，最基本的传感器，执行器甚至驱动电路都可以复用
4.就单个功能来说，它的实现比以前方便多了，测试也很简单。
但是也发现了许多问题:
本来一个ECU可能有几百个任务，已经很多了，但是整合后可能变成几千个甚至几万个这成千上万个任务中的每一个都会在时间要求和资源之间产生冲突因为很多都是共享资源，而只有这么一部分，这些资源发生冲突时如何协调管理是一个很大的挑战
最坏情况是很难做到的，更多的应用场景会导致更多的最坏情况，这最终会导致功能安全计算和分析的一些挑战。
举几个例子:
首先是车窗防夹目前我们做的天窗，窗户，座椅，多达25个电机每个电机在执行过程中，都会有各种电流和位置的信号，这些数据需要及时处理这些数据如果不进行处理，就会丢失，导致性能下降，甚至功能失效需要的时间很短，但是会让系统非常碎片化，让你的系统调度更加困难
其次，当多个功能/服务在执行阶段最终使用同一个物理设备时，会导致功能之间或者服务之间的耦合比如你驱动某个电机，上一阶段已经驱动了另一个电机，驱动芯片的温度已经很高了，你就不能按照最大性能来执行，这就会带来很多挑战，软硬件的解耦也不会那么容易
此外，上电和断电过程的定时和分布式功能也将带来更多的协调挑战。
我们的工程师总结了经验，并在实践后提出了我们的建议:
1.在SDV的服务框架体系下，是否可以考虑在一些极端的工作条件下，传感器可以直接调用执行器服务，或者从传感器到域控制器再到执行器。
2.对于一些分布式的功能，比如需要多个域控制器参与完成，是否可以用一个域控制器作为主节点来协调所有控制器的共同执行。
3.在原有的区域控制器下，进一步发展，由一个简单的控制器负责小范围的集中负荷，比如图左上角的本地控制器，再与区域控制器相连，使每个控制器的功能相对简单同时，整体来看，整车ECU数量仍然大幅减少，局部控制器略有增加，作为区域控制器的补充，区域控制器保持不变，这样整车和单个模块的复杂度可以相对平衡
郑重声明：此文内容为本网站转载企业宣传资讯，目的在于传播更多信息，与本站立场无关。仅供读者参考，并请自行核实相关内容。
