1、1,2,内容,1、 AUTOSAR简介 2、 AUTOSAR软件结构 3、 AUTOSAR方法、模型、工具和一致性测试,3,AUTOSAR简介,AUTomotive Open System ARchitecture 汽车开放系统结构,4,AUTOSAR背景（1）,随着车载控制系统日益先进和复杂化，每辆汽车投入的软件开发工数(时间及人力)2010年将达到2002年的5-10倍。汽车电子系统设计复杂化造成的可靠性隐患导致汽车因安全隐患被“招回”的现象频繁发生，一些国际顶级汽车制造商已经因此倍感痛苦。,5,AUTOSAR背景（2）,2003年9月德国的汽车制造商和汽车电子产品供应商成立AUTOSAR
2、组织，旨在推动建立汽车电气/电子(E/E)架构的开放式标准，使其成为汽车嵌入式应用功能管理的基础架构，并规范汽车电子产品、软件和元器件的互通性,6,AUTOSAR背景（3）,包括汽车制造商：BMW、Bosch、Continental、DaimlerChrysler、Ford、PSA Peugot Citroen、Siemens VDO、Toyota和Volkswagen等半导体制造商：英飞凌科技、NEC、瑞萨科技、IBM等,7,AUTOSAR的主要驱动力,管理随着功能的不断提升，复杂不不断增加的E/E设备 提高产品更改、升级和更新的灵活性 提升生产线内或者跨生产线的可度量性 提升E/E系统的质
3、量和可靠性 能够在早期设计阶段检测错误,8,AUTOSAR采取的一些技术,标准化的规范交换格式 基础软件核 微控制器抽象 运行时环境 接口标准化,9,内容,1、 AUTOSAR简介 2、 AUTOSAR软件结构 3、 AUTOSAR方法、模型、工具和一致性测试,10,AUTOSAR软件结构内容,2.1 软件的组成与分层 2.2 RTE 2.3 系统服务 2.4 诊断服务 2.5 通信栈,11,AUTOSAR软件组件,12,软件分层,ECU：Electronic Control Unit,13,例子层的交互,FeeWrite(.),Fls_Write(.),Nvm_Write(.),MemIf_
4、Write(.),Rte_Write(.),服务层,ECU抽象层,微控制器抽象层,14,AUTOSAR软件结构内容,2.1 软件的组成与分层 2.2 RTE 2.3 系统服务 2.4 诊断服务 2.5 通信栈,15,RTE作用,RTE是AUTOSAR ECU体系的核心,使AUTOSAR软件组件能访问包括OS和通信服务在内基础软件模块,实现了AUTOSAR软件组件之间的通信,提供AUTOSAR软件组件间通信的基础服务,RTE实现了AUTOSAR虚拟功能总线(VFB) 的接口,16,AUROSAR 软件组件,应用软件概念上位于AUTOSAR RTE之上 - AUTOSAR应用软件组件 - AUTO
5、SAR传感器-致动器组件 AUTOSAR软件组件在系统配置期间可以配置给任何可用的ECU RTE确保组件可以通信,17,基础软件模块,能直接访问ECU抽象层和其他基础软件模块 AUTOSAR软件组件不能直接访问基础软件模块 所有的通信都要通过AUTOSAR接口 访问是由RTE控制的,18,可运行实体,指一系列能由运行时环境（RTE）启动的组件中的一段指令及相关的数据集 代表的就是组件的一个功能 一个组件提供一个或几个可运行实体 一个可运行实体有一个入口点 RTE负责调用可运行实体，由RTE事件激活,19,通信,通信接口由一些端口组成 AUTOSAR软件组件能和位于同一个ECU上的其他AUTOS
6、AR软件组件通信 AUTOSAR软件组件能和位于不同ECU上的其他AUTOSAR软件组件通信 AUTOSAR软件组件能和有端口并位于同一个ECU上的基础软件模块通信 通信是静态的 端口分为 发送-接收端口接口提供消息传递 客户-服务端口接口提供功能调用,20,通信模型（一）,ECU内软件组件间通信,21,通信模型（二）,22,通信模式,针对接收-发送通信提供两种通信模式 显式的使用显式的RTE API调用来发送或接收数据元素 隐式的在可运行实体被调用前RTE自动的读一个特定中的数据元素集合，在可运行实体终止以后RTE自动的往另外的数据元素集合中写,23,RTE 产生器,负责AUTOSAR软件组
7、件API的创建 连接AUROSAR软件组件和OS 管理组件间的通信 RTE订约阶段 定义了组件与RTE之间的“契约” RTE产生阶段 用组件相关的所有信息来生成RTE,24,AUTOSAR软件结构内容,2.1 软件的组成与分层 2.2 RTE 2.3 系统服务 2.4 诊断服务 2.5 通信栈,25,系统服务,系统服务为应用和基本软件模块提供基本服务。,26,系统服务,OS ECU状态管理器 BSW调度器 看门狗管理器,27,OS,AUTOSAR OS的基本特征包括： 静态配置 能够推断实时系统性能 提供基于优先级的调度策略 提供运行时保护功能（存储、计时等） 可驻留在低端控制器上，并且不需要
8、其他资源 对于特殊的应用，操作系统可以配置为只包含该应用需要的服务。因此操作系统的资源需求会尽可能的少。,28,OS,如果AUTOSAR组件需要在某些专用OS上运行，例如Windows CE、VxWorks、QNX等，应该使用AUTOSAR OS中定义的接口作为操作系统抽象层（OSAL）。 那些不使用AUTOSAR OS的系统可以通过操作系统抽象层（OSAL）提供AUTOSAR软件组件执行的平台。AUTOSAR OS严格定义了连接到OSAL的接口。,29,OS,AUTOSAR OS的核心功能基于OSEK OS。这意味着应用程序是向后兼容的，为OSEK OS编写的应用程序可以在AUTOSAR O
9、S上运行。 使用AUTOSAR OS引入的一些新特性需要对已存在的OSEK OS特性的使用有所限制。 AUTOSAR OS扩展了一些已存在的特性。,30,OS,一些扩展的API,31,ECU状态管理器,ECU状态管理器： 负责初始化和关闭所有基本软件模块，包括OS和RTE。 关闭ECU。 管理所有唤醒事件，并在被要求时配置ECU为SLEEP状态。,32,BSW调度器,BSW调度器的功能是： 把BSW模块的实现嵌入AUTOSAR OS上下文 触发BSW模块的主要处理函数 应用BSW模块的数据一致性机制 BSW调度器建立AUTOSAR OS任务体，安排OS任务体内对主处理函数的调用。,33,看门狗
10、管理器,看门狗管理器在触发看门狗硬件的同时提供了对一些独立应用的生存监控。,34,AUTOSAR软件结构内容,2.1 软件的组成与分层 2.2 RTE 2.3 系统服务 2.4 诊断服务 2.5 通信栈,35,诊断服务,诊断事件管理器 功能禁止管理器 开发错误跟踪器 诊断通信管理器,36,诊断事件管理器,诊断事件管理器负责处理和存储诊断事件（错误）和相关FreezeFrame数据。,37,功能禁止管理器,功能禁止管理器（Function Inhibition Manager ）负责提供软件组件和软件组件功能的控制机制。,38,开发错误跟踪器,开发错误跟踪器(Development Error
11、Tracer)主要用于在开发期间跟踪和记录错误。 API参数给出了追踪源和错误类型： 错误所在的模块 错误所在的功能 错误类型,39,诊断通信管理器,DCM在AUTOSAR体系结构中的位置,40,诊断通信管理器,诊断通信管理器（DCM）处在通信服务中（服务层）。 DCM与PDU路由器之间有一个接口。在通信过程中，DCM从PDU（Protocol Data Unit）路由器接收诊断消息。 DCM在其内部处理、检查诊断消息，并把消息传送到AUTOSAR SW组件进一步处理。,41,AUTOSAR软件结构内容,2.1 软件的组成与分层 2.2 RTE 2.3 系统服务 2.4 诊断服务 2.5 通信
12、栈,42,AUTOSAR通信栈,CAN（控制器局域网 ）COM（通信 ）FlexRayLIN（局部互联网络 ）,43,AUTOSAR 通信栈,44, AUTOSAR CAN CAN驱动 CAN接口 CAN传输层 CAN收发器驱动,CAN 控制器局域网,45,AUTOSAR CAN 分层体系结构,AUTOSAR CAN,46, CAN驱动为上层使用者提供统一的接口CAN接口。 CAN驱动尽可能合理地隐藏了相关CAN控制器的硬件专用性。 CAN驱动是最底层的一部分，为上层执行对硬件的访问和提供硬件无关的API。,CAN驱动,47, CAN接口提供标准化的接口，通过ECU的CAN总线系统来支持通信。
13、 CAN接口能够通过统一的接口访问一个或多个CAN驱动。 CAN接口仅能用于CAN通信。,CAN接口,48,CAN传输层是位于PDU路由和CAN接口模块之间的模块。其主要作用是分割和合并大于8字节的CAN I-PDU（交互层协议数据单元 ）。CAN传输层提供的服务有： 发送方向的数据分割； 接收方向的数据合并； 数据流控制； 分割期间内的错误检测。,CAN传输层,49, CAN收发器驱动负责处理ECU上的CAN收发器，根据是与整个ECU当前状态相关的总线专用NM的状态。 CAN收发设备驱动的目标：CAN收发设备驱动抽象使用CAN收发设备硬件芯片，向更高层提供硬件无关接口。,CAN收发器驱动,5
14、0,CAN API,51, AUTOSAR COM COM Manager,COM,52,AUTOSAR COM层位于RTE和PDU路由器之间。它来源于OSEK_COM标准。AUTOSAR COM提供了信号网关功能。,AUTOSAR COM,53,COM Manager（COM管理）是基本软件Basic Software（BSW）的一个组件。COM Manager控制的基本软件模块（BSW）与通信相关，而不是与软件组件或可运行实体相关。COM Manager从通信请求者那里收集总线通信访问请求，并协调总线通信访问请求。,COM Manager,54,COM Manager的目标是： 1、为用户
15、简化总线通信栈的使用。这包括了总线通信栈的初始化和简化的网络管理处理。 2、协调与多个软件组件（在一个ECU上）无关的总线通信栈（允许信号的发送和接收）的可用性。 3、临时性取消信号的发送以阻止ECU唤醒通信总线。 4、控制ECU的一个以上的通信总线通道，这通过为每个通道实现一种状态机制来实现。 5、提供使ECU保持总线处于“静默通信”模式。 6、通过分配对请求通信模式必需的所有资源来简化资源管理。,COM Manager,55,COM API,56,AUTOSAR COM与OSEK COM比较,根据通信部分提供的功能，对比两者在相同功能上的API，以及两者各自所特有的API。AUTOSAR
16、COM较之OSEK COM，多出了一个COM Manager，即通信管理模块部分，所以整个AUTOSAR COM Manager为AUTOSAR标准所特有。,57,AUTOSAR COM与OSEK COM比较,1. 相同功能及服务 （1）启动与控制服务,58,AUTOSAR COM与OSEK COM比较,两者在启动与控制服务部分的区别： AUTOSAR提供的API较多，表明它的功能较强； AUTOSAR的启动与控制服务中包含对I-PDU （交互层协议数据单元）的处理和控制，如Com_IpduGroupStart、Com_IpduGroupStop。,59,AUTOSAR COM与OSEK CO
17、M比较,（2）通信服务,60,两者在通信服务部分的区别： OSEK通信服务中包含了对错误的一些简单的处理，如获得错误服务的Id（COMErrorGetServiceId）。 AUTOSAR通信服务仍然包含对I-PDU的处理，如Com_TriggerIPDUSend。,AUTOSAR COM与OSEK COM比较,61,AUTOSAR COM与OSEK COM比较,（3）通知机制支持服务（OSEK）与回调通知服务（AUTOSAR）,两者在这个部分提供的功能差别不大，主要是对一些标志的修改和设置，以控制通信的状态和执行的功能。,62,AUTOSAR COM与OSEK COM比较,1. 不同功能及服
18、务,（1）OSEK为I-PDU的处理提供一类专门的服务，称为 OSEK间接网络管理接口，包含2个API： I-PDU传输指示（I_MessageTransfer）和I-PDU超时指示（I_MessageTimeOut）。（2）OSEK通信部分提供了一些例行程序对通信起扩展作用，包含3个API： StartCOMExtension、COMCallouts、COMErrorHook。,63,AUTOSAR COM与OSEK COM比较,（3）AUTOSAR提供了一些调度函数，主要是对消息或信号的接收或发送起路由、调度的作用，包含3个API：Com_MainFunctionRx、Com_MainFu
19、nctionTx、Com_MainFunctionRouteSignals。（4）AUTOSAR的通信部分有一个COM Manager，这是一个通信管理模块，是AUTOSAR标准特有的，主要负责对通信进行监控、管理、诊断以及管理涉及通信的ECU状态。下表列出了它所提供的部分API。,64,AUTOSAR COM与OSEK COM比较,65, AUTOSAR FlexRay FlexRay接口 FlexRay驱动 FlexRay传输层 FlexRay收发器驱动,FlexRay,66,AUTOSAR FlexRay 分层体系结构,AUTOSAR FlexRay,67,FlexRay接口提供一种标准
20、化的接口以访问FlexRay通信系统/硬件。FlexRay接口通过统一接口的对一个或几个FlexRay驱动进行访问。,FlexRay接口,68,FlexRay接口的主要任务有： 1、为上层提供到FlexRay通信系统的抽象接口。 2、FlexRay接口通过一个或多个硬件专用驱动模块来访问FlexRay硬件，而不是直接访问。 3、为了访问FlexRay通信控制器，FlexRay接口使用一个或多个FlexRay驱动模块。 4、为了访问FlexRay收发器，FlexRay接口使用一个或多个FlexRay收发器驱动模块。 5、FlexRay接口可执行代码与FlexRay通信控制器和FlexRay收发器
21、完全不相关。 6、FlexRay接口允许代码模块的对象代码提交，遵循“one-fits-all”原则。,FlexRay接口,69,FlexRay驱动模块为FlexRay接口模块、API的使用者提供统一接口，以访问FlexRay通信控制器，这些控制器的类型通常是相同的。FlexRay驱动是一个软件层，它将抽象功能请求映射到CC专用硬件的序列上。CC的硬件实现将由FlexRay接口隐藏。,FlexRay驱动,70,FlexRay传输层,FlexRay传输层为使用物理地址和功能地址的、分段式的确认过的和未确认过的1对1通信，以及分段式的未确认过的1对n通信提供支持。,FlexRay收发器驱动,Fle
22、xRay收发器驱动负责处理ECU上的FlexRay收发器，其依据是总线专用NM的状态。,71,FlexRay API,72, AUTOSAR LIN LIN驱动 LIN接口,LIN局部互联网络,73,AUTOSAR LIN 分层体系结构,AUTOSAR LIN,74,LIN驱动是最底层的一部分，执行硬件访问和为上层提供硬件无关的API。一个LIN驱动能够支持一个以上的通道。LIN驱动能够处理一个或多个属于相同LIN硬件单元的LIN通道。,LIN驱动,75,LIN接口是硬件无关的，它位于上层模块（PDU路由器）和下层模块（LIN驱动）之间。LIN接口可以处理一个以上的LIN驱动。一个LIN驱动能
23、够支持一个以上的通道。,LIN接口,76,LIN接口,LIN接口负责向上层提供的主要功能有： 1、为每个与ECU连接的LIN总线执行当前选择的调度。 2、当上层请求到来时，切换调度表。 3、从上层接收帧的传送，并传送数据部分作为适当LIN帧中的响应。 4、当相应的响应在适当的帧中接收时，为上层提供帧接收通知。 5、睡眠和唤醒服务 6、错误处理 7、诊断传输层服务,77,LIN API,78,内容,1、 AUTOSAR简介 2、 AUTOSAR软件结构 3、 AUTOSAR方法、模型、工具和一致性测试,79,AUTOSAR方法,AUTOSAR在系统开发的某些步骤需要通用的技术方法。这一方法就叫“
24、AUTOSAR方法”。 “AUTOSAR方法” 并没有定义“角色”和“责任”之类的东西，而且不规定要执行那些活动，并不定义整体的时间线，也并不定义迭代怎样和何时执行。 AUTOSAR方法仅仅是一个“工作产品流”（work-product flow），定义“工作产品流”中活动的相互依赖性。,80,图形表示,81,例：ECU从设计到构建、集成的过程,82,AUTOSAR模板,AUTOSAR模型属于UML2.0的一个子集，是UML2.0元模型的简化。 因为UML2中高度模块化的结构和对类、属性、关联重定义的过度使用，有时很难在用一两副图展现某个特定方面的同时又保持清晰的可读性。所以，这里简化了UML
25、2.0元模型，只包含部分元素。,83,AUTOSAR模板与UML的区别（部分）,84,AUTOSAR模板与UML的区别（部分）,85,例：一个简单模型,86,AUTOSAR工具,“AUTOSAR创作工具”是指所有支持解释、修改、创建用于描述系统的AUTOSAR XML描述（AUTOSAR模型的XML表示）的工具。 这些模型由以下模板产生： 软件组件模板， ECU资源模板， AUTOSAR系统模板。,87,AUTOSAR工具,88,当前较大的AUTOSAR商用工具提供商有： ETAS主要产品：ASCET系列 Mentor Graphics主要产品：Volcano系列 Vector主要产品：DaV
26、inci系列,AUTOSAR商用开发、设计工具,89,AUTOSAR商用开发、设计工具,90,例：ECU从设计到构建、集成的过程,91,业界动态,Volkswagen（大众汽车）公司已经通过使用Real-Time Workshop Embedded Coder从Simulink模型中自动产生相容软件，第一次将一个完全符合AUTOSAR标准的ECU整合到一个已有的Volkswagen ECU网络中。 Mentor公司和Volvo卡车公司宣布一项Autosar论证项目取得成功，从而把车载网络架构(VNA)用于设计流程之中 。,92,业界动态,BMW公司的AUTOSAR 概念车carIT和相关ECU,93,AUTOSAR一致性测试,AUTOSAR一致性测试的目的是为了验证产品是否符合AUTOSAR规范。这些产品需要在互操作性、重用/移植性、可扩展性上证明符合AUTOSAR标准。 一致性测试中的角色有： AUTOSAR Conformance Test Agency Product Supplier,94,AUTOSAR一致性测试,95,路径A,96,路径B,97,路径C,98,路径D,
