EEA——架构开发工具介绍及架构开发流程

Posted 2023-03-31 汽车人——EEA

一.架构开发工具

（1）PREEvision

PREEvision是Vector公司开发的基于模型的图形化电子电气架构开发工具，可用于汽车OEM及Tier1进行整车或系统级电子电气架构开发。PREEvision采用分层开发模式，将电子电气架构自上而下划分多个层级，每层架构设计内容均采用图形化的统一建模语言（UML）进行建模，并通过映射/链接的方式将各层架构元素有效地关联，形成统一完整的电子电气架构模型。

特点及优势：

● 功能全面：涵盖需求、功能、软件、通信、硬件、线束、功能安全等内容

● 设计跟踪：各层设计内容从上到下建立映射与链接，有效支持设计跟踪

● 数据单源：所有工程师共享同一数据库协同开发，有效保证设计数据一致性

● 图形化界面：所见即所得，避免纯文字的二义性且提高设计效率

● 变形管理：支持设计备选方案，有效区分高中低配，并支持多种方案评估

● 一致性检查：通过检查规则检查设计模型，保证输出模型的一致性和完整性

● 架构评估：根据用户的评估要求建立评价指标，评估架构及各备选方案的优劣

● 定制报告：可配置模板，提供图形及文字类报告输出，高效生成各种定制化文档

● 协同开发：提供协同开发环境，支持不同阶段、不同角色的多人在线协同工作

（2）SystemWeaver

SystemWeaver软件是瑞典Systemite公司研制的一款面向企业级的电子电气协同研发平台工具。支持电子电气系统研发V流程，从需求-功能-系统-ECU-测试等多阶段对电子电气系统进行设计、分析、验证及管理工作，并可对系统全流程数据进行追溯关联，保证数据的正确性、一致性和有效性。企业可根据自身产品需要定制开发符合企业设计模式的SystemWeaver模型，并通过模型配置自定义软件功能模块。

（3） PREEvision与SystemWeaver对比

PREEvision与SystemWeaver对比

对比项	子功能对比项	PREEvision	SystemWeaver
数据类型	需求建模	支持	支持
	逻辑功能建模	支持	支持
	AUTOSAR软件架构建模	支持	支持
	基于SOA的以太网设计建模	支持	不支持
	网络和部件建模	支持	支持
	通信数据库建模	支持	不支持
	AUTOSAR软件集成	支持	支持
	供电及接地分配建模	支持	不支持
	线束拓扑建模	支持	不支持
数据管理	变型管理	支持	支持
	生命周期管理	支持	支持
	测试数据管理	支持	支持
	权限管理	支持	不支持
	项目管理	支持	支持
	任务管理	支持	不支持
架构分析	一致性检查	支持	支持
	报告生成	支持	支持
	规则RuleFramwork	支持	不支持
	架构数据静态评估	支持	不支持
	JAVA二次开发	支持	不支持
功能安全	HARA	支持	支持
	FMEA	支持	支持
	FTA	支持	支持
可追溯性	架构层次	支持	支持
	需求和测试	支持	支持
数据格式支持	RIF	支持	支持
	DBC	支持	不支持
	LDF	支持	不支持
	FIBEX	支持	不支持
	AUTOSAR	支持	支持
	LBL	支持	不支持

二.基于PREEvision的EEA架构开发

整车电子电气架构V模式开发流程：

EEA的V流程开发 

层级 

EEA开发详细流程 

基于PREEvision的EEA开发 

 （1）设计目标定义（Product Goal）

PREEvision工具建模的第一层：需求工程和需求管理

客户特征（Customer Feature）是作为整车电子电气系统设计第一步，它以整车的feature与function清单为基础（Customer Feature通常和逻辑架构层（Logical Function Architecture）的元素(Activity Chain)进行映射）。

需求（Requirements）用于描述具体功能与非功能需求，包括技术需求、结构需求、布置需求、法规需求、性能需求、EMC需求（或目标）等（Requirement通常和软件架构层（Software Architecture）的元素以及硬件架构层（Harware Architecture）的元素进行映射）。

A.需求及目标定义

需求及目标的定义是整车EEA 开发的输入和目标，关系到整车及 EEA开发的成败，包括：

1）客户需求分析

通过市场调研，获取不同客户群对不同级别车型的配置和功能要求、操作习惯等信息。

2）标杆车型分析

对标杆车型的选择及分析，确定不同级别、不同配置车型在不同方面 （配置 、 装配、空间、成本等）设计的优劣，作为搭建 EEA平台的输入。

3）发展趋势分析

客户需求；法规需求。

B.需求规范与管理

1）需求规范

需求规范是指对要开发的系统或产品确定一个完整的、无歧义的、结构化的规范进行描述。不仅对描述的内容与结构进行了限制，而且对描述语言的规则和描述方法也作了要求。

需求规范的内容包括 :

<1>确定需求类型；

<2>确定需求相关文档的内容：如任务书、相关的标准、法规、合同或其他正式规定性文档 、开发流程要求 、各系统或部件的详细功能描述、接口描述 、各种需求分析报告等；

<3>定义需求描述模板；

<4>定义评价需求规格说明书的质量准则等；

<5>定义专用词汇表：包含 : 技术概念、缩写、动作描述等；

<6>形成规范的需求规格说明书，作为系统开发的输入。

2）需求管理

<1>需求变更管理：对要变更的内容进行标识；明确哪些需求可以变更，哪些需求不能变更，并设置实现的优先级，确定目标版本。

<2>版本管理：注明版本号，记录变更日期以及变更原因记录。

（2）系统／架构设计

根据电子电器系统的需求，制定系统级电子电器架构的解决方案，定义电子电器架构中物理架构和逻辑架构的需求，同时制定验证系统／架构设计目标是否被实现的测试规范与方法。

A.逻辑功能架构（Logical Function Architecture）

 PREEvision工具建模的第二层：功能分配的process

根据需求阶段定义的Customer Feature，为每一个Feature设计功能实现的逻辑，设计Activity Chain（一个功能的抽象视图）。从功能实现的角度划分逻辑组件（Logical Component）包括传感模块（Sensor）、逻辑模块（Logical Function）以及执行模块（Actuator）。通过接口（Interface）定义模型元素间的关系，通过数据（Data）定义彼此之间交互的具体信息。该步骤不关心具体的软件实现、以及硬件实现。

Activity Chain 

B.软件架构（Software Architecture）

 PREEvision工具建模的第三层：

软件架构开发包括软件行为（Software behavior）模型设计、面向服务的架构（SOA）模型设计、软件架构模型设计以及面向对象的软件设计、诊断模型的设计。基于AUTOSAR的软件架构开发，AUTOSAR的核心思想“统一标准、分散实现、集成配置”，即提供统一、开放的软件架构标准和平台，软件构建在不同的汽车平台上复用，应用软件整合到ECU 中，建立独立于硬件的、分层的软件架构。

C.硬件架构（Hardware Architecture）

硬件架构的设计分为三层：硬件组件（Hardware components）和网络拓扑（Network topology），电气原理和线束原理。

 PREEvision工具建模的第四层：

1）硬件架构及网络拓扑（Hardware Network Architecture）

设计硬件组件（如ECU、传感器、执行器）之间的硬线连接，包括硬线信号（PWM、高低电平等），总线连接（CANFD/CAN/LIN等），以及电源连接和接地连接；网络拓扑模型设计。

2）电气原理（Electric Circuit）

 PREEvision工具建模的第五层：

电气原理层将硬件架构层的数据进行重构，重新定义硬件组件之间的连接，并关注与线束设计相关的电气属性，例如电源供应、接地连接等，其可设计电源分配的保险、继电器以及接地分配电路。

3）线束原理（Wiring Harness）

 PREEvision工具建模的第六层：

将电气原理数据进行细化，将逻辑连接转换为导线，同时添加导线之间的焊接点（Splice），内部连接器（Inline），端子（Terminal），线束端连接器（Female Connector）。

D.通讯设计

软件架构映射（Mapping）至硬件架构后完成信号路由(Signal Routing)即进行网络通讯设计

E.几何拓扑（Geometric Topology）

 PREEvision工具建模的第七层：

几何拓扑层是整车电器的2.5D布局视图，使用CAD软件通过KBL格式展平为2D视图，表达各电器的安装位置，线束分段，导线的路由规划。

（3）架构验证

EEA评估

EEA评估指标

维度	定义
可靠性	系统在各种复杂环境下在一定时间内保证功能满足设计意图的能力（总线负载率）
安全性	发生影响车辆、人员安全的失效的可能性
成本	设计、开发、制造、物流、维修等阶段成本
可扩展性	在硬件资源方面为可能的更改做好预留（总线负载率、诊断接口、CAN线长度）
灵活性	在不更改硬件的前提下适应更改的能力
复用性	零部件支持不同产品线的能力
重量	零部件重量
可维护性/可诊断性	失效系统可以在一定时间内完成维修、诊断的能力
开发周期	满足项目开发周期的能力
布置灵活性	硬件资源在布置、设计等方面的自由度
兼容性	架构设计与过往设计、工具、数据、供应商等方面的兼容性
可用性	在特定失效模式下确保车辆基本操作的可用性
复杂性	对设计复杂度的评估（ECU数量、网段数量）
信息安全	预防非侵权入侵、操控能力

（4）方案测试与验证

A.功能测试

1）部件级功能测试

2）系统级功能测试

3）整车级功能测试

B.性能测试

整车电气系统性能测试（VEST）主要在台架上进行前期的部分测试。

1）整车静态电流测试；

2）整车待命状态电流测试；

3）电气回路电流及电压降测试；

4）整车接地性能测试及接地点移除造成电气功能紊乱确认测试；

5）保险丝熔断性能测试以及保险丝缺失造成电气功能失效确认测试；

6）整车电压相关的功能测试。

C.诊断测试

诊断测试规范制定了关于系统参数配置、软件刷新、DTC测试、I/O控制测试、传输层测试和服务层测试。

D.网络测试

根据整车网络测试规范，对整车网络进行认证。包含整车的CAN总线、网络管理、网络负载、一致性测试以及总线故障处理等。

E.EMC测试

EMC测试也称为电磁兼容测试，分为EMI测试和EMS测试。EMI测试包括辐射发射骚扰、传导耦合、EMC测试、瞬态发射骚扰。

ansible架构原理及工作流程

一、ansible介绍

ansible是一种自动化运维工具，基于paramiko模块开发，用于批量执行任务和发布工作,被广泛用于日常运维工作当中.

二、ansible架构
架构图:

ansible核心模块介绍:
core models: ansible自带的模块，file,shell,copy等
custom models: ansible自带模块不足以满足工作需要时，用户添加扩展模块
host inventory: 由ansible 管理的主机，包括主机名，ip,端口等
playbook: yaml格式文件，多任务定义在一个yaml文件中，主要定义哪些功能由哪些模块完成，顺序执行
connection plugins: ansible通过该插件连接到各个目标主机，内部默认使用paramiko模块ssh协议来完成

三、ansible特性

• 被管理端无需安装agnet,只要配置满足条件的python版本，和ssh服务
• no server 只需要安装ansible软件，配置完之后，命令行完成工作
• 可以基于任何语言开发新模块
• 由于被控端没有安装agent软件，只能通过命令端推送任务
• 模块是幂等性的,定义的任务已存在则不会做任何事情,意味着在同一台服务器上多次执行同一个playbook和执行一次，效果一样

四、ansible执行任务模式
1.ad-hoc模式
单模块，批量执行单条命令
2.playbook模式
批量执行多个任务，多个任务完成一个大的功能，相当于多个ad-hoc的配置文件

五、工作流程