面向OEM的AUTOSAR应用与实施
- 格式:docx
- 大小:251.60 KB
- 文档页数:7
请选择Web Layout 浏览模式1.总体概述AUTOSAR(汽车开放系统架构),整车软件系统可以通过AUTOSAR架构对车载网络、系统内存及总线诊断进行深度管理,他的出现有利于整车电子系统软件的更新及交换,并改善系统的可靠性和稳定性.目前支持AUTOSAR标准的工具和软件供应商都已经推出了相应的产品,提供需求管理,系统描述,软件构件算法模型验证,软件构建算法建模,软件构件代码生成,RTE(Runtime Environment)生成,ECU配置以及基础软件和操作系统等服务,帮助OEM实现无缝的系统软件架构开发流程。
AUTOSAR计划目标主要有三个:1)建立独立于硬件的分层软件架构;2)为实施应用提供方法论,包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU;3)制定各种车辆应用接口规范,作为应用软件整合标准,以便软件构件在不同汽车平台复用。
2.分层概述AUTOSAR体系架构分层标准1)应用层(Application Layer)应用层中的功能由各软件组件SWC(software component)实现,组件中封装了部分或者全部汽车电子功能,包括对其功能的具体实现以及描述,比如控制汽车大灯、空调等部件的运作,但是与汽车硬件系统没有连接。
1.1)软件组件(software component)软件组件SWC(software component)是由Atomiccomponent(最小逻辑单元)组成。
Atomiccomponent最小逻辑单元有Application、Sensor/actuator(传感器/执行器)两种类型。
其中Application是算法实现了类型,能在ECU中自由映射;Sensor、Actuator是为Application提供的I/O端口类型,用于与ECU绑定,但不可像Application那样能在各ECU上自由映射。
数个SWC的逻辑集合组合成Composition。
autosar中同步、异步与线程的关系前言汽车电子系统日趋复杂,数量庞大、功能多样的E/E组件相互协调、互相合作,成为了汽车电子系统设计的关键问题。
针对这一问题,汽车工程领域提出了一种名为AUTOSAR (Automotive Open System Architecture)的标准化架构。
为了更好地理解和应用AUTOSAR 软件架构,需要深入了解其中的核心概念,本文着重介绍了AUTOSAR中同步、异步与线程之间的关系。
一、AUTOSAR基本概念AUTOSAR是一种汽车电子系统标准化架构,旨在为不同的OEM厂商提供标准化的软件架构,以便更好地整合和协调汽车电子各个方面的组件,提高汽车电子系统的可靠性和稳定性。
AUTOSAR定义了许多术语和概念,下面介绍几个基本概念。
(一)ECU计算机单元(ECU)是指安装在汽车上的电子控制装置,它负责控制和监测车辆的各项功能,如发动机控制、制动控制、空调控制等。
(二)SWC软件组件(SWC)是指AUTOSAR架构中的一个软件单元,它是ECU内部的一个独立模块,可以独立运行或组合成更复杂的应用程序。
(三)BswM基础软件管理(BswM)是指AUTOSAR架构中的一个基础软件组件,它负责管理ECU内部的所有SWC和对外部网络的通讯。
(四)CDD复杂驱动器器件(CDD)是指一种驱动器件的软件实现,它将底层的硬件驱动与高层应用程序分离,使得高层应用程序可以与不同的驱动器件相对独立地进行通讯和控制。
(五)RTE二、同步与异步的基本概念在AUTOSAR系统中,同步和异步通信是SWC之间进行消息传递的两种方式。
下面分别介绍这两种通信方式的基本概念。
(一)同步通信同步通信是指发送方和接收方之间的消息传递在时间上是同步的,即发送方发送消息后,必须等到接收方接收并处理完消息后,发送方才能继续执行后续的操作。
在AUTOSAR系统中,同步通信使用的是阻塞式方式,发送方发送消息后一直等待接收方处理完成,直到接收方返回确认消息,才能继续执行后续的操作。
autosar基本任务和扩展任务的叙述摘要:一、Autosar 基本任务介绍1.Autosar 基本任务的定义2.基本任务的功能与特点3.基本任务的实例二、Autosar 扩展任务介绍1.扩展任务的定义2.扩展任务的功能与特点3.扩展任务的实例三、Autosar 任务的应用领域1.汽车电子系统2.工业自动化领域3.其他实时操作系统应用场景正文:Autosar(Automotive Software Architecture)是一种汽车电子软件系统架构,旨在解决汽车电子系统日益复杂化带来的挑战。
在Autosar 中,任务是软件组件的基本单位,用于实现特定的功能。
根据任务的功能和范围,可以将其分为基本任务和扩展任务。
一、Autosar 基本任务介绍1.Autosar 基本任务的定义Autosar 基本任务是预定义的一组功能模块,用于实现汽车电子系统的基本功能。
它们可以直接应用于汽车电子系统的各个子系统,如动力系统、底盘系统、车身系统等。
基本任务的实例包括:Start/Stop、Ready、Error Handling 等。
2.基本任务的功能与特点(1)功能:基本任务提供了一组预定义的行为,用于实现特定的功能需求。
(2)特点:基本任务具有可重用性、可组合性和可裁剪性,可以根据实际需求进行配置和调整。
3.基本任务的实例(1)Start/Stop 任务:用于控制发动机的启动和停止。
(2)Ready 任务:用于检测系统是否准备好执行特定操作。
(3)Error Handling 任务:用于处理系统运行过程中出现的错误。
二、Autosar 扩展任务介绍1.扩展任务的定义扩展任务是在基本任务的基础上,根据特定应用场景的需求进行扩展和定制的一组功能模块。
扩展任务可以包含基本任务,也可以包含自定义的行为。
2.扩展任务的功能与特点(1)功能:扩展任务提供了基于基本任务的功能扩展,以满足特定应用场景的需求。
(2)特点:扩展任务具有较高的灵活性和可定制性,可以根据实际需求进行设计和调整。
autosar方法论详解什么是AUTOSAR?AUTOSAR(Automotive Open System Architecture,汽车开放式系统架构)是一种基于开放标准的汽车软件架构和方法论。
它是由全球主要的汽车制造商和电子设备供应商共同制定的,旨在提高汽车软件的可重用性、互操作性和可扩展性。
为什么需要AUTOSAR?在过去的几十年里,汽车电子设备的数量和复杂性不断增加,导致了软硬件开发的困难和成本上升。
传统的汽车软件开发方式通常是基于特定供应商的闭源解决方案,这导致了软件的高度定制化和低可重用性。
此外,不同供应商的软件往往无法互操作,从而限制了汽车制造商在选择和集成新技术方面的自由度。
AUTOSAR的目标是通过统一并开放软件架构,在整个汽车行业实现软件的高度重用性和互操作性。
它提供了一组规范和方法论,以供汽车制造商和供应商使用,使他们能够共同开发和集成复杂的汽车软件系统。
AUTOSAR的方法论AUTOSAR方法论是指在开发和集成汽车软件系统时所遵循的一系列规范和实践。
它包含了以下几个主要方面:1. 架构设计:AUTOSAR方法论鼓励使用面向服务的架构(Service Oriented Architecture,SOA),将整个汽车软件系统划分为多个独立的软件组件。
每个组件都提供特定的功能服务,并通过标准化的接口进行通信。
这样可以提高软件的可重用性和模块化程度。
2. 模型驱动开发:AUTOSAR方法论采用了模型驱动开发(Model-Driven Development,MDD)的方法。
开发人员使用特定的建模语言和工具来描述和分析汽车系统的软件需求,然后通过自动生成代码的方式来实现这些需求。
这样可以提高开发效率和代码质量,并减少错误。
3. 接口标准化:AUTOSAR方法论定义了一套标准化的软件接口,包括信号传输、错误管理、芯片通信等。
这些接口的标准化使得不同供应商的软件能够互操作,并方便进行系统集成和替换。
AutoSAR配置和实践AutoSAR(AUTomotive Open System ARchitecture)是一种汽车开放系统架构,旨在为汽车电子系统提供标准化的软件架构和工具链。
它被广泛应用于汽车ECU(Electronic Control Unit)软件开发中,以简化复杂系统的开发和集成。
AutoSAR的配置和实践涉及到多个方面,包括硬件抽象层(HDL)、运行时环境(RTE)、基础软件(BSW)和应用程序(SW-C)。
1. 硬件抽象层(HDL):这一层为ECU硬件提供了抽象描述,以便于软件的开发和部署。
在AutoSAR中,HDL的主要目标是定义ECU 的硬件接口,包括总线和外设接口。
2. 运行时环境(RTE):RTE是AutoSAR架构的核心,它提供了通信和同步机制,使得ECU中的软件组件能够相互协作。
RTE提供了标准化的API和框架,以便应用程序、基础软件和其他服务能够相互通信。
3. 基础软件(BSW):BSW是一组预定义的软件组件,为ECU提供了基本的操作系统功能,例如任务调度、内存管理、网络通信等。
这些组件可以由供应商根据需要进行配置和裁剪。
4. 应用程序(SW-C):SW-C是特定功能的软件组件,它们与应用程序相关。
在AutoSAR中,SW-C可以通过配置或手动编程实现。
在实践中,AutoSAR的配置通常涉及使用工具链中的工具对上述组件进行配置和集成。
这些工具通常提供图形用户界面,以便用户通过拖放组件、设置参数和配置连接来进行配置。
在完成配置后,工具可以生成代码、下载到硬件或进行模拟和验证等操作。
此外,AutoSAR还提供了一组标准化的接口和规范,以便不同供应商的软件组件能够相互协作。
这些规范包括通信协议、数据格式和服务接口等。
遵循这些规范可以确保软件的可移植性、可重用性和互操作性。
总之,AutoSAR的配置和实践是一个复杂的过程,需要深入了解硬件、操作系统和通信等方面的知识。
通过使用适当的工具和遵循规范,开发人员可以有效地开发和集成高质量的汽车ECU软件。
AUTOSAR架构深度解析AUTOSAR的分层式设计,⽤于⽀持完整的软件和硬件模块的独⽴性(Independence),中间RTE(Runtime Environment)作为虚拟功能总线VFB(Virtual Functional Bus)的实现,隔离了上层的应⽤软件层(Application Layer)与下层的基础软件(Basic Software),摆脱了以往ECU软件开发与验证时对硬件系统的依赖。
软硬件分离的分层设计,对于OEM及供应商来说,提⾼了系统的整合能⼒,尤其标准化交互接⼝以及软件组件模型的定义提⾼了各层的软件复⽤能⼒,从⽽降低了开发成本,使得系统集成与产品推出的速度极⼤提升。
AUTOSAR分层结构及应⽤软件层功能图中所⽰,算上复杂驱动层(Complex Device Drivers),AUTOSAR架构中共分六层:1. 应⽤软件层(Application Layer)2. 运⾏环境RTE(Runtime Environment)3. 服务层(Services Layer)4. ECU抽象层(ECU Abstraction Layer)5. 微控制器抽象层(Microcontroller Abstraction Layer)6. 复杂驱动(Complex Device Drivers)⾃上⽽下逐层介绍:应⽤软件层AUTOSAR的软件被组织在独⽴的单位软件组件(software-component)中,其中封装了部分或全部汽车电⼦的功能与⾏为,包括对具体模块功能的实现以及对应描述,但是对外界仅仅开放了定义好的接⼝,称之为PortPrototypes,⽽所有ECU内部组件之间的通信及获取其他ECU 资源的动作就都必须要通过接⼝来访问RTE来完成了。
应⽤软件层内的通信关系如下:1. 软件组件能和同⼀个ECU上其他软件组件通信2. 软件组件能和位于不同ECU上的其他软件组件通信3. 软件组件能和有端⼝并位于同⼀个ECU上的基础软件(BSW)进⾏通信虚拟功能总线VFB及运⾏环境RTE虚拟功能总线(VFB)是底层基础软件与⽹络拓扑结构的抽象,是AUTOSAR提供的所有通信机制的集合,在信息数据交互的过程中,应⽤程序被建模为组合组件。
Autosar AP 方法论和开发流程的最佳实践1. 介绍Autosar(Automotive Open System Architecture)是一种用于汽车电子系统开发的标准化架构。
在汽车行业中,Autosar已经成为了一种广泛采用的技术标准,通过统一软件架构,可以使汽车电子系统更加模块化、可重用和可伸缩。
在Autosar中,AP(Adaptive Platform)是针对汽车领域的自适应性应用的一种技术规范。
2. AP 方法论的概念和原则在Autosar AP方法论中,最佳实践是遵循一系列概念和原则,以确保汽车电子系统的可靠性、高效性和安全性。
其中包括:- 模块化设计:将系统划分为相互独立的模块,以便实现功能的高度复用和替换。
- 自适应性:能够根据外部环境和条件自动调整系统功能和性能。
- 安全性和可靠性:确保系统在各种工作状态下都能够保持稳定、可靠和安全。
3. AP 方法论的开发流程在实际的开发过程中,遵循AP方法论的最佳实践,可以采用以下开发流程:- 需求分析:从用户需求、市场需求和技术需求等方面进行全面、深入的分析,以确保系统设计能够满足各项需求。
- 架构设计:根据需求分析的结果,进行系统架构设计,将系统划分为模块,并定义模块之间的接口和关系。
- 模块开发:根据架构设计,进行模块的开发和编码,确保模块功能的完整性、可靠性和安全性。
- 整合测试:将各个模块进行整合,进行系统级的测试,以验证系统功能的完整性和稳定性。
- 验收测试:在实际环境中对系统进行验收测试,确保系统能够在实际工作条件下正常运行。
4. 对AP方法论的个人观点和理解作为汽车电子系统领域的专家,我认为遵循AP方法论的最佳实践是极其重要的。
汽车电子系统作为汽车的核心组成部分,其安全性、稳定性和可靠性对整个汽车的安全和性能起着至关重要的作用。
只有通过遵循AP方法论的最佳实践,才能够确保汽车电子系统的高效运行和长期稳定性。
总结回顾通过对Autosar AP方法论和开发流程的讨论,我们了解到了AP方法论的概念、原则和具体开发流程。
autosar标准AUTOSAR标准。
AUTomotive Open System ARchitecture(汽车开放系统架构)简称为AUTOSAR,是一个由汽车行业联盟(Automotive Industry Alliance)成员共同制定的标准。
该标准的目的是为了提高汽车电子系统的可重用性、可扩展性和可靠性,从而降低汽车电子系统的开发成本和时间。
AUTOSAR标准的制定得到了包括宝马、戴姆勒克莱斯勒、福特、通用汽车、大众汽车等在内的众多汽车制造商和供应商的支持和参与。
AUTOSAR标准的核心是基于标准化的软件架构,其中包括了汽车电子控制单元(ECU)之间的通信协议、软件组件的定义和架构、以及软件开发工具链的规范。
通过AUTOSAR标准,不同厂家的汽车电子系统可以更好地进行集成,从而提高整车系统的可靠性和稳定性。
AUTOSAR标准的实现主要包括了以下几个方面:1. 架构,AUTOSAR标准定义了一个通用的汽车电子系统架构,其中包括了应用软件、基础软件和硬件的分层结构。
这种分层结构可以使不同厂家的软件和硬件更加容易地进行集成和替换。
2. 通信,AUTOSAR标准规定了汽车电子控制单元之间的通信协议,其中包括了CAN、LIN、FlexRay等总线协议。
这些通信协议的标准化可以使不同厂家的ECU之间更加容易地进行通信和数据交换。
3. 软件组件,AUTOSAR标准定义了一套通用的软件组件模型,包括了应用软件组件和基础软件组件。
这些软件组件可以在不同的汽车电子系统中进行重用,从而提高软件开发的效率和质量。
4. 工具链,AUTOSAR标准规定了一套通用的软件开发工具链,包括了软件建模、代码生成、调试和测试等工具。
这些工具的标准化可以使不同厂家的软件开发人员更加容易地进行协作和交流。
总的来说,AUTOSAR标准的实现可以使汽车制造商和供应商更加容易地进行合作和集成,从而降低整车系统的开发成本和时间。
同时,AUTOSAR标准还可以提高汽车电子系统的可靠性和稳定性,从而提高整车的安全性和性能。
AUTOSAR背景介绍AUTOSAR是英文AUTomotive Open Systems ARchitecture的缩写,中文意思是汽车开放系统架构,它定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案,以便应用于不同的汽车平台,提高软件复用,降低开发成本。
AUTOSAR是由汽车OEM和其一线供应商建立的汽车软件开发全球合作联盟,于2003年夏天正式成立,并于2004年启动了主要的工作,其目的就在于控制汽车软件的复杂性和多样性。
AUTOSAR包括9个核心成员:BMW Groups(宝马)、BOSCH(博世)、Continental (大陆)、DAIMLER(戴姆勒)、Ford(福特)、GM(通用)、PSA Peugeot Citron(标志-雪铁龙)、TOYOTA(丰田)、VOLKSWAGEN AG(大众)。
目前其成员已超过150个,国内OEM中已有一汽及上汽加入,恒润科技成为继一汽、上汽之后,国内第三家加入该组织的公司。
AUTOSAR自面世以来,从半导体工业、工具和软件厂商、零部件供应商到汽车制造商本身,整个汽车领域内的价值体系都给予该标准积极的推动。
AUTOSAR开发成员在2007年发布了2.1版本,使AUTOSAR的发展到达了一个稳定的阶段,随后通过几个不同的开发项目对AUTOSAR的实用性进行了测试,现在AUTOSAR已经做好进入到产品ECU 的准备,而宝马集团已将符合AUTOSAR标准的ECU(电子控制单元)应用在全新BMW 7系量产车型中,预计在2010年AUTOSAR的所有核心成员都将推出相关的产品。
在商业领域里,支持AUTOSAR标准的工具和软件供应商已推出了相应的工具和软件,提供需求管理,系统描述,软件构件算法模型验证,软件构件算法建模,软件构件代码生成,RTE 生成,ECU配置以及基础软件和操作系统等服务,帮助OEM实现无缝的AUTOSAR系统软件架构开发流程。
面向OEM的AUTOSAR应用与实施一、 AUTOSAR背景介绍AUTOSAR是英文AUTomotive Open Systems ARchitecture的缩写,中文意思是汽车开放系统架构,它定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案,以便应用于不同的汽车平台,提高软件复用,降低开发成本。
AUTOSAR是由汽车OEM和其一线供应商建立的汽车软件开发全球合作联盟,于2003年夏天正式成立,并于2004年启动了主要的工作,其目的就在于控制汽车软件的复杂性和多样性。
AUTOSAR包括9个核心成员:BMW Groups(宝马)、BOSCH(博世)、Continental(大陆)、DAIMLER(戴姆勒)、Ford(福特)、GM(通用)、PSA Peugeot Citroën(标志-雪铁龙)、TOYOTA(丰田)、VOLKSWAGEN AG(大众)。
目前其成员已超过150个,国内OEM中已有一汽及上汽加入,零部件供应商恒润科技成为继一汽、上汽之后,国内第三家加入该组织的公司。
AUTOSAR自面世以来,从半导体工业、工具和软件厂商、零部件供应商到汽车制造商本身,整个汽车领域内的价值体系都给予该标准积极的推动。
AUTOSAR开发成员在2007年发布了2.1版本,使AUTOSAR的发展到达了一个稳定的阶段,随后通过几个不同的开发项目对AUTOSAR的实用性进行了测试,现在AUTOSAR已经做好进入到产品ECU的准备,而宝马集团已将符合AUTOSAR标准的ECU(电子控制单元)应用在全新BMW 7系量产车型中,预计在2010年AUTOSAR的所有核心成员都将推出相关的产品。
在商业领域里,支持AUTOSAR 标准的工具和软件供应商已推出了相应的工具和软件,提供需求管理,系统描述,软件构件算法模型验证,软件构件算法建模,软件构件代码生成,RTE生成,ECU配置以及基础软件和操作系统等服务,帮助OEM实现无缝的AUTOSAR系统软件架构开发流程。
目前AUTOSAR 版本为3.1版,预计将于2009年秋季发布4.0版本。
由于AUTOSAR提倡“在标准上合作,在实现上竞争”的原则,其核心思想在于“统一标准、分散实现、集中配置”,所以采用AUTOSAR将为OEM带来很大的好处,这将使得他们对于软件采购和控制拥有更灵活和更大的权利,因为软件系统的标准化和开放化将使更多的软件供应商进入汽车电子行业,从而使得他们有更多的选择,同时软件的质量监督也会相应提高,有利于提高他们的产品质量。
但是,也必须看到在全行业内推行此标准还是存在潜在障碍的,就是来自一些OEM厂商和大的第一级汽车供应商的抵制,因为他们已经有自己的标准和架构了,而采用AUTOSAR标准及其架构可能产生更换成本、丧失控制等风险。
尽管如此,汽车电子软件开发方法和软件架构的标准化是汽车行业不可阻挡的发展趋势,而且目前还没有哪种标准比AUTOSAR标准走的更远。
鉴于此,国内汽车OEM必须做好应对AUTOSAR的准备,这对他们来说,是挑战更是机遇。
在AUTOSAR标准的实施过程中,OEM将起主导作用。
OEM应如何提出需求并在他们的产品上使用这些来自不同供应商的具有标准功能和接口的软件呢?AUTOSAR为此同时制定了方法上、流程上的标准,即AUTOSAR方法论。
本文将着重解读AUTOSAR方法论内容,讲解OEM应如何将该标准应用在他们的产品研发及生产过程中。
二、 AUTOSAR 技术概述AUTOSAR的计划目标主要有3项,第一是建立独立于硬件的分层的软件架构;第二是为实施应用提供方法论,包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU中;第三是制定各种车辆应用接口规范,作为应用软件整合标准,以便软件构件在不同的汽车平台上的复用。
1、AUTOSAR软件架构为了实现AUTOSAR的目标,即实现应用程序和基础模块之间的分离,汽车电子软件架构被抽象成几个层,如图1所示。
图1:AUTOSAR软件架构层次图为了区别软件依赖和硬件依赖,基础软件分为四个层次:服务层(Services Layer)、ECU 抽象层(ECU Abstraction Layer)、微控制器抽象层(Microcontroller Abstraction Layer)和RTE (Runtime Environment)。
除此四层外,在AUTOSAR软件架构中还有复杂驱动(Complex Driver),由于对复杂传感器和执行器进行操作的模块涉及到严格的时序问题,在AUTOSAR 中这部分没有被标准化。
∙服务层提供包括诊断协议、存储管理、ECU模式管理和操作系统等在内的系统服务。
除了操作系统外,服务层的软件模块都是与平台无关的。
∙ECU抽象层将ECU结构(如外设与ECU的联接方式等)进行了抽象处理。
该层与ECU 平台相关,但与微控制器无关。
∙微控制器抽象层包括微控制器相关的驱动(如I/O驱动、ADC驱动等)。
∙RTE层负责AUTOSAR软件构件(即应用层)相互间的通信以及软件构件与基础软件之间的通信。
RTE层之下的基础软件对于应用层来说是不可见的,必须通过RTE进入,它将软件构件从对底层软件和硬件平台的依赖中独立出来,实现了应用程序和基础软件之间的分隔。
2、AUTOSAR方法论AUTOSAR为符合该标准的汽车电子软件系统开发过程定义了一套通用的技术方法,这种方法即被称为AUTOSAR方法论(AUTOSAR Methodology)。
汽车OEM作为整车系统功能的规划和设计者,需要了解并掌握AUTOSAR提供的这套开发流程,才能主导和推进符合AUTOSAR标准的系统的开发过程。
兼容AUTOSAR标准的汽车电子软件系统设计与开发流程如图2所示。
图2 :AUTOSAR系统设计与开发流程主要步骤可划分两个阶段:第一个阶段是系统配置阶段,这属于系统级设计决策工作。
首先是编写系统配置输入文件,为XML类型的文件。
应用软件的描述术语在AOTUSAR中为软件构件(Software Components),该文件将确定需要使用的软件构件(即系统具有哪些功能)和硬件资源(ECU),以及整个系统的约束条件。
AUTOSAR提供了一系列的模板(软件构件模板,ECU资源模板和系统模板)和标准的信息交换格式,工具供应商可据此提供相应的工具支持,从而简化系统设计的工作,最终系统设计者只需要使用工具填充或编辑相应的模板即可导出系统配置输入文件。
系统配置输入包含三部分内容,第一个输入是软件构件描述,定义每个需要的软件构件的接口内容,包括数据类型,端口,接口等;第二个输入是ECU资源描述,定义了每个ECU 的资源需求,如处理器、外部设备、存储器、传感器和执行器等;第三个输入是系统约束描述,定义总线信号,拓扑结构和软件构件的映射关系。
系统配置阶段接下来的工作是将初步获得的系统配置输入文件借助系统配置生成器生成系统配置描述文件,同样为XML文件,这是系统配置阶段的最终工作成果。
该文件将包含所有的系统信息,包括将软件构件映射到相关的ECU上(这种映射需要考虑到构件的需要、构件的连接、资源需求以及约束条件,有时也需要考虑成本等方面的因素),以及通信矩阵(整车的网络结构、时序以及网络数据帧的内容)。
第二个阶段是ECU的配置,这阶段的工作需要对系统中每个ECU分别进行。
首先是使用第一个阶段的工作成果——系统配置描述文件,从中提取出与各个ECU相关的系统配置描述信息,提取的信息包括ECU通信矩阵、拓扑结构、顶级功能组合(据此产生需映射到该ECU 上的所有软件构件),将放在另一个XML文件中。
提取信息的工作可借助工具完成。
然后进入ECU配置的实际工作中,这一步负责往输入对象中添加具体应用所必需的信息,如任务调度、必要的BSW模块、BSW配置信息、给任务分配的可运行实体等。
这一步的结果被放在ECU 配置描述文件中,它包含了具体ECU所需的所有信息。
最后一步是生成具体ECU的可执行程序,此步将根据ECU 配置描述文件中的配置信息构建完成ECU的基础软件的设置和与基于AUTOSAR构件的应用软件的集成,最终生成ECU的可执行代码。
此外,要说明的是,AUTOSAR系统的设计过程使用了虚拟功能总线(Virtual Functional Bus)的概念。
虚拟功能总线(Virtual Functional Bus)将AUTOSAR软件构件相互间的通信以及软件构件与基础软件之间的通信进行了抽象,同时使用预先定义的标准接口。
而对于虚拟功能总线来说,ECU内部通信和外部总线通信并没有什么区别,这种区别要等到系统布局以及ECU的具体功能最终确定才会体现出来。
软件构件本身对于这种区别并不关注,因此我们可以在独立的情况下开发软件构件。
在系统实现过程中,虚拟功能总线所代表的功能最终以RTE的生成来体现。
3、标准化的应用接口通过RTE实现AUTOSAR软件构件(即应用程序)相互间的通信以及软件构件与基础软件之间的通信的前提是,软件构件必须具有标准的AUTOSAR接口。
目前,AUTOSAR 3.1版已定义了一些典型的汽车电子应用领域(动力,车身/舒适和底盘)的标准接口。
AUTOSAR按照功能逻辑分别将这些领域的系统划分成若干个模块,这些模块可被视为一个软件构件或多个软件构件的组合,这些功能性的软件构件的接口被明确定义,所定义的接口的内容包括名称,含义,范围,数据类型,通信类型,单位等。
应用软件开发者在软件构件的设计与开发时需要应用这些接口定义。
这里以车身/舒适系统的雨刷管理的软件构件的接口定义为示例,如图3:图3 :软件构件的接口定义说明:雨刷管理构件(WiperWasherManager)有两个接口,CmdWashing 和StaWasher,图中WWManager表示为雨刷管理软件构件的实例。
针对CmdWashing接口定义了以下信息:1) CmdWashing接口由WiperWasherManager构件提供,其数据内容为FrontWasher构件的Activation接口所使用。
2)CmdWashing包含一个“Command”的数据元素。
3)“Command”的数据类型为“t_onoff”。
4)“t_onoff”属于“RecordType”,该类型描述一般的开/关信息。
应用软件开发者应该意识到,面向AUTOSAR运行时环境(RTE)接口的应用软件设计的重要性,及早地将AUTOSAR应用层接口引入到实际的项目中来,为实现应用软件的可复用性做好准备,从而优化整个软件开发流程。
三、设计应用与实施仍以车身/舒适领域的外部车灯控制系统的设计为例,在本例中只涉及转向灯的闪烁控制功能的实现。