首先请允许我简单的介绍一下科世达是一家什么样的公司。科世达在车身电子产品方面基本都覆盖完整，产品包括从电动尾门、无钥匙系统、车身控制模块、电动车窗、电动天窗、座椅记忆、电子排挡等等。这些产品在行业里面都有足够高的市场份额，其中部分产品在全球市场的占有率都超过50%。
对于我们公司来说，SDV到底给我们带来什么样的影响？我们能够在这个场景和这个行业的体系里面可以做到什么样的定位，是非常值得我们思考的内容。
从汽车电子电气架构发展来说主流的主机厂逐步往功能域控制器架构或者中央集中+区域控制架构这两个方向发展。功能域控制器架构主要是通过自动驾驶和智能座舱两大域控给客户带来极致的使用体验，是在传统的电子电气架构上做加法。但是这样的架构带来的是高成本，目前基本上从特斯拉开始，到蔚来、小鹏，相对传统车企而言，它的价格比传统汽车平均价格高一大截。接下来区域控制器带来的是什么？
1、带来了SOA的可能性，会把更多终端的模块、智能传感器慢慢集中。
2、通过整合，包括自动驾驶、智能座舱整合成一个，在车身区域通过把更多的ECU整合成少量的功能更复杂的域控制器，会带来最终整车成本的下降，为整个智能汽车的普及带来很大的好处。
在这种情况下，我们能做什么？从我们的角度来说，在传统的电子电气架构当中我们处于非常强的地位，算是行业的获利者，但是在这个新体系里面我们需要怎么做？既然这个体系可以给整个汽车行业带来新变革，我们就应该拥抱它，我们就应该重新思考原来的这些产品给我们带来强势地位的真正原因是什么。是我们的软件开发？硬件开发？还是会测试？其实都不是。在我们中国的行业环境里，我们有这么多的工程师、有这么多的大学、有这么多的学生毕业，这些软硬件能力是可以通过一定的方式快速建立的，这个从手机行业，从各种消费电子行业就可以明显看出来。但是汽车行业的这些零部件，客户为什么选择这一家或者选择那一家？最终是取决于Tire1对于这些产品应用场景的know-how，这里的应用场景不仅仅是常规的工况，也包括极限情况下的安全工况和应用场景。我个人体会最深的一点，在刚加入我们公司的时候，我始终觉得车窗防夹是一个很简单的应用。我们在大学的实验室里通过一些简单的台架也可以完成这个功能，但是在市场上确只有两三家做的很大？为什么？有一次在漠河做冬标实验的时候发现，如果参数保守，在极寒的这种工况下车窗根本无法上升（结冰情况下车窗助力大大增加），这对用户是致命的；如果参数激进，防夹功能根本无法实现，会直接导致客户身体受伤。这样的平衡怎么做，其实是非常考验我们的算法。还有这样的应用场景，在颠簸路面上，车窗会突然有一个重力加速度，导致电机所承受的负载急剧增加。这样的场景下我们怎么做控制的算法？这样的knowhow才是我们产品的竞争力和市场力。
基于这样的情况，我们对于SDV的思考，不管我们现在的产品是什么，是卖ECU也好还是卖软件也好，我们只要保持这部分的knowhow，积极参与整个市场环境中，跟各个合作伙伴一起把汽车市场做大，把智能汽车市场做大，我们的影响力还是会在那。这就是我们最主要的理解。
现在的EEA带来的好处非常明显：
第一，我们可以更多从整车的系统去考虑功能的开发。
第二，它可以有更多纬度的升级，比如说我们软件的OTA；如果是在硬件和软件接口标准化以后，也可以做到硬件相对的标准化，也可以在后期做硬件升级。比如说低端的车型用什么样proformance的硬件，高端的是什么样。这个在手机行业很明确，比如说高端的摄像头可能用一亿像素的，中端的可能用五百万像素的。在汽车行业很重要的一点，可以快速的配置不同层级的内容，我甚至可以替换整个硬件。在汽车整个生命周期中，可以根据客户不同的要求去替换他想要的内容，只要我们的设计（包括安全的考虑）是统一的。
第三，毫无疑问就是软件这些算法逐步上移，从基础的ECU慢慢上移到区域的ECU，慢慢上移到中央计算单元，标准化的部件传感器和执行器应用的越来越广泛。
当然这样一些特点，也会带来很多新的挑战。
第一， 系统的复杂性。原来传统的ECU开发，可能一个ECU只要负责一个或者几个功能就可以了，他可以考虑整个任务调度是什么，他所面临的场景是有限，也可以轻松的知道我需要的性能是什么样。但是当所有组合在一起的时候，系统设计和优化非常困难。如果每个应用场景都按照最大化的算力来算，这些场景的叠加是非常庞大的算力要求。很多情况下功能之间是有一定排斥性，资源是可以复用的，可以通过合理的设计达到价格和性能的平衡点，当然这是一个很大的挑战。
第二，分工职责相对不那么明确。传统的架构Tire1负责产品所有的问题，现在有可能是主机厂开发一部分、Tier1开发一部分、甚至Tier2再负责一部分。这三者怎么平衡？因为各家的开发环境、各家的工具、每个人对于需求的理解不一样，还是会带来很多的问题。
我们在哪些地方做过尝试？在SDV1.0和2.0开始的时候，我们内部针对各种ECU模块做了很多的尝试。把ECU软件修改SDV的标准接口，然后模拟整车的场景来测试，测试产品包括电动尾门、电动车窗、电动天窗、电动门、座椅调节、数字钥匙（包括蓝牙钥匙、无钥匙系统等等）、车灯控制等等，我们都做过一些尝试。我们整个设计开发的过程是模拟我们是主机厂或者我们是更大平台的供应商来实施的。我们通过这样方式方法验证和确认了SDV定义的这一套场景、实现方法和标准原则，在大环境和大框架上是非常成功，绝大部分的应用场景是可以通过SDV去实施的， 而且还会带来很多优势：
1、开发产品的体系架构更清晰。
2、通过这样的定义把硬件和抽象相对来剥离出来，把一些控制逻辑更好的独立出来，为以后控制逻辑上移做好准备。
3、基础功能服用性大大提高，复用不仅仅是整车架构的复用，包括最基础的传感器、执行器甚至驱动电路都可以复用。
4、单个功能来说，它的实施比以前方便很多，测试也很简单。
但是也发现了很多问题：
本来一个ECU里面可能有几百个任务，已经很多了，但是整合以后可能变成几千个甚至上万个，这上万个任务每个之间又会有时间的要求和资源的冲突。因为很多是共享资源，资源只有这么一部分，这些资源冲突的时候怎么协调、怎么管理，这是非常大的挑战。
Worst-case很难做，有更多的应用场景以后导致更多的Worst-care，会最终导致功能安全计算分析的时候会有一定的挑战。
举几个例子：
第一个就是车窗防夹。我们现在做的天窗、车窗加座椅，最多到了25个电机。每个电机执行过程中会有各种电流和位置的信号过来，这些数据需要及时处理，不处理这些数据就会丢失，就会导致性能的下降甚至功能的失效。它占用的时间很短，但是会把系统变得非常碎片化，让你的系统调度变得更困难。
第二点，当多个功能/服务最终在执行阶段用到同一个物理器件，这会导致功能与功能之间的耦合，或者服务与服务之间的耦合。比如你驱动某一个电机的时候，上一个阶段已经驱动另外一个电机，驱动芯片温度已经很高，你就无法按照最大的性能去执行，这会带来很多的挑战，软硬件的解耦也就没有那么容易。
除此之外，还有上下电过程的时序、分布式功能（当一个功能原来是一个模块执行，现在分配到多个域控制器执行的时候）也会带来更多协调性的挑战。
我们的工程师在实践后进行了经验的总结并提出我们的建议：
1.在SDV的服务框架体系下，是不是可以考虑在一些极限的工况下，可以由传感器直接调用执行器服务，或者由传感器到域控制器再到执行器。
2.针对一些分布式功能，如必须多个域控制器共同参与完成，可不可以把某一个域控制器作为主节点来协调所有控制器共同执行。
3.在原有的区域控制器之下，再往下发展，把小范围集中的负载由一个简单的控制器来负责，比如说图中左上角的局部控制器，局部控制器再和区域控制器相连，把每个控制器的功能变得相对简单一点。同时整体上来说，整车ECU的数量任然急剧减少、局部控制器作为区域控制器的补充少量增加、区域控制器不变，这样可以到达整车和单个模块复杂度相对比较平衡的效果。
