[汽车总站网 www.chianautoms.com欢迎你]
2023年11月3日，2023中国汽车软件大会在上海嘉定举办。本届大会以“聚软件之力，创数智未来”为主题，由中国汽车工业协会主办，中国汽车工业协会下属单位中德智能网联汽车推广应用中心、上海智能汽车软件园共同承办，中国汽车工业协会软件分会、智能网联汽车分会和中国汽车工程学会汽车基础软件分会协办。紧扣新时代汽车产业高质量发展和汽车软件发展要求，本次会议设置了“1场大会论坛+4个主题论坛”，旨在打造汽车软件领域开放、高端、权威的交流与沟通平台。
其中，在下午举办的“智能重塑生态，软件赋能转型”主题论坛上，科世达（上海）管理有限公司开发四部部长程晖发表精彩演讲。
以下内容为现场演讲实录：
前面各位嘉宾对SDV已经做了很多精彩的阐述，我今天在这里主要分享一下SDV在车身域的应用。大家谈了很多的智能座舱域、自动驾驶域，车身领域相对是涉及比较少的。随着新一代的电子架构往前推，区域控制架构出来之后车身变成了炙手可热的。我们在车身有这么多产品，如何在车身域去实现新的电子电气架构，如何把我们的产品整合起来，为主机厂提供不仅仅是传统的ECU、ZCU，同时也可以在软件方向为客户赋能，达到更好的使用体验，这是我们在SDV实践中的主要思考点。
功能域架构和区域架构的区别是什么？第一代功能域控制器架构是目前市场上主流的架构，现在大家都着重发展基于区域控制器和中央计算单元的新架构。相对于功能域架构，区域架构可以实现跨域功能的集中，把周围的负载接到离这个点最近的区域控制器，可以大幅度减少线束，简化网络架构。在需要的时候用区域控制器的单元做完整功能，也可以用完整的中央计算做功能，在特定的情况下可以从区域到区域，更灵活、更分散、更集中。
每个传统的车身电子模块都有特定的功能，在SDV新的模式下我们要从软件的思维考虑怎么定义架构、怎么定义汽车。从车身领域来说我们科世达是最完整的车身电子零配件提供商，我们帮助很多主机厂梳理应用场景，一起定义的应用场景，然后把功能逻辑和服务经过一定细化之后定好执行的整个过程。
我们具体在哪些地方已经做了SDV的实践？这页上大家可以看到常用的电子模块，我们都已经实施了，包括尾门、电动车门、天窗、座椅调节，包括我们使用的数字钥匙，这些的产品我们都在实践。SDV对我们的挑战是什么？从系统架构、客户需求到系统需求再到软件实施都有很多的调整。刚刚有同事也说过，软件定义汽车会带来对组织结构的挑战，传统的V模型很难适应SDV的新模式。我们根据SDV实践的情况定义了新的开发V模型，从应用场景和服务设计开始，服务的变更会带来需求的完整变化。就是说在新的V模型中，我们所有的需求不是以功能需求为前提，而是以整个实际的应用场景为基础去定义我们的功能的场景和服务场景，之后增加了服务架构定义，通过这个服务架构可以快速定位到服务接口是怎么走的。这套东西跟我们的很多合作伙伴特别是跟华为的IDVP合作过程把这套服务定义架构、用服务架构设计定义产品开发过程做了深度细化，也再实践中得到了有效的证明。
根据刚刚我们新的V模型，我们也制定了新的开发工具链。就是说我们原来用DOORS、EA等工具去实施，现在调整为所有的顶层架构会在PREE Vision去做，定义完之后进行服务部署。部署做完以后要做服务设计的仿真和分析，确认我这个服务是合理的，能够实时高性能地完成客户的要求。再接下来是每个服务设计，这个接近于最终传统汽车开发里面的软件开发模型，只不过测试的场景是基于服务的模式来走的。
在这个过程有没有遇到问题，答案是肯定的。
在传统架构中，某个ECU只负责某个功能的实施，现在一个区域控制器要负责车身一半的功能，但是比如说左边所有的灯光、雨刮、车窗、座椅控制等。它会打破各个传统小组之间的界限，A小组做雨刮功能的、B小组做门的，现在这两个功能在一起的，他们两个合作这是很大的挑战。原来一些特定功能需要快速响应的时候是可以独占MCU的，现在这种情况不太可能的，独占MCU影响的不仅仅是你个人，影响的是你所有的功能。
第二个共享资源的功能非常容易冲突，我们这里的共享资源包括共享的以太网、共享的数据的存储、还有CAN总线、AD、定时器等等。传统的ECU所处理的信号，所看到的信息可能100个基本上封顶了，但是区域控制器现在轻而易举超过1000个，怎么把资源用到哪块功能了，用到哪块服务上，事先要做非常详细的规划。
第三个我们在汽车行业，根据功能安全也好、根据可靠性也好往往要做一个事情可靠性，在某个点我执行这样的功能最坏的情况我的时间是多少，很简单的例子:如果你踩刹车，在毫秒级里没有响应是灾难性的后果。在采用新的架构以后worst case计算已经很困难了，影响你的分析过程可能从原来的一两百增加到几万个，增长都是呈指数级的，原来的计算完全没有办法实施。
最后一个测试的理念需要更新。原来我们基于系统测试、软件测试和单元测试，这样的理念是不是真的可行? 原来的这种方式和测试理念现在碰到的很多困难，原因是新的架构对测试的功能要求高了。测试的原来我有某个产品的功能，我可以把这个产品测好，现在对你影响的东西，你可能是有你自己的DCU、也有可能是其他的服务。而且服务动态部署，可以快速从A ECU调整到B ECU，服务运行的顺序和需要的资源都需要快速的调整以最终达到的理想的效果。
所有的这些东西并没有完美的解决方案，我们仍然在持续的探索。虽然我们知道SDV可以带来这么多的好处，也带来这么多的困难，从我们公司自己的本身实践角度会做很多调整，第一个我们把服务标准化，我们测试也会基于服务和标准化的接口去做。我们分的等级不再是软件测试，软件集成，而是我们创建了一个平台，分成不同的舱，每个舱集成，分布开发分布集成。
现在我们SDV有什么改进的空间？首先，新的架构奔着集中的方式走，所有的传感器分布在车身各个地方、传感器把数据传到中央计算单元、要么中央单元自己计算或者传到云端计算，再通过云端下发到执行器去做。好的地方是很明确，所有的信号都可以通过区域控制器或者是中央计算，可以做到所有数据的追溯和分析，统一策略统一调配。其实也有很多问题，比如说我就是想开一个车门，如果要全部走集中过程的话，我碰到测试最坏的情况是从拉车门到解锁花了很长时间，但是现实和理想不一样，中央计算单元的以太网速度确实够快，但是可能任务调度并不快，还有各种各样的原因打断你的正常运行，增加了你整个运行的时间，这样的体验有时候是非常差的。
所以基于SDV实践的总结，我们给我们的客户和合作伙伴提出了一些建议。除了这套中央计算之外，我们建议是不是可以有从传感器到执行器的过程，如：车辆碰撞传感器检测到车子发生碰撞立即把门锁打开，不要经过中间的过程。第二有本地区域的区域控制器采集传感器控制集成器，不要通过中央集成单元。区域和区域控制器可以直接协调工作，避开中央计算单元。当需要多个控制器做协调控制的时候，把某个控制器作为最主要的控制器来协调其他控制器的执行，让区域控制器真正做到边缘计算功能。
第二：现在大部分车企是中央计算+四个区域的控制器，再加传感器和执行器执行新的架构，根据我们的估算3-4个可能不是最好，最优的架构要看你的传感器、执行数量和位置。必要的时候区域控制器可以有更多，用6个或者是8个，也许他带来的优势更多。因为6个或者是8个单个的区域控制器的成本比4个区域控制器的成本低很多，因为它变小以后它的价格有可能是会呈数量级下降的，这是一个。第二个最明显的优势，它跟周围传感器连接的线束会短很多，开发复杂度、软件测试工作量都会大大下降、还有整体的开发和时间管理的复杂度都会降低很多。有可能8个区域控制器会比4个区域控制器所带来的效果更好、成本更低。
这就是我今天想要分享的。顺便给我们公司做个广告，我们公司的目标是成为“每一辆车的第一选择”，我们所有的车身电子产品是非常有竞争力的，欢迎大家来考察评估，谢谢大家！
[汽车总站网 www.chianautoms.com欢迎你]
