《软件定义汽车产业生态创新白皮书》
本文节选自11月10日发布的《软件定义汽车产业生态创新白皮书》，系统的阐述了软件定义汽车的五大挑战，包括：
本白皮书由中国汽车工业协会软件分会提出，软件定义汽车委员会联合各成员单位以及行业企业共同编制。
软件定义汽车是大势所趋，在业界已经形成基本共识。但如何落地，落地过程中需要解决哪些关键问题？是每一个参与企业需要首先面对、认清和解决的难题。
随着智能汽车的逐步推进，汽车的复杂度在持续的提升，造成智能汽车的开发复杂度越来越难以管理。影响或滞缓智能汽车产业升级发展的主要原因有以下四点：
第一：用户体验带来的复杂度提升。随着智能化的发展与普及，用户驾乘体验逐渐从传统的交通工具向第三空间扩展，汽车使用的场景、用户功能等均在大幅度扩展，成百上千的场景、功能组合形成了现在越发复杂的智能汽车体系。
第二：技术进步带来的复杂度提升。
如越来越大的电池能量密度的追求和快充性能的追求带来了严重的电池安全挑战；人工智能、5G 通信、云计算等多种数据驱动汽车向智能化不断进化的同时，也大幅度增加了软硬件开发复杂度。
第三：竞争带来的堆料、堆配置、各种选配等模式导致汽车配置多样性、复杂度快速增长。
第四：监管&法规带来的复杂度提升。智能化、网联化赋予汽车智能、便捷体验的同时，也带来了黑客攻击、数据滥用等严重的安全问题。
对于传统汽车产业链上下游企业而言，复杂度提升的四大原因，到底意味着什么？这些原因对汽车产业的具体影响和挑战是什么？这都将导致未来智能汽车在配置、硬件、外设、软件的种类与数量将分别增加 10 倍以上。
第一：技术架构方面，
当前架构下任何一个部件的增加、修改、更新都会对整车带来影响，以传统通信矩阵为例，当前修改和配置需要 N 周时间。未来电子电气软硬件数增加 10 倍以上，大量软件的引入，那又意味着什么呢？
第二：安全和隐私保护方面
，全量测试时间长、代价高，如果部分测试造成漏测会导致什么后果？尤其是安全漏洞被黑客劫持，那对整车厂的品牌和用户粘性会带来什么样的后果？
第三：组织流程方面，
整车厂如何建立与软件定义汽车开发模式相匹配的组织架构？面对消费者上千种配置组合、上千种体验场景、上万种组合服务和应用，哪些更新推送给所有的用户？哪些推送给限定的用户？
第四：商业模式方面，
面对软件定义汽车对传统汽车供应链与合作模式的颠覆，产业中各方利益如何分配？如何共同做大产业蛋糕？
第五：生态协同方面，
传统汽车供应链是 Tier2->Tier1->整车厂线性模式，但对于软件定义汽车时代，一方面会出现新的玩家，比如互联网公司、ICT 科技公司等，甚至出现个人开发者，另一方面整车厂按照传统的采购和项目模式难以满足消费者对汽车常用常新、千车千面的需求，故各企业将围绕以消费者为中心进行产品创新、研发和供应，传统线性模式将被打破，出现以网状合作的形态。但如何合理分工从而优化整车研发效率和成本，成为行业发展的难题。
面向汽车行业转型发展，需要产业链中各利益相关方共同推动完成。当前，整车厂、Tier1、Tier2、ICT 科技公司等均从不同视角推出软件定义汽车相关技术能力规划和解决方案，技术着力点不一致，行业级技术协同方案尚未形成，如下图所示，当前仍处于行业技术方案促动期。
传统“以整车硬件产品为主销点”的技术能力逐渐转变为“软硬件融合，且以软件产品为主销点”的技术能力，需要在完成整车电子电气架构升级的基础上，依据研发主导程度和软件能力两个维度上进行技术能力规划。
一般会形成四种模式：全栈技术布局；核心领域技术重点突破；与软件企业战略合作；同主流核心 Tier1 深度绑定。
因此，要形成长期清晰的软件技术能力发展规划、相应技术能力和软件生态方案，都需要一定的探索论证周期。
在“软件定义汽车，整车架构升级”的背景下，既有的产品供应方式和技术能力存在严重挑战，需要深刻调整，如何实现与尽可能多的整车厂技术方案对接，需要完成哪些关键技术能力储备，需要一定的探索论证周期。
软件定义汽车如同是“四个轮子的智能手机”在手机端的相关成熟技术能力可直接借鉴，跃跃欲试，和其他相关方存在一定程度认知偏差和技术能力对接偏差，需要一定的探索论证周期。
软件定义汽车刚刚在行业内达成共识，产业链中各利益相关方在软件定义汽车技术能力方面仍处于探索储备期，行业内缺少成功案例，没有成熟经验借鉴，大规模尝试一旦选错技术路径将带来巨大的风险。
因为产业链中各利益相关方基本处于同一起跑线，所以在软件定义汽车探索中会发现很多新技术在消费电子领域成功应用过，但在车辆领域并没有应用过。有的芯片产品规划路线图不满足控制器和整车开发计划；有的操作系统、协议栈、中间件还处于一种不成熟状态；原有的电子电气架构不满足快速响应市场的需求；原有的开发流程和开发工具不满足快速迭代的开发需求。
要解决这些问题，需要整个产业链，包括整车厂、零部件供应商、软件开发商、芯片厂商、工具厂商、ICT 等企业共同努力。
汽车行业自身存在的大量定制化与私有化接口，这种低效、浪费的的传统开发模式却还在持续。
-
软件方面：软件定制化将带来大量的接口适配、驱动适配、反复标定、通信矩阵的反复调整等重复性劳动，端到端软件开发效率低，人力资源浪费严重。在传统汽车时代，这种传统模式可以基本维持，但随着整车智能化加快，软件将呈现指数级的增长，软件开发模式转型将势在必行。
-
硬件方面：硬件定制化导致的结果就是硬件的频繁定制、线束定制、重复的 DV/PV、认证等，使端到端管理复杂度和成本居高不下，频繁的产线调整导致产能浪费，型号的切换导致备件和库存总量的线性增加等。随着汽车智能化的发展，对硬件的要求越来越高，如果延续这种硬件定制模式，那硬件的定制工作量以及由此带来的软件的适配工作量是难以想象的，故这种硬件模式也亟待优化。
汽车生产供应链和制造流程复杂，需要各级的供应商配合参与，若其中有一个供应商环节出现安全隐患，就会影响到最终消费者的安全。如何构建贯穿全流程涉及研发、生产、供应链、销服、消费者等多个环节的整车数字化安全防护体系是智能网联汽车的巨大挑战。
从汽车产业发展方向看，未来以车内网、车际网和车载移动互联网为基础，在 V2X 之间实现智能化交通管理、智能动态信息服务和车辆智能化控制的一体化网络将是大趋势。随着智能汽车产业的发展，汽车行业将安全的范畴从功能安全延伸到网络安全。智能网联汽车网络攻击风险加剧，将对社会和生命造成安全威胁。
汽车行业安全事件频发，整车厂越来越重视汽车网络安全。汽车智能化程度越高，所遭受的安全攻击面越多。在智能化背景下，全球整车厂无一幸免，例如奔驰、宝马、奥迪、大众、丰田、本田、现代等国际一线品牌，均遭受了不同程度的安全攻击。数据安全对智能汽车甚至国家安全都有重要影响，未来不排除将进一步出台更多政策规范。
智能网联汽车的产品形态决定了攻击面众多、物理暴露面巨大。仅无线接口安全就涉及到 WIFI 安全、蓝牙安全、蜂窝通信安全、GNSS 安全、TPMS 安全、调频安全等方面。在可接触的范围内，又有 NFC 安全、USB 安全、OBD 安全等需要考虑的暴露面。
-
车内网络目前大多采用 CAN/CAN FD 协议进行通讯，而 CAN/CAN FD 的字节长
度有限、仲裁机制、无源地址域和无认证域等问题有潜在的网络安全隐患；
-
ECU 硬件可能存在可读丝印和暴露的调试口，容易遭受防逆向分析等安全隐患；
-
ECU 固件刷写机制未进行信息安全保护，可能导致 ECU 固件或其配置数据被篡改；
-
ECU 中的敏感数据（如调校数据、虚拟钥匙数据、地图数据、配置数据等）的存储、访问过程中，若未采取加密存储和访问控制等防护措施，则可能导致数据被篡改或泄露，被篡改的数据可能导致系统功能偏离预期，甚至带来其他信息安全方面的隐患。
漏洞和缺陷多，分布在不同器件上，防不胜防。造成漏洞分布广，数量多，隐藏性强的原因是由于随着智能网联车技术架构的迭代发展，软件定义汽车概念的兴起，汽车正在软件层面被重构。
智能汽车的发展，是由智能汽车承载的应用功能发展来作为驱动力的，而且离不开电子电气架构的发展。在未来智能汽车控制器将会承载越来越多的功能，而且不同的电子电气架构下呈现的信息安全状态也有所不同，同时车载控制器复杂度越来越高，逐渐趋同于 ICT 行业的高性能计算机，也可能会带来新的信息安全威胁和攻击手段。
以智能驾驶技术为核心驱动力的智能网联汽车依赖大量的智能传感器、算法、云端平台的支撑。这些基础设施和功能单元包含了海量的代码以支撑运作，其中稍有一个环节出现问题，就会影响到整个链条的安全可靠运行。所以软件大规模的进入车辆生产制造行业，带来了机遇，同时也带来了极大的安全挑战。
国内近几年开始重视智能汽车网络安全、数据安全、OTA 升级安全问题，在以政府引导、产业推动、标准委员会执行的模式下积极开展相关汽车安全标准制定工作。在汽车网络安全标准研制方面已取得一定进展，如下图所示，全国汽车标准化技术委员会（SAC/TC114）2021 年 10 月 11 日已发布《GB T 40855-2021 电动汽车远 程服务与管理系统信息安全技术要求及试验方法》、《GB T 40856-2021 车载信息交互系统信息安全技术要求及试验方法》、《GB T 40857-2021 汽车网关信息安全技术要求及试验方法》和《GB T 40861-2021 汽车信息安全通用技术要求》四项国标，并于2022 年 5 月 1 日开始实施，同时启动国际汽车网络 安全、升级管理的标准法规R155、R156 的国标转化工作。
在数据安全方面，备受消费者和国家层面的关注。一方面，关于数据安全的法规相继
出台，从《网络安全法》到《数据安全法》到《个人信息保护法》，进一步规范汽车数
据安全管理和网络安全自查制度。另一方面，数据安全能力进一步聚焦，具体体现
-
-
进一步加强中国法律法规的监管要求和个人信息的处理要求；
-
为支撑 2021 年 10 月 1 日发布的《汽车数据安全管理若干规定（试行）》落地实施，全国信息安全标准化技术委员会于 10 月 8 日发布技术文件 TC260-001《汽车采集数据处理安全指南》，技术文件细化了部分《规定》条款中关于汽车数据传输、存储和出境等方面的要求，同时为遵循《规定》中的部分原则给出了指引。其中汽车采集数据是通过汽车传感设备、控制单元采集的数据，以及对其进行加工后产生的数据；不包括通过其他网络传输到汽车进行处理的数据，例如手机等车外设备采集的数据、汽车数据处理者通过销售合同等线下方式收集的个人信息等。
技术文件明确了汽车采集数据分为车外数据、座舱数据、运行数据和位置轨迹数据，
-
技术文件对车外数据，围绕车外个人信息的匿名化处理、数据的最长存储时间、数据出境等方面提出要求；
-
对座舱数据，围绕数据向车外传输和数据出境等方面提出要求；
-
对位置轨迹数据，围绕数据的最长存储时间和数据出境等方面提出了要求。
同时，技术文件明确提出汽车制造商应对其生产的整车数据安全负责，除约束和监督零部件供应商处理汽车采集数据的行为外，还应将汽车采集数据向外传输的完整情况对用户披露。
构建整车级的安全能力和机制，确保智能汽车真正让消费者放心、安心成为发展的关键。而传统功能车时代，汽车处于孤立单元，整车厂具有很强的功能安全保障机制，但基本未涉及网络安全和隐私保护，也没有相关应对经验。智能汽车时代亟需构筑功能安全、网络安全、隐私保护全方位防御护城河。
组织架构决定了产品架构，想要什么样的系统就要搭建什么样的团队。目前整车厂组织架构示意图如下所示。整车研发团队主体是研发总部，同时在国内外设置分支机构。研发总部的机构划分有两个维度，一个维度是车型，根据车型划分为乘用车、商用车、客车、新能源车等车型开发部门；另一个维度是车辆功能模块，根据车辆功能划分为电子电气、发动机、变速箱、车身等总成开发部门，其中软件开发只是隶属于电子电气部门之下的一个专业模块。在软件开发专业模块下，发动机电控系统、变速箱电控系统、车身电控系统等控制单元是由不同专业团队独立开发的。
随着软件定义汽车时代到来，汽车电子电气架构向“域集中”、“中央集中”方向发展，电控单元之间的界线逐步模糊化。硬件被合并，软件运行在同一控制单元当中。原来整车厂中很多部门的边界被打破，在向中央集中式组织架构迈进过程中，部门的边界已经变得非常模糊。
传统的整车功能软件是整体性、系统级的，在软件定义汽车趋势下，软件架构和形态上越来越强调分层解耦、标准化、模块化和开放性。模块具备标准清晰的接口，模块之间可组合扩展，且可由不同的供应商提供。层出不穷的场景会催生出新的应用，这势必要求软件架构具备足够的开放性和鲁棒性，面向不同的场景要能够有高复用度、高延展性。中央计算平台/域控制器通常采用面向服务的软件架构进行部署，下图为面向服务的软件架构示意图。
为此，产业链中各利益相关方都需要从战略出发调整公司组织架构，建立一个自上而下驱动、基于共同战略目标、能协调跨部门合作、平台型的软件组织，打破原来烟囱式的以功能模块划分的组织模式。
在组织机构变革过程中，决策层战略上的投入决心与定力起着至关重要的作用，如果决策层对软件定义汽车发展趋势缺乏判断，那么在内部变革碰到阻力时，就会碰到很多困难，结果可能是半途而废。
在过去的整车开发模式中，整车厂主要负责产品的功能需求定义与验收，供应商负责根据整车厂释放的需求规范进行软硬件开发与验证，并交付给整车厂，在这个过程中整车厂很少参与零部件产品的实际开发过程，从而导致整车厂现有研发团队相对缺乏软件开发能力。
在中央/域集中电子电气架构下，软件架构的复杂度大大提升。不同功能域的软件模型或代码如何集成到单一的 SoC 或 MCU 上，并且进行合理的算力分配与优化，融合后的集成测试与验证等都是汽车软件开发人员面临的技术挑战。
随着 SoC 等芯片技术的引入，许多 IT 技术领域的软件技术将应用到汽车中，例如操作系统、SOA 中间件、AI 技术及复杂的以太网通讯协议等等，这些都对整车厂和供应商的软件开发能力都提出了更高的要求。
传统整车厂人才结构以机械和动力为主，目前各整车厂正积极引入软件工程、人工智能、车联网、自动驾驶、电子工程等复合型人才，以快速调整现有人才队伍结构，增加软件工程师的比例，确保企业在向软件转型、产品创新过程中保持竞争力。
汽车电子软件开发属于嵌入式软件的一个分支，行业相对封闭，从业人员来源相对较窄，人员能力储备不足，高度紧缺。
汽车工程师需要跨界，传统的汽车电子电气架构工程师和嵌入式软件开发工程师主要领域是 CAN 总线通信、控制器配电和线束、车辆物理拓扑、动力、底盘、娱乐、AUTOSAR CP 等，而软件定义汽车大趋势下，更多的 ICT 能力需要融入，增加了以太网、TSN、SOME/IP、SOA、Linux/QNX、Hypervisor、AUTOSAR AP 等领域技能。而来自互联网企业的软件工程师，IT 软件开发虽然能力强，但在汽车电子嵌入式硬件等领域，缺乏汽车工程和软件技能。
综上所述，行业中缺少既懂软件又懂汽车的人才，尤其是系统架构工程师，汽车软件工程师处于紧缺的状态。因此，很难通过短时间集中一大批的软件人才形成成熟的软件开发团队。
传统汽车的软件开发采用 V 字形瀑布式开发模式，如下图所示。由于各开发部分之间相对独立，更多只是在部分内部展开局部性优化，缺乏系统级平台级的开发全局观，很难做到整体优化。同时各部分的开发时间都不一致，各部分之间的进度顺序依赖很容易造成队列效应，一旦出现某个部分开发发生延误时，便会影响整体的开发进度。每个阶段都过于依赖上个阶段成果，导致开发成本较高且周期过长，而这些都是与“软件定义汽车”要求整车厂必须缩短产品上市周期、产品基于消费者需求、支持不断的迭代、对市场需求迅速响应等相矛盾。
在软件定义汽车背景下，汽车软件开发将由传统的瀑布式开发向敏捷开发模式转变。敏捷式开发模式既有利于达到密切的协调合作，最大限度地减少管理成本，同时因其灵活的工作模式，使开发团队可与用户实现高度互动，采用最低可行性产品的形式快速满足用户需求，并在使用中不断创新迭代，实现持续开发、持续集成、持续交付，体现软件定义汽车的优势。主要体现如下：
传统控制器的开发，遵循 V 型开发流程，以整车厂的需求为输入，考虑信息安全和功能安全，严格执行设计、实现、验证的完整流程，最终也以控制器为对象完成需求的验收，该流程的执行有利于保障需求的完整实现。同时，整个流程也有质保、流程、售后等部门参与其中进行评审和审核，以此形成良好的质量管理和质量保证体系。但整个流程相对封闭，不符合软件快速迭代的开放性和扩展性要求。
传统汽车软件的开发场景明确，软件与硬件紧密耦合，对于嵌入式软件的交付，并没有明确的“软件交付”的概念，软件随着控制器硬件一起交付。从技术层面，应用软件与基础软件一起集成和固化，有明确统一的释放节点。
随着软件定义汽车时代的到来，“软硬分离，软软分离”逐渐成为了主旋律，嵌入式软件从依附于硬件的一堆“代码”真正脱胎换骨为独立可售卖的产品；且这项产品可以在整个车辆的生命周期内持续产生价值。从嵌入式软件开发和验证的技术层面，这样的趋势使得软件要能够快速迭代，持续更新持续交付。
在传统控制器开发中，在项目前期形成相对完备的系统架构和软件架构，再向下分解到软件组件，经由详细设计到达软件开发。这样的开发模式适合控制器的产品形态，依赖成熟技术的完整积累。
面向开放架构/持续交付的软件特性，在项目管理上，敏捷成为了关键词，随着软件交付不再是统一固定的交付节点，软件模块在整个车辆生命周期都有新增的机会：模块化软件具备单独交付的条件和场景，随之而来的是软件的设计/开发/测试/验证的节点也随之迭代起来，变化和持续交付是常态，这对整体的软件项目管理提出了更高的要求。
综上，汽车软件开发模式由传统的瀑布式开发向敏捷开发模式的变革，为软件定义汽车落地面带来巨大挑战。
软件定义汽车对产业链分工产生了颠覆性的改变，各利益相关方的分工变化如下图所示：
大部分整车厂的职责是定义整车电子电气配置特性，描述车型特性及功能，明确用户明显可见的汽车特征，比如“电动天窗”、 “全景天窗”等能够被驾驶员或乘客所应用的功能，“防抱死系统 ABS”或“车道偏离报警 LDW”等用户能够感受到的增加汽车安全的特性。
传统模式下，整车厂协调各 Tier1 开发产品，装配成试验车，并通过一系列整车试验完成产品认证，变更周期长。这种完全依赖 Tier1 的方式存在着执行不灵活、业务效率低、数据碎片化等弊端，不满足功能迭代快速上市的需求。
各个整车厂在新型电子电气架构开发过程中，希望自上而下定义需求、功能和标准。在定义整车电子电气配置特性时，需要讲好用户故事（User Story），明确作为一个<角色>, 想要<活动>, 以便于<取得商业价值>。并在此基础上完成用例（Use Case）设计，复杂的系统设计和软件设计，从而形成各电控系统的硬件需求和软件需求，再分软件、硬件单独采购。当前电子电气架构实现方式一般有两种，一种方式是与基础平台厂家建立合作，另外一种方式是自主研发、垂直整合。两种方式都将导致供应关系发生根本性变化，原有传统供应链体系变革存在阻力。
整车厂、Tier1 和 Tier2 各司其职的价值链将被进一步打破，Tier1 甚至 Tier2 将深度参与整车厂主导的复杂系统设计和软件设计，ICT 科技公司、互联网公司、车载软件公司等的涌入带动供应链管理扁平化，产业链的各利益相关方还没有明确边界。软件定义汽车总体规划，SOA 顶层设计，整车厂应该负责哪一部分？Tier1 应该负责哪一部分？这些都是摆在整车厂面前的难题，如果全部自己做会耗费大量精力和财力，全部交给 Tier1 厂家又很难形成产品差异化，如何进行业务分工，厘清整车厂与 Tier1 厂家边界是目前面临的挑战。
整车厂传统采购模式主要围绕硬件制定组织、流程和工具，而面向当前及未来软件定义汽车所要求的电子电气架构正由信号导向向服务导向转变，并带来软硬件的充分解耦与供应链协同模式的转变。整车厂已经开始思考软件的 Maker-or-Buyer 策略、采购策略、质量保障以及组织优化等关键问题，比如：
-
软件价值链的哪些环节应由整车厂自研把控？哪些环节应该交给外部供应商来提供？
-
整车厂如何与供应商协作以有效保障和把控软件系统的开发成熟度与完成度？
-
针对软件开发，整车厂如何调整长期合作关系与并购投资规划？如何拓展与软件供应商以及其他伙伴的合作关系？
传统模式下汽车行业都是通过汽车销售挣钱，用户花钱买到的也是车辆本身，例如发动机、变速箱、底盘、驾驶室等，整车厂赚的是材料成本和汽车售价的差价。现在汽车硬件越来越同质化，配件行业越来越透明，整车厂利润越来越薄。
在软件定义汽车时代，不拼硬件拼软件。整车厂将车辆提供的所有服务在服务注册中心进行注册，所有用户，包括企业用户、个人用户和生态用户都可以通过服务注册中心订阅服务。服务订阅示例如下图所示。例如通过服务订阅可以让用户的车辆具有语音控制功能，包括控制车速、灯光开启和亮度、车窗升降、空调温度和风量等等，语音控制服务可以一次性付费购买，也可以每月付费租用。这些功能不需要额外安装硬件，只需要软件工程师编写代码即可，而软件开发可以在不增加任何成本的情况下进行不断复制，所以只需要有好的创意，利润空间无上限。
整车厂通过硬件预埋和服务订阅将后市场打造成新的利润增长引擎。越来越多的整车厂将以接近成本价的价格销售汽车，并主要通过软件为用户提供附加价值，这不仅会降低消费者的购车成本，更会让用户享受到万物互联的实质便利。整车商业模式由一次性前装收费转变为后市场订阅持续收费，构建有竞争力的盈利模式并真正带来商业价值是很大的挑战，挑战主要体现在：
软件落地应用后，复制成本微乎其微，软件的盈利规模完全基于目前软件载体（车）的保有量和选装软件的用户占比。然而后市场持续变现能力还有待进一步挖掘。
-
造车新势力创收潜力大，但难于形成规模。最大的问题是自费选装软件普及率低，比如，中国市场特斯拉 FSD 的选装率仅有 1%-2%；其次造车新势力的用户基数与传统整车厂的差距悬殊。
-
传统整车厂拥有着大批品牌簇拥者，这使得传统整车厂的营商环境比新势力更友好。但也正是由于用户黏性的存在，传统整车厂在转型过程中又不得不兼顾到各个年龄段的用户，而开发各年龄段、多层次的用户都能够轻松上手的智能软件也绝非易事。
虽然软件决定产品性能，但是硬件决定产品性能的天花板，再强大的功能也要依托硬件来实现。所以为保证车辆在一段时间内的成长属性，需要预置更多的硬件设备。而传统整车厂的商业模式很少考虑后续的升级需求，在成本压力巨大的竞争模式下，很难预留芯片算力、存储空间、冗余模块用于后续升级，基本上都是刚刚好满足当前功能需求。所以在如何平衡硬件预置与成本压力方面存在挑战。
新的商业模式将更多地关注驾乘人员的个性化、体验化的功能需求。这将在产品开发最前端进行转变，需要更多深谙用户体验的产品经理来根据不同细分消费群体的特征来设计定义相关的功能需求，而往往这些产品经理通常对汽车的了解较少，设计的功能往往在落地性方面难度较大。
如何构建具有竞争力的商业模式形成大规模持续变现，技术上如何选择可持续演进的软件架构，以支持未来的附加功能或按需服务，目前还处于雏形阶段。
在新型电子电气架构领域，目前大部分整车厂和供应商短期内都聚焦在平台基础建设，例如新架构的硬件、软件中间件、SOA 架构及原子服务等开发落地。长期来看，在 SOA 架构及广义的整车操作系统建设初步成熟后，丰富的上层应用生态才是未来价值增长的关键点，拥有巨大的想象空间。而创造出丰富的应用的核心是打造繁荣的开发者生态，以智能手机行业在中国的开发者生态数据为例，详见下表。
部分整车厂和零部件供应商已经开始布局并建设汽车应用软件的开发者生态，但是相比于智能手机行业，汽车应用软件开发者生态的挑战更大，主要体现如下：
汽车是一个定制化、非标化程度很高的产品，各整车厂设计的电子电气架构下的软硬件接口各不相同，并都在开发定义自己的汽车操作系统、服务接口、开发工具链等，这意味着同一个应用要落地到不同品牌的汽车上可能需要经过大量的开发适配工作，从而导致应用开发和部署成本很高，一定程度上会影响开发者参与的意愿度。
第二：单一整车厂的体量和用户基数有限，难以吸引到大量的开发者
单一整车厂的用户数量有限，大部分国内整车厂每年不到 200 万辆，小整车厂可能只有 10 万量不到，再加上前面提到的各车厂的标准、接口都不相同，意味为单次应用开发及部署开发可触达的用户有限。
第三：汽车软件开发的专业性要求度高，落地见效周期长
汽车作为安全属性很高的产品，这就需要开发者具备较强的专业知识背景，所开发的应用要确保不能影响功能安全及信息安全要求，需要经过长时间的测试验证才能部署到汽车上使用。
软件定义汽车委员会（原“软件定义汽车工作组”，简称“SDV”）隶属于中国汽车工业协会软件分会，成立于 2020 年 12 月 21 日，其目标是协同整车厂、零部件供应商、汽车软件供应商等企业单位，共同定义智能汽车软硬件标准化接口，降低智能汽车研发复杂度，加速智能汽车创新发展。自成立至今，在各成员单位的协作下，已经面向业界公开发布了《软件定义汽车原子服务和设备抽象 API 接口》第三版参考规范。
文章来源汽车ECU开发
当前暂无评论，小编等你评论哦！
