1.1 软件架构：分层解耦、服务化、API 接口标准化
随着企业向软件定义汽车开发方法的转变，软件架构也需要同步进行升级，引入面向服务的架构（Service-Oriented Architecture，简称 SOA）方法论。汽车 SOA 是对整车智能化的底层能力进行组织。将车端的硬件能力和各种功能服务化，这些服务根据 SOA 标准进行接口设计，基于 SOA 标准协议进行通信。这样，各服务组件之间就可以相互访问，从而扩展了服务的组合形式。
图1 SOA 服务化架构示意图
SOA 的引入使汽车传统封闭、固化的软件系统逐渐成为具备开放性、重用性的软件生态。在新一轮的软件架构升级中，基于分层解耦的 SOA 服务化架构，利用设备抽象和原子服务实现硬件能力的充分服务化，具体对象包括控制器周边的传感器、执行器、传统总线通信，以及控制器自身的诊断、存储设备。同时，基于“逻辑语义转换”的设计思想，完成接口标准化，实现不同平台、不同车型的接口重用性目标。
图2 SOA 架构下的基础服务举例
随着基础架构及开发方式的变化，“软件定义汽车”会颠覆整个汽车开发流程，基于SOA 的软件架构方案为智能汽车系统提供了重要的服务抽象。严谨的封装和分层结构支持使用敏捷开发方法和针对接口进行测试，并降低了系统的复杂性，将大大简化软件组件在车辆更新换代时的重用。
图3 软件分层架构示意图
架构标准化：
分层架构，在原有的整车架构中，引入原子服务层和设备抽象层。
接口标准化：
跨车型、跨零部件供应商，最大化复用，降低软件定义汽车软硬件开发复杂度。
在架构标准化的基础上，如何能实现软件的跨车企使用？就需要对层与层之间的接口进行标准化，不同整车厂、Tier1、平台供应商定义同一套服务接口，使得不同整车厂之间，不同 Tier1 之间的软件可以相互调用，大大增加软件的复用性，缩短车辆开发周期。
在接口标准化推动方面，中国汽车工业协会已经发布了第三版《软件定义汽车原子服务 API 接口与设备抽象 API 接口参考规范》，包含 700 多个 API，涵盖车身控制、热管理、能量管理、运动控制、智驾域、动力域、底盘域等多个功能域，参与接口标准化定义的成员包含整车厂、零部件、基础平台供应商、软件供应商等 100 多家公司。
1.2 通信架构：基于车载以太网的技术应用
随着车辆功能的不断增加，特别是自动驾驶、智能座舱的不断发展，需要传递的信号已呈爆炸式增长，车辆功能不断升级更新，用户对于 OTA 升级体验提出更高的要求，传统的 CAN 总线通信的方式已不能满足车辆功能的增长速度，采用基于以太网服务的通讯方式，可实现功能的灵活重组，有效解决传统面向信号的通信架构中因个别信号增减/变更，而导致功能相关的所有系统均产生变更的问题。
车载以太网及其支持的上层协议架构如下图所示，车载以太网主要涉及 OSI 的 1、2层技术，车载以太网同时支持 AVB、TCP/IP、DoIP、SOME/IP、DDS 等多种协议或应用形式。
图4车载以太网及其支持的上层协议架构
SOME/IP 的全称为：Scalable service-Oriented MiddlewarE over IP，基于 IP 的可扩展的面向服务的中间件，已于 2013 年纳入 AUTOSAR 4.1 规范。
图5 支持面向服务的 SOME/IP中间件
通信架构升级之后带来的变化：
1.3 硬件架构：区域接入 算力集中化
整车电子电气架构是实现软件定义汽车的基石，目前市场上销售的传统汽车大部分是分布式电子电气架构，如下图所示。
图6 传统分布式电子电气架构示意图
在分布式电子电气架构中，首先将汽车功能划分为不同的模块，如动力控制、底盘控制、主动安全、被动安全、智能驾驶、信息娱乐和车身等。然后再将每个模块的功能再进一步细分，例如车身功能又细分为车灯控制、车门控制、座椅控制等功能。不同的电控功能采用独立电控单元（ECU）实现，不同 ECU 之间通过 CAN/CAN FD 进行通信。
因为每个 ECU 由不同的供应商开发，有着不同的嵌入式软件和底层代码，所以分布式电子电气架构在整车层面造成大量的冗余和 BOM 成本。另外，因为车内软件都分布于各 ECU 上，且 ECU 都由各供应商独立完成，其软硬件是紧密耦合的，整车厂并没有权限去维护和更新 ECU 上的软件。
快速满足用户需求是整车厂抢占市场份额的关键，而分布式电子电气架构严重制约整车厂响应市场需求的速度。假设某车型中设计完成后，用户提出增加驾驶员位置记忆功能，即驾驶员将车辆的座椅、方向盘、外后视镜等相关系统调整到舒适的位置后，可以将其设置为记忆位置，方便后续快速调整。需要对车门控制器、座椅控制器、方向盘控制器、网关等多个部件进行软件变更，只有当各个零部件供应商完成变更，并且整车厂完成集成测试和整车测试后，才能够将新功能投放市场，这将造成开发和变更周期长、成本高等问题。
为此，各整车厂早已开始储备新型电子电气架构方案，以促进软件定义汽车的快速实现。新型电子电气架构的显著特征是功能（软件）集中化、硬件标准化。通过中央计算平台/域控制器对控制功能进行统一管理，从而降低硬件冗余和 BOM 成本，减少整车厂对众多供应商的依赖。根据功能集中程度不同，新型电子电气架构主要分为三种类型。
第一种：域集中式电子电气架构
在域集中式电子电气架构中，将整车电子电气控制功能划分为 N 个功能域，每个功能域设计一个域控制器，其余控制器均为域内控制器，各域内控制器一般为智能传感器、执行器和传统控制器。
域集中式电子电气架构示意图如下图所示，示例中将整车电子电气控制功能划分为五大功能域：动力域、底盘安全域、智能驾驶域、信息娱乐域和车身舒适域。
图7 域集中式电子电气架构示意图
第二种：跨域集中式电子电气架构
在域集中式电子电气架构中，域控制器只负责一个域的功能集中控制；而在跨域集中式电子电气架构中，有些域控制器负责两个或两个以上域的功能集中控制，进一步提升了系统功能集成度。比较常见的跨域集中式电子电气架构是三域架构，跨域集中式电子电气架构的示意图如下图所示。
图8 跨域集中式电子电气架构示意图
三域架构分别为车辆控制域、智能驾驶域和智能座舱域，将原来的动力域、底盘安全域和车身舒适域整合为车辆控制域，智能驾驶域和智能座舱域专注实现汽车智能化和网联化。
三域架构有 3 个域控制器：
车辆域控制器负责整车控制，对实时性和安全性要求高；
智能驾驶域控制器负责自动驾驶相关感知、规划、决策相关功能实现；
智能座舱域控制器负责 HMI 交互和座舱相关功能实现。
第三种：区域接入 中央集中式电子电气架构
中央集中式电子电气架构不再按照功能去部署车内的电子电气系统，而将整车所有功能域的控制逻辑均集中于中央计算平台，进一步提升了系统功能集成度。原有分布式和域集中式架构中的 ECU 的控制/计算功能被中央计算平台收编，转变为更加简单的传感器或执行器。
为了减少线束长度，简化通信，就近接入和供电，在中央集中式架构下可以按照物理位置划分区域并在区域内部署区域控制器，形成中央计算平台和多个区域控制器的架构，中央集中式电子电气架构的示意图如下图所示。
图9 中央集中式电子电气架构示意图
硬件架构的升级，同时需要考虑跨域功能的融合、SOA 架构下的软件功能分层、服务化后的控制实时性、功能安全设计、复杂的硬件设计与集成等等。
2.1 功能安全
随着电子电气架构技术的不断升级，整车越来越多的系统和组件对功能安全产生影响，为此，功能安全也从部分关键系统开发，向整车各系统全面开发拓展。
同时，由于域控制器、中央计算平台等新架构技术的出现，对功能安全提出了新的技术挑战，功能安全必须建立针对这些复杂系统及软件的开发和测评手段。
功能安全技术也影响着电子电气架构技术的发展，从传统的失效安全（Fail-Safe）向失效运行（Fail-Operational）演变，电子电气架构设计中引入了更多的冗余（如通信冗余、冗余控制器等）及安全保障措施。
未来，车辆智能化生态的形成，将促进功能安全技术走出单车，向全链路延伸，实现整体智能生态的整体安全。
2.2 预期功能安全
电子电气架构相关的预期功能安全指的是规避由于功能不足、或可合理预见的人员误用所导致的人身危害。预期功能安全技术属于汽车技术的一部分，对应的标准为 ISO 21448。根据自动驾驶功能及其运行设计域，分析满足预期功能安全要求的系统配置方案，基于系统配置方案确定或选择合适的电子电气架构方案。预期功能安全关键技术点：
（1）自动驾驶安全准则制定技术：针对自动驾驶已知场景和未知场景下的安全表现，制定客观量化准则，科学判定自动驾驶的安全水平；
（2）安全分析技术：通过 STPA 等安全分析手段，识别自动驾驶安全相关功能的不足性能局限及危害触发条件，制定针对性措施，开展功能更新；
（3）多支柱法测试技术：由仿真测试、定场景测试和真实道路测试组成的自动驾驶预期功能安全测试体系；
（4）安全论证技术：基于安全开发、分析、测试等结果，制定预期功能安全档案策略，通过 GSN 等论证手段，评估自动驾驶安全风险，完成预期功能安全发布；
（5）安全监控技术：通过车载和远程手段，监测自动驾驶运行过程中的安全表现，识别安全风险并开展必要的风险控制措施，以确保自动驾驶运行安全。
2.3 网络安全
智能汽车车辆端、通信管道、云平台以及移动应用均面临一系列的信息安全威胁。从汽车网络空间维度出发，通过多重技术协同、不同手段互补、从外到内多层次部署安全防线，满足车辆信息安全防护的纵深性、均衡性、完整性的要求。需要依据新一代车辆电子电气架构，从网联安全、内网安全、ECU 安全角度实施部署相应防护措施。
图10 智能汽车全方位网络安全防御
网联安全
网联接入层主要抵御针对以太网的 DOS、PING 类型、畸形报文、扫描爆破、欺骗、木马等网络攻击。需要具备车云联动机制的主动安全防护能力，可通过云端系统实时配置防护策略，主要包括接入认证机制、通信保护机制、以太网防火墙机制和入侵检测与防御（IDPS）机制。
车内网安全
车辆内网安全主要抵御针对车载 CAN/CAN FD、车载以太网的攻击入侵，包括报文监听、错误注入、报文重放等攻击。防护的策略包括：总线入侵检测机制、内网防火墙机制、功能域隔离机制、总线通信保护机制和诊断安全保护机制。
关键 ECU 安全
为确保车辆系统或关键数据不被破坏，在车辆关键 ECU 层面需具备安全启动、关键数据安全存储、系统安全运行的安全能力，并可为应用运行提供权限管理能力。
服务安全
SOA 安全框架需要遵循五个基本原则：机密性、完整性、真实性、授权性和可用性，通过信息加密、数字签名、密码认证、设计访问控制列表 ACL、DOS 攻击监控等多种方案及产品实现网络安全，同时保证这些网络信息可被发现、被访问、被通信以及被监测。
图11 车载 SOA 服务网络安全原则
汽车上的功能日新月异，软件代码量日益增加，传统 V 模型下的瀑布式开发已经不堪重负，为了快速交付给客户最迫切需要的功能，软件开发流程的转变至关重要。目前，越来越多的汽车零部件供应商转向了敏捷开发。在系统架构实现软硬件解耦，层次化架构系统软件、中间件和应用软件的基础上，实现软件功能的快速迭代、发布，使得整车厂可以快速占领市场。
敏捷开发流程的核心是培养研发人员的协作意识、责任意识、质量意识、学习意识、创新意识，进而提升整个软件研发团队的研发能力，高效地开发高质量的软件产品。特性开发采用以月为研发周期的迭代开发模式，进一步分为详细设计与评审、特性开发与代码走读、代码质量检视与评估、测试用例设计与编写、特性功能联调、特性合入评审等多个子流程。每个子流程有具体的输出件（设计文档、源代码、评审报告、测试用例、测试报告等）和量化评判体系（设计文档章节完整性、增量代码度量报告、评审意见密度、测试用例覆盖率、缺陷密度等），确保每一个子流程均按照软件研发质量要求达成，并对所有文档归档以支持软件质量回溯。
版本发布采用以周为发布周期的软件版本快速迭代模式，每周从稳定分支发布版本，对软件基本功能、新增特性进行充分验证，对已解决的问题进行回归测试，均通过之后再发布版本。敏捷开发的业务价值：
SOA 的总体思路是设计服务模型，将不同的基础服务进行抽取，分层解耦定义恰当的API 接口，应用调用服务 API 接口实现业务逻辑。API 接口定义独立于实现服务的硬件平台、操作系统和编程语言，确保构建在不同系统中的服务可以以一种统一通用的方式进行交互。
对于汽车行业而言，SOA 是一套新引入的技术，需要一套有效的流程、方法和工具链，三者相辅相成，当前业界还没有一套非常成熟的方法论和工具链，大部分整车厂和 Tier1/Tier2 都处于探索阶段，下图展示了一种基于服务的功能开发流程方法。
图12 基于服务的功能开发流程方法
首先对功能进行需求分析，输出场景定义和特性设计，以及对应的物理拓扑和模块功能定义接着继续进行系统设计，包括服务架构设计、服务设计和通信设计，服务定义需依据中国汽车工业协会软件定义汽车工作组发布的 API 接口参考规范。
面向未来的智能汽车时代，随着原有产业价值链开始被打破，传统车企纷纷转型，新生力量奋力崛起，技术进步日新月异，跨界玩家悉数入局，产业竞争的要素和形态正在悄然变化，一方面驱动着新产业格局的形成，另一方面也催生着新产业生态的出现。智能汽车产业朝着更加多元化、复合化的方向发展，出现诸多不曾涉猎的新技术领域，开放合作才能实现共赢，优势互补才能形成合力。
5.1 整体建议
如前所述，汽车产业正向电动化、智能化演进，技术、用户体验等驱动汽车行业快速成长。随着智能汽车的逐步推进，整车软硬件复杂度也在持续提升，行业向软件定义汽车转型已成产业共识，但软件定义汽车还处于起步阶段，软件的大量引入给汽车产业从设计、开发、集成、测试、发布和维护都带来一系列的挑战。只有管理好软硬件组合的复杂度，才能持续满足消费者的体验需求，形成市场竞争力。
分层解耦是提升软件复用性，降低软硬件开发复杂度的关键手段，也是迈向软件定义汽车的必由之路。通过分层解耦，可以实现软件与硬件分离，应用与基础平台分离，但如何实施成为关键挑战，将直接影响软件定义汽车的战略目标和价值达成。从技术层面，架构如何分层，服务如何划分有利于最大化复用、最简化开发维护和长期演进是关键挑战。只有合理、稳定、统一的服务划分才能确保软件定义汽车价值实现最大化。从产业链方面，各方如何定位、分工、协作才能保障各方最大化利益是关键难点，开放、合作、共赢是软件定义汽车快速落地的基础。
整体建议：
从技术规范统一性和产业合理分工两方面，加强汽车产业链上下游企业合作协同，共同推动智能汽车软硬件接口标准化，构建原子服务和设备抽象层，实现应用、基础平台和硬件的分层解耦；建立 SOA 服务架构和接口规范化统一化，实现跨车型、跨零部件供应商最大化复用，减少定制加速创新，提升智能汽车产业协同效率。同时，结合产业链各方诉求和优势，基于分层架构，形成合理分工从而通力合作。
具体建议：
图13 软件定义汽车产业合作整体建议
同时，API 规范化并不等于产业竞争同质化，在标准上开放，在产品上竞争。整车厂和各零部件供应商可在关键技术上分层构筑核心竞争力，在协同上构筑管理能力提升效率和规模，在商业模式上构筑保护机制确保独家/先发优势，从而最终面向用户提供独特性、可进化、更高附加值的产品。
同时，不同厂商的硬件、软件、平台等具有互操作性，即不同车型和不同部件，能够用相同的语言完成跨域调用、交换和共享信息的能力，让产业链的每一个企业都受益。
对于整车厂：
对于零部件供应商：
对于软件开发企业/开发者：
5.2 整车厂
整车厂直接面向终端用户，提供满足用户需求的汽车产品，将软硬件、应用功能及生态服务等各方集成起来，完成从整车制造到长期出行服务的交付。
整车厂不仅仅是生产汽车的制造商，也会面向消费者提供移动出行相关服务，通过软件的开发、配置、迭代升级来满足用户多种多样的用车需求。用户能通过软件设置汽车产品的不同功能，甚至可以根据个人喜好编辑出行场景或下载需要的特定场景功能。为此，整车厂需要完成以下平台的搭建及开发：
1) 硬件平台整合
硬件平台是软件定义汽车的基础，现阶段各个整车厂规划的电子电气架构主要有三种：集中功能域、跨域融合、中央计算域 区域接入。为应对智能化汽车和软件定义汽车的需求， 中央计算域 区域接入将会是未来的主流电子电气架构。整车厂需要根据自身情况合理分配各域的功能及区域接入硬件的接口。
2) 软件集成
整车厂需要具备软件集成能力，构建“软件中心”或者“用户体验中心”，并建立相应的组织架构，提升整车软件开发能力。
第一阶段：关注整车控制应用层软件和与用户体验强相关类软件，形成品牌特色，提高用户粘性。搭建软件开发环境，按照软件开发流程，例如导入 AUTOSAR 规范等，实现应用层软件和供应商硬件在开发层面解耦，应用层软件封装后交给供应商集成和配置，而不需要对其开放应用层，可以指定几个硬件供应商。同时可与生态服务商合作，将第三方软件嵌入应用层。应用层自主掌控后可实现快速移植，提高开发效率，也为功能持续迭代、用户常用常新提供基础。OTA 是核心通道，第一阶段实现是迈向软件定义汽车的第一步。
第二阶段：通过购买配置工具逐步实现应用层与底层的集成，硬件供应商提供“白盒”，在整车厂进行集成和刷写。实现真正意义上的软硬件解耦，扩大硬件的采购范围，降低采购成本。但是底层配置功能需要整车厂大量的投入，整车厂根据自身能力考虑是否入局。
第三阶段：逐步进入硬件和底层的自主开发。通过硬件降低整车成本，自主选择核心芯片，打破硬件平台化的局限，以成本和客户体验为导向，根据整车配置及功能需求进行软件模块化移植。
3) 开放平台的构建
传统汽车开发完全依托车厂的工程师理念，是一种凌驾于客户之上的开发模式。开放平台本着共赢、共生、共创的新模式，能在新形势下解决供应商、整车以及用户之间的关系。
开放平台可以为车企开发工程师、第三方、用户提供整车车辆能力，这些能力包括一些底层硬件能力、软件能力、数据及信息，根据这些能力结合使用场景可以开发出多样化的软件，为用户提供定制化、个性化、订阅式服务，即为用户和整车厂创造价值，也获得自身收益。实现用户参与车辆软件的开发，真正实现软件定义汽车。
通过开放平台，可以调用汽车上百千个硬件模块，能提供比手机更强的感知能力，更多的应用场景，更大的覆盖范围，更长的生命周期，所以汽车生态圈要比手机生态圈更广，比手机更加开放，更加贴近用户。
5.3 零部件供应商
对于传统零部件供应商来说，在软件定义汽车发展趋势下，整车厂在系统功能开发的话语权越来越大，借助软硬件解耦和 SOA 架构的落地，整车厂也将逐渐承担部分零部件供应商应用功能的开发，因此传统以硬件为主的 Tier1 迫切需要转型寻求新的出路。
目前来看，软硬件全栈能力的打造，是抢占下一个市场份额制高点的关键所在，很多能力非常全面的 Tier1 正在打造“硬件 底层软件 中间件 应用软件算法 系统集成”的全栈技术能力，既能为客户提供硬件、也能提供软件，同时也提供软硬一体化的解决方案。但这样的布局要求 Tier1 大量的人力和资金的投入，不是所有 Tier1 能够承担的。
对此，零部件供应商应将进一步开放硬件端口，对硬件的能力抽象化，为降低面向不同整车厂的定制成本，提高交付效率，需要将接口按照统一标准进行开放，从而降低匹配复杂度，减少软硬件耦合度，增强灵活性和复用度。并主动联合整车厂、软件供应商等多方共同打造零部件生态，吸引和创造更多元更丰富的盈利场景在标准接口的前提下，性能的差异性会给零部件供应商带来竞争，同时也会促进零部件供应商去创新和进步。零部件供应商的重点应该聚焦内部的核心算法，通过内部算法和代码的优化升级，实现性能和体验的差异性和持续进化。并通过和整车厂、人工智能、软件等领域的 IT 公司合作，了解最新的需求和发展方向，调整自己的研发方向和能力，立足硬件，运用积累的行业 Know-How 优势构建应用功能软件能力，反哺并带动差异化硬件销售，是很多零部件供应商的选择。
5.4 基础平台提供商
面向软件定义汽车时代，基础平台厂商的目标是运用自身 ICT 技术积累和优势，帮助整车厂打造适合整车上自身规划的、差异化的下一代电子电气架构，降低智能汽车研发复杂度，提高效率，加速智能车开发落地。
但目前从整车厂到一级供应商、二级供应商和三级供应商这样的供应链模式正越来越模糊，而车企越来越希望能够主导更多的内容，这迫使基础平台提供商必须以更加开放的姿态打破边界，聚焦自身优势产品，面向上下硬件和应用软件提供开放 API 接口，并为功能软件提供安全可信的运行环境和易用的服务开发及验证工具链。
建议基础平台提供商为整车厂提供一个面向智能汽车可持续进化的架构，在设计理念上应以人为本，围绕用户体验与整车厂商业成功持续创新。
5.5 软件供应商/软件开发者
随着整车厂自主权和软件自研能力的不断加强，整车厂开始寻求与软件供应商的直接合作，比如整车厂商将首先寻求把座舱 HMI 交互系统功能收回，UI/UX 设计工具、语音识别模块、音效模块、人脸识别模块等应用软件则直接向软件供应商购买软件授权，从而绕过传统 Tier1，实现自主开发。
随着软件定义汽车的变革的推动，汽车硬件体系逐渐趋于标准化，而软件是汽车里迭代最快、最容易个性化和差异化的部分，同时软件也将推动硬件创新，二者相辅相成。对于软件供应商来说，能提供越多的软件 IP 产品组合，就越可能获取更高的单车价值。
同时，软件供应商也正寻求进入传统 Tier1 把持的硬件设计、制造环节，比如域控制器、T-BOX 等，以提供多样化的解决方案。对智能汽车 APP 应用开发来说，基于原子服务标准 API 开发应用软件将变得非常便捷，容易上手。对于应用来说不用过多的关注底层的实现，降低不同层次、不同模块的依赖性，类似基于安卓的开发模式。针对不同的人群、不同的车、不同的生活场景，不同的应用开发商就会做出功能不同、画面不同、体验不同的应用。
应用开发的门槛变低了，就有更多的软件供应商/开发者能参与到汽车应用 APP 开发中来，随之而来的就是软件开发的竞争变大了。软件供应商应该基于一些调查数据去分析不同人群的偏好，针对不同的车型，开发出适合大众并具有差异性的应用。用户可以根据自己的实际情况，选择性的安装部分功能和特性应用，通过不同的应用和服务，可以定义自己车辆的一些特性，达到通过软件进行功能升级或个性化定制的目的。
在竞争的过程中不仅会出现非常受欢迎的应用软件，也会提升应用软件供应商提升服务的主动性和精确性，提高产品创新的能力，从而繁荣智能汽车应用生态。
5.6 行业组织
政府应该从法规、政策、标准等方面来帮助整个汽车行业建立合理高效的管理制度，监督整个行业有序、平稳地运转，不断做大做强，并确保整个行业的公平竞争。
从政策上鼓励各企业发展新技术，比如可以奖励对汽车行业有贡献或者在某些技术方面有突破的企业单位，分享、展示创新成果，实现科技政策和科技创新的深度融合，并不断地完善政策，完善反馈体系，发挥政策对发展新技术的推动力，创造出良好的汽车软件生态系统，以智能网联汽车带动智慧交通与智慧城市的建设发展。
从标准上建立解决共性问题的通用接口等规范，实现汽车软硬件产品的互联互通，避免各企业在通用标准化接口层面各自为战，倡导各企业在统一接口下做好自身产品的创新与研发，避免重复和碎片化投入，提高研发效率，推动我国智能网联汽车发展。
以上是一文聊聊软件定义汽车落地的五大关键要素的详细内容。更多信息请关注PHP中文网其他相关文章！
