《汽车软件升级通用技术要求编制说明.docx》由会员分享，可在线阅读，更多相关《汽车软件升级通用技术要求编制说明.docx（23页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、汽车软件升级通用技术要求（征求意见稿）编制说明汽车软件升级通用技术要求（征求意见稿）编制说明一工作简况（一）任务来源根据国家标准化管理委员会关于下达包装机械平安要求等31项强制性国家标准制 修订计划及相关标准外文版计划的通知（国标委发202127号）中工程编号20214423- Q-339的强制性国家标准制定工程，制定强制性国家标准汽车软件升级通用技术要求。（二）主要工作过程受工业和信息化部委托,汽标委智能网联汽车分标委根据单位申请情况成立标准起草项 目组，确定中国汽车技术研究中心和工业和信息化部计算机与微电子开展研究中心 （中国软件评测中心）为牵头单位，并在此基础上明确了任务和分工，积极开展
2、标准的预研、 起草及征求意见等工作。自标准制定工作启动以来，牵头单位屡次组织工程组成员单位召开工程组会议，分析了 联合国等国际标准法规组织的汽车软件升级标准法规现状，讨论确定了适应中国产业开展现 状的汽车软件升级的技术要求并编写了标准草案，最终完成了标准的征求意见稿。2018年12月启动标准预研，成立工程组，召开第一次会议。2019年1月9月研究国内外标准化成果和技术开展现状，初步确定标准名称、标准 范围及标准框架。2019年9月11月持续完善标准框架，并形成第一版草案。2019年112020年8月 形成第二版草案，并面向工程组征求意见。2020年8月2021年1月 持续讨论工程组成员意见，并
3、完善标准草案。2021年3月4月根据行业管理需求和主管部门要求，将原推荐性国家标准工程调整 为强制性国家标准工程。2021年4月9月组织屡次封闭写稿和专题研讨会议，持续完善标准草案。2021年9月11月 组织行业开展车辆要求和试验方案标准草案验证试验工作。2021年12月2022年1月 组织行也开展软件升级管理体系试运行工作。2022年3月在信息平安标准工作组进行征集意见，收集反应意见共计256条，并召开 意见协调会，其中63条采纳，105条不采纳，88条局部采纳。并根据意见反应修改形成公 开征求意见稿和编制说明。1 .工程组第一次会议汽车软件升级通用技术要求标准工程组第一次会议于2018年1
4、2月19日在北京召开， 正式启动标准制定工作。会议就标准的制定背景、范围、框架、技术现状进行了详细的讨论， 并梳理了 14项专项问题。会议明确：该标准以推荐性国家标准进行立项；该标准应该规范 所有技术方案的软件升级方式，不只针对0TA方案；将参考联合国正在制定的软件升级标（a）识别需软件升级的目标车辆；（b）检测目标车辆最新配置与软件升级的兼容性。17 .条款4. 3. 5描述车型所有软件升级的文件：a）软件升级的目的；b）软件升级可能影响的车辆系统或功能；c） b）中系统或功能是否与准入或认证有关；d）对于c）中与准入或认证有关的系统或功能，软件升级是否影响其准入或认证 的符合性；e）软件升
5、级是否影响系统的任何准入或认证相关参数；f）是否获得软件升级批准；g）执行软件升级的方法和先决条件；h）确认软件升级将平安可靠地进行；i）确认软件升级已经成功通过验证和确认程序。说明：车辆制造商应以车型为单元记录描述该车型所有软件升级的文件。关于b）,目的是让车辆制造商描述软件升级的目标系统或功能，例如制动系统、转向系 统和可能受影响的任何其他系统或功能。关于d）,这要求制造商记录和条款中描述的过程输出。决策的理由/推理 过程应与结果一起记录。关于e）,此要求应考虑受影响的型式试验，以及软件升级是否可能影响或改变该试验 的结果。决策的理由/推理过程应与结果一起记录。关于h）,所提供的信息应详细
6、说明为何条款g）中的条件会保障软件升级平安执行以及 如何满足这些条件。关于i）,验证和确认程序目的用于保障升级包和软件升级过程经过充分测试，确保软 件升级过程可以平安进行。可提供的文件/证据例如：应通过展示用于记录信息的过程来提供证据。如果过程已经被使用，那么可以展示过程输 出（结果文档）。关于g）,车辆制造商可使用软件升级的发布说明来满足此要求。发布说明应包含（但 不限于）以下信息：（i）定义可平安执行软件升级的先决条件；（ii）在安装升级包之前，需要车辆用户/技术人员（如有必要）采取的额外措施。关于i）,用于确保软件升级经过验证和确认程序后能到达车辆制造商预设的平安水平, 以及相关记录。1
7、8 .条款应具备保护升级包的过程，合理地防止其在执行前被篡改。说明：该要求是确保所推送升级包的完整性和真实性。结果应该是，车辆制造商应能够证明其 有适当的过程来控制向车辆推送哪些升级包，并确保只向车辆推送和有效的升级包。这 可能包括保证供应商提供的保障软件升级平安的过程。“篡改”是指未经授权对升级包的软件代码进行更改或干扰。“合理”是指车辆制造商所采用的过程足以应对威胁。可提供的文件/证据例如：信息平安管理体系(CSMS)可以用来支撑这一要求。车辆制造商应该证明其如何到达要 求。信息平安相关标准可以作为参考。车辆制造商的过程演示可作为证据。这可能包括对软件升级在下载和执行中任何阶段的 完整性检
8、验机制的说明。应提供真实性验证来证明源升级包与发送到车辆的升级包是一致 的。19 .条款4. 4. 2应保护软件升级过程，合理地防止其受到损害，包括软件升级推送系统。说明：该要求针对推送软件升级的过程，确保推送过程免受未授权的损害。结果应该是，车辆 制造商应能够证明其有适当的过程来确保升级机制不会被操纵用于提供未经授权的升级。“软件升级推送系统”是指为推送升级包而建立的系统，应在建立的过程中从设计的角 度保证信息平安。可提供的文件/证据例如：信息平安管理体系(CSMS)可以用来支撑这一要求。车辆制造商应该证明其如何到达要 求。信息平安相关标准可以作为参考。车辆制造商应演示应用于软件升级过程中的
9、信息平安保障。20 .条款4.4. 3应确保验证和确认车辆软件的功能和代码的过程是适当的。说明：车辆制造商应确保过程到位，使得仅有正确测试过的升级包才能发送到车辆。目的在于 最大限度地减少升级包中的缺陷(bug)。该要求与条款i)相联系。本条款需要检查 过程，第4. 3. 5条款需要文档说明验证与确认过程已应用于升级包。“适当”是指满足合理期望的水平。可提供的文件/证据例如：车辆制造商能够基于声明和证据来提供论据，证明其采用的过程是适当的。21 .条款4.4. 4应具备处理软件升级突发事件的应急管理机制。说明：针对软件升级过程中可能突然发生的意外事件（例如升级中断或失败，以及升级过程中 因车辆
10、或人为因素导致的意外事件），车辆制造商应具备应急管理机制用于处理相应事件。可提供的文件/证据例如：企业针对软件升级的应急管理方案。22 .条款4. 5.1假设在线升级是在车辆行驶过程中进行，车辆制造商应证明其采用了过程和 程序以确保该在线升级不会影响车辆平安。说明：车辆制造商应对在驾驶过程中进行的软件升级进行平安评估，保障在线升级不会影响车 辆平安。这些过程的产出物应按照4. 3. 5条款g）和h）所述进行记录。可提供的文件/证据例如：车辆制造商提供相应的判定过程和标准等信息。23 .条款4. 5. 2当在线升级需要特定的技能或复杂操作时，车辆制造商应证明其采用了过 程和程序以确保只有在专业人
11、员在场或执行该操作的情况下才能进行在线升级。说明：车辆制造商应建立过程确保车辆用户不需要做任何需要技术或复杂的事情来启动或完 成软件升级。当软件升级可能需要复杂操作时，需要有一个过程来确保只有当具备合适技能 或训练有素的人员在场或者在远程执行时控制该过程时才进行这种软件升级。该过程的产出 物应按照4. 3. 5条款g）和h）所述进行记录。24 .条款应保护升级包的真实性和完整性，合理地防止其受到损害和防止无效软件升级。说明：要求在车辆上实施有效的真实性与完整性保护机制，以确保仅有效的升级包可被下载和 执行，真实性和完整性应该由车辆进行有效验证。同时应满足4. 4.1和4. 4. 2条款中描述的
12、 过程要求，确保端到端平安（即升级包的创立、推送到执行过程的平安）。“合理地”是指基于当前的预防措施到达可预见的保护水平。可提供的文件例如：车辆制造商应提供相关保护机制的详细方案，以确保在车辆上仅执行成功通过真实性和 完整性校验的升级包。信息平安相关标准可以作为参考。25 .条款当车辆存储软件识别码时，车辆应具备更新软件识别码的能力，每个软件 识别码应能通过使用电子通信接口，至少通过标准接口（如OBD端口），以标准化的方式 易于读取。说明：如果软件识别码在车辆上存储时，软件识别码应具备更新机制，且便于从车辆读取。可提供的文件例如：可参考的标准/法规：(a) GB/T 40822道路车辆 统一的
13、诊断服务；(b)道路车辆 车辆和外部设备之间排放相关诊断的通信；.条款5. 1.3当车辆未存储软件识别码时，车辆应具备更新软件版本的能力，与准入或 认证相关系统的软件版本应能通过使用电子通信接口，至少通过标准接口(如0BD端口), 以标准化的方式易于读取。说明：如果软件识别码未在车辆上存储，那么应将与准入或认证相关的所有软件版本存储在车辆 上，且具备更新机制，并便于从车端读取，并声明与准入或认证相关系统的相关性。可提供的文件例如：可参考的标准/法规：(a) GB/T 40822道路车辆统一的诊断服务；(b)道路车辆 车辆和外部设备之间排放相关诊断的通信；.条款5. 1.4应保护车辆上的软件识别
14、码和/或软件版本免受篡改。说明：该要求涉及软件识别码和/或软件版本的平安性，对于车辆存储软件识别码的，应同时 保护软件识别码和软件版本，对于车辆未存储软件识别码的，应保护软件版本。软件识别码 和/或软件版本只有授权方可以更新,且仅当在车辆上执行相关软件升级时才会发生此情况。 进行准入或认证时，车辆制造商对所采用的防止车辆软件识别码和/或软件版本免受篡改的 方法应采用机密方式提供。可提供的文件例如：车辆制造商可以描述软件识别码和/或软件版本的存储位置或存储方式，以及采取了哪 些措施来保护其免受篡改。26 .条款5. 2.1在执行软件升级前，应告知车辆用户有关软件升级的信息，至少应包括： a)目的
15、(例如，软件升级的重要性，以及是否与召回 平安等有关)； b) 对于车辆功能的任何更改；C)完成软件升级的预期时间；d)执行软件升级期间任何可能无法使用的车辆功能；e)可能帮助车辆用户平安执行软件升级的任何说明。说明：该要求与4. 2. 9条款中要求的过程相关，该要求与具备在线升级功能的车型相关。目的 是车辆用户在执行软件升级前被告知，并获得决定是否执行软件升级所需的所有信息。如果 一组升级包具有相同内容，可以用一个告知信息覆盖整组升级包。如果为车辆用户提供了软件升级的一次性授权选项，并且选择了该选项，那么不必每次软 件升级都被告知。车辆制造商应证明如何完善地管理此授权，以确保当车辆转移给新的
16、车辆 用户时，新用户能够更改他们的授权。可提供的文件例如：车辆制造商可以为每次软件升级提供发布说明，说明的详细信息符合本条款要求。车辆 制造商应说明如何向车辆用户提供这些信息，可能包括车辆用户如何被告知的说明。27 .条款在执行软件升级前，应得到车辆用户确实认。说明：该要求与进行在线升级的车型相关，确认方式可根据车型情况而定。可提供的文件例如：车辆制造商可以为每次软件升级提供发布说明。车辆制造商应说明如何得到车辆用户的 确认。28 .条款在执行软件升级前，应确保车辆满足先决条件。说明：该要求与进行在线升级的车型相关。车辆制造商应定义软件升级要满足的先决条件，并 确认每当软件升级开始时，这些条件
17、都得到满足。可提供的文件例如：车辆制造商可以为每次软件升级提供发布说明。车辆制造商应为每次软件升级提供所定 义的先决条件及定义方法的说明。29 .条款5. 2. 4在执行软件升级前，应确保车辆有足够电量（包括可能恢复到以前版本或 使车辆进入平安状态所需的电量）完成软件升级。说明：该条款目的是保障车辆具备完成软件升级所需的电量，且具备在升级失败后恢复到以前 版木/使车辆进入平安状态所需的电量。该要求不限制技术路线，例如电量检测、电压检测 等。可提供的文件例如：车辆制造商可以为每次软件升级提供发布说明。车辆制造商应提供所使用电量保障措施 的说明文件。30 .条款5. 2. 5假设执行软件升级可能影
18、响车辆平安，在执行软件升级中，应通过技术手段 确保车辆平安。说明：本条款的目的是要求车辆制造商对执行软件升级是否影响车辆平安进行评估和识别，并 通过技术手段确保车辆平安。可能影响车辆平安的软件升级工程的例如：a）升级驻车相关控制器时，车辆驻车功能可能失效，导致在斜坡出现溜坡；b）升级车门相关控制器时，车门功能可能失效，导致车内人员被困。可提供的文件例如：车辆制造商应说明哪些软件升级工程可能影响车辆平安。对于影响车辆平安的软件升级 工程，还应说明做了哪些技术手段进行了保护使车辆保持平安。31 .条款5. 2. 6假设执行软件升级可能影响驾驶平安，在执行软件升级中，至少应满足：a）确保车辆不能被驾
19、驶；b）确保任何影响成功执行软件升级或影响车辆平安的车辆功能不能被使用。说明：本条款的目的是要求车辆制造商对执行软件升级是否影响驾驶平安进行评估和识别，对 于影响驾驶平安的软件升级工程，应采用技术手段确保车辆不能被驾驶，同时为了保障车辆 平安和软件升级成功执行，还应限制局部车辆功能的使用。可能影响驾驶平安的软件升级项的例如：a）升级制动系统时，车辆制动系统可能不可用，导致行驶过程中无法制动；b）升级转向系统时，车辆转向系统可能不可用，导致行驶过程中无法转向；可提供的文件例如：车辆制造商应说明哪些软件升级工程可能影响驾驶平安。对于影响驾驶平安的软件升级 工程，还应说明限制了哪些车辆功能用于保障车
20、辆平安和软件升级成功执行。32 .条款在执行软件升级中，不应禁止车辆用户从车内解除车门锁止状态。说明：本条款目的是要求车辆在执行软件升级的过程中，至少保障车辆用户可以从车内解除车 门锁止状态。防止一些紧急情况下，车内用户无法下车。技术方案不限行。可提供的文件例如：车辆制造商提供解锁车门的方法说明。33 .条款5. 2. 8在执行软件升级后，车辆应：a）告知车辆用户升级的结果（成功或失败）；b）假设成功，告知车辆用户实施的更新，以及车载电子用户手册（如果有）的任何相 关更新；C）假设失败，告知车辆用户处理建议。说明：本条款目的是要求车辆制造商在软件升级执行后，应将软件升级的结果及附加信息告知 车
21、辆用户。对于具有车载电子用户手册的，应及时更新手册内容防止对车辆用户造成误导。 36.条款5. 2. 9假设软件升级失败或中断，应确保将系统恢复到以前的可用版本或将车辆置于平安状态。说明：本条款的目的是要求车辆制造商对升级失败或中断进行管理，建议优先考虑恢复到以前 可用的版本；当不可能或不希望恢复到以前的版本时，至少应该保证车辆处于平安状态。“安 全状态”由车辆制造商具体定义并证明其有效性。可提供的文件例如：为确保满足该要求，可提供以下相关内容作为证明：(a)软件升级失败或中断后的处理策略；(b)将恢复版本的说明；(C)平安状态的说明；(d)为到达平安状态而添加/禁用的功能。37 .条款6.2
22、升级包真实性完整性试验说明：本试验是为了验证的要求。使用升级包篡改工具对车辆制造商提供的升级包进行损害,将损害后的升级包通过技术 手段放入车辆，通过影音设备记录软件升级结果，将日志校验结果与车辆制造商提供的保护 机制进行比照，软件升级不执行且日志校验结果符合保护机制，那么试验通过。38 .条款6.3软件识别码/软件版本更新及读取试验说明：本试验是为了验证5.1. 2和5.1. 3的要求。如果车辆上存储了软件识别码，车辆制造商应提供相应升级包，并提供软件识别码的标 准接口的读取方式，包括通信协议、读取的诊断服务、诊断DID等。比照软件升级前后的软 件识别码，符合车辆制造商的更新规那么，那么试验通
23、过。如果车辆上没有使用软件识别码，车辆制造商应提供相应升级包，并提供各相关软件版 本的标准接口的读取方式，包括通信协议、读取的诊断服务、诊断DID等。比照软件升级前 后的软件版本，符合车辆制造商的更新规那么，那么试验通过。39 .条款6. 4软件识别码/软件版本防篡改试验说明：本试验是为了验证5.1. 4的要求。根据车辆制造商提供的软件识别码和/或软件版本的存储位置或存储方式，以及采取了 哪些措施来保护其免受篡改，尝试修改软件识别码和/或软件版本。软件识别码和/或软件版 本不能被篡改，那么试验通过。40 .条款6.5用户告知试验说明：本试验是为了验证5. 2.1的要求。本试验针对在线升级。41
24、 .条款6.6用户确认试验说明：本试验是为了验证5. 2. 2的要求。本试验针对在线升级。42 .条款6. 7先决条件试验说明：本试验是为了验证5. 2. 3的要求。本试验针对在线升级。根据车辆制造商提供的先决条件说明，在满足所有先决条件情况下，触发软件升级，查 看是否能执行软件升级；在不满足先决条件情况下，触发升级，查看是否能执行软件升级。 在满足所有先决条件情况下能执行软件升级，且在不满足先决条件情况下不能执行软件升 级，那么试验通过。43 .条款6. 8电量保障试验说明：本试验是为了验证5. 2. 4的要求。本试验针对在线升级。根据车辆制造商提供的电量保障措施的说明文件，在满足电量保障情
25、况下，触发软件升 级，查看是否能执行软件升级；在不满足电量保障情况下，触发软件升级，查看是否能执行 软件升级。在满足电量保障情况下能执行软件升级，且在不满足电量保障情况下不能执行软 件升级，那么试验通过。44 .条款6.9车辆平安试验说明：本试验是为了验证5. 2. 5的要求。本试验针对在线升级。当车辆制造商声明该车型不涉及会影响车辆平安的软件升级工程，那么本试验不适用。当存在影响车辆平安的软件升级工程,根据车辆制造商提供的影响车辆平安的软件升级 工程说明开展相应试验。如果车辆制造商设定的技术保护手段均被实施，那么试验通过。可能影响车辆平安的软件升级项的例如：a）升级驻车相关控制器时，车辆驻车
26、功能可能失效，导致在斜坡出现溜坡；b）升级车门相关控制器时，车门功能可能失效，导致车内人员被困。45 .条款6.10驾驶平安试睑说明：本试验是为了验证5.2. 6的要求。本试验针对在线升级。当车辆制造商声明该车型不涉及会影响驾驶平安的软件升级工程，那么本试验不适用。当存在影响驾驶平安的软件升级工程，根据车辆制造商提供的影响驾驶平安的软件升级 工程说明开展相应试验。如果在执行软件升级中，车辆不能被驾驶，且影响车辆平安和影响 软件升级成功执行的车辆功能不能被使用，那么试验通过。46 .条款6.11车门防锁止试验说明：本试验是为了验证5. 2. 7的要求。本试验针对在线升级。47 .条款6.12结果
27、告知试验说明：本试验是为了验证5. 2. 8的要求。本试验针对在线升级。48 .条款6.13失败或中断处理试验说明：本试验是为了验证5. 2. 9的要求。本试验针对在线升级。根据车辆制造商提供的触发升级失败或中断的方法使软件升级失败或中断，查看车辆状 态：a）当车辆支持恢复到以前的可用版本，读取当前状态下的软件版本，如果恢复到车辆 制造商声明的预期恢复的版本，那么试验通过；b）当车辆未恢复到或不支持恢复到以前版本，如果车辆进入车辆制造商声明的平安状 态，那么试验通过。（五）主要试验（或）验证情况分析根据工作安排，中国汽车技术研究中心、工业和信息化部计算机与微电子开展 研究中心（中国软件评测中心
28、）、中国汽车工程研究院股份、上海机动车检测认证 技术研究中心、招商局检测车辆技术研究院、襄阳达安汽车检测中心有限 公司等检测机构以及北京汽车研究总院、比亚迪汽车工业、上海汽车集团 股份、重庆长安汽车股份、长城汽车股份、中国第一汽车股份有 限公司、上汽大通汽车、一汽解放汽车、合众新能源汽车、华人 运通（江苏）技术、北京车和家汽车科技、上海蔚来汽车、威马 汽车科技集团、广州小鹏汽车科技、上汽群众汽车、上汽通用五 菱汽车股份、一汽一群众汽车、宇通客车股份、奇瑞汽车股份有 限公司、广州汽车集团股份、安徽江淮汽车集团股份、吉利汽车研究院（宁 波）、宝马（中国）服务、戴姆勒大中华区投资、标致雪铁龙（中 国
29、）汽车贸易、沃尔沃汽车（亚太）投资控股、特斯拉汽车（上海）有限 公司、本田技研工业（中国）投资等单位进行了相关的标准验证的试运行工作。验 证内容包括标准草案确定的体系要求和主要试验工程。由于验证内容比拟多，以下仅选择有 代表性的验证内容对主要验证情况进行说明。1.软件升级管理体系审查结果序号标准条款通过情况未通过/未审核主要原因14. 1. 1通过数量：17未通过数0未审核数量：024. 1.2通过数量：6 未通过数量：11 未审核数量：0 信息保存时间暂无明确规定。34. 2. 1通过数量：11 未通过数量：6 未审核数量：0 过程不完善，未明确标注软硬件与准入或认证 的相关性。 相关管理文
30、件、证明材料等不完善。44. 2.2通过数量：1 未通过数量：0 未审核数量：16 暂不具备软件识别码，所以该要求不适用。54. 2.3通过数量：11 未通过数量：6 未审核数量：0 过程不完善，未建立识别系统相关性的过程。 相关管理文件、证明材料等不完善。64. 2.4通过数量：17 未通过数量：0 未审核数量：074. 2.5通过数量：16 未通过数量：1 未审核数量：0 过程不完善，升级前未确认车辆最新软硬件配置；8通过数量：6 未通过数量：11 未审核数量：0 未建立相应过程，未分析软件升级对准入或认 证相关参数的影响。 建立了相关过程，但未提供相关记录。9通过数量：8 未通过数量：9
31、 未审核数量：0 过程不完善，未分析软件升级对准入或认证相 关功能的影响。 建立了相关流程，但未提供相关记录。10通过数量：10 未通过数量：7 未审核数量：0 过程不完善，对于软件升级对于其他系统的影 响分析不充分。11通过数量：17 未通过数量：0 未审核数量：0124. 3. 1通过数量：12 未通过数量：4 未审核数量：0 相关企业管理文件等不完善。134. 3.2通过数量：4 未通过数量：13 未审核数量：0 文件记录内容不充分，记录了系统配置信息， 但没有对与准入与认证相关系统配置形成单独的文 件。144. 3. 3通过数量：1 未通过数量：0 未审核数量：16 暂无软件识别码，该
32、条款不适用。154. 3.4通过数量：16 未通过数量：1 未审核数量：0 未形成记录文件。164. 3.5通过数量：3 b) c) d) e)等工程相关记录缺失。准，保持与联合国法规的协调；该标准可以包含信息平安要求，后续将深入讨论标准框架和 范畴。2 .工程组第二次会议汽车软件升级通用技术要求标准工程组第二次工作会议于2019年6月5日在无锡召开, 会议主要围绕标准现存问题、标准名称、标准框架确定、编写分工以及后续工作规划等展开 讨论。会议明确：标准名称确定为“汽车软件升级通用技术要求”；确定标准坚持兼容并包 的原那么，制定通用性技术要求，防止限制技术路线；进一步明确将参考联合国法规；确定
33、将 两种标准框架进行整合，同时考虑技术开展特性，持续完善标准框架；确定采用分工编写的 工作方式，每章节一个牵头单位，由牵头单位继续细化内容。3 .工程组第三次会议汽车软件升级通用技术要求标准工程组第三次工作会议于2019年9月5日在北京召开。 会议讨论并明确标准工程组工作范畴，详细介绍标准编写格式，总结标准现存问题并探讨解 决方案，进一步梳理标准二级框架及各章节编写分工。在此基础上，更新了工程组工作计划， 并部署了近期工作任务。会议明确:标准草案要严格遵照标准编写格式;标准内容聚焦车端， 重关注功能要求和平安要求;调整标准范围，保证标准范围与标准名称、标准内容保持一致； 对于“软件升级概述”局
34、部，该局部暂定为资料性内容，内容需要简化；对于“汽车软件升 级功能要求”局部，立足车端的技术要求，不涉及服务器端要求和管理要求；对于“汽车软 件升级平安要求”局部，立足车端的技术要求，不涉及服务器端要求和管理要求；对于“升 级包平安要求”局部，立足升级包本身的平安，暂不考虑升级包编码要求。4 .工程组第四次会议汽车软件升级通用技术要求标准工程组第四次工作会议于2019年11月7日在杭州召 开。会议回顾了前期工作成果和遗留问题，并对标准范围、适用对象和标准框架进行深入讨 论。会议明确：标准的适用车型为M类和N类；针对车辆提出技术要求，不规范车外离线升 级工具或后台服务器；5. 1. 1节增加环境
35、要求、新版本检测、升级包下载和升级包安装；整 合第6章和第7章为“信息平安要求”，其中第7章修改为6. 3；删除第6章中服务器信息 平安要求；6. 3节下设升级包完整性要求、升级包的保密性要求、升级包的真实性要求等小 节；确定后续各章节继续完善内容。5 .工程组第五次会议汽车软件升级通用技术要求标准工程组第五次工作会议于2020年8月19日以网络形 式召开。本次会议主要讨论和处理工程组成员所反应182条意见中的15-54条意见，以及规 划后续工作。会议确定：保存应允许手动开启或关闭软件升级功能；根据软件升级类型重新 梳理车辆状态监测要求；新增升级任务用户提示要求；保存检测升级包与车辆现有软硬件
36、兼 容性的要求；删除检测离线升级工具接入状态的要求；保存断点续传要求；删除允许用户取 消升级包下载要求；删除显示升级包下载进度要求。6 .工程组第六次会议未通过数量：14 未审核数量：0174. 4. 1通过数量：17 未通过数量：0 未审核数量：0184. 4.2通过数量：16 未通过数量：1 未审核数量：0 相关管理文件、证明材料等不完善。194. 4.3通过数量：16 未通过数量：1 未审核数量：0 相关管理文件、证明材料等不完善。204. 5. 1通过数量：17 未通过数量：0 未审核数量：0214. 5.2通过数量：17 未通过数量：0未审核数量：0总结：大局部企业均具备软件开发和软
37、件升级管理的过程，但大多企业的过程比拟分 散，需要以软件升级为中心进行过程优化整合。另外，准入和认证相关参数或子系统相关 过程要求需要企业根据自身的系统和产品进行分析完善，经过整改后可以支撑并通过本系 统的评审。2.车辆试验结果序号标准条款通过率未通过/未试验主要原因16.2(5. 1. 1)通过数量：5 未通过数量：2 未试验数量：7 未开发真实性校验能力。 企业未提供试验条件，未完成相应测试。26.3(5. 1.2+5. 1.3)通过数量：12 未通过数量：2 未试验数量：0 仅能通过IVI读取，不能通过标准化接口读取。36.4(5. 1.4)通过数量：3 未通过数量：0 未试验数量：11
38、 企业未提供防篡改保护措施，不具备试验条件。46. 5(5.2. 1)通过数量：11 未通过数量：3 未试验数量：0 提示信息不符合要求，如未提示升级目的、升级的 功能、升级过程中不可用的功能。56.6(5. 2.2)通过数量：13 未通过数量：1 未试验数量：0 提供给用户的升级确认选项中只包含立即安装按 钮，不具备可供用户选择的其他操作选项。66. 7(5. 2. 3)通过数量：14 未通过数量：0 未试验数量：076.8通过数量：13 企业无法清晰表述电量保障策略，不能实现不满(5.2.4)未通过数量：1 未试验数量：0足电量保障的条件。86.9(5. 2. 5)通过数量：11 未通过数
39、量：0 未试验数量：3 企业未提供影响车辆平安相关的升级任务。96. 10(5.2.6)通过数量：12 未通过数量：1 未试验数量：1 在多包升级过程中，会有电子功能恢复的时间段， 该时间段期间可以驾驶。 未提供影响驾驶平安的软件升级工程。106. 11(5. 2. 7)通过数量：14 未通过数量：0 未试验数量：0116. 12(5.2.8)通过数量：13 未通过数量：1 未试验数量：0 升级失败提示时间过短，提示不明显。126. 13(5.2.9)通过数量：11 未通过数量：3 未试验数量：0 在升级失败后未定义平安状态。总结：升级包真实性和完整性试验、软件识别码/软件版本号防篡改试验等需
40、要企业配 合度高，涉及其信息平安的审批，该局部试验可以与信息平安相关标准同步开展。三、与有关法律、行政法规和其他标准的关系本标准是我国智能网联汽车管理的重要内容；与现行相关法律、法规、规章及相关标 准没有冲突或矛盾。四与国际标准化组织其他国家或者地区有关法律法规和标准的比对分析本标准未采用国际标准，基于国内行业开展现状和管理需求自主制定。2020年6月，联合国世界车辆法规协调论坛(WP29)通过并发布R 156关于软件升级 和软件升级管理系统的汽车型式批准统一规定，在软件升级管理体系证书、软件升级管 理体系要求、车型要求、车型修改及扩展、生产一致性等方面做出规定，该法规已于2021 年1月1日
41、实施。欧盟计划从2022年7月起所有新车型如果不满足R 156将无法获取WVTA(Whole Vehicle Type Approval)证书,无法上市销售,2024年7月起制造的车辆必须满 足该要求方可出厂销售。同时日本也将R 156纳入其汽车法规体系。本标准主要技术内容包括汽车软件升级管理体系要求、车辆要求、试验方法。本标准 的制定借鉴联合国世界车辆法规协调论坛(UN/WP29)已发布关于软件升级和软件升级管理 系统的汽车型式批准统一规定法规的思路，在满足政府管理需求和符合行业开展现状的 基础上自主制定。五重大分歧意见的处理过程、处理意见及其依据本标准修订过程中无重大分歧。六对强制性国家标
42、准自发布日期至实施日期之间的过渡期的建议及理由由于汽车软件升级涉及企业软件升级管理体系调整、车辆功能开发、检测机构特殊试 验开展等问题，建议本标准自发布日期至实施日期之间给予12个月过渡期。本标准的实施日期为：（1）对于新申请车辆型式批准的车型，自本文件实施之日起开始执行；（2）对于已获得车辆型式批准的车型，自本文件实施之日起第13个月开始执行。七与实施强制性国家标准有关的政策措施本标准的实施监督管理部门是工业和信息化部。对于违反强制性国家标准的行为，应 按照以下法律、行政法规、部门规章相关规定进行处理：（-）中华人民共和国标准化法Q017修订）第二十五条不符合强制性标准的产品、服务，不得生产
43、、销售、进口或者提供。第三十六条生产、销售、进口产品或者提供服务不符合强制性标准，或者企业生产 的产品、提供的服务不符合其公开标准的技术要求的，依法承当民事责任。（二）中华人民共和国产品质量法（2018年修订）第十三条 可能危及人体健康和人身、财产平安的工业产品，必须符合保障人体健康 和人身、财产平安的国家标准、行业标准；未制定国家标准、行业标准的，必须符合保障 人体健康和人身、财产平安的要求。禁止生产、销售不符合保障人体健康和人身、财产平安的标准和要求的工业产品。具 体管理方法由国务院规定。（三）工业和信息化部车辆生产企业及产品生产一致性监督管理方法（工产业（2010）第 109号）第十条
44、对于不能保证产品生产一致性的车辆生产企业，工业和信息化部将视情节轻 重，依法分别采取通报、限期整改、暂停或撤销“免予平安技术检验”备案、暂停或撤销 其相关产品公告等措施。八、是否需要对外通报的建议及理由本标准为强制性国家标准，在标准适用范围为M类和N类汽车，涉及进口车，需对外通 报。九、废止现行有关标准的建议无。十、涉及专利的有关说明本标准不涉及专利。十一、强制性国家标准所涉及的产品、过程或者服务目录本标准涉及产品包括M和N类汽车。十二、其他应当予以说明的事项无。标准起草组2022年4月8日汽车软件升级通用技术要求标准工程组第六次工作会议于2020年10月22日在北京召 开。本次会议继续讨论和
45、处理工程成员所反应182条意见中的55-114条意见。会议确定： 继续梳理技术要求，将适用于在线升级和离线升级的技术要求进行别离；计划成立专项小组 研究软件的分级分类，并梳理分类原那么；继续研究软件识别码的适用性；当升级失败或中断 是，增加使车辆处于平安状态的要求；进一步明确升级端的定义；增加具备升级包真实性、 保密性、完整性的校验能力。7 .工程组第七次会议汽车软件升级通用技术要求标准工程组第七次工作会议于2021年1月12日在长沙召 开。本次会议继续讨论和处理工程成员所反应182条意见中的115-182条意见。会议确定：o(1)更新“软件升级”的定义为“根据需要，将某版本的软件程序或配置参
46、数更新到另 一个版本的过程J(2)更新“在线升级”的定义为“通过0TA连接至后台服务器进行软件下载和升级的 方式”。(3)针对“4.1 一般要求”，工程组内成员普遍反应目前不具备允许用户关闭功能，认 为不应允许驾驶员关闭软件升级功能；(4)针对“4.2车辆状态检测要求”，工程组建议对于电动汽车，还应该增加检测充放 电状态；(5)针对“4.2.1”，“询检”修改为“巡检”；(6)针对“4.2.6”，工程组企业认同目前主要由后台服务器确保软硬件的兼容性，车载 软件升级系统无法检测软硬件的兼容性，建议修改为检测软硬件的版本；(7)针对“4.3.1和4. 3.2,工程组同意这两项不是平安性要求；(8)针对“4.4.3”，工程组建议将该条与4.2相融合；(9)针对“5.1.8，车载软件升级系统无法发现其自身漏洞，需要修改表述。8 .作为强制性国家标准重新立项2021年3月，由于软件升级对现行汽车管理制度带来严峻挑战且不良软件升级严重影 响用户生命财产平安等问题，主管部门出于行业管理需要，要求将该推荐性国家标准工程调 整为强制性国家标准工程。9 .工程组第八次会议汽车软件升级通用技术要求标准工程组第八次工作会议于2021年4月27日在天津