车载电子电器架构 —— 电气架构释放检查

车载电子电器架构 —— 电气架构释放检查

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。非必要不费力证明自己，无利益不试图说服别人，是精神上的节能减排。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。

文章大体有如下内容：

1、电气架构释放检查

2、架构层检查

3、子系统层检查

4、SCR检查

5、Car Config检查

6、ECU层检查

7、功能安全检查

8、PNC/VFC检查

一、电气架构释放检查

为了保证每个节点、每个层级数据释放的基线版本一致和上游输入给下游的数据质量，同时兼顾数据的完整性、一致性和可追溯性，需要在节点释放前进行各层级的一致性检查，这些检查包括8个方面:功能、架构、子系统、SCR、Carconfigure、ECU、功能安全、PNCNFC。

1.1、功能层检查

功能层包括FDR和FR，共计检查内容多项，其主要目的是为了确保功能层数据一致性和可追溯性。所有FDR检查须在节点释放前1周开始进行检查，在FDR释放并分配至FR后开始进行FR相关检查，在FR Release前必须保证所有检查项均无问题，该检查内容由功能管理团队和FO、FRR负责。

-> 1)Function List创建及分配检查

确保Generic Function在System Weaver(需求管理系统)中正确创建及分配至FDR Sub Function;

-> 2)FDR变量检查

确保变量正确创建，并且与Sub Function及output requirements正确关联；

-> 3)FDR分配检查

确保Sub Function分配版本的一致性。

-> 4)Change Log填写检查

确保FDR中正确填写Change Log，以便于后续快速确认版本变更的依据

-> 5)FDR需求复用版本一致性检查确保复用需求版本一致。

-> 6)FR需求trace检查确保FR需求正确追溯对应FDRoutput requirements。

-> 7)FR需求分配检查,确保FR-subsystem分配版本的一致性

-> 8)FR需求Handshake状态检查,### ->确保FR需求完成与子系统的handshake或相关issue的处理;

-> 9)FR需求复用版本一致性检查,确保复用需求版本一致。

二、架构层检查

架构层检查主要分为三项，分别为：

-> ECU变量检查；

-> 网络拓扑校核；

-> 车型变量维护。

其主要目的是为了在应对不同车型变量时保证数据的一致性、可追溯性和正确性，同时保证数据导入VSA的准确性。所有检查在SDB释放前6周开始进行，在通信数据库 Release前必须保证所有检查项均无问题，由架构工程师负责完成。

-> 1、ECU变量检查

确保ECU变量的正确性，汇总ECU变量内容，确认其正确性。

-> 2、网络拓扑校核

确保网络拓扑导入到对应工具中是无一致性问题。

-> 3、车型变量维护

确保各车型变量功能完整，数据正确。

三、子系统层检查

子系统层检查主要分为：

-> FR-SSC handshake需求握手检查；

-> port检查：子系统设计接口无一致性问题；

-> 需求检查。

其主要目的是为了确保承接所有功能需求，通信数据库数据的正确性，子系统设计接口无一致性问题以及设计满足所有功能和架构的变更。从功能释放并分配FR到子系统开始进行handshake相关检查，并逐步完成Ports和Requirements检查，在Release前必须保证所有检查项均无问题。该检查内容由各域子系统Leader和子系统owners负责完成。

Port主要提供了作为AUTOSAR概念的连接点的功能，而具体传递的是什么属性的信息，则由Port Interface进行细节的定义。 Port Interface可以理解为一个包含传递信息静态结构，定义传递信息的细节。

1、FR-SSC Handshake检查

确保子系统能够识别和承接相关的功能需求，保证数据的完整性和追溯性，对于车载控制器，若对应的功能需求没有完整落到该ECU的功能需求文档中，供应商就无法进行开发；

2、Port检查

确保LC和Port的设计正确性，通信数据库数据的一致性和正确性；

3、Requirements检查

确保对于FR requirements（功能需求）追溯的正确性，功能承接的完成行，Design requirements的无一致性问题以及与ECUhandshake的完整性。

四、SCR检查

SCR检查主要分为SCR实施状态推进到ECU allocated落实和SCR内容和变更内容的一致性其主要目的是为了所有变更都被系统和ECU接收且正确实施。相关检查在功能释放后开始进行，在子系统Release前必须保证所有检查项均无问题。该检查内容由架构工程师负责完成。

1、SCR实施状态推进到ECU的检查

确保SCR快速推进及子系统和ECU之间的互相握手与落实；

2、SCR内容和变更内容的一致性检查

确保SCR发起内容与实际变更落实内容一致，保证了后续的可追溯性及数据的完整性。

五、Car Config检查

其检查内容分为车辆配置Map情况一致性检查，配置需求引用一致性检查和需求内容检查，其主要目的为了保证测试能够正确导出配置相关的需求列表和功能需求文档中配置相关的需求及参数能被有效识别及应用，相关检查在子系统释放前2~3周开始进行检查，在Release前必须保证所有检查项均无问题。该检查由Carconfigure Manager和子系统owner共同负责完成。

1、配置字map情况一致性检查

确保配置字与requirements正确关联，版本一致

2、需求引用配置字一致性检查

确保与requirements关联的配置字被正确引用在需求的Description中

3、需求内容检查

确保配置字的使用描述在Description中正确表达可以按如下图示方法查看CarConfig检查内容。

六、ECU层检查

ECU层检查主要分为三个内容，分别为：

-> 子系统数据接收检查;

-> 车型变量的一致性检查;

-> LC数据完成同步检查.

其主要目的是为了检查子系统设计数据承接的完整性和可追溯性，同时保证各个项目数据一致性以及LTC数据能够准确释放。在子系统释放并分配LC到ECU后开始进行子系统设计数据接收检查，并依次完成后续一致性检查，在ECU Release前必须保证所有检查项均无问题。该检查内容由ECUmanager和owners共同负责完成。

1、子系统设计数据接收完成检查：确保子系统数据分配到ECU的完整性及一致性且被ECU接收完成;

2、根据车型变量的一致性检查:确保各车型下数据的完整性和一致性，可以支持各车型测试开发

3、LTC数据完成同步检查确保LTC参数同步完成，timing问题处理完毕。

七、功能安全检查

其检查内容主要分为三项，涉及到如下三个方面：

-> Safety Item层；

-> Subsystem层；

-> ECU层。

主要目的是为了功能安全需求的正确分配、接受和实现，同时确保E2E的合理性及一致性且兼顾部分E2E相关参数。Safety Item层级相关功能安全检查需求在节点释放前完成并确保无一致性问题，子系统层相关检查在FSR分配到子系统后开始进行，在子系统Release之前保证无问题，ECU层级相关检查在子系统释放并加TSR分配到ECU后开始进行，在ECU release之前确保无致性问题。该项由功能小组成员、子系统owners和ECUowners共同负责完成相关层级检

Safety Item层级功能安全数据一致性检查

确保SG正确关联FSR，且FSR正确分配到各子系统

Subsystem层级功能安全数据一致性检查确保各子系统正确接受FSR且TSR能够正确实现FSR，同时确保E2E合理性和一致性以及Max Delta Counter Init参数的正确性。

ECU层级功能安全数据一致性检查，确保各ECU正确接受来自子系统层的FSR分配并承接。

八、PNC/VFC检查

其检查项主要分为三项，涉及：

-> 子系统；

-> ECU层级，其主要目的为了相关功能激活时，能够建立LC之间Port交互。子系统层相关检查在功能释放并分配到子系统后开始进行，ECU层相关检查在子系统释放并分配LC到ECU后开始进行，在各层级Release前必须保证该层级下的检查项均无问题。该检查由架构小组VFC成员负责完成

1)、设计端map关系

确保相关LC均MapVFC，相关Port均与VFC建立关联

2)、NC版本检查及SWRS内部检查

确保VFC均Map PNC且在SWRS功能需求文档使用正确版本

3)VFC/PNC flter script检查

确保VFC role和激活条件对应关系正确。

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者！