软件定义汽车

软件定义汽车概念认识，价值体现，面临的问题与挑战，如何落地实现，典型的应用场景。软件定义汽车既是一种 整车设计、开发、销售、服务的全新模式，也是新的整车软硬件技术架构。

软件定义汽车

• 一、 软件定义汽车的概念
  • 1. 软件定义汽车的概念
    • 软件定义汽车就是软件深度参与到汽车的定义、架构、开发、验证、销售、服务等全生命周期的过程中，并不断改变和优化各环节，实现驾乘体验持续优化、汽车价值持续增值
    • 软件定义汽车既是一种整车设计、开发、销售、服务的全新模式，也是新的整车软硬件技术架构
    • 软件定义汽车是驱动传统汽车升级为智能汽车的关键，将涉及到商业模式、产品竞争力、组织与研发流程、人才体系、供应与生态体系等的全面变革
  • 2. 软件定义汽车体系框架
  • 3. 架构特征
    • 软件定义汽车架构层面最核心的特点为：软硬解耦。与过去软硬紧耦合不同，在软件定义汽车时代，软硬解耦是面向服务架构进行功能迭代，促进汽车“成长进化”的重要途径
      • 面向软件开发商/广大开发者实现软件可跨车型、跨平台、跨车企重用，支持应用快速开发、持续发布
      • 面向零部件提供商实现硬件可扩展、可更换，执行器、传感器等外设硬件可即插即用
      • 具备整车级数字安全与纵深防御系统
      • 让汽车逐渐成为可持续保值增值平台，全生命周期投资回报最优
    • 系统开放、生态融合是软件定义汽车时代的另一个典型特征
• 二、 软件定义汽车的价值
  • 1. 产业链升级优化：大幅提升开发维护效率，缩短 TTM
    • 软件功能的开发不再受整车上市流程约束，具有一定的灵活性
    • 软件功能可灵活复制到其他车型，而无需同一功能在不同车型上开展大量重复性 定制开发工作
    • 在使用车辆的过程中，用户可以按需订阅新功能，让整车厂与用户的联接不单单 是买车环节这一次，而是用车的全生命周期的互动，产生更多交易的可能
  • 2. 消费者体验提升：千车千面常用常新，提高保值率
    • 在软件定义汽车的技术体系内，OTA 产生的盈利不会随着第一次销售而停止，而是以 此为起点，在汽车全生命周期内持续创造丰厚的回报并保证最新的产品功能体验
    • 随着软件标准化的可复制性以及整车硬件进一步标准化，整车成本将得到极大的 优化
    • 软件定义汽车会极大提高整车厂的盈利能力，尤其是常用常新将有力提升汽车的保值率
    • 以特斯拉为例，波士顿咨询公司通过对比纯电动汽车、内 燃机车和 Model S 三款车型的售后保值率发现，特斯拉 Model S 的产品保值率明显高于同级别车型，到第七年， Model S的保值率约为 47%，高出同级别车型 11%- 14%
  • 3. 新商业空间激活：以体验为中心创造出更大的市场机会
    • 在汽车产业链重塑升级过程中，软件定义汽车将推动整车厂由传统汽车的硬件、造型、动力等向智能服务（如体验类/出行类/数据类服务）、可快速迭代的软件方向等转 化。而这也将汽车商业模式转变为包含“一次性购车”和“软件服务”的新商业模式，软件服务也将持续不断的为车企创造新的价值
    • 在软件服务方面，围绕用户数据、车辆数据和场景数据，软件可提供车辆相关服务和拓展类服务
      • （1） 车辆相关 服务方面
        • a. 车辆管理与驾驶服务
          • 主要聚焦车辆状态监测和升级优化
        • b. 车辆后市场服务
          • 主要包含保养、二手车残值、保险金融等服务
        • c. 车辆智能服务
          • 主要包含自动 驾驶、辅助驾驶和智能交互等相关功能
      • （2） 拓展类 服务方面
        • a. 出行服务
          • 将向满足消费者高体验出行需求，提供智慧停车、补能、代驾等服务
        • b. 生态服务
          • 将构建车与外界的融合生态，包含车家互联、车机互联和车载应用生态等
        • c. 数据/用户洞察服务
          • 能进一步优化需求，进行数据管理、维护、使用和变现等
      • （3）
• 三、 软件定义汽车面临的挑战
  • 1. 影响或滞缓智能汽车产业升级发展的主要原因
    • （1） 用户体验带来的复杂度提升
      • 随着智能化的发展与普及，用户驾乘体验逐 渐从传统的交通工具向第三空间扩展，汽车使用的场景、用户功能等均在大幅度 扩展，成百上千的场景、功能组合形成了现在越发复杂的智能汽车体系
    • （2） 技术进步带来的复杂度提升
      • 如越来越大的电池能量密度的追求和快充性 能的追求带来了严重的电池安全挑战
      • 人工智能、5G 通信、云计算等多种数据驱 动汽车向智能化不断进化的同时，也大幅度增加了软硬件开发复杂度
    • （3） 监管&法规带来的复杂度提升
      • 智能化、网联化赋予汽车智能、便捷体验 的同时，也带来了黑客攻击、数据滥用等严重的安全问题
    • （4） 竞争带来的堆料、堆配置、各种选配等模式导致汽车配置多样性、复杂度快速增长
  • 2. 需要解决的关键问题
    • （1） 技术架构方面
      • 当前架构下任何一个部件的增加、修改、更新都会对整车带来影响
      • 以传统通信矩阵为例，当前修改和配置需要 N 周时间，未来电子电气 软硬件数增加 10 倍以上 ，大量软件的引入 ，那又意味着什么呢？
    • （2） 安全和隐私保护方面
      • 全量测试时间长、代价高
      • 如果部分测试造成漏测 会导致什么后果？
      • 尤其是安全漏洞被黑客劫持，那对整车厂的品牌和用户粘性会 带来什么样的后果？
    • （3） 组织流程方面
      • 整车厂如何建立与软件定义汽车开发模式相匹配的组织架构？
      • 面对消费者上千种配置组合、上千种体验场景、上万种组合服务和应用，哪 些更新推送给所有的用户？哪些推送给限定的用户？
    • （4） 商业模式方面
      • 面对软件定义汽车对传统汽车供应链与合作模式的颠覆， 产业中各方利益如何分配？
      • 如何共同做大产业蛋糕？
    • （5） 生态协同方面
      • 传统汽车供应链是 Tier2->Tier1->整车厂线性模式
      • 对于软件定义汽车时代
        • 一方面会出现新的玩家，比如互联网公司、ICT 科技公司等， 甚至出现个人开发者
        • 另一方面整车厂按照传统的采购和项目模式难以满足消费者对汽车常用常新、千车千面的需求，故各企业将围绕以消费者为中心进行产品创新、研发和供应，传统线性模式将被打破， 出现以网状合作的形态
        • 如何合理分工从而优化整车研发效率和成本 ，成为行业发展的难题。
  • 3. 面临的主要挑战
    • （1） 技术架构方面
      • 1||| 软件定义汽车技术亟待提升
        • a. 从整车厂视角来看
          • 传统“以整车硬件产品为主销点 ”的技术能力逐渐转变为“软硬件融合，且以软 件产品为主销点 ”的技术能力，需要在完成整车电子电气架构升级的基础上，依 据研发主导程度和软件能力两个维度上进行技术能力规划
          • 会形成 四种模式
            • 全栈技术布局
            • 核心领域技术重点突破
            • 与软件企业战略合作
            • 同主流核心 Tier1深度绑定
          • 要形成长期清晰的软件技术能力发展规划、相应技术能力和软件生态方案， 都需要一定的探索论证周期
        • b. 从零部件供应商（Tier1/Tier2）视角来看
          • 在“软件定义汽车，整车架构升级 ”的背景下，既有的产品供应方式和技术能力 存在严重挑战，需要深刻调整，如何实现与尽可能多的整车厂技术方案对接，需 要完成哪些关键技术能力储备，需要一定的探索论证周期
        • c. 从 ICT 科技企业视角来看
          • 软件定义汽车如同是“ 四个轮子的智能手机 ”在手机端的相关成熟技术能力可直接借鉴，跃跃欲试，和其他相关方存在一定程度认知偏差和技术能力对接偏差， 需要一定的探索论证周期
      • 2||| 定制和私有接口，造成开发低效和浪费
        • a. 软件方面
          • 软件定制化将带来大量的接口适配、驱动适配、反复标定、通信矩阵的反复调整 等重复性劳动，端到端软件开发效率低，人力资源浪费严重
          • 随着整车智能化加快，软件将呈现指数级的增长， 软件开发模式转型将势在必行
        • b. 硬件方面
          • 硬件定制化导致的结果就是硬件的频繁定制、线束定制、重复的 DV/PV、认证等， 使端到端管理复杂度和成本居高不下，频繁的产线调整导致产能浪费，型号的切 换导致备件和库存总量的线性增加等
          • 随着汽车智能化的发展，对硬件的要求越 来越高，如果延续这种硬件定制模式，那硬件的定制工作量以及由此带来的软件 的适配工作量是难以想象的，故这种硬件模式也亟待优化
    • （2） 安全和隐私保护方面
      • 1||| 安全威胁日益严峻
        • 汽车生产供应链和制造流程复杂，需要各级的供应商配合参与，若其中有一个供应商 环节出现安全隐患 ，就会影响到最终消费者的安全
          • 如何构建贯穿全流程涉及研发、 生产、供应链、销服、消费者等多个环节的整车数字化安全防护体系是智能网联汽车 的巨大挑战
        • 未来以车内网、车际网和车载移动互联网为基础，在 V2X 之 间实现智能化交通管理、智能动态信息服务和车辆智能化控制的一体化网络将是大趋势
          • 随着智能汽车产业的发展，汽车行业将安全的范畴从功能安全延伸到网络安全。
          • 智能网联汽车网络攻击风险加剧，将对社会和生命造成安全威胁
      • 2||| 网络安全的技术挑战
        • a. 智能网联汽车的攻击面广
          • 车端 ECU 面临的常见网络安全风险
            • 车内网络目前大多采用 CAN/CAN FD 协议进行通讯，而 CAN/CAN FD 的字节长 度有限、仲裁机制、无源地址域和无认证域等问题有潜在的网络安全隐患
            • ECU 硬件可能存在可读丝印和暴露的调试口，容易遭受防逆向分析等安全隐患
            • ECU 固件刷写机制未进行信息安全保护，可能导致 ECU 固件或其配置数据被篡改
            • ECU 中的敏感数据（如调校数据、虚拟钥匙数据、地图数据、配置数据等）的存 储、访问过程中，若未采取加密存储和访问控制等防护措施，则可能导致数据被 篡改或泄露 ，被篡改的数据可能导致系统功能偏离预期，甚至带来其他信息安全 方面的隐患
        • b. 智能网联车的漏洞更多
          • 软件定义汽车概念的兴起，汽车正在软件层面被重构
            • 造成漏洞分布广，数量多，隐藏性强
          • 电子电气架构的发展
            • 未来智能汽车控制器将会承载越来越多的功能，而且不同的电子电气架构下呈现的信息安全状态也有所不同 ，同时车载控制器复杂度越来越高，逐渐趋同于 ICT 行业的高性能计算机，也可能会带来新的信息安全威胁和攻击手段
          • 以智能驾驶技术为核心驱动力的智能网联汽车，依赖大量的智能传感器、算法、云端平台的支撑
            • 这些基础设施和功能单元包含了海量的代码以支撑运作，其中稍有一个环节出现问题，就会影响到整个链条的安全可靠运行
        • c. 法规监管要求
          • I. 汽车网络安全标准研制方面
            • i. 工作模式
              • 以政府引 导、产业推动、标准委员会执行
            • ii. 取得进展
              • 《GB T 40855-2021 电动汽车远 程 服务与管理系统信息安全技术要求及试验方法》
              • 《GB T 40856-2021 车载信息交互系 统信息安全技术要求及试验方法》
              • 《GB T 40857-2021 汽车网关信息安全技术要求及试验方法》
              • 《GB T 40861-2021 汽车信息安全通用技术要求》
          • II. 数据安全方面
            • i. 出台法规
              • I. 《网络安全法》
              • II. 《数据安全法》
              • III. 《个人信息保护法》
            • ii. 问题聚焦
              • 数据采集和处理过程可追溯，可审计
              • 进一步加强中国法律法规的监管要求和个人信息的处理要求
              • 进一步加强对基于密码学的通信安全的研究和监管
    • （3） 组织流程方面
      • 1||| 组织架构变革
        • 汽车电子电气架构向“域集中”、“中央集中”方向发展，电控单元之间的界线逐步模糊化
          • 硬件被合并，软件运行在同一控制单元当中
          • 原来整车厂中很多部门的边界被打破，在向中央集中式组织架构迈进过程中，部门的 边界已经变得非常模糊
        • 软件架构和形态上越来越强调分层解耦、标准化、模块化和开放性
          • 模块具备标准清晰的接口，模块之间可组合扩展，且可由不同的供应商提供
          • 层出不穷的场景会催生出新的应用，这 势必要求软件架构具备足够的开放性和鲁棒性，面向不同的场景要能够有高复用度、高延展性
        • 产业链中各利益相关方都需要从战略出发调整公司组织架构，建立一个自上而下驱动、基于共同战略目标、能协调跨部门合作、平台型的软件组织，打破原来烟囱式的以功能模块划分的组织模式
      • 2||| 汽车软件人才
        • a. 传统整车厂对软件的把控能力需要进一步提高
          • 传统整车厂人才结构以机械和动力为主， 目前各整车厂正积极引入软件工程、人工智 能、车联网、自动驾驶、电子工程等复合型人才，以快速调整现有人才队伍结构，增 加软件工程师的比例，确保企业在向软件转型、产品创新过程中保持竞争力
        • b. 汽车软件人才紧缺的主要原因
          • 汽车电子软件开发属于嵌入式软件的一个分支，行业相对封闭，从业人员来源相对较 窄，人员能力储备不足，高度紧缺
          • 汽车工程师需要跨界 ，传统的汽车电子电气架构工程师和嵌入式软件开发工程师主要 领域是 CAN 总线通信、控制器配电和线束、车辆物理拓扑、动力、底盘、娱乐、AUTOSAR CP 等
          • 软件定义汽车大趋势下，更多的 ICT 能力需要融入，增加了以太 网、TSN、SOME/IP、SOA、 Linux/QNX、 Hypervisor、AUTOSAR AP 等领域技能
          • 来自互联网企业的软件工程师， IT 软件开发虽然能力强，但在汽车电子嵌入式 硬件等领域，缺乏汽车工程和软件技能
          • 行业中缺少既懂软件又懂汽车的人才，尤其是系统架构工程师，汽车软件 工程师处于紧缺的状态
      • 3||| 开发模式变革
        • a. 传统汽车的软件开发采用 V 字形瀑布式开发模式
          • 各开发部分之间 相对独立，更多只是在部分内部展开局部性优化，缺乏系统级平台级的开发全局观，很难做到整体优化
          • 各部分的开发时间都不一致，各部分之间的进度顺序依赖很 容易造成队列效应，一旦出现某个部分开发发生延误时，便会影响整体的开发进度
          • 每个阶段都过于依赖上个阶段成果，导致开发成本较高且周期过长
        • b. 软件定义汽车背景下，汽车软件开发将由传统的瀑布式开发向敏捷开发模式转变
          • 既有利于达到密切的协调合作，最大限度地减少管理成本，同时因其 灵活的工作模式，使开发团队可与用户实现高度互动，采用最低可行性产品的形式快 速满足用户需求，并在使用中不断创新迭代 ，实现持续开发、持续集成、持续交付， 体现软件定义汽车的优势
    • （4） 商业模式方面
      • 1||| 产业分工价值链转移
        • 产业链中各利益相关方分工的变化
      • 2||| 车企传统供应链模式转变
        • a. 传统采购模式
          • 围绕硬件制定组织、流程和工具
        • b. 软件定义汽车时代
          • 电子电气架构正由信号导向向服务导向转变
          • 软硬件的充分解 耦与供应链协同模式的转变
        • c. 整车厂已经开始思考软件的 Maker-or-Buyer 策略、采购策略、质量保障以及组织优化等关键问题
          • 软件价值链的哪些环节应由整车厂自研把控？哪些环节应该交给外部供应商来提供？
          • 整车厂如何与供应商协作以有效保障和把控软件系统的开发成熟度与完成度？
          • 针对软件开发，整车厂如何调整长期合作关系与并购投资规划？如何拓展与软件供应商以及其他伙伴的合作关系？
      • 3||| 行业盈利模式变革
        • a. 传统模式
          • 拼硬件
          • 汽车行业都是通过汽车销售挣钱，整车厂赚的是材料成本和汽车售价的差价
        • b. 软件定义汽车时代
          • 拼软件
          • 整车厂将车辆提供的所有服务在服务注册中 心进行注册，所有用户，包括企业用户、个人用户和生态用户都可以通过服务注册中 心订阅服务
            • 例如通过服务订阅可以让用户的车辆具有语 音控制功能，包括控制车速、灯光开启和亮度、车窗升降、空调温度和风量等
            • 这些功能不需要额外安装硬 件，只需要软件工程师编写代码即可，而软件开发可以在不增加任何成本的情况下进 行不断复制，所以只需要有好的创意，利润空间无上限
          • 服务订阅示例
        • c. 整车厂通过硬件预埋和服务订阅将后市场打造成新的利润增长引擎。整车商业模式由一次性前装收费转变为后市场订阅持续收费
          • 构建有竞争力的盈利模式并真正带来商业价值需要面临的挑战
            • I. 后市场持续变现能力有待进一步挖掘
              • 造车新势力创收潜力大，但难于形成规模。最大的问题是自费选装软件普及率低， 比如，中国市场特斯拉 FSD 的选装率仅有 1%-2%；其次造车新势力的用户基数与 传统整车厂的差距悬殊
              • 传统整车厂拥有着大批品牌簇拥者，这使得传统整车厂的营商环境比新势力更友好。但也正是由于用户黏性的存在，传统整车厂在转型过程中又不得不兼顾到各个年龄段的用户，而开发各年龄段、多层次的用户都能够轻松上手的智能软件也 绝非易事
            • II. 硬件预置与成本压力难平衡
              • 虽然软件决定产品性能，但是硬件决定产品性能的天花板，再强大的功能也要依托硬 件来实现。所以为保证车辆在一段时间内的成长属性，需要预置更多的硬件设备。而 传统整车厂的商业模式很少考虑后续的升级需求，在成本压力巨大的竞争模式下，很 难预留芯片算力、存储空间、冗余模块用于后续升级，基本上都是刚刚好满足当前功 能需求。所以在如何平衡硬件预置与成本压力方面存在挑战
            • III. 软件产品思维转变的挑战
              • 新的商业模式将更多地关注驾乘人员的个性化、体验化的功能需求。这将在产品开发 最前端进行转变，需要更多深谙用户体验的产品经理来根据不同细分消费群体的特征 来设计定义相关的功能需求，而往往这些产品经理通常对汽车的了解较少，设计的功 能往往在落地性方面难度较大
              • 如何构建具有竞争力的商业模式形成大规模持续变现，技术上如何选择可持续演进的 软件架构，以支持未来的附加功能或按需服务 ， 目前还处于雏形阶段
    • （5） 生态协同方面
      • 在新型电子电气架构领域，目前大部分整车厂和供应商短期内都聚焦在平台基础建设，例如新架构的硬件、软件中间件、SOA 架构及原子服务等开发落地。长期来看， 在 SOA 架构及广义的整车操作系统建设初步成熟后，丰富的上层应用生态才是未来价值增长的关键点，拥有巨大的想象空间。而创造出丰富的应用的核心是打造繁荣的开发者生态
      • 汽车应用软件开发者生态的挑战
        • a. 各整车厂之间的标准、接口规范不统一
          • 汽车是一个定制化、非标化程度很高的产品，各整车厂设计的电子电气架构下的软硬 件接口各不相同，并都在开发定义自己的汽车操作系统、服务接口、开发工具链等， 这意味着同一个应用要落地到不同品牌的汽车上可能需要经过大量的开发适配工作， 从而导致应用开发和部署成本很高，一定程度上会影响开发者参与的意愿度
        • b. 单一整车厂的体量和用户基数有限，难以吸引到大量的开发者
          • 单一整车厂的用户数量有限，大部分国内整车厂每年不到200 万辆，小整车厂可能只 有 10 万量不到，再加上前面提到的各车厂的标准、接口都不相同，意味为单次应用开 发及部署开发可触达的用户有限
        • c. 汽车软件开发的专业性要求度高，落地见效周期长
          • 汽车作为安全属性很高的产品，这就需要开发者具备较强的专业知识背景，所开发的 应用要确保不能影响功能安全及信息安全要求，需要经过长时间的测试验证才能部署 到汽车上使用
• 四、 软件定义汽车落地实现
  • 1. 架构升级
    • （1） 软件架构：分层解耦、服务化、API 接口标准化
      • 随着企业向软件定义汽车开发方法的转变，软件架构也需要同步进行升级，引入面向 服务的架构（Service-Oriented Architecture ，简称 SOA）方法论。汽车 SOA 是对 整车智能化的底层能力进行组织。将车端的硬件能力和各种功能服务化 ，这些服务根 据 SOA 标准进行接口设计，基于 SOA 标准协议进行通信。这样，各服务组件之间就 可以相互访问，从而扩展了服务的组合形式
      • SOA服务化架构
      • SOA软件分层架构
      • 架构标准化
        • 分层架构，在原有的整车架构中，引入原子服务层和设备抽象层
          • 设备抽象层负责封装底层的硬件差异，并把硬件层的特性以服务的方式提供接口， 供原子服务层进行调用，硬件的调整不应导致系统软件对外提供的接口发生变化， 使得应用逻辑摆脱底层硬件平台的束缚
          • 原子服务层作为中间层，与平台解耦，对上承接应用服务的调用，对下进行设备 抽象的访问，体现车型差异，并配置化适配，使能上层应用跨车型复用
          • 应用/组合层服务主要负责用户需求逻辑的实现，通过调用原子服务层提供的接口， 组合出千变万化的场景化应用
      • 接口标准化
        • 不同整车厂、Tier1、平台供应商定义同一套服务接口，使得不同整车厂 之间，不同 Tier1之间的软件可以相互调用，大大增加软件的复用性，缩短车辆开发 周期
        • 中国汽车工业协会已经发布了第三版《软件定义汽车原子服 务 API 接口与设备抽象 API 接口参考规范》
    • （2） 通信架构：基于车载以太网的技术应用
      • 随着车辆功能的不断增加，特别是自动驾驶、智能座舱的不断发展，需要传递的信号 已呈爆炸式增长，车辆功能不断升级更新，用户对于 OTA 升级体验提出更高的要求， 传统的 CAN 总线通信的方式已不能满足车辆功能的增长速度，采用基于以太网服务的 通讯方式，可实现功能的灵活重组，有效解决传统面向信号的通信架构中因个别信号 增减/变更，而导致功能相关的所有系统均产生变更的问题
      • 通信架构升级之后 带来的变化
        • 更灵活的沟通机制
        • 更高的带宽，更低的时延
        • 更多的应用场景，易互联易扩展
        • 更快的 OTA 升级速度，更易用的体验
    • （3） 硬件架构：区域接入+算力集中化
      • 分布式电子电气架构严重制约整 车厂响应市场需求的速度，整车厂早已开始储备新型电子电气架构方案，以促进软件定义汽车的快速实现
        • 传统分布式电子电气架构
      • 新型电子电气架构的显著特征是功能（软件）集中化、硬件标准化。通过中央计 算平台/域控制器对控制功能进行统一管理，从而降低硬件冗余和 BOM 成本，减少整 车厂对众多供应商的依赖
        • 域集中式电子电气架构
          • 在域集中式电子电气架构中，将整车电子电气控制功能划分为 N 个功能域，每个功能 域设计一个域控制器，其余控制器均为域内控制器，各域内控制器一般为智能传感器、执行器和传统控制器
        • 跨域集中式电子电气架构
          • 在域集中式电子电气架构中，域控制器只负责一个域的功能集中控制；而在跨域集中 式电子电气架构中，有些域控制器负责两个或两个以上域的功能集中控制，进一步提 升了系统功能集成度
        • 区域接入+中央集中式电子电气架构
          • 中央集中式电子电气架构不再按照功能去部署车内的电子电气系统，而将整车所有功 能域的控制逻辑均集中于中央计算平台，进一步提升了系统功能集成度。原有分布式 和域集中式架构中的 ECU 的控制/计算功能被中央计算平台收编，转变为更加简单的 传感器或执行器
  • 2. 安全升级：构建多层次的整车纵深防御体系
    • （1） 功能安全
      • 随着电子电气架构技术的不断升级，整车越来越多的系统和组件对功能安全产生影 响，为此，功能安全也从部分关键系统开发，向整车各系统全面开发拓展。
      • 同时，由于域控制器、中央计算平台等新架构技术的出现，对功能安全提出了新的技 术挑战，功能安全必须建立针对这些复杂系统及软件的开发和测评手段
    • （2） 预期功能安全
      • 电子电气架构相关的预期功能安全指的是规避由于功能不足、或可合理预见的人员误 用所导致的人身危害
      • 预期功能安全技术属于汽车技术的一部分，对应的标准为 ISO 21448
      • 预期功能安全关键技术点
        • a. 自动驾驶安全准则制定技术
          • 针对自动驾驶已知场景和未知场景下的安全表现， 制定客观量化准则，科学判定自动驾驶的安全水平
        • b. 安全分析技术
          • 过 STPA 等安全分析手段，识别自动驾驶安全相关功能的不足 性能局限及危害触发条件，制定针对性措施，开展功能更新
        • c. 多支柱法测试技术
          • 由仿真测试、定场景测试和真实道路测试组成的自动驾驶预 期功能安全测试体系
        • d. 安全论证技术
          • 基于安全开发、分析、测试等结果，制定预期功能安全档案策 略，通过 GSN 等论证手段，评估自动驾驶安全风险，完成预期功能安全发布
        • e. 安全监控技术
          • 通过车载和远程手段，监测自动驾驶运行过程中的安全表现，识 别安全风险并开展必要的风险控制措施，以确保自动驾驶运行安全
    • （3） 网络安全
      • a. 网联安全
        • 网联接入层主要抵御针对以太网的 DOS、 PING 类型、畸形报文、扫描爆破、欺骗、 木马等网络攻击。
        • 需要具备车云联动机制的主动安全防护能力，可通过云端系统实时 配置防护策略，主要包括接入认证机制、通信保护机制、以太网防火墙机制和入侵检 测与防御（IDPS）机制
      • b. 车内网安全
        • 车辆内网安全主要抵御针对车载 CAN/CAN FD、车载以太网的攻击入侵，包括报文监 听、错误注入、报文重放等攻击。
        • 防护的策略包括：总线入侵检测机制、内网防火墙 机制、功能域隔离机制、总线通信保护机制和诊断安全保护机制
      • c. 关键 ECU 安全
        • 为确保车辆系统或关键数据不被破坏，在车辆关键 ECU 层面需具备安全启动、关键数 据安全存储、系统安全运行的安全能力，并可为应用运行提供权限管理能力
      • d. 服务安全
        • SOA 安全框架需要遵循五个基本原则：机密性、完整性、真实性、授权性和可用性， 通过信息加密、数字签名、密码认证、设计访问控制列表 ACL、DOS 攻击监控等多种 方案及产品实现网络安全，同时保证这些网络信息可被发现、被访问、被通信以及被 监测
        • 在服务发现上，设定信息安全分组隔离机制，使得服务广播消息只发给有需要的 的服务使用者
        • 在服务访问上，为服务提供方设置信息安全访问控制机制，认证并授权服务使用 方发起的服务请求
        • 在服务通信上，根据 SOA 服务实际的业务应用场景决定 SOA 消息应采用的信息 安全传输机制
        • 在服务监测上，设置服务安全监控机制，发现 SOA 服务相关的异常事件及安全响 应处理机制
  • 3. 流程变革：敏捷开发，迭代发布
    • （1） 敏捷开发流程的核心是培养研发人员的协作意识、责任意识、质量意识、学习意识、 创新意识，进而提升整个软件研发团队的研发能力，高效地开发高质量的软件产品
    • （2） 特性开发采用以月为研发周期的迭代开发模式
      • 分为详细设计与评审、特性开 发与代码走读、代码质量检视与评估、测试用例设计与编写、特性功能联调、特性合 入评审等多个子流程
      • 每个子流程有具体的输出件（设计文档、源代码、评审报告、 测试用例、测试报告等）和量化评判体系（设计文档章节完整性、增量代码度量报告、评审意见密度、测试用例覆盖率、缺陷密度等）
      • 确保每一个子流程均按照软件研 发质量要求达成，并对所有文档归档以支持软件质量回溯
    • （3） 版本发布采用以周为发布周期的软件版本快速迭代模式
      • 每周从稳定分支发布版本， 对软件基本功能、新增特性进行充分验证，对已解决的问题进行回归测试，均通过之 后再发布版本
    • （4） 敏捷开发的业务价值
      • 用户体验能以月为单位发布。
      • 漏洞和补丁按周进行快速发布。
      • 软件版本按小时迭代，部件与整车同步集成、自动化验证（7*24h 无人值守）
  • 4. 工具链升级：基于 SOA 的整车服务化开发
    • OA 的总体思路是设计服务模型，将不同的基础服务进行抽取 ，分层解耦定义恰当的API 接口 ，应用调用服务API接口实现业务逻辑。API接口定义独立于实现服务的硬件平台、操作系统和编程语言，确保构建在不同系统中的服务可以以一种统一通用的 方式进行交互
    • 对于汽车行业而言，SOA 是一套新引入的技术，需要一套有效的流程、方法和工具链，三者相辅相成，当前业界还没有一套非常成熟的方法论和工具链，大部分整车厂和 Tier1/Tier2 都处于探索阶段
  • 5. 产业分工升级：合理分工、开放协同
    • 面向未来的智能汽车时代，随着原有产业价值链开始被打破，传统车企纷纷转型，新 生力量奋力崛起，技术进步日新月异，跨界玩家悉数入局，产业竞争的要素和形态正 在悄然变化，一方面驱动着新产业格局的形成，另一方面也催生着新产业生态的出现。智能汽车产业朝着更加多元化、复合化的方向发展，出现诸多不曾涉猎的新技术 领域，开放合作才能实现共赢 ，优势互补才能形成合力
• 五、 软件定义汽车典型应用场景
  • 1. 智能交互应用
    • 结合场景化功能引擎实现一键休憩服务
      • 主可以通过 APP，开启或关闭一键休憩指 令，根据车主的习惯或设置自动调整车椅位置角度、车窗开度、车灯开关颜色亮度、遮阳窗等，不需要手动一一去调整，降低了操作的复杂度，大大提升了用户体验。在具体的实现中，应用开发者通过调用各原子服务 API 来实现不同的场景 APP，提升汽车应用开发的效率。类似的软件定义汽车的典型应用场景还有很多，想象空间很大
  • 2. 用户自定义场景
    • （1） 威马 W6场景编辑
      • 用户只需进入车内，即可直接体验官方预设的九种场景模式，用户也可根据个人用车习惯，通过威马智行 APP，开启自主编程操作， 实现驾驶辅助、车窗、座椅、空调、驾驶模式、音乐、氛围灯等主被动软硬件模块的自由组合和设置，并根据自己的汽车偏好制作不同风格的场景卡
    • （2） 小鹏 P7 语音私人定制
      • 小鹏 P7 可在手机 APP 定制模块中，针对一系列常用的功能设定快捷方式，可以让用户一步一步自由定制输入命令、执行功能、语音回馈等各项步骤，通过简单的组合实现一个专属于用户的一串动作
    • （3） 针对洗车场景设定的私人定制模式
      • 在准备洗车的时候，一句已设定好的 话将会执行提醒天气、关闭车窗、关闭空调、关闭车顶、折叠后视镜、挂 N 档这一系 列动作 ，实现了场景自主编辑与语音指令对场景的控制
    • （4） 联合汽车电子预约智能充电
      • 由于不同驾驶员在不同场景下对于充电的需求不 同，预约智能充电功能可以让驾驶员在进行充电时，根据充电的实际需求和相关信息对比，选择四种模式：经济模式、健康模式、快充模式、正常 模式
  • 3. 智能汽车应用商城
    • 随着智能网联汽车的快速推广，车机端所需要的应用程序开发及管理成为了一个新的 业务增长点，通过建立企业和品牌专用的应用商城，为厂家、合作企业、三方软件的 开发者提供一个方便又高效的应用推广、销售、管理平台，能够有效管理各类应用， 为车主用户提供方便，同时也在一定程度上促进了智能汽车品牌的科技卖点
    • 特斯拉打造了硬件平台（汽车）、超级充电服务（基础服务）、应用软件商店（特斯拉 APP）及娱乐服务应用等，加速软件服务生态付费模式，“类苹果模式”在汽车产业中开始创新发展
  • 4. 智能驾控应用
    • （1） 预测性经济车速规划服务应用场景
      • 借助高精度地图和定位系统，提前获知前方区域路况和交 通信息，以节能与驾驶时间综合最优作为目标，驾驶性和安全性作为约束，利用动态 规划算法规划前方车速曲线。该功能对象为车辆纵向动力学模型，通过控制动力源扭 矩得到最优的车速曲线
    • （2） 预测性续驶里程功能应用场景
      • 充分利用 智能网联车辆可以获取环境和驾驶员信息的优势，全面考虑了实际道路交通环境以及 驾驶员驾驶风格和习惯对续航里程的影响
    • （3） 预测性滑行回收功能应用场景
      • 基于智能网联信息的减速场景驾驶辅助功能。其借由智能网联 系统获取前方道路和车辆信息，在前方有减速需求时通过 HMI 或提示音提醒驾驶员松 开踏板，并规划滑行车速轨迹，使车辆在滑行过程能安全舒适的减速到需求的目标车 速，且同时回收部分动能
  • 5. 智能底盘驾乘新体验
    • （1） 乐趣
      • 1||| 坦克掉头
        • 在装有分布式驱动的汽车底盘上，让车辆近乎原地转向的方式来掉头
      • 2||| 汽车跳舞
        • 在装有主动悬架的汽车上，通过软件控制汽车悬架有节奏的升降，达 到跳舞的效果，观赏感十足
      • 3||| 汽车 90°横移
        • 在机械允许车轮旋转 90°的前提下，通过软件控制 4 个车轮旋转 90° , 实现侧向移动
    • （2） 体验
      • 1||| 个性化体验
        • 在 SOA 和敏捷开发技术支持下，底盘域可根据终端用户习惯提供个 性化的定制服务，满足差异化和个性化体验
      • 2||| 高性能体验
        • 伴随着汽车集中式电子电气架构的逐步成熟、底盘各个系统的紧密 关联，动态响应更加精准和迅速，可提供更优质的高性能驾乘体验
      • 3||| 可成长体验
        • 利用深度学习算法和 OTA 等技术，底盘域系统具备自学习能力并支 持 OTA 终身服务升级，使得底盘域系统具备自学习和可成长的功能体验
      • 4||| 高安全体验
        • 汽车行业各项强标逐渐推出，功能安全 ISO26262、预期功能安全 ISO21448 和信息安全 ISO SAE21434 成为汽车必备的多重安全保障，为底盘域系统提供更高安全的用车体验
  • 6. 基于数据的个性化应用
    • 软件定义的前提是数字化，需要能提前获取相对应的数据。在万物互联的趋势下，可 将车辆数据、用户数据、外联生态数据、交通数据等进行收集，通过 AI 算法进行处 理，建立基于账户的用户画像
  • 7. 衍生更多后市场应用场景
    • 软件定义汽车背景下，基于用户数据、车辆数据、场景数据的出行服务新兴模式也将 获得高速发展 ，通过车辆数据智能化存储及应用可以实现人-车-家生活服务连接 ，车 辆保险理赔等后市场服务 ，及智慧出行共享等带来创新应用场景
    • 随着 V2X 技术的发展，汽车的控制功能不仅限于汽车本身，汽车实现对智能家居如冰 箱、电视、洗衣机、空调等控制，反过来车端部分功能也能被家居控制，形成人-车- 家-可穿戴设备等万物互联的产业生态