在智慧城市、智慧交通背景下，智能汽车将逐渐发展为具备高智能、可进化、泛连接能力的智慧终端。
2024年9月4日，在第四届智能汽车域控制器与中央计算平台创新峰会上，一汽研发总院架构设计高级主任郑欢谈到，当前，汽车正处于从“单车智能” 向“车路云一体化”为代表的“群体智能”过渡的关键时期，基于新一代移动互联、云计算等手段，打通智能汽车、智能交通、智能通讯三大万亿级产业，实现信息-物理的深层融合，显著提升道路交通的综合性能。预计到2030年，“车路云一体化”相关市场规模超14万亿元。
通过车-路-云一体化能实现数据的共享，赋予终端多维感知能力，确保精准感知，提升安全性，使得广域情景得以感知、驾驶意图得以传递，将城市交通的智慧化带到更高的层级。
郑欢 | 一汽研发总院架构设计高级主任
以下为演讲内容整理：
背景分析
在当前，智慧交通、智慧生活以及软件全生命周期管理是核心议题，而智能化则引领着智慧终端与智能领域的发展潮流。
当前主流车企研发逐步转向集中式架构转型，云计算、车云架构等模式是架构发展的先进形态。在车企范围内虽非全部，但多数已涉足云服务、云信息等领域。未来，我们将更加注重强化车辆的功能与控制层在云端的实现。
关于车云协控部分，目前仍处于研发、思考或实施阶段。李克强院士指出，当前所谓的单车智能已非传统意义上的概念，而是所有车企都在积极探索的云技术，包括训练、大模型等。从当前来看，单车智能已呈现出进阶的发展态势。
图源：一汽（一汽来源 CICV 冉斌演讲内容）
另一位专家在阐述此问题时指出，发展车路云协同的本质是追求群体智能。单车智能虽已在单车车企或企业集团中取得显著成效，但其仅能达到人类老司机的水平。然而，是否足够取决于能展现出何种场景与用户功能。若群体智能展现出核心亮点，则标志着技术的巨大进步。
云技术实则为复杂的云，而非简单的云。它整体包含企业数据云、企业公有云以及第三方云。城市云则构成另一朵云。目前，由于城市云数据应用方式以及和车企交互关系尚未明确，因此可能仍采用专线方式。车企在企业云上的布局，取决于其企业战略与技术能力。
当前，国家正推出数据安全法规，且为强制性标准。该标准认为，当前智能驾驶的数据采集和存储等，需由国家统一监管。未来，若车辆数据上传至企业云进行训练，将面临一系列法规问题和技术问题（如要求坐标偏转等）。这一定程度上会促进国家主导的城市云的应用，这已经是车企不容忽视的重要事项。
从我个人的角度来看，未来架构的梳理应关注云带来的用户场景增强和车端架构的变化。若云仅在信息提示，训练协同上，则可能造成资源浪费。长远来看，重云轻车的方案将是发展趋势，即云作为控制主体，为车辆减负，智慧的云带来车能力的大幅提升，同时对车端感知及计算的要求降低。当然，若计算平台通用化，也不意味着要缩小计算平台的算力（和当前对比），而是应追求最大的效能比。
由于云、云控与云应用的引入，用户体验将进一步提升，功能也将得到意想不到的提升，包括成本方面。虽然成本降低可能是一个长期过程，但我们未来追求的目标一定是增强云控功能，从而为车辆端减负。
我们当前应重视重云轻车与车辆端简化的理念。其核心在于，云端能为车辆端提供何种安全机制。在安全机制的保障下才能去研究智能驾驶的主体责任，所有车辆都将从中受益的同时，也可以把协同驾驶辅助和协同自动驾驶予以实施。
目前而言，这是一个规模庞大的产业，其特点在于群体智能的广泛应用与整合。近期，我们正携手工商协会，推进车云一体化应用2.0项目，该项目明确了八大系统及十五个应用场景，相关行动已在积极实施中。
具体细化内容涵盖四大类别：协同预警、协同增强、协同驾驶辅助以及自动驾驶。展望未来应用，总体而言，将通过以下几种方式提升用户体验，包括安全性增强、空间效率提升、舒适性体验优化、特殊场景应用以及车端降本。当前，我们的产业体系已完善，各方已具备共同进行技术突破及提升协同能力的条件，具备在可见的时期内，取得突破性技术进步的可能。。
车云一体架构的层级
关于车路云一体化的层级结构，我们以一汽九章平台为例进行说明， 有“四横三纵”架构，每一纵代表一项基本任务，这一架构在车企间尽管表现形式有所不同，实质上意思表达相似。
图源：一汽
从另一维度看，可简化三层：云脑层（包括城市云脑和企业云脑）、整车级操作系统层（作为车云一体支撑标准化接口，服务和资源调动，软件灵活部署的载体），还有一个车辆基础平台（计算平台与基础平台的是密不可分的）。
关于城市云部分，它是权威且建设性的标准，未来将继续沿此方向深化发展。企业云部分，通过业务中台、AI中台和数据中台三个中台实现业务承上启下，同时提供工具和数字化工具的全生命周期管理。
在软件应用层面，核心在于软件的开放性和解耦及接口暴露的利用，以创造更多用户期待的应用，进而转化为用户价值和车企价值。
在操作系统层，各车企和科技公司都在开发自己的操作系统（OS），其核心目标是摆脱以往操作系统的限制。简而言之，这一架构旨在提高工作效率、软件开发效率和风险控制能力。操作系统层将进一步细分为服务层、技术软件层和车云一体化中间件。技术软件层负责动态调度分配，服务层提供标准化API接口并对外报告；中间件则关注如何提升云应用的可靠性。之前提到的影子模式、大模型，以及更进一步的同源同构，都可能是未来的发展趋势。
基础平台层除了计算平台外，还包括网络、软件和电气的基本要求。各车企也在积极研发48伏应用，以兼顾效率和成本。当前，我们的任务是采用中央计算方案，以满足上层对技术平台的要求，从而真正构建一个有效的技术平台。此外，车云一体的芯片融合及集成方案已具备一定的基础条件，并有望进一步提升。针对车型开发的成本问题，由于各车企面对成本构成复杂，需综合考虑平台因素及车企或各单位的具体特点。
我们的工作应与车企的战略紧密相关。车企是专注于销售10-20万价位的车型，还是追求更广泛的市场覆盖？总体而言，这关乎覆盖范围的广度及我们如何策略性地应对，以确保企业战略能够有效促进销售目标的实现，这是企业所采取的战略方向。
在软件层面，迭代是可行的策略；而在硬件层面，根据车型覆盖度，选择恰当的产品货架方案是应对平台化的解决方案。
红旗的集中式电子电气架构开发探索
一汽在红旗集中式架构上的探索已历时三年，本次我将分享一些新的见解。
架构的追求在于一体化、硬件集成与软件SOA化。从设计角度来看，它通过五个视图来阐述，分别解决了五个不同维度的问题。
图源：一汽
之所以采用这种架构方式，是因为它强调自主性，包括软件自主及快速生成能力。SOA的核心价值在于软件模块的借用、复用及开发效率的提升，这是其根本出发点。在架构设计中，成本、周期与质量需兼顾。若有人声称其架构在每个方面都最优，那显然是不切实际的，因为架构的本质在于协同，而非每个方向都达到极致，是平衡的最优解决方案。
从功能架构的角度看，需求分析与数字化的开发传递是至关重要。理想状态下，正规的功能需求应从高层级的功能能力向下渗透。每一层级都需要有相应的支撑。
此外，一个公司的开发实力主要体现在其系统的开发能力上，。架构则是支撑这一切的工具、资源和翅膀。
在需求分析中，MBSE作为一种模型化工具，为架构师所熟知。它分为三横四列，展示了从整车到系统再到零部件的需求导出及向下传递的过程。需求的传递效率直接取决于架构的设计。核心问题在于，用户需求如何正确产生和传递，以及我们开发的功能是否能最终满足用户要求，实现卖点。
在软件架构方面，主要采取分层策略，将模块分层，并定义每层的关系及标准化的接口。物理架构则主要包括拓扑设计、接口设计及部署。它的核心以方法论为主，关键在于如何归纳原则性内容并进行设计和评价，如拓扑设计、融合设计及部署原则的制定。这涉及如何实施及如何评价是否达到设计目标。
电气架构在很大程度上解决了平台化应用、冗余、区域智能配电及能源管理之间的关系。智能配电虽是新技术，但其只是整车能源管理的一部分，需要这种管理贯穿始终，，包含多个维度的整体性节能设计。包括网络节能、场景化配电设计、电源模式和车辆模式等。红旗九章平台未来将以构建车云一体AI架构为目标，这一愿景由一汽董事长在SIGHT531发布会上提出。
目前，我们近期的云解决方案以增强车端感知为主，聚焦于车辆感知、预警提示，协同驾驶辅助为主。在短期内，车端情况不会有显著变化，因为云端控制要应用于车，仍需要解决一些核心的技术和难题。
此处引出当前几个核心议题，共计三个方面亟待解决：一、关于延迟问题。二、关于精度与安全问题。三、关于覆盖场景问题。
就安全问题及实时性而言，在自动驾驶领域，若云端需实现直接控制，延迟必须控制在50毫秒以内。而目前，从端到端的最佳表现仅为160毫秒，这显然是我们需要重点突破的内容。
二、关于安全问题。其核心在于，若我选择使用你的服务，你能提供何种等级的安全机制，是B级、D级还是其他等级？责任主体又是谁？
再者，该技术突破是否能得到全天候、全产业的支持亦至关重要。车企的车辆不能仅限于在某一城市区域行驶，也不能要求每到一个城市都需进行调整。我们必须确保车辆能覆盖全国范围，至少主要城市和高速公路应得到覆盖。我们需要有一定的覆盖面，并且标准应统一。虽然全国可能无法实行单一标准，但可以设定为几个核定的标准。只要我的车辆符合某一标准，便可在该标准基础上实现协同自动驾驶，在符合另一标准时，则可进行增强的协同辅助驾驶。
（以上内容来自一汽研发总院架构设计高级主任郑欢于2024年9月4日在第四届智能汽车域控制器与中央计算平台创新峰会发表的《红旗针对车云一体架构的思考和实践》主题演讲。)
