当前的国家形势决定，我们的经济正处于“双循环”中的内循环主导外循环，主推自主创新，自身腰杆子要硬。因此，对于汽车行业，也不例外，我们也要加快自主创新，建立自己能力的步伐，建立具备自主权的OEM和技术先进性的Tier1，但如何建立这种能力，就需要各位同仁共同努力。
01. xxx定义xxx
不管从事何种行业，都有自成体系的一套规则，在汽车行业也一样，所有的技术落地都要遵循循序渐进的原则，心急吃不了热豆腐，因此首先我们来理清楚新架构落地的层层关系：
图2. xxx 定义 xxx
- 市场定义需求
首先，从整车电子电气架构流程来说，整车设计全生命周期的的起点必须是市场行为，OEM需要进行大量的市场调研，结合自身情况，定位对应的用户群体，之后进行大量的同类型车辆市场对标、技术对标，从而推导出产品的特性，分析自己产品的优势，在这其中，务必要分析出别人没有我有的亮点，而这些亮点也必须是可以让客户觉得物有所值。
因此，在技术快速发展迭代的这个时代，大家更不能忽视市场分析，需求提炼，只有分析清楚市场，才能根据梳理出产品需求，同时还需要结合自己车型情况，找到适合自己公司的市场定位以及对应的需求，再来决策是否需要引入一些新技术。
- 需求定义架构
有了明确的需求，架构团队就可以根据特定需求进行架构设计，有的放矢的分析每条需求，从中提取架构特征，根据所要达到的架构特征，找到最适合的架构拓扑，在对应的架构拓扑中细化相关的技术方案，找到需求的最优方案决策，从而输出对应的设计方案，规范，和设计指导给到软硬件开发团队。
- 架构定义功能
架构在输出对应的设计指导时，必须基于识别的架构特征和拓扑，来约束和限制整车功能，并基于相关约束设计整车功能以及功能实现方案，输出面向不同对象的功能描述文档，有了这些文档输出，整车功能基本定型，接下来才有可能进行开发实现。
- 功能定义软件
架构设计的功能，最终需要借助软硬件来实现，尤其是软件，不同的功能策略，必须对应不同的软件系统和架构，从功能角度就需要对软件进行模块化设计，以及定义模块化之间的交互接口和行为。
有了功能逻辑之间的交互，软硬件开发团队，就可以开始进行对应的功能开发和实现，因此如果功能逻辑设计不清晰，就会导致软件代码逻辑混乱。只有功能清晰，软件才能基于功能定义的基础上，设计好功能实现细节。
- 软件定义汽车
“软件定义汽车”的含义我懂，但如果像之前行业内特意把这个概念单独拎出来，着重强调，我就一直有个疑问，软件是如何来定义汽车的，尤其是在这个词没出现之前，难道软件在汽车里就不存在。
当然有的人会说，好的软件可以优化汽车的方方面面，首先这句话是完全正确的，没有任何问题，但是靠什么设计好软件呢，SOA？评判标准是什么？这方面我也一直在探索，没想明白。
但有一点，在我看来是非常清晰的，软件定义汽车作为设计的最后一环，绝对是将大家共同的努力呈现出来的一环。举个例子，在服务定义时，首先要定义Service，之后定义Service Interface，再就是定义SOME/IP Service Interface Deployment，最后才是Service Instance，但我们在看服务通信行为的时候，只看到了实例化后的服务交互，但没有前面的那些类型定义，服务实例化如何存在？如果不去梳理功能，设计好服务逻辑，整合服务接口，会有好的服务实例？那软件定义汽车的概念其实也一样，如果不从源头梳理清楚需求，做不到每个设计都有其对应的需求，那软件定义汽车就无法落地，软件工程师实现的时候肯定也是一脸懵。
其实这里就是想强调一点，整车开发的流程应该是环环相扣，软件脱离其他，是无法单独存在的。
02 . 架构如何设计
在上述层层关系中，某种程度来说，架构是成就了软件定义汽车，如下图所示。
图3. EEA成就软件定义汽车
那在弄清楚软件如何定义汽车之前，我觉得最重要的是考虑清楚架构如何设计，而我的专业是架构，所以我从自身经验出发，分析下架构如何设计：
作为OEM，首先要对架构如何设计了然于心，并有一套可以适用于所有车型的架构设计方法论，这套方法论必须做到不管技术如何更新迭代，架构如何演变，方法论可以一直被沿用，内容可以不断更新，但框架始终不变。如下图所示，就是我理解中的架构设计方法论。
我将架构设计划分为四大方向：架构特征、架构拓扑，架构决策，设计指导。
图4. 架构设计方法论
- 架构特征
首先，架构特征是定义整车架构最主要的一个维度，架构特征定义了系统的成功标准，它通常与系统的功能强相关，通过功能需求和OEM需求来推导和定义架构特征。比如，如果OEM需要通过沿用架构来降低成本，那架构特征就必须包括可复用性，同时如果技术不断变革，架构势必也要具备不断更新迭代，但如何做到即可复用又满足后续技术发展，这样的架构就必须要做到可扩展性，随着智能驾驶等级的不断升级，整车系统的安全稳定同样也是一个重要的特征，因此比起可复用性和扩展性来说，架构的可靠性也变得尤为重要。
- 架构拓扑
架构通过拓扑来呈现，而拓扑划分为物理拓扑，网络拓扑，功能拓扑。不同的拓扑对应不同的架构团队，各个架构团队负责各自的专业内容设计，并要做到整个架构系统协调统一。
- 架构决策
定义架构的下一个因素是架构决策，架构决策定义了应该如何构建系统的规则。例如，架构决策是否采用SOA，这将决定了OEM整个技术方向，如果不采用SOA，就需要考虑后续是否会脱离主流技术路线，如果采用SOA，是否就代表押对宝了呢？因此架构决策逐渐形成了整车系统的约束，并指导设计开发团队确定什么是允许的，什么是不允许的。
- 架构原则
架构定义中的最后一个因素是设计原则。设计原则与架构决策的不同之处在于，设计原则是指导方针，而不是硬性规则，每个决策的定版都要有一套对应的设计原则。
面对新型架构，OEM往往面临着定义架构师的角色与定义架构一样困难。OEM往往不具备判断一个架构师好与坏的能力，但我认为好的架构师势必是从基层中来的，必须要具备实战经验，口说无凭，说的天花乱坠，如果无法合理推导以上四大方向策略，也就只是请了个会念经的和尚，但3个和尚没水喝。另一个角度，光有实战经验也无法成为一个好的架构师，好的架构师必须要能够从基层实战中升华，找出规律，提炼方法论，对整个新型电子电气架构架构落地了然于胸，能够为公司定义战略技术方向，并同时能够对自己的决策有足够的的信心。因此我建议OEM与其将时间浪费在定义角色上，还不如将重点放在对架构师的期望上。
因为新型电子电气架构是建立在以太网，SOA，智能座舱，智能驾驶等新技术的基础上，因此绝非资历越深越能满足OEM对该领域架构师的期望，真正的期望应该与对方的角色，头衔，工作年限等都无关，如下为新型电子电气架构架构师的七个核心期望:
- 具备做出架构决策的能力
架构师需要定义用于指导团队、部门或整个企业的技术决策或者架构决策，以及设计原则。
- 能够持续分析架构
架构师应该持续分析架构和当前的技术环境，然后提供可行的改进方案
- 紧跟最新趋势，具备不断学习的能力
架构师应该紧跟最新的技术和行业趋势，需要有清晰的技术路径，不允许出现模棱两可的地方
- 坚持对决策负责
架构师应该确保遵从架构决策和设计原则，并有对其决策负责的决心和自信
- 具备知识面的广度，接触不同领域和建立不同领域的经验
架构师应该接触多种不同的技术、框架、平台和环境，从实战中来。
- 具备非常深的业务领域知识
架构师应该对本专业领域的理论，经验要达到很高的深度和广度。
- 人际交往能力
架构师应该具备卓越的人际交往能力，包括团队合作、促进和领导能力。
架构师角色能否成功的第一个关键因素取决于理解和实践以上每一个期望。
对于上面所说的架构四大因素，对架构设计人员的要求是必须要对整车系统架构有个非常非常深入的理解，纸上谈兵肯定是不行的。
03. 架构拓扑分析
从今年开始，区域架构变成了后起之秀，成为了新一代网红。如果哪家主机厂还没有开始准备量产区域架构，简直是马上要被淘汰的节奏，行业内充满了恐慌。
下面由我来提供一些市场调研和分析，架构特性分析，给大家带来一些冷静思考或者一些参考。首先，在分析不同架构之前，我们必须清楚我们要分析的是那种类型的架构拓扑，不同的架构拓扑中的节点类型是不同的：
- 控制器
—— 基于域控D-based
域控制器是一组系统，是按照功能域进行划分，每个功能域拥有一个域控制器，特定域下的传感器和执行器直接或者间接的连接到对应的域控制器上。
—— 基于区域Z-based
区域控制器同样也是一组系统，但是是根据在汽车物理位置来定义的，每个区域拥有一个区域控制器，传感器和执行器直接连接到最近的区域控制器。
- 中央
—— 基于中央计算单元VC
所有的复杂功能逻辑都映射到中央单元，传感器将数据直接传送到中央单元，中央单元再直接传送给执行器。这时，域或区域控制器仅执行该域或区域网络与中央单元之间的组网功能，执行一些简单功能逻辑。
—— 基于控制器单元CC
将复杂功能逻辑映射到域或区域中的控制器，这样域控制或者区域控制器就要具备很强的计算能力，因此中央单元只执行需要来自多个域或区域的数据或向多个域或区域提供数据的任务，而无需处理复杂功能，严格来说是弱化了中央计算单元。
通过以上的分类，当前可实施的架构就可组合成4种，分别是D-VC，D-CC，Z-VC，Z-CC，如果有些OEM想直接从Z-VC开始入手，跳过中间D-CC，D-VC，Z-CC环节，也是可以的，只要落实了具体架构落地的技术路径，这些都不是难点，就怕有些没有十足的把握，甚至没有任何理论支撑直接就一刀切的做Z-VC，这样就容易成为前浪，花了人力物力，最终出来一个四不像，光为他人做嫁衣。如果以落地为目标，前期就必须做好需求分析，技术分析，规划出合理的技术路径，再行动。
相对于域控架构，区域架构和它之间的区别将是本章节的重点：
- 硬件资源成本
- 关键应用程序的故障概率
- 通信电缆长度
- 通信负载
- 功能负载
1. 硬件资源成本
首先要对需求进行分析，区域架构和域控架构核心问题是以太网是否作为主干网，这种区别就主要体现在不同等级的功能安全，是否进行冗余设计，以及冗余的程度是什么。国外研究表明，不同的功能安全等级，所对应的硬件资源成本是不同的，因此我们基于不同功能安全所对应的资源成本矩阵，来分析不同架构所需要的成本。
表1：功能安全等级对应的资源成本矩阵
对于四种不同的架构类型，最终所对应的成本是不一样的：
1）无冗余设计
- D-CC：成本最低
- D-VC：成本相对于D-CC高，但差距不是很大，增加了大约2.9%
- Z-VC和Z-CC：成本相对于域控架构，增加了28%左右
2）有冗余设计
- D-CC：依然是成本最低
- D-VC：成本第二，但和D-CC差距就拉大了，增加了大约29%
- Z-CC：成本相对于D-VC增加的不是很明显，增加了6%
- Z-VC：成本比前三者大了许多， 相对于Z-CC，增加了21%左右
首先有个前提就是，区域架构是必须要引进冗余设计，而域控架构一般无需引进过多的冗余设计。因此对于成本这块，应该拿有冗余设计的区域架构和无冗余设计的域控架构进行比较，这样就可以得出最终我们想要的成本数据：区域架构Z-VC在域控架构D-CC的基础上，成本增加了63%之多。
另外，以上是我们的硬件成本，但其实从软件成本上，我们依然可以进一步得到一些结论，本身域控架构是在分布式架构的基础上，增加了很多资源，比如域控制器增加了多颗MPU芯片，全都运载了以太网协议栈，部分域控制器还采用Adaptive AUTOSAR协议栈，因此域控制器的成本相对于分布式架构已经是质的飞越了。那区域架构还在域控制器的基础上，不断增加冗余。因此总结来说，区域架构的落地充满了钱的味道，所以需要做一些权衡，既保证需求，又能降低成本。
2. 关键应用程序的故障概率
对于主干网上关键应用程序的故障概率，和不同的架构类型内部网络配置是强相关的：
1）无冗余设计
- D-CC：因为架构相对简单，依然四种架构类型中故障率最低的。
- Z-CC：鉴于D-CC和D-VC之间，相对于D-CC保持了12.9%的增量
- D-VC：在Z-CC的基础上，增加了11.4%左右
- Z-VC：在D-VC的基础上，增加了2.5%
2）有冗余设计
- D-CC：相对于无冗余的D-CC架构，增加了6%
- Z-CC：鉴于D-CC和D-VC之间，相对于D-CC提升了21.2%的增量
- D-VC：在D-CC的基础上，增加了17.5%左右
- Z-VC：在D-VC的基础上，增加了4.1%
基于以上的数据，我们可以得出，有冗余设计的Z-VC相对于无冗余设计的D-CC，故障率大约增加了61.2%，故障率的增加，失效概率也会大幅度增加。
3. 通信电缆长度和通信负载
上面也说了故障率是跟这些架构内部网络通信相关的，那对于这四种架构来说，需要的通信总线缆长度和总通信负载情况又是如何呢？
1）无冗余设计
基于控制器CC和中央计算单元VC在通信线缆层面，并没有太大区别，主要的区分点在于域控控制器和区域控制器之间，因为域控制器是按照区域分布，相对于域控制器架构的线缆，区域控制器线缆总长度下降30%左右。
但线缆长度和成本下降，并不会降低通信负载数量，对于通信负载，因为跟数据流向强相关，在功能相同的情况下，D-CC拥有最低负载，而D-VC，Z-CC，Z-VC的通信总量大概是D-CC的2.53倍。
2）冗余设计
增加了链路冗余，则需要的线缆长度增加了78-80%左右，同时链路冗余，功能冗余和通信冗余等原因，也导致这四种架构的通信负载呈倍数增加，功能逻辑也增加50%左右。
综上，在两个不同的应用程序节点上应用冗余对系统属性的影响，D-CC拓扑比其他拓扑具有更好的负载和成本结果，同时在故障概率和总通信电缆长度方面被一些基于区域的拓扑超越。以上的数据只能分析出不同的架构特性，我们并不倾向于任何一种架构，至于OEM具体采用那种，是一定要结合自己的需要来做相关规划，域控架构和区域架构各自的优势也都很明显。
考虑到当前OEM一方面希望通过传感器、执行器和其他组件融合在一起实现相同的功能，以便作为一种节省成本的策略进行考虑。另一方面，OEM又希望维护独立的组件以实现系统冗余，确保功能安全。所以架构设计还是要以需求为导向，架构目标清晰之后，架构设计方向才能清晰。
