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