软件定义产品——软件定义汽车技术路线(SDV)
软件定义产品——软件定义汽车技术路线（SDV）
软件定义汽车技术路线（新型汽车构架⽅案）
1、前⾔
软件定义汽车SDV（Software Define Vehicle）是新⼀代车辆电⼦系统体系构架中的核⼼部分，2000年之前的汽车电⼦系统构架以及⽬前主流的汽车的汽车电⼦构架主要是掌握在零部件⼚家⼿中，包括博世、⼤陆、联电等。汽车的电⼦构架是以功能元件为基础加总线的模式EEA：
传统的EEA就是将功能单元电⽓化，单元与单元之间总线化。功能单元的电⽓件包括相关的传感器、控制器、驱动器、电⽓功能件等，总线连接包括Can（FD）、Lin、部分⽹络或⽆线连接等。
如果我们要对某个车型平台的某个功能进⾏更改或者升级，只需要针对这个功能模块的电⽓功能组件和总线通信数据进⾏升级和变化即可。
⽼的EEA有⼀个显著的优势就是汽车组件化、部件化。组件化⼜很容易形成平台化，所以我们经常说某个平台。或者是多个车型共平台。平台下⾯有很多的⼦平台，⼦平台下⾯有很多的功能组件。
组件化和平台化的优势在于可以快速的批量化，快速的进⾏车型的不断以年或周期进⾏升级。并且这种变化可以在极低成本代价之下来进⾏。
传统的EEA优势虽然很明显，但是他的缺点也很明显，那就是EEA构架是在功能基本定义完成的基础上进⾏功能组件化。如果功能或者⽤户需求在不断变化，或者⽤户⾃⼰想定义⼀部分功能，这种情况下应该怎么办？传统的EEA构架就制约了这种需求。
⽽恰恰新能源汽车的兴起，造车新势⼒需要在汽车的驾驶和运载功能之上，创造⼀种和传统汽车的差异化竞争，就像当年的苹果⼿机⼀样，要弯道超车就需要创造⼀种⽅式去引导⽤户。软件定义汽车（SDV）的新的构架就产⽣了。
什么是软件定义汽车呢？
所谓软件定义汽车就是汽车的功能，整车⼚可以通过软件接⼝或者软件参数进⾏定义和调整，部分功能，终端⽤户可以通过参数定义进⾏功能升级或者个性化调整。
距离⽽⾔，例如以前整车⼚做⼀款汽车，需要先进⾏平台定义，部件选型。现在只需要对参数进⾏调整，可以定制车灯位置、桥长度、车辆娱乐系统的可视化、车辆刹车（特斯拉的问题）系统等。⽽⽤户则可以定义车内灯光的亮度、氛围灯的颜⾊、车辆交互系统的语⾳等。这种功能可定义、参数可定义就是软件化的外在表现形式。
SDV后，新⽼构架的差异就变成：
项⽬⽼构架新构架
功能组件功能部件如ABS、BCM等功能参数、功能软件接⼝
车辆平台电⽓平台EEA软件平台
⼦电⽓件传感器、车灯等可编程智能部件
通信总线和协议分布式总线
⼦系统系统组件软件功能块
2、SDV的三⼤技术路线
SDV从2000年后逐步发展成型，并且逐步在改变汽车⾏业的格局。以前⽼构架的时候汽车零部件⼚家掌握了构架的核⼼，特别是功能核⼼部件。催⽣了博世、⼤陆等世界级的公司，他们定义了⼤量的标准以便设⽴⼤量的排他性“护城河”。
SDV的诞⽣，彻底改变了这种现状，变成了整车⼚的绝对话语权。由于软件的易得性，导致整车⼚对软件平台进⾏需求定义和构架后，可以像互联⽹⾏业⼀样，直接外包给软件公司和硬件公司⼀样。就
像⼩⽶在消费电⼦领域正在做的那样，⼩⽶完成⽣态链定义后，直接完成产品定义，然后软件和硬件直接交给⼤量的硬件代理设计公司如英伟达完成FDA后，再交给代⼯⼚如富⼠康进⾏加⼯。这将彻底提升整车⼚的话语权，但是也改变了⾏业规则，给互联⽹或者其他进⼊者降低了软硬件门槛，但是提⾼了设计和构架门槛。
从⽬前的新势⼒汽车和⽬前的发展趋势看，当今世界（指点江⼭）有三种SDV技术⽅向：
1. 域定义构架模式：以特斯拉为代表的早期进⼊的企业，保留了部分⽼构架，重新以功能和通信定义构架，并在娱乐、电控等功能进⾏
软件化和参数化定义。传统车企和部分⾮互联⽹⾏业的新势⼒造车企业多采⽤这种模式。
2. 平台场景接⼝模式：建⽴汽车平台化操作系统，并将功能应⽤封装为场景模块，在场景模块下提供功能接⼝和功能参数。通过参数和
接⼝实现功能，功能⽀撑场景，场景⽀撑系统，系统构建汽车。这条路线的典型代表是华为，估计⼩⽶也会是这种模式。
3. 平台功能态模式：类似机器⼈，构建汽车功能态，建⽴汽车的数据软件平台、传输软件平台、算法平台，并使之在软件层级图形化、
模块化和组件化。类似Matlab的组件模型或数字双胞胎模型，类似机器⼈平台或者功能组态平台。这条路线在⽇本⽐较流⾏，同时在⾃动驾驶及车辆控制等领域进⼊汽车⾏业的相对流⾏，如百度等。
下⾯详细介绍三种技术⽅案：升级鸿蒙系统步骤
第⼀种：域定义构架模式
以特斯拉为⾸的构架模式，将域控制器的核⼼发展是芯⽚的计算能⼒快速提升，公⽤信息的系统组件，能在软件中分配和执⾏，可实现以⾜够的资源快速响应完成客户需求，具备平台化、兼容性、集成⾼、性能好等优势。
其构架是分布式的，功能分布，例如将传统汽车功能集中化，分为座舱域、底盘域、娱乐域、刹车系统域。。。。。。域之间通过⾼速⽹络总线连接，域内部根据需要可以选择以太⽹⾼速总线、也可以选择传统的负Lin、Can总线。
硬件则完全分布化，将功能直接分不到执⾏部件这⼀个层次。⽽域控制器则只做功能的下发、配置、协调和域调度。
例如上图的驾仓域的分布系统图，通过多种类型的通信⽅式，将数据标准化接⼊总线通信，并将部件参数化布置进⼊域控制器，最终实现车辆定义的软件化。
这种模式的优势是由于与传统构架有共通性，且可以部分利⽤或者稍加改造就可以利⽤现有的电⼦部件产品，快速实现产品构架到产品的量产化。特斯拉是成功的代表，因为特斯拉必须需要量产和批量化，产业化和商业化，不可避免的需要采⽤这种模式。但是连特斯拉在其规划中也提到“功能域分布不是未来汽车构架的⾥程碑，是⼀个过渡”。
第⼆种：平台场景接⼝模式
最近我们很⾼兴的看到华为公开了鸿蒙车辆系统的说明书和接⼝代码，也让我们看到2008年前后宝马做过的汽车操作系统的构思得以延续，可以有幸看到平台场景接⼝模式的逐步产业化和商业化。
平台场景接⼝模式就是类似⼿机或者互联⽹云服务的平台系统模式，通过建⽴层级化的系统构架，建
⽴以功能和数据为核⼼的功能化系统。包括应⽤平台系统、⽀撑平台系统、核⼼组件系统、硬件⽀撑系统等。
和特斯拉的域结构不同，前者还是建⽴在传统汽车电⼦的构架基础上，结合芯⽚技术的发展推进的，⽽建⽴平台场景接⼝模式的核⼼前提是对软件操作系统STOS和软件应⽤平台SAAS的深⼊理解，对互联⽹⾏业软件定义⽹络（SDN）、软件描述平台（SDP）技术的深⼊
和延伸。
实际实现过程中，在操作系统之上将功能封装进操作系统，形成车机操作系统，封装的⽅法有很多，例如利⽤软件类的⽅法、利⽤物模型的⽅法、利⽤软组态的⽅法，这些属于软件⽅法和⼯具的问题，与软件语⾔⼀样，具有多样性，每个⼚家在实现时候的⽅式是不同的，但是构架是⼀样的。
下⾯是⼀个典型的平台场景接⼝模式的例⼦——华为鸿蒙车机系统的功能层（应⽤层）的基本功能表和功能接⼝的例⼦：
功能软件类关键接⼝
车辆座舱管
理：
VehicleCabinManager getVehicleSignal()
获取座舱相关设备的信号值。getVehicleSignalMultiAreas()获取座舱指定信号的多区域值。setVehicleActuator()
设置车辆座舱信号值。subscribeVehicleSignal()
订阅指定的座舱信号。unsubscribeVCabinSignal()
取消订阅指定的座舱信号。unsubscribeVCabinSignalAll()
提供了车辆座舱信号访问控制⽅法，例如车门、空调。开发者可以通过定义的车辆信号标识来获取或
者设置对应的信号值，完成对车辆座舱的控制    取消订阅全部座舱信号。
车辆车⾝管理：
提供了车辆车⾝设备控制相关的⽅
法，例如⾬刷器、挡风玻璃、清洁剂、车灯、引擎盖、⾏李箱等设备控制信息VehicleBodyManager
getVehicleSignalMultiAreas()
获取车⾝指定信号的多区域值。
setVehicleActuator()
设置车辆车⾝的信号值。
subscribeVehicleSignal()
订阅指定的车⾝信号。
unsubscribeVBodySignal()
取消订阅指定的车⾝信号。
unsubscribeVBodySignalAll()
取消订阅全部车⾝信号。
车辆底盘管理：
提供了车辆底盘设备控
制相关的⽅法，例如获取车辆重量、轴距、⽅向盘转向⾓度等VehicleChassisManager
getVehicleSignal()
获取车辆底盘相关设备信号值。
getVehicleSignalMultiAreas()
获取车辆底盘指定信号的多区域
值。
setVehicleActuator()
设置车辆底盘相关设备的状态值。
subscribeVehicleSignal()
订阅指定的车辆底盘信号。
unsubscribeVChassisSignal()
取消订阅指定的车辆底盘信号。
unsubscribeVChassisSignalAll()
取消订阅全部的车辆底盘信号。
上图是部分功能分类和功能接⼝。⽬前处于半开源状态，具体⼤家可以去查和⾃⼰看（代码有点多，构架需要⾃⼰整理，笔者在将来如果有时间，可以把整个功能构架和功能模型整理出来，但是⼯作量确实巨⼤）。
第三种：平台功能态模式
现在这种技术路线也还没有⼀个特定的名字，具体总结来说应该叫平台功能“组态”模式。仔细研究这种开发模式后，笔者翻查了很多⾏业的平台开发模式，从机器⼈、CNC⾏业CODESYS CNC到了部分影⼦。有点类似于Matlab的仿真模型的⽅式，也有点类似于数字双胞胎的数据模型的⽅式，其核⼼是汽车软件化系统开发平台CODESYSTEM CAR。
由于开放的资料较少，从⽇本⼈的⽹站和中国部分公司的资料推论其⼤概的框架和描述如下：
平台功能”态”模式是⼀种利⽤软件技术，将功能和算法模型化，并将模型“组态”化，并通过数据、功能、算法、通信等等现实世界的东西，全部软件化成组件和模型、数字、参数，并将软件化的东西形成功能“态”、算法库、数字“态”，并使之图形化，这样在汽车实现的时候可以通过编程的⽅式直接实现，这⼀点和第⼆种技术“平台场景接⼝”的⽅式是⼀样的，但是平台功能态模式在实现编程的时候不同，在组件和算法的实现过程中不同，这种技术的编程是⼀种完全可图形化和模块化的编程，⽤户只需要像搭积⽊⼀样就能够完成⼀个汽车的开发。
同时模块分层级，模块编程可以组件形成⼀个新的⼤模块，⼤模块⼜可以组件形成更⼤的模块。这个过程称之为“态”的组合，姑且叫做“组态”。
通过这种“组态”（什么⿁，⽇本⼈是这么叫的，直接⽤汉字写，都不⽤翻译！），可以从零实现汽车的完全软件化，并且是⾃我迭代的，就像是有DNA以后，从⼀个细胞开始，逐步逐步长⼤成⼈——听着
有点恐怖。
有点难懂，我们⽤两个例⼦来说明：
第⼀个例⼦是机器⼈，如果我们要定义和设计⼀款3节刚性臂的抓取机器⼈，我们⾸先设计基本的输⼊、输出、变量定义等等基础的量，设计PID、运动、模糊等基础算法，再设计各种⼿指关节的控制算法，包括移动、转动、停⽌等各种算法，并再构建⼿指关节软件模型。
⼀个⼿指关节设计完成后，根据不同的输⼊参数，直接Copy形成⼀根⼿指的各个关节，这个⼿指的模型⼜包括输⼊和输出，以及控制算法。
⼀个⼿指模型设计完成后，根据不同的输⼊参数，直接Copy形成⼀只⼿的五个⼿指模型，模型也包括⾃⼰的输⼊输出和控制算法。
以此类推再设计⼿腕、再设计臂、再设计后关节等。
可以发现这种⽅法会越来越简单，前⾯完成的可以复⽤在后⾯的设计中，并且设计完成⼀个⼿臂后，可以直接复制到其他⼿臂，只是更改以下输⼊输出和算法参数即可。所有的算法是可以随时修改和迭代的。
有了迭代就体现了恐怖性。
下⾯是详细典型的例⼦：
平台功能态模式就是通过具有⼀定标准的统⼀图形化语⾔或者模型化的语⾔，进⾏不断的模块定义和组合，形成软件迭代和功能迭代，完全实现功能的软件化。其核⼼是需要构建和开发⼀套软件平台，集合算法的迭代开发、基本算法库、可图形化的开发系统平台，汽车专⽤部件库、数字化信息交换等的基础软件元件。
3、后记
前⾯论述了汽车软件化SDV的当前的三种技术路线，域定义模式作为传统构架到功能可定义的构架的过度，受多核CPU即芯⽚技术的快速发展，是近⼏年研究较多的⽅案，并能够快速借⽤现有零部件或者稍加改造，并在娱乐系统和智能座舱快速实现，特别是新能源汽车的发展，催⽣了这种模式的快速量产化。
场景接⼝模式是在芯⽚在供给的时候⽆法快速满⾜，或者芯⽚的技术⽆法跟上汽车软件化的步伐情况下，通过软件场景的模块化和接⼝化，实现汽车操作系统，并以此为基础，构建基于场景的可快速开发的汽车软件系统。通过软件系统的不断优化，这种软件系统是可以在不需要太⾼的芯⽚或者极⾼算⼒基础上快速实现。
平台功能态更适合敏捷⽽快速的开发，⼀套设计平台，通过不断的迭代，可以从⽆到有逐步实现越来越复杂的产品设计，搭积⽊，⼀步步实现，未来的空间站就是这样通过“态”的组合快速设计的（NASA 2050 Realizable Space Station Model For Future）。关键是可以⾃我迭代，例如同⼀个⼿指模型，可以通过参数和算法的⼩变更，组态成成为⼿臂的模型，⼀个⼿臂的模型，通过迭代可以组态成机器⼈的腿、个体⼈。通过⼈的模型，组态成多⼈协作的模型，通过多⼈协作模型，组态成⼯⼚作业模型。。。。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。