当前位置:首页 > 汽车电子1 > 糖果Autosar
[导读]一电子电气架构的正向开发流程国外的OEM在多年的Know-how积累下,其在规划新一代电子电气架构平台时,基本完全按照正向的流程来开发,例如VW的MEBE3架构,Volvo的SPA2等,伴随其正向电子电气架构开发的需要,诞生了强大的工具供应商,比如Vector的PREEvisio...


一 电子电气架构的正向开发流程

国外的OEM在多年的Know-how积累下,其在规划新一代电子电气架构平台时,基本完全按照正向的流程来开发,例如VW的MEB E3架构,Volvo的SPA2等,伴随其正向电子电气架构开发的需要,诞生了强大的工具供应商,比如Vector的PREEvision,其囊括了电子电气开发的整个流程,从需求分析、逻辑功能架构、软件架构、硬件架构到电气原理设计、线束原理设计、几何拓扑设计以及线束2D图纸设计,同时包含通讯设计、功能安全开发、变形管理等,提供了电子电气开发的集成平台,需求工程师、功能工程师、软件工程师,通信工程师、架构工程师、电气工程师、功能安全工程师可以在这个平台彼此协作开发,数据无缝传递,每个专业的输入可通过上游设计的输出数据重构生成,数据可在全流程追溯,在应对目前电子电气的复杂性上确实具有领先性。

 

下面以PREEvision为例来简单介绍下电子电气架构的正向开发流程是什么样的:

1、需求工程和需求管理

在电子电气架构开发的概念阶段,我们需要明确开发的目标及范围,需要收集客户对车辆的功能需求、法规需求以及其他非功能需求,在这个阶段涉及两个重要的概念:

lCustomer Feature:在高层级描述车辆的特征,通常是客户可以感知的功能,比如自动空调,自动启停,自动泊车、自适应巡航等,

lRequirements:需求Requirement 是对Customer Feature的进一步细化,包括功能需求,技术需求(工作温度范围等),法规需求(排放法规等);

 

同时可以将Requirement和Customer Feature进行映射关联,从而实现追溯,另外Customer Feature和Requirement在向下映射过程也是有差别的,Customer Feature通常和逻辑架构层(Logical Function Architecture)的元素(Activity Chain)进行映射,而Requirement通常和软件架构层(Software Architecture)的元素以及硬件架构层(Harware Architecture)的元素进行映射。



2、逻辑功能架构(Logical Function Archtecture)

逻辑功能架构设计阶段,就是根据需求阶段定义的Customer Feature,为每一个Feature设计功能的实现逻辑,设计的Activity Chain提供了一个功能的抽象视图,只从功能实现的角度划分Sensor(Input)、Logical Function(Process)、Actuator(Output),并不关心具体的软件实现、以及硬件实现,在该阶段设计完成的逻辑组件(Logical Component)会分配到硬件架构中的组件(ECU、传感器、执行器等)以及软件架构中组件(Application Software Component等)。

3、软件架构(Software Architecture)

在汽车行业嵌入式软件开发领域绕不开AUTOSAR(Automotive Open System Architecture),其定义了一套分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准方案,AUTOSAR的核心思想“统一标准、分散实现、集成配置”,即提供统一、开放的软件架构标准和平台,软件构建在不同的汽车平台上复用,应用软件整合到ECU 中,建立独立于硬件的、分层的软件架构,针对AUTOSAR Classic的系统和软件架构设计在PREEvision中可以分为如下步骤:

 

同时,在目前SDV趋势下,PREEvision同时支持面向服务的架构设计(SOA)以及Adaptive AutoSAR系统和软架构设计,并提供SOA
本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除。
关闭
关闭