车载电子电器架构 —— 基础技术概念开发
我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。
老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：
屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。非必要不费力证明自己，无利益不试图说服别人，是精神上的节能减排。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。
文章大体有如下内容：
1、基础技术概念介绍
2、通讯
3、诊断
4、软件平台
5、软件下载
6、车辆配置
7、通讯安全机制
8、基础技术概念分解与细化
一、基础技术概念介绍
简介
在本中会介绍基础技术所涉及到的各个概念，包括specification (规范)、TOOLS(工具)、Correlative Department (关联部门)、Deviation Approval (偏离批准)、Accept (评审)和Validation (验证)。3
谁应该阅读本文呢？本文涉及到ECU软件的开发规范及ECU软件开发，因此ECU软件工程师及基础技术工程师需熟悉本文。
基础技术概念
基础技术概念对各项技术要求进行详细规范及参数定，ECU 硬件或软件开发和评审的标准都必须严格遵照规范中的定义的需求，如有偏离必须得到偏离流程的批准
对基础技术概念开发来说，当前平台开发输出规范包括七大部分，如下图所示:
交互:Base tech工程师-ECU 软件工程师工作:ECU软件工程师澄清所有需求，Basetech根据需求制定Basetech SWRS (基础技术软件需求规范)和DPR(设计先决条件)文件(共七个方面，下面文章列出):
交付物: 基础技术需求文档和设计先决条件文件;
相关培训:
-> 基础技术开发需求宣贯;
-> 制定基础技术规范;
-> 修订基础技术规范;
-> 导出诊断需求;
-> 诊断需求冻结;
-> 释放开发用诊断数据库;
-> 评审及释放测试用诊断数据库等培训。
二、通讯
主要描述了车辆通讯在物理层，数据链路层，物理交互界面元件，硬件选择指导和需求，IP网络等方面的需求及他们之间的关系。物理层的交互界面和需求定义了通讯硬件，通讯硬件需要支持CAN,LIN、FlexRay、LVDS和Ethermet等多种通讯模式。每种模式下都有各自的物理层和数据链路层设计，其中LVDS和Ethernet需要在P网络的框架下进行，包括P链接管理，IP Command协议。
交付物:
-> CAN Data Link Layer;
-> Ethernet Data Link Layer;
-> FlexRay Data Link Layer;
-> LIN Data LinkLayer;
-> LVDS Data Link Layer;
-> IP Command Protocol;
-> IP Link Manager;
-> IP
三、诊断
诊断的SPEC需求规范主要描述了诊断所面向的传输层，UDS 中的服务/会话/数据，安全校验算法和OEM在各个传输层 UDS 的定义
诊断的SPEC需求规范在车载通信领域中具有至关重要的作用，它详细描述了诊断通信所依赖的传输层要求，以及UDS（Unified Diagnostic Services，即统一的诊断服务）协议中的服务、会话、数据和安全校验算法等关键要素。这些规范确保了诊断通信的准确性、可靠性和安全性，为汽车制造商和供应商提供了统一的标准和指导。
首先，诊断的SPEC需求规范明确了诊断通信所面向的传输层。在车载通信系统中，数据需要在不同的ECU（电子控制单元）之间进行传输，而传输层则负责确保数据的可靠传输。规范中详细描述了传输层的特性、接口和要求，以确保诊断数据能够在不同ECU之间高效、准确地传输。
其次，UDS协议中的服务、会话和数据是SPEC需求规范的核心内容。UDS是一种通用的诊断服务标准，用于汽车电子控制单元（ECU）的诊断和调试。规范中详细定义了UDS协议中的各种服务，如会话控制、诊断请求、诊断响应和ECU编程等。这些服务允许诊断工具与ECU进行交互，获取ECU的状态信息和故障码，以及执行各种诊断任务。同时，规范还描述了会话的概念，包括默认会话、扩展会话和编程会话等，每种会话具有不同的权限和操作范围。此外，规范还定义了与诊断相关的数据格式和传输要求，以确保数据的正确性和一致性。
在保障数据传输的安全性和可靠性方面，SPEC需求规范强调了安全校验算法的重要性。这些算法用于确保数据在传输过程中不被篡改或损坏，以及确保只有授权的诊断工具才能与ECU进行通信。规范中详细描述了安全校验算法的原理、实现方法和要求，以确保诊断通信的安全性。
最后，规范还涉及了OEM（原始设备制造商）在各个传输层UDS的定义。OEM是汽车制造过程中的关键参与者，他们负责设计和生产汽车的核心部件和系统。在SPEC需求规范中，OEM需要定义他们在各个传输层上对UDS协议的实现和支持情况。这包括所使用的硬件、软件和网络架构等方面的内容。通过明确OEM的定义和支持情况，规范有助于确保不同OEM之间的兼容性和互操作性，从而推动整个汽车行业的标准化和规范化发展。
因此，诊断的SPEC需求规范在车载通信领域中具有至关重要的作用。它详细描述了诊断通信所依赖的传输层要求以及UDS协议中的服务、会话、数据和安全校验算法等关键要素。这些规范确保了诊断通信的准确性、可靠性和安全性，并为汽车制造商和供应商提供了统一的标准和指导。同时，规范还涉及了OEM在各个传输层UDS的定义和支持情况，有助于推动整个汽车行业的标准化和规范化发展。
如上图所示，诊断的框架要求诊断功能面向所有公有节点，包括CAN，LIN,FR，IP及LVDS等节点。所有的诊断会话，诊断数据及诊断服务都必须遵循安全校验算法及其他ISO诊断规范中的定义。
交付物:
-> GeneralDiagnostic Guideline;
-> Diagnostic and Bootloader Gateway Specification;
-> UnifiedDiagnostic Services on LIN;
-> UDSOnLIN;
-> UDSonIP;
-> UDSOnMOST150,
-> UDSonFR;
-> UDSonCAN;
-> UDSonUSB;
-> UDSonLVDS;
-> UDS Data;
-> UDS Service;
-> UDS Session.
四、软件平台
在软件平台的设计规范中，主要涉及的有 AUTOSAR(软件设计)配置规范，AUTOSARBSW 规范及一级/二级供应商需求。
在软件平台的设计规范中，AUTOSAR（汽车开放系统架构）无疑扮演了核心的角色。AUTOSAR旨在提供一套标准化的、可复用的软件组件，以简化汽车ECU（电子控制单元）的开发过程，并确保不同供应商提供的软件组件能够无缝集成。以下是关于AUTOSAR及其相关规范的一些关键内容：
AUTOSAR软件设计规范：这一规范定义了如何在AUTOSAR架构下设计和开发软件。它涉及了从需求分析、设计、编码、测试到维护的整个软件开发生命周期。此规范确保了软件的可移植性、可重用性和可扩展性，从而降低了开发成本和维护成本。
AUTOSARBSW（基础软件）规范：BSW是AUTOSAR架构中的一个关键组件，它为应用层软件提供了必要的基础功能，如操作系统、通信、内存管理等。BSW规范详细描述了这些基础功能的实现方式、接口定义以及与其他软件组件的交互方式。它确保了不同供应商提供的BSW组件能够兼容并协同工作。
一级/二级供应商需求：在汽车行业中，一级供应商通常指的是直接向汽车制造商提供零部件或系统的公司，而二级供应商则为一级供应商提供支持或供应零部件。这些供应商在开发软件时，需要遵循AUTOSAR规范，以确保他们的软件能够与整个车辆系统兼容。一级/二级供应商的需求可能包括特定的功能实现、性能要求、安全性需求等，这些都需要在软件设计规范中得到充分考虑。
在软件平台的设计规范中，AUTOSAR及其相关规范为汽车制造商和供应商提供了一个统一的、标准化的开发框架。这不仅简化了开发过程，还提高了软件的可重用性和可维护性，为汽车行业的持续发展提供了有力支持。
AUTOSAR定义了车辆配置的需求，网络管理的需求，诊断功能的大纲和一级到二级供应商的需求。以AUTOSAR为规范要求，基于BSW(基础软件)，在供应商的开发下才能制造出符合ECU需求和规范的软件。
交付物:
-> Autosar Network Management - additional requirements；
-> Autsar BSW - Tier1 toTier2 Requiremens；
-> Autosar Configuration；
-> Autosar Diagnostic Guideline。
五、软件下载
SWDL基于OEM软件下载规范,CAN/LIN/FR/IP诊断引导程序装载需求的规范和VBF主要规范了软件验证签名方法、数据压缩加密、数据格式、各类总线上的引导程序装载规范和测试规范并提供了案例。
在车载软件领域，SWDL（Software Download）、CAN/LIN/FR/IP诊断引导程序装载需求以及VBF（Vehicle Binary Format）等规范在软件下载、诊断和验证方面扮演着重要角色。这些规范确保了软件在不同汽车系统和总线上的兼容性、安全性和有效性。
SWDL基于OEM软件下载规范：
SWDL是一种标准化的软件下载机制，用于将软件更新或新软件组件从外部设备（如诊断工具）传输到车载ECU中。
基于OEM的软件下载规范意味着每个汽车制造商（OEM）可能会根据其车辆架构和需求制定特定的下载协议和流程。
这些规范通常包括文件格式、传输协议、安全性要求（如加密和签名验证）、错误处理和重试机制等。
通过遵循这些规范，可以确保软件下载的可靠性和安全性，同时简化不同车型和ECU之间的软件更新过程。
CAN/LIN/FR/IP诊断引导程序装载需求的规范：
这些规范描述了在不同类型的汽车总线（如CAN、LIN、FlexRay和以太网IP）上进行诊断引导程序装载的具体要求。
引导程序装载是指将诊断或更新工具加载到目标ECU中，以便进行进一步的诊断或软件更新操作。
这些规范涵盖了通信协议、数据格式、传输速度、错误检测和处理等方面，以确保引导程序在不同总线上的正确和高效传输。
VBF主要规范了软件验证签名方法、数据压缩加密、数据格式等：
VBF是一种用于描述和存储车载软件二进制数据的格式。
它规定了软件验证签名的方法，这通常涉及使用公钥加密技术来验证软件包的完整性和来源。
数据压缩和加密规范确保了软件在传输和存储过程中的安全性和效率。
VBF还定义了数据格式，包括文件结构、元数据、依赖关系等，以便在不同系统和工具之间实现互操作性。
各类总线上的引导程序装载规范和测试规范：
这些规范详细说明了在不同类型的汽车总线（如CAN、LIN、FlexRay、以太网等）上执行引导程序装载的具体步骤和要求。
测试规范则提供了用于验证和引导程序装载过程有效性的测试用例和方法。
提供了案例：
这些案例可能包括实际的车载软件下载和诊断引导程序装载的示例，用于说明规范的具体应用和实践中的挑战。
通过学习这些案例，开发人员和测试人员可以更好地理解规范的实际应用，并据此改进他们的软件下载和诊断流程。
这些规范在车载软件领域具有至关重要的作用，它们确保了软件在不同系统和总线上的兼容性、安全性和有效性。通过遵循这些规范，汽车制造商和供应商可以简化软件开发和更新过程，提高产品质量和客户满意度。
交付物:
-> Data Compression and Encryption Specification；
-> Versatile Binary Format Specification26General Software Download Specification；
-> Bootloader - UDSonCAN；
-> BootloaderUDSonFR；
-> Bootloader -UDSonIP；
-> Bootloader -UDSonLIN；
-> Bootloader-UDSonLVDS
六、车辆配置
车辆配置信息详细记录了车辆各项配置如发动机/变速器类型、车辆网络拓扑信息(如装载哪些ECU)和整车配置管理等。
车辆配置信息对于汽车制造商、供应商以及最终用户来说都是至关重要的。它详细记录了车辆的各项配置，从发动机和变速器的类型，到车辆网络拓扑信息（如哪些ECU被装载），再到整车配置管理。这些信息不仅有助于确保车辆的性能和安全性，还能在车辆生产、维修和升级过程中提供重要的参考。
首先，发动机和变速器的类型是决定车辆动力性能和燃油效率的关键因素。了解这些信息有助于选择最适合用户需求的车型，以及在后续维修和升级过程中选择合适的零部件。
其次，车辆网络拓扑信息详细记录了车辆中装载的各个ECU（电子控制单元）。这些ECU负责控制车辆的各种功能，如发动机控制、制动系统、车身稳定系统等。了解车辆网络拓扑信息有助于诊断和解决车辆故障，以及进行车辆维护和升级。
最后，整车配置管理涉及车辆的所有配置信息的整合和管理。这包括从基本的车辆参数（如车身颜色、内饰材质等）到高级功能配置（如智能驾驶辅助系统等）。整车配置管理有助于确保车辆在生产过程中的一致性和质量，同时也能为用户提供个性化的定制服务。
在实际应用中，车辆配置信息通常会被存储在车辆的数据管理系统中，以便随时查阅和更新。这些数据可以用于生产过程中的质量控制、故障诊断和维修，以及用户服务和市场营销等方面。随着汽车智能化和电动化的发展，车辆配置信息的重要性将进一步提升，它将成为实现车辆智能化、互联化和可持续发展的重要基础。
在Car Configuration的服务器中记录了相关车型所有的配置信息已经配置对应的代码，工程师在服务器可以修改各项配置的参数，客户可以在单独的车辆上修改已经写入的车辆配置参数(EOL及售后通过SWDL写入)。Car Configuration规范则记录了各项参数定义、修改、管理和输出的各项规则。
交付物:
-> Central Car Configuration;
-> Overview of Vehicle Configurations & Customer Settings.
七、通讯安全机制
通讯安全旨在保证信号准确地传达到相应的ECU上，OEM的通讯安全大纲guidelines for safety related communication作为处理信号错误的模板。大纲同时也能用于改善车况，提升诊断效率或修正车辆配置。同时使用信号品质定义指导(Guideline for quality factor signals)来定义通讯信号的质量。
数据安全数据安全包含了安全校验算法、软件签名、凭证管理和评审记录等用于保证数据安全的文档。这类文档中规定了执行某些操作时需要通过的软件认可操作或者审核通过之后才能进行相关操作。而数据保密的SPEC中规定了如何制作这些文档、所需的算法、相关角色及文档开发的流程。
交付物:
-> Security Access algorithm;
-> Software Authentication;
-> Authentic communication;
-> Certificate (client - in keystore) /credential/trust (root cert, in truststore) management;
-> Hardware security module;
-> Security Audit log。
八、基础技术概念分解与细化
基础技术概念分解和细化包括线束总线设计的需求确认、评审验收和偏离认可，及ECU软硬件基础技术开发需求确认、验收及偏离认可等。基础技术概念分解和细化是为了确保基础技术开发需求在控制器零部件开发得到正确实施。根据ECU系统方案、ECUmaster list信息及ECUPMXU列表，对ECU进行基础技术分解和细化，输出ECU基础技术需求硬件规范(Basetech DPR)及其需求确认表(HWRT)、ECU基础技术需求软件规范(Basetech SWRS)及其需求确认表(SWRT)s.
输出线束总线设计需求确认文档给到项目线束开发负责人进行设计约束，并对线束设计状态进行评审，输出线束设计基础技术需求评审报告。确保ECU基础技术概念在ECU开发和线束设计中得以正确实施，保证产品开发质量。
验证与评审每个需求项都需要进行验证，由ECU软件工程师提出测试案例，需求测试要求覆盖度达到100%，即所有已知的测试案例都需要进行验证。测试报告由ECU软件工程师接收后审核，审核通过接收后进行软硬件测试，测试部门释放软硬件测试文档给供应商，供应商根据测试文档及工具完成测试并递交测试报告，OEM再组织进行ECU单体测试，台架测试及系统级测试，释放测试报告并组织会议对测试结果进行评审，所有的相关人员需要参加进行测试报告的审核，确认所有需求项无误之后进行会签释放当前规范。
交互:Basetech工程师、ECU软件工程师;
工作:审核测试模板，测试验证，输出测试报告;
交付物:DVM(单件测试规范)，Review DVM(单件测试规范外项目);
培训:DVM开发，释放初版Basetech用例，集成测试培训，系统测试培训
偏离批准
在协议的制定中，任何时候都会存在不同的意见和方案。当供应商对协议规范存在
不同意见时，需要按照流程走偏离申请，以得到批准。流程如下图所示。
输入: 需求文件评审工程师提出偏离需求文件。需要登录OEM的偏离审核系统，然后由多个责任人进行确认会签，会签人员包括OEM基础技术负责人、OEM售后负责人、OEM ME负责人、OEM诊断负责人。
输出:
最终结果,相关责任人同意，偏离认可，规范重新定义;
都不同意，偏离否决;
存在不同意见，组织各方责任人及管理人员进行评审，表达各自意见，领导决策。
