车载电子电器架构 —— 基础技术开发概述
我是穿拖鞋的汉子,魔都中坚持长期主义的汽车电子工程师。
老规矩,分享一段喜欢的文字,避免自己成为高知识低文化的工程师:
屏蔽力是信息过载时代一个人的特殊竞争力,任何消耗你的人和事,多看一眼都是你的不对。非必要不费力证明自己,无利益不试图说服别人,是精神上的节能减排。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。
文章大体有如下内容:
1、基础技术开发概述
2、基础技术开发
3、小结
一、基础技术开发概述
1、车载基础技术介绍
本文介绍车载基础技术(车辆诊断、通信、网络管理、车辆模式)的开发范围、流程及内容,使得研发工程师对于基础技术开发有基本的认知,并知晓整车信号、诊断及配置数据库的开发流程。所有基础技术开发工程师和ECU开发工程师应阅读本文。
2、基础技术职能职责
以每家OEM整车开发流程为前提,基础技术开发对整车电子电器系统、零部件设计与开发、工厂制造、售后系统等进行设计开发,制定基础技术相关业务流程、方法,按项目时间节点完成基础技术设计开发及高质量输出。基础技术主要职责如下:
-> (1)、负责基础技术概念开发,基础技术需求规范发布及基础技术测试验证发布的审核;
负责车载基础技术概念开发、基础技术需求规范发布及基础技术测试验证发布的审核是一个关键角色,在车载技术领域中起着至关重要的作用。以下是对这一职责的详细解读:
A、车载基础技术概念开发:
负责研究、分析和开发车载领域的基础技术概念,如自动驾驶、智能互联、高效能源管理等。
与行业专家、合作伙伴及内部团队紧密合作,确保技术概念的前沿性和实用性。
制定技术概念的开发路线图,明确短期和长期的技术目标,以及实现这些目标所需的策略和步骤。
B、基础技术需求规范发布:
将开发完成的技术概念转化为详细的技术需求规范,明确车载系统的功能、性能、安全性等方面的要求。
与项目团队、供应商和客户沟通,确保他们对技术需求规范有清晰、准确的理解。
对技术需求规范进行严格的审查和批准,确保其完整性和一致性,为后续的开发工作提供坚实的基础。
C、基础技术测试验证发布的审核:
负责对车载基础技术的测试验证过程进行审核,确保测试结果的可靠性和有效性。
审核测试计划、测试用例和测试报告,确保测试工作的全面性和严谨性。
对测试结果进行分析和评估,如果发现问题,及时与项目团队沟通并制定改进措施。
在确认技术满足需求规范后,负责批准技术的发布和应用。
这一职责需要深厚的车载技术背景和丰富的项目管理经验。此外,还需要具备强烈的责任心和细致的工作态度,确保每一次的技术开发和应用都能达到最高标准,为车载技术的持续发展和创新做出贡献。
-> (2)、负责基础技术需求规范分解和细化,基础技术开发对线束设计需求的发布及确认;
车载基础技术需求规范分解和细化:
-> 接收并理解高级别的技术需求规范,例如车载系统的整体功能、性能和安全要求;
-> 根据这些高级需求,将其分解为更具体、更详细的技术需求,包括各个子系统的功能定义、性能指标、接口要求等。
-> 确保分解后的技术需求与原始需求保持一致,并满足车载系统的整体设计要求。
-> 与技术团队、供应商和客户沟通,确保他们对细化后的技术需求有清晰的理解。
基础技术开发对线束设计需求的发布:
-> 根据细化的技术需求,识别出线束设计相关的需求,例如线缆的规格、长度、连接方式等。
-> 编制线束设计需求文档,明确设计目标、设计准则、接口定义和验证方法等。
-> 将线束设计需求文档发布给相关的设计团队,确保他们了解并遵循这些需求进行线束设计。
线束设计需求的确认:
-> 接收设计团队提交的线束设计方案,并进行审查,确保设计方案满足之前发布的设计需求。
-> 与设计团队沟通,讨论设计方案中可能存在的问题或改进点,确保最终的设计方案满足技术要求和项目需求。
-> 与设计团队沟通,讨论设计方案中可能存在的问题或改进点,确保最终的设计方案满足技术要求和项目需求。
在确认设计方案满足所有需求后,签署确认文件,允许设计团队进入下一阶段的设计或开发工作。
-> (3)、负责ECU基础技术开发文档握手及状态跟踪、开发风险汇报及基础技术需求偏离确认;
ECU基础技术开发文档握手及状态跟踪:
文档握手:与开发团队、供应商或其他相关部门进行技术文档的交接和确认,确保所有相关方都明确理解文档内容,并对文档中的要求、标准或约定达成共识。
状态跟踪:持续监控ECU基础技术的开发进度,包括设计、测试、验证等各个环节。确保所有工作都按计划进行,并及时记录和更新开发状态,以便管理层和其他相关人员了解项目进展。
开发风险汇报:
在开发过程中,及时识别、分析和评估可能存在的风险,如技术难题、供应链问题、时间延误等。
定期向管理层或相关利益方汇报开发风险,包括风险的性质、可能的影响、已采取的或计划采取的应对措施等,确保项目能够顺利进行。
基础技术需求偏离确认:
在开发过程中,由于各种原因(如技术可行性、成本考虑、市场需求变化等),可能会出现技术需求与原始规范有所偏离的情况。
负责对这些偏离进行审查,与相关部门或客户沟通,明确偏离的原因、影响及解决方案。
在得到相关方同意后,对技术需求偏离进行确认,并更新相关文档,确保所有相关方都明确了解新的技术要求和标准。
-> (4)、负责整车ECU刷写需求开发及空中下载(OTA)的开发与验证:
1、整车ECU刷写需求开发
需求分析:与车辆工程、电子工程和其他相关部门紧密合作,收集和分析整车ECU刷写的需求,确保刷写过程满足车辆功能、性能和安全性的要求。
刷写流程设计:设计ECU刷写的完整流程,包括刷写前的准备、刷写过程、刷写后的验证和错误处理等。
工具与软件开发:选择和开发适当的刷写工具和软件,确保它们能够高效、准确地完成刷写任务。
文档编写:编写详细的刷写需求文档、操作手册和技术规格书,为后续的开发、测试和维护工作提供指导。
2、空中下载(OTA)开发与验证
OTA架构设计:设计OTA系统的整体架构,包括服务器端、车载端和通信协议等。
OTA功能开发:实现OTA更新所需的各项功能,如软件包管理、版本控制、安全认证等。
通信协议开发:开发OTA通信协议,确保数据包能够安全、可靠地在服务器和车辆之间传输。
验证与测试:对OTA系统进行全面的验证和测试,包括功能测试、性能测试、安全测试等,确保OTA更新过程稳定、可靠。
文档编写:编写OTA系统的需求文档、设计文档、测试报告等技术文档,为后续的维护和改进工作提供依据。
-> (5)、负责整车信号数据库(SDB)、诊断数据库(DDB)及车辆配置数据库(CCDB) 开发与推进;
1、整车信号数据库(SDB)开发
数据收集与整理:收集并整理车辆上所有传感器和执行器的信号数据,确保数据的准确性和完整性。
数据库设计:根据信号数据的特性和需求,设计合理的数据库结构,包括信号名称、数据类型、数据范围、采样频率等。
数据录入与维护:将收集到的信号数据录入到数据库中,并定期对数据库进行维护和更新,确保数据的时效性和准确性。
2、诊断数据库(DDB)开发
故障诊断逻辑开发:根据车辆故障的特点和需求,开发故障诊断逻辑,能够准确识别并定位车辆故障。
诊断数据收集:收集与故障相关的诊断数据,包括故障码、故障发生时的车辆状态、故障发生时间等。
数据库设计与维护:设计合理的诊断数据库结构,将收集到的诊断数据录入到数据库中,并定期进行维护和更新。
3、车辆配置数据库(CCDB)开发
车辆配置信息收集:收集车辆的各种配置信息,包括车型、发动机型号、底盘号、配置选项等。
数据库设计与维护:设计车辆配置数据库结构,将收集到的配置信息录入到数据库中,并定期进行维护和更新。
配置信息管理:管理车辆配置信息的变更和更新,确保数据库中的配置信息与实际生产车辆保持一致。
4、数据库推进与优化
跨部门协作:与车辆工程、电子工程、软件开发等其他相关部门紧密合作,确保数据库的开发与车辆开发进度保持同步。
性能优化:定期对数据库进行性能评估和优化,提高数据库的查询速度和数据处理能力。
标准化与规范化:推动数据库开发的标准化和规范化,确保数据库的质量和可维护性。
-> (6)、负责整车EOL需求开发及验证:
负责整车EOL(End of Line)需求开发及验证是一个在汽车制造领域至关重要的职责。EOL测试是指在生产线末端对整车进行的一系列测试和验证,以确保车辆的质量和性能符合设计要求。以下是关于这一职责的详细解读:
1、EOL需求开发
需求分析:与车辆工程、电子工程、质量控制等部门紧密合作,收集和分析整车EOL测试的需求,确保测试能够全面覆盖车辆的功能、性能和安全性要求。
测试计划制定:根据需求分析结果,制定详细的EOL测试计划,包括测试目标、测试方法、测试步骤、测试设备等。
测试脚本编写:根据测试计划,编写EOL测试脚本,包括测试用例、测试条件、预期结果等,为测试执行提供明确的指导。
2、EOL测试系统开发与集成
测试系统开发:根据测试需求,开发EOL测试系统,包括硬件和软件部分,确保系统能够准确、快速地执行测试任务。
系统集成与调试:将EOL测试系统与生产线的其他系统(如车辆诊断系统、生产线控制系统等)进行集成和调试,确保系统之间的协同工作正常。
3、EOL测试执行与验证
测试执行:在生产线上执行EOL测试,记录测试结果,确保每辆下线车辆都经过严格的测试验证。
结果分析与问题反馈:对测试结果进行分析,识别潜在的问题和缺陷,并及时向相关部门反馈,推动问题的解决和改进。
4、文档编写与维护
测试文档编写:编写EOL测试的需求文档、测试计划、测试脚本、测试报告等技术文档,为后续的测试和维护工作提供指导。
文档维护与更新:随着车辆和测试系统的更新和升级,及时维护和更新相关文档,确保文档的准确性和时效性
-> (7)、负责售后诊断系统开发与验证
1、售后诊断系统开发
需求分析:与售后服务团队、车辆工程和技术支持部门紧密合作,收集和分析售后诊断系统的需求,明确系统应具备的功能和性能要求。
系统设计:根据需求分析结果,设计售后诊断系统的整体架构、用户界面、数据库结构等,确保系统能够满足用户的实际需求。
系统开发:利用编程语言和开发工具,实现售后诊断系统的各个功能模块,包括故障诊断、数据收集、报告生成等。
2、售后诊断系统验证
功能验证:对开发完成的售后诊断系统进行功能验证,确保系统能够准确识别车辆故障、提供有效的解决方案,并生成详细的诊断报告。
性能测试:对系统的响应时间、稳定性、安全性等方面进行测试,确保系统在高负载和恶劣环境下仍能正常运行。
用户验证:邀请售后服务人员或实际用户参与测试,收集他们的反馈意见,对系统进行持续改进和优化。
3、售后支持与维护
用户培训:为售后服务人员提供售后诊断系统的培训,确保他们能够熟练使用系统,提高售后服务的质量和效率。
技术支持:为用户提供售后技术支持,解决他们在使用系统过程中遇到的问题和困惑。
系统维护:定期对售后诊断系统进行维护和升级,确保系统的稳定性和安全性。
4、文档编写与更新
用户手册编写:编写售后诊断系统的用户手册,为用户提供详细的操作指导和帮助。
技术文档更新:随着系统的更新和升级,及时更新相关技术文档,确保文档的准确性和时效性。
二、基础技术开发
本文节将详细介绍基于电子电器开发流程的基础技术开发的开发思路、开发范围、开发流程及其交付物,上下游的关系和时间节点也将在此文中体现。
1、基本开发思路
基础技术开发是电子电气架构开发的重要组成部分。从项目起动开始到ECU 层需求设计开发,都与基础技术开发紧密交互、息息相关。基础技术开发包括基础技术概念开发、基础技术分解及握手、三大数据库(SDB、DDB 及CCDB)开发及SWDL刷写需求设计及验证,并应用于EOL需求、设备开发及售后诊断系统开发等。其上下游关系如图所示。
2、基础技术开发范围
基础技术开发范围如图所示,基础技术即图中绿色部分,但其涉及ECU软硬件开发实现、线束设计、EOL及售后开发等,因此基础技术开发会与 ECU开发关联部门《红框部分)进行交互,确认 ECU 软硬件开发等按照统一要求实现为实现更高等级的功能做好铺垫。
3、基础技术开发流程
如基础技术开发流程,分为四个阶段,分别是:
基础技术概念开发;
基础技术分解和细化;
通讯/配置/诊断数据表开发;
诊断设备GLDS开发。
整个流程始于Program Technology Request(PTR,项目技术需求)阶段,于Job1(J1)量产批准)阶段结束,并输出符合控制器零部件设计要求的ECU硬件和软件。在开发的过程中会产生偏离和变更,使用基础技术偏离流程和信号变更流程用于审核和确认偏离/变更。
基础技术流程所有人归属于电子电器开发中心,基础技术开发经理对整个流程负责开发中会工程,财务和采购等部门交互。在 PTR阶段输入功能清单、系统及ECU列表、法规要求、PMXU 列表等给基础技术开发,经分解细化及基础技术开发输出用于工程开发的基础技术SWRS功能需求文档、DPR硬件文档等,用于ECU软硬件的开发。
4、基础技术概念开发
基础技术概念开发共分为两个部分。
-> 基础技术策略规划;
-> 基础技术需求规范/测试验证发布/测试验证工具环境确认。
两个部分为承接关系,需在Program Strategy Finalized(PSF,项目策略完成) 阶段完成策略规划,并完成方案构想及基础技术开发工具开发策略。在 Program Confirmation(PC 项目确认)节点完成输出基础技术规范文档、测试验证发布和测试验证工具环境发布。
5、基础技术分解和细化
基础技术分解和细化从 Program Start(PS 项目起动)节点开始,承接基础技术概念开发,与数据库及售后诊断系统开发同步进行,于Launch Readiness(LR 投产准备)节点完成。在此流程执行中,各中心和项目组向基础技术接口工程师输入 ECU 系统开发方案。基础技术接口工程师根据提供 ECU 设计方案对诊断覆盖度、线束设计 (硬件解决方案)等,结合平台架构网络拓扑和ECU Master List 进行评审和批准,同时进行基础技术测试验证。在 ProgramApproval(PA 项目批准)阶段输出评审报告和问题清单。反馈评审报告和问题清单后,测试验证团队继续验证修改后的 ECU 软/硬件设计方案,最终在 LR 节点冻结基础技术方案并输出 BT 设计审计报告、BT问题清单及 ECU 诊断数据表
6、通信配置/诊断数据库开发
通讯/诊断/车辆配置数据库的开发如图所示,在分解和细化基础技术需求的同时(PS之后),E 系列通讯/配置/诊断数据表的开发按软件开发计划进行,在需求管理工具(比如PREEvision、SyatemVeaver)完成系统设计及ECU分配执行后,导出系统描述文件用于信号工程师开发Signal Database (SDB),同时基础技术接口工程师从 ECU 软件工程师接收控制器诊断需求并制定诊断数据库。
通过 ECU 软件工程师提供的车辆特征参数表和子系统配置参数需求,整车配置开发工程师制定车辆配置参数数据库。三大数据均会通过软件集成与零部件测试,最终提交样件与零部件测试报告。除了测试报告之外,Car Configuration Database(CCDB) 还将导出 CCL和VCD 格式文件用以配置车辆参数。
7、售后诊断系统开发
售后诊断仪的开发分为三个步骤,分别是:
-> 诊断开发范围定义
-> 数据评审;
-> 诊断数据内容开发及验证测试。
在电子电器M1造车节点,Basetech基础技术工程师会向ECU软硬件工程师下发PIN 脚调查表以收集DTC & DID 更信息,Script(脚本)工程师收集脚本变更信息及整车零部件信息,DME(售后诊断数据)工程师收集功能FIP表及整车线束原理图以确认功能变更信息。之后,DME工程师将组织会议,与DE工程师及Basetech工程师一起对收集的信息进行评审,此流程在E3、E4 阶段循环。在诊断数据内容开发阶段,即从FDJ节点到J1节点,诊断系统开发中各个角色会基于开发范围定义的结果进行数据库开发。如基于DTC及DID数据,DME工程师在诊断数据汇总工具中进行售后数据的编辑,基于功能变更信息,DME工程师撰写客户功能文档中编辑引导式诊断策略,基于脚本变更信息,Script 工程师更新对应诊断脚本等。
序