作者：宋珂、王民、单忠伟、谭杨 编著
出版社：化学工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
AUTOSAR规范与车用控制器软件开发试读：
前言
汽车电子技术已成为汽车各方面功能拓展、性能提升的重要技术支撑。随着汽车新能源化与智能化的逐步推进，汽车电子技术的功能需求将不断增加，控制软件也将变得越来越复杂。为了提升软件复用度，提高软件开发质量与效率并降低开发风险与成本，由全球汽车制造商、零部件供应商及其他半导体和软件系统公司联合建立了汽车开放系统架构联盟（AUTomotive Open System ARchitecture，AUTOSAR），并联合推出了一个开放的、标准化的汽车嵌入式系统软件架构——AUTOSAR规范。
AUTOSAR规范在国外的应用已经较为普遍和成熟，随着AUTOSAR规范的认可度越来越高，它有望成为整个汽车电子行业普遍使用的软件标准。近年来，随着国内一些企业纷纷加入新能源汽车“三电”相关控制器的研发，控制器正向开发需求不断增加，AUTOSAR规范在国内的应用也进入了一个高潮，基于AUTOSAR平台可以使得开发者更高效、更高质量地完成汽车嵌入式系统软件的开发。
本书中笔者以通俗易懂的语言、形象的图解展现了AUTOSAR中一些复杂的概念问题，并精心设计了一个示例作为本书的开发对象。笔者主要以ETAS AUTOSAR系统解决方案为基础，以AUTOSAR方法论为线索，详细介绍了基于AUTOSAR工具链完成车用控制器软件开发的具体流程与方法，并将基本概念融入开发过程介绍，加深读者的印象，提升读者的感性认识和认知水平。最后，还剖析了AUTOSAR对功能安全的支持情况，并对AUTOSAR与信息安全以及Adaptive AUTOSAR平台进行了介绍。
本书共分为10章。第1章介绍了汽车电子控制系统的发展史、应用现状和基本构成，并提出了当下车用控制器软件所面临的问题。第2章介绍了AUTOSAR的基础理论知识，详细介绍了AUTOSAR分层架构、软件组件、虚拟功能总线、方法论及应用接口。第3章介绍了本书示例的开发需求、设计方案以及本书所采用的AUTOSAR系统解决方案，起到承上启下的作用；第4～8章详细介绍了AUTOSAR方法论的具体实施过程，以方法论为“纲”，各阶段配置开发为“目”，纲举目张，便于读者理解开发过程中每个阶段的作用，并学会AUTOSAR工具链的基本使用方法。其中，第4章主要讲述了使用Matlab/Simulink进行应用层软件组件开发以及符合AUTOSAR规范的代码和描述文件配置生成方法。第5章主要讲解了使用ETAS ISOLAR-A工具进行AUTOSAR系统级设计与配置的方法。第6章详细阐述了本书示例所涉及的基础软件模块和运行时环境的基本概念，以及基于ETAS RTA系列工具进行AUTOSAR ECU级开发的具体方法，包括CAN通信协议栈、ECU状态管理器、BSW模式管理器、运行时环境RTE、操作系统OS等常用模块。第7章则详细介绍了本书示例所用到的微控制器抽象层MCAL各模块的基本概念、配置及接口代码实现方法，基本覆盖了所有常用的MCAL模块。第8章介绍了AUTOSAR工程代码集成与调试方法，并展示了本书示例的开发结果。第9章和第10章主要介绍了AUTOSAR与功能安全、AUTOSAR与信息安全以及Adaptive AUTOSAR平台的相关内容，作为本书内容的拓展外延。
本书第1章～第7章由同济大学宋珂、单忠伟编写，第8章由ETAS谭杨编写，第9章与第10章由上海捷能汽车技术有限公司王民编写，书中示例由同济大学宋珂、单忠伟设计开发。全书由宋珂统稿，王民及ETAS ERS部门高级经理汤易负责审阅。
在本书编写过程中得到了ETAS公司、恩智浦半导体公司和MathWorks公司的支持！
本书适合具有一定嵌入式软件开发基础知识的读者阅读，可作为高等院校本科生、研究生学习AUTOSAR规范以及符合AUTOSAR规范的车用控制器软件开发方法的参考书，也可以作为汽车电子行业软件工程师学习参考的资料。
本书中所有内容都经过ETAS公司、恩智浦半导体公司和MathWorks公司相关专家的审阅，且本书示例经过笔者亲自测试验证。但由于我们水平有限，书中难免会出现疏漏或不当之处，诚望读者批评和指正。编著者第1章 汽车电子控制系统介绍
如今，电子技术在汽车中的应用日益广泛，汽车电子已成为汽车领域最热门的话题与研究方向之一。作为全书的引子，本章先介绍电子技术在汽车上的应用、汽车电子控制系统的基本构成以及车用控制器软件标准。1.1 电子技术在汽车上的应用1.1.1 汽车电子技术的发展历史
汽车电子技术的发展史是一段以电子技术发展为基础，以人们对汽车功能需求的日益增长为驱动力的发展史，其大致可以分为以下四个阶段。
第一个发展阶段：从20世纪50年代中期到70年代中期，这是汽车电子技术发展的起始阶段。在那时，一些汽车厂家开始研发一些单一的电子零部件，用来改善汽车上某些机械部件的性能，以及采用一些简单的电子设备来取代以前的机械部件，如整流器、电压调节器、交流发电机、晶体管无触点点火装置、电子喇叭、数字钟、汽车收音机等都是这一阶段出现的具有代表性的汽车电子装置。
第二个发展阶段：从20世纪70年代末期到80年代初期，以集成电路和16位以下的微处理器在汽车上的应用为标志，主要是开发汽车各系统专用的独立控制部分，电子装置被应用在某些机械装置无法解决的复杂控制功能方面。这期间最具代表性的是电子控制汽油喷射技术的发展和防抱死制动技术的成熟。该阶段涌现的其他汽车电子技术还包括自动门锁、高速警告系统、自动除霜控制、撞车预警传感器、电子正时、电子变速器、闭环排气控制、自动巡航控制、防盗系统等。
第三个发展阶段：从20世纪80年代中期到90年代初期，随着大规模集成电路技术的快速发展和微处理器在控制技术方面的应用，汽车电子技术迅速发展。此阶段主要是开发可以完成各种功能的综合系统，如集发动机控制与自动变速器控制为一体的动力传动控制系统、制动防抱死系统与驱动防滑转控制系统等。
第四个发展阶段：从20世纪90年代中期至今，随着计算机运算速度和存取位数的提高以及车载网络与通信技术的迅速发展，车辆的智能控制和网络控制技术应运而生，它们给汽车赋予了更多的“想象力”。在当今汽车“电动化、网联化、智能化、共享化”的过程中，几乎任何一项新技术的诞生都离不开汽车电子技术的身影。1.1.2 汽车电子技术的应用现状
目前，汽车电子技术主要应用于动力传动总成电子系统、底盘电子系统、车身电子系统、汽车通信与娱乐电子系统等。（1）动力传动总成电子系统
①对于传统汽车而言，动力传动总成电子控制系统主要包括：发动机管理系统（Engine Management System，EMS）、自动变速器控制系统（Automatic Transmission Control System）等。
②对于新能源汽车而言，则主要包括：整车控制器（Vehicle Control Unit，VCU）、混合动力控制单元（Hybrid Control Unit，HCU）、驱动电动机控制器（Motor Control Unit，MCU）、电池管理系统（Battery Management System，BMS）、燃料电池发动机控制系统（Fuel Cell Engine Control System，FCECS）等。
它们主要是保证汽车动力系统在不同的工况下均能在最佳状态下运行，从而降低能耗，并简化驾驶员的操作，减轻驾驶员的劳动强度，以此来提高汽车的动力性、经济性和舒适性。（2）底盘电子系统
汽车底盘由传动系统、行驶系统、转向系统和制动系统四大系统组成，随着电子技术在汽车中的广泛应用，使汽车底盘的控制正在快速地向电子化、智能化和网络化方向发展，从而出现了许多汽车底盘电子控制系统。常用的控制系统如下。
①牵引力控制系统（Traction Control System，TCS）。
②电子稳定控制系统（Electronic Stability Control，ESC）。
③电控悬架系统（Electronic Control Suspension System，ECS）。
④定速巡航系统（Cruise Control System，CCS）。
⑤自适应巡航控制系统（Adaptive Cruise Control，ACC）。
⑥电动助力转向系统（Electric Power Steering，EPS）。
⑦防抱死制动控制系统（Anti-lock Braking System，ABS）。
⑧电子制动力分配系统（Electronic Brakeforce Distribution，EBD）。
⑨电子控制制动辅助系统（Electronic Brake Assist，EBA）。
⑩自动紧急制动系统（Autonomous Emergency Braking，AEB）。车道偏离预警系统（Lane Departure Warning，LDW）。车道保持辅助系统（Lane Keeping Assist，LKA）。（3）车身电子系统
车身电子控制系统主要用于增强汽车的安全性与舒适性，常用的如下。
①自动采暖通风和空调系统（Heating，Ventilation and Air-Conditioning System，HVAC）。
②胎压检测系统（Tire Pressure Monitoring System，TPMS）。
③安全气囊系统（Supplemental Restraint System，SRS）。
④座椅位置调节系统（Seat Adjustment Position Memory System，SAMS）。
⑤雷达车距报警系统（Radar Proximity Warning System，RPWS）。
⑥倒车报警系统（Reverse Vehicle Alarm System，RVAS）。
⑦前部碰撞预警系统（Forward Collision Warning System，FCWS）。
⑧盲点监测系统（Blind Spot Detection，BSD）。
⑨停车辅助系统（Parking Assist System，PAS）。
⑩中央门锁控制系统（Central Locking Control System，CLCS）。防盗报警系统（Guard Against Theft and Alarm System，GATA）。自适应前照灯系统（Adaptive Front-lighting System，AFS）。夜视辅助系统（Night View Assist，NVA）。疲劳驾驶预警系统（Driver Fatigue Monitor System，DFMS）。（4）汽车通信与娱乐电子系统
汽车通信与娱乐电子系统主要用于提升驾乘人员的舒适性，常用的如下。
①北斗导航系统（BeiDou Navigation Satellite System，BDS）。
②全球定位系统（Global Positioning System，GPS）。
③汽车音响（Amplifier）。
④收音机（Radio）。
⑤车载电话（Car Telephone，CT）。
⑥抬头显示（Head Up Display，HUD）。
⑦人机界面（Man Machine Interface，MMI）。
可见，电子技术在汽车中的应用越来越广泛，汽车电子控制技术已成为支撑现代汽车发展的关键技术之一。将来，随着汽车“电动化、网联化、智能化、共享化”进程的全面推进，电子技术在汽车中的应用将越来越广泛，汽车电子行业的前景尤为广阔。1.2 汽车电子控制系统的基本构成
汽车电子控制系统主要由传感器（Sensor）、电子控制单元（Electronic Control Unit，ECU）和执行器（Actuator）组成（图1.1），对被控对象（Controlled Object）进行控制。图1.1 汽车电子控制系统的基本构成（1）传感器
为信号输入装置，其作为汽车电子控制系统的信息源。传感器用来检测和采集各种信息，如温度、压力、转速等，并通过一定转换装置将一些非电量信号（物理量、化学量等）转换为电信号传给电子控制单元。（2）电子控制单元（ECU）
也可称为汽车嵌入式系统（Automotive Embedded System，AES），是汽车电子控制系统的核心。ECU对传感器的信号进行处理，通过控制算法向执行器发出控制指令。电子控制单元一般由硬件和软件两部分组成，硬件部分主要由微控制器（Microcontroller，MCU）及外围电路组成；软件部分主要包括硬件抽象层（Hardware Abstraction Layer，HAL）、嵌入式操作系统及底层软件和应用软件层。（3）执行器
执行器为执行某种控制功能的装置，用于接收来自ECU的控制指令，并对控制对象实施相应的操作。1.3 车用控制器软件标准（从OSEK到AUTOSAR）
为了迎合汽车高精度、高实时性、高可靠性控制的需要，嵌入式实时操作系统（Real Time Operating System，RTOS）逐渐在ECU中使用。与此同时，由于不同实时操作系统间应用程序接口（Application Programming Interface，API）的各不相同，出现应用程序的移植性差等问题。于是，在1993年德国汽车工业界提出了OSEK（Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug），其英语全称为Open Systems and the Corresponding Interfaces for Automotive Electronics，中文名称为汽车电子开放式系统及其接口标准。该体系最初得到了宝马、博世、戴姆勒-克莱斯勒、西门子、大众等公司的支持。1994年，随着标致和雷诺加入该体系，他们将法国汽车工业使用的汽车分布式执行标准（Vehicle Distributed eXecutive，VDX）也纳入该体系，并在1995年的研讨会上得到共识，从而产生了OSEK/VDX标准。
OSEK/VDX标准包括以下七个部分。
①OSEK/VDX操作系统规范（OSEK Operating System，OSEK OS）。
②OSEK/VDX通信规范（OSEK Communication，OSEK COM）。
③OSEK/VDX网络管理规范（OSEK Network Management，OSEK NM）。
④OSEK/VDX实现语言规范（OSEK Implementation Language，OSEK IL）。
⑤OSEK/ORTI运行时接口规范（OSEK Run Time Interface）。
⑥OSEK-Time时间触发操作系统规范（OSEK Time-Triggered Operating System）。
⑦OSEK FTCom容错通信规范（OSEK Fault-Tolerant Communication）。
OSEK/VDX标准在一定程度上使得应用层软件与底层软件分离，提升了应用软件的可移植性；其次，使用符合OSEK/VDX标准的嵌入式操作系统可以提高代码的复用率，提升开发效率、降低开发成本。但由于不同整车企业和零部件供应商缺乏兼容性工具，使得开发者需要花费大量的时间在基础软件的实现和优化上，并且对于新的需求，需要花费大量的精力调整软件的接口。总之，OSEK/VDX标准还是没能解决跨平台化高效地进行嵌入式系统软件的移植。
在之后的一段时间里，随着汽车分布式嵌入式系统软件复杂度的迅速增长，汽车工业界开始逐步探索从原有的以硬件设计和组件驱动为主的设计方式向以需求设计和功能驱动为主的系统开发方法转变。在该进程中，比较有代表性的是EAST-EEA项目，它是ITEA（International Test and Evaluation Association）资助的面向汽车领域嵌入式系统架构的研究项目，其目标是通过建立面向汽车工业的通用嵌入式系统架构，实现接口的标准化并提升复杂系统开发的质量与效率。最终，EAST-EEA项目定义了一个分层的软件架构，并提出了一个“中间件”的层次来提供支持嵌入式系统模块在不同平台之间移植的接口和服务；并且，EAST-EEA项目还定义了公共的架构描述语言（Architecture Description Language，ADL）。EAST-EEA项目的研究成果可谓是AUTOSAR规范的雏形。1.4 本章小结
本章首先回顾了汽车电子技术的发展史，并详细介绍了电子技术在汽车中的应用现状，进而分析了汽车电子控制系统的基本构成。之后，介绍了车用控制器软件标准——OSEK标准，并揭示了车用控制器软件开发所面临的问题与挑战。通过本章的学习，可以较为全面地认识汽车电子控制系统的发展与应用现状、基本构成以及软件开发标准。第2章 AUTOSAR规范基础理论
AUTOSAR规范作为汽车嵌入式系统软件的通用性规范，在软件架构、软件开发流程等方面都定义了众多新概念，掌握这些理论知识是进行符合AUTOSAR规范的软件开发的基础。所以，本章从AUTOSAR的由来及发展历程着手，详细介绍AUTOSAR规范中三块主要内容，即分层架构、方法论与应用接口，并对其中软件组件与虚拟功能总线的概念进行详细剖析。2.1 AUTOSAR的由来与发展历程2.1.1 AUTOSAR的由来
如前所述，电子技术在动力总成控制、底盘控制、车身控制以及车载信息娱乐系统等各个部分所占的比重越来越大，所占的整车成本也越来越高。电子技术已悄然成为汽车各方面功能拓展和性能提升的重要技术支撑。
由于汽车电子硬件系统的多样性，ECU软件的开发受到硬件系统的制约，每当需要更新硬件时，都会导致ECU软件重新编写或大规模修改，之后还要进行一系列测试，从而导致了高昂的研发费用与漫长的研发周期。
目前，汽车电子网络正向多总线混合网络互联方向发展；电控系统硬件正向专业化、高集成度、高性能方向发展，其软件架构也正向模块化、平台化、标准化方向发展。并且，未来随着汽车新能源化和智能化的普及，以及对于一些非功能需求的增加，汽车电子/电气系统的复杂度也将进一步提升。这都将进一步导致新产品开发周期、成本的急剧增加。整车厂为了降低汽车控制软件开发的风险，于是开始寻找提高软件复用度的方法。
为解决上述问题，基于先前EAST-EEA项目的研究成果，在2003年，由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立了汽车开放系统架构联盟（AUTomotive Open System ARchitecture，AUTOSAR），并联合推出了一个开放化的、标准化的汽车嵌入式系统软件架构——AUTOSAR规范。如图2.1所示，与传统ECU软件架构相比，AUTOSAR分层架构的高度抽象使得汽车嵌入式系统软硬件耦合度大大降低。图2.1 传统软件架构与AUTOSAR架构对比
AUTOSAR规范的出现，将带来如下主要优势：
①有利于提高软件复用度，尤其是跨平台的复用度；
②便于软件的交换与更新；
③软件功能可以进行先期架构级别的定义和验证，从而能减少开发错误；
④减少手工代码量，减轻测试验证负担，提高软件质量；
⑤使用一种标准化的数据交换格式，方便各公司之间的合作交流等。
这些优势对将来愈发复杂的汽车嵌入式系统软件的开发过程可谓是大有裨益，在保证软件质量的同时，可以大大降低开发的风险与成本。2.1.2 AUTOSAR的原则及核心思想
AUTOSAR联盟自成立至今，一直提倡“在标准上合作，在实现上竞争”的原则，标准大家共同制定，但具体的实现方法是由各公司自己去探索的。其核心思想在于“统一标准、分散实现、集中配置”。“统一标准”是为了给各厂商提供一个开放的、通用的平台；“分散实现”要求软件系统高度的层次化和模块化，同时还要降低应用软件与硬件平台之间的耦合；不同的模块可以由不同的公司去完成开发，但要想完成最终软件系统的集成，就必须将所有模块的配置信息以统一的格式集中整合并管理起来，从而配置生成一个完整的系统，这就是“集中配置”。
采用AUTOSAR将为OEM（主机厂）带来很大的好处，使得其对于软件采购和控制拥有更灵活和更大的权利。因为AUTOSAR不仅在软件的功能上、接口上进行了一系列的标准化，还提出了一套规范化的开发流程与方法，这就使得能有更多的软件供应商进入汽车电子行业，大家都遵循同一个标准去开发，最终比的是产品的功能和质量。2.1.3 AUTOSAR的发展历程及应用现状
AUTOSAR联盟从2003年成立至今，成员队伍不断壮大，标准内容日臻完美。AUTOSAR联盟成员如图2.2所示，可见AUTOSAR联盟成员按等级分为核心成员（Core Partner）、高级成员（Premium Member）以及合作成员三类正式成员，基本涵盖了世界上各大著名整车厂、零部件公司、半导体公司以及软件工具提供商。图2.2 AUTOSAR联盟成员
目前，AUTOSAR平台最新版为4.3.1。为了迎合未来汽车智能化、网联化的需求，AUTOSAR联盟推出了一个全新的平台——自适应AUTOSAR平台（AUTOSAR Adaptive Platform，AP），并将现有平台更名为经典AUTOSAR平台（AUTOSAR Classic Platform，CP），AUTOSAR官网（https：//www.AUTOSAR.org/）也进行了更新，给人一种耳目一新的感觉。
由于AUTOSAR Adaptive Platform配套工具链还没发布，并且本书以介绍AUTOSAR基本理论知识与AUTOSAR方法论具体实现方法为主，所以，采用AUTOSAR Classic Platform，并且主要使用4.2.2和4.0.3版本。
AUTOSAR规范在国外的应用相较于国内更早、更普遍、更成熟。大众、博世、通用、德尔福、菲亚特等公司已将符合AUTOSAR规范的软件应用于它们的ECU产品。
德国大众集团与MathWorks、Elektrobit（EB）等公司联合开发了符合AUTOSAR规范的车身舒适控制系统，并应用于帕萨特车型。
玛涅蒂玛瑞利公司将AUTOSAR应用于菲亚特汽油发动机平台，并进行了硬件在环测试和不同工况下2万千米行程的实车测试。此外，他们还将AUTOSAR运用于车灯控制、动力总成控制等电控系统。
ETAS公司成功将宝马5系发动机管理系统开发为符合AUTOSAR规范的控制系统。开发人员利用ASCET进行软件组件开发，管理软件组件端口及其运行实体；使用RTA-OS开发AUTOSAR操作系统，配置、划分、管理任务；应用RTA-RTE连接应用层和基础软件层；代码集成后，进行了硬件在环仿真，结果表明与传统开发方法相比复杂度降低50%。整个博世集团已将AUTOSAR架构应用于自适应巡航系统ECU、动力总成系统ECU、底盘控制系统ECU和车身控制模块（Body Control Module，BCM）的开发，并且今后将运用于更多的ECU开发过程。
近年来，随着国内新能源汽车相关控制器正向开发需求的增长，AUTOSAR规范在国内越来越受到大家的关注，并且应用需求也越来越大。目前，上汽、北汽等国内主流整车厂以及一些零部件供应商都开始致力于符合AUTOSAR规范的车用控制器软件开发。AUTOSAR规范也有望成为未来整个汽车电子行业所普遍使用的软件标准。2.2 AUTOSAR分层架构
AUTOSAR规范主要包括分层架构、方法论和应用接口三部分内容。其中，分层架构是实现软硬件分离的关键，它使汽车嵌入式系统控制软件开发者摆脱了以往ECU软件开发与验证时对硬件系统的依赖。
在AUTOSAR分层架构中，汽车嵌入式系统软件自上而下分别为应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller），如图2.3所示。为保证上层与下层的无关性，在通常情况下，每一层只能使用下一层所提供的接口，并向上一层提供相应的接口。图2.3 AUTOSAR分层架构2.2.1 AUTOSAR应用软件层
应用软件层（Application Software Layer，ASW）包含若干个软件组件（Software Component，SWC），软件组件间通过端口（Port）进行交互。每个软件组件可以包含一个或者多个运行实体（Runnable Entity，RE），运行实体中封装了相关控制算法，其可由RTE事件（RTE Event）触发。2.2.2 AUTOSAR运行时环境
运行时环境（Runtime Environment，RTE）作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能。RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件的服务。此外，RTE抽象了ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE的实现与具体ECU相关，所以必须为每个ECU分别实现。2.2.3 AUTOSAR基础软件层
基础软件层（Basic Software Layer，BSW）又可分为四层，即服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers），如图2.4所示。图2.4 AUTOSAR基础软件层
上述各层又由一系列基础软件组件构成，包括系统服务（System Services）、存储器服务（Memory Services）、通信服务（Communication Services）等，如图2.5所示。它们主要用于提供基础软件服务，包括标准化的系统功能和功能接口。图2.5 AUTOSAR基础软件层结构（1）服务层
服务层（Services Layer）提供了汽车嵌入式系统软件常用的一些服务，其可分为系统服务（System Services）、存储器服务（Memory Services）以及通信服务（Communication Services）三大部分。提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统（Real Time Operating System，RTOS）等服务。除了操作系统外，服务层的软件模块都是与ECU平台无关的。（2）ECU抽象层
ECU抽象层（ECU Abstraction Layer）包括板载设备抽象（Onboard Devices Abstraction）、存储器硬件抽象（Memory Hardware Abstraction）、通信硬件抽象（Communication Hardware Abstraction）和I/O硬件抽象（Input/Output Hardware Abstraction）。该层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者I/O的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设备提供的。该层与ECU平台相关，但与微控制器无关，这种无关性正是由微控制器抽象层来实现的。（3）微控制器抽象层
微控制器抽象层（Microcontroller Abstraction Layer，MCAL）是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器驱动（Microcontroller Drivers）、存储器驱动（Memory Drivers）、通信驱动（Communication Drivers）以及I/O驱动（I/O Drivers），如图2.6所示。图2.6 微控制器抽象层（4）复杂驱动层
由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在AUTOSAR规范中这部分没有被标准化，统称为复杂驱动（Complex Drivers）。2.3 AUTOSAR软件组件
软件组件（SWC）不仅仅是应用层的核心，也是一些抽象层、复杂驱动层等实现的载体。由于软件组件包含的概念较多，这里单独介绍AUTOSAR软件组件相关概念，这是后期进行应用层、抽象层等开发的基础。
AUTOSAR软件组件大体上可分为原子软件组件（Atomic SWC）和部件（Composition SWC）。其中，部件可以包含若干原子软件组件或部件。原子软件组件则可根据不同用途分为以下几种类型：
①应用软件组件（Application SWC）；
②传感器/执行器软件组件（Sensor/Actuator SWC）；
③标定参数软件组件（Parameter SWC）；
④ECU抽象软件组件（ECU Abstraction SWC）；
⑤复杂设备驱动软件组件（Complex Device Driver SWC）；
⑥服务软件组件（Service SWC）。
应用软件组件（Application SWC）主要用于实现应用层控制算法。
传感器/执行器软件组件（Sensor/Actuator SWC）用于处理具体传感器/执行器的信号，可以直接与ECU抽象层交互。
标定参数软件组件（Parameter SWC）主要提供标定参数值。
ECU抽象软件组件（ECU Abstraction SWC）提供访问ECU具体I/O的能力。该软件组件一般提供引用C/S接口的供型端口，即Server端，由其他软件组件（如传感器/执行器软件组件）的需型端口（Client端）调用。此外，ECU抽象软件组件也可以直接和一些基础软件进行交互。
复杂设备驱动软件组件（Complex Device Driver SWC）推广了ECU抽象软件组件，它可以定义端口与其他软件组件通信，还可以与ECU硬件直接交互。所以，该类软件组件灵活性最强，但由于其和应用对象强相关，从而导致其可移植性较差。
服务软件组件（Service SWC）主要用于基础软件层，可通过标准接口或标准AUTOSAR接口与其他类型的软件组件进行交互。
需要指出的是，上述这些软件组件有的仅仅是概念上的区分，从具体实现及代码生成角度而言都是相通的。下面将详细介绍AUTOSAR软件组件的几个重要概念：数据类型、端口、端口接口以及内部行为。2.3.1 软件组件的数据类型
AUTOSAR规范中定义了如下三种数据类型（Data Type）：
①应用数据类型（Application Data Type，ADT）；
②实现数据类型（Implementation Data Type，IDT）；
③基础数据类型（Base Type）。
应用数据类型（Application Data Type，ADT）是在软件组件设计阶段抽象出来的数据类型，用于表征实际物理世界的量，是提供给应用层使用的，仅仅是一种功能的定义，并不生成实际代码。
实现数据类型（Implementation Data Type，IDT）是代码级别的数据类型，是对应用数据类型的具体实现；它需要引用基础数据类型（Base Type），并且还可以配置一些计算方法（Compute Method）与限制条件（Data Constaint）。
在AUTOSAR中，对于Application Data Type没有强制要求使用，用户可以直接使用Implementation Data Type。若使用了Application Data Type，则必须进行数据类型映射（Data Type Mapping），即将Application Data Type与Implementation Data Type进行映射，从而来对每个Application Data Type进行具体实现。2.3.2 软件组件的端口与端口接口
软件组件的端口根据输入/输出方向可分为需型端口（Require Port，RPort）与供型端口（Provide Port，PPort），在AUTOSAR 4.1.1标准中又提出了供需端口（Provide and Require Port，PRPort）。
①需型端口：用于从其他软件组件获得所需数据或者所请求的操作。
②供型端口：用于对外提供某种数据或者某类操作。
③供需端口：兼有需型端口与供型端口的特性。
需型端口可以和供型端口连接。如图2.7所示，软件组件SWC1有一个需型端口（R）和一个供型端口（P），其中需型端口与SWC2的供型端口相连，它们之间的交互关系通过连线箭头表示，由SWC2的供型端口指向SWC1的需型端口。SWC3具有一个供需端口，它可被认为自我相连。图2.7 AUTOSAR软件组件端口
由于端口仅仅定义了方向，所以AUTOSAR中用端口接口（Port Interface）来表征端口的属性，端口接口主要有如下几种类型：
①发送者-接收者接口（Sender-Receiver Interface，S/R）；
②客户端-服务器接口（Client-Server Interface，C/S）；
③模式转换接口（Mode Switch Interface）；
④非易失性数据接口（Non-volatile Data Interface）；
⑤参数接口（Parameter Interface）；
⑥触发接口（Trigger Interface）。
其中，最常用的端口接口是发送者-接收者接口（Sender-Receiver Interface，S/R）与客户端-服务器接口（Client-Server Interface，C/S）。如图2.8所示，软件组件SWC1具有两个端口，其中一个引用的端口接口类型为发送者-接收者（S/R）接口，另一个引用的端口接口类型为客户端-服务器（C/S）接口。从中也可以看出，对于引用发送者-接收者接口的一组端口而言，需型端口为接收者（Receiver），供型端口为发送者（Sender）。对于引用客户端-服务器接口的一组端口而言，需型端口为客户端（Client），供型端口为服务器（Server）。图2.8 AUTOSAR软件组件端口接口
下面详细讨论发送者-接收者接口（Sender-Receiver Interface，S/R）与客户端-服务器接口（Client-Server Interface，C/S）的特性。（1）发送者-接收者接口
发送者-接收者接口用于数据的传递关系，发送者发送数据到一个或多个接收者。该类型接口中定义了一系列的数据元素（Data Element，DE），这些数据元素之间是相互独立的。如图2.9所示，该发送者-接收者接口SR_Interface中定义了两个数据元素，名字分别为DE_1与DE_2，并且需要为每个数据元素赋予相应的数据类型。图2.9 发送者-接收者接口定义
需要指出的是，一个软件组件的多个需型端口、供型端口、供需端口可以引用同一个发送者-接收者接口，并且它们可以使用该接口中所定义的任意一个或者多个数据元素，而并不一定使用所有数据元素。
（2）客户端-服务器接口
客户端-服务器接口用于操作（Operation，OP），即函数调用关系，服务器是操作的提供者，多个客户端可以调用同一个操作，但同一个客户端不能调用多个操作。客户端-服务器接口定义了一系列操作（Operation），即函数，它（们）由引用该接口的供型端口所在的软件组件来实现，并提供给引用该接口的需型端口所在的软件组件调用。如图2.10所示，该客户端-服务器接口CS_Interface中定义了两个操作OP_1与OP_2，对于每一个操作需要定义相关参数及其方向，即函数的形参。图2.10 客户端-服务器接口定义
需要注意的是，每个端口只能引用一种接口类型，并且引用相同端口接口类型的端口才可以进行交互。2.3.3 软件组件的内部行为
软件组件的内部行为（Internal Behaviour，IB）如图2.11所示，其主要包括：图2.11 软件组件的内部行为
①运行实体（Runnable Entity，RE）；
②运行实体的RTE事件（RTE Event）；
③运行实体与所属软件组件的端口访问（Port Access）；
④运行实体间变量（Inter Runnable Variable，IRV）。（1）运行实体
运行实体（Runnable Entity，RE）是一段可执行的代码，其封装了一些算法。一个软件组件可以包含一个或者多个运行实体。（2）运行实体的RTE事件
每个运行实体都会被赋予一个RTE事件（Trigger Event），即RTE事件（RTE Event），这个事件可以引发这个运行实体的执行。对于RTE事件可以细分为很多种类，这将在后续章节介绍软件组件的内部行为设计时结合工具进行介绍。较常用的RTE事件有以下几种：
①周期性（Periodic）事件，即Timing Event；
②数据接收事件（Data-received Event）；
③客户端调用服务器事件（Server-call Event）。
如图2.12所示，其中Runnable_1、Runnable_2和Runnable_3分别采用了Timing Event、Data-received Event以及Server-call Event。图2.12 运行实体的RTE事件示意（3）运行实体与所属软件组件的端口访问
运行实体与所属软件组件的端口访问（Port Access）是和端口所引用的端口接口类型密切相关的。
对于S/R通信模式，可分为显示（Explicit）和隐式（Implicit）两种模式。若运行实体采用显示模式的S/R通信方式，数据读写是即时的；当多个运行实体需要读取相同的数据时，若能在运行实体运行之前先把数据读到缓存中，在运行实体运行结束后再把数据写出去，则可以改善运行效率，这就是隐式模式。显示模式与隐式模式的对比如图2.13所示，可见后者的实现方式中，会在运行实体被调用之前读数据，在运行结束后写数据。图2.13 显式模式与隐式模式的对比
对于C/S通信模式，可分为同步（Synchronous）和异步（Asynchronous）两种模式，它们的对比如图2.14所示。图2.14 同步模式和异步模式的对比（4）运行实体间变量
运行实体间变量（Inter Runnable Variable，IRV）即两个运行实体之间交互的变量，如图2.15所示。图2.15 运行实体间变量示意2.4 AUTOSAR虚拟功能总线
若从整车级别去看待整车上所有的功能模块，即软件组件的架构，它们之间的通信形式主要涉及以下两种：
①在单个ECU内部的通信（Intra-ECU Communication）；
②在多个ECU之间的通信（Inter-ECU Communication）。
如果使用传统的系统设计方法，则会带来一个问题，即在定义整车级别的应用层软件架构的时候会受到具体实现手段的束缚，这主要体现在与底层软件的接口。AUTOSAR为了实现一种“自顶向下”的整车级别的软件组件定义，提出了虚拟功能总线（Virtual Function Bus，VFB）的概念。VFB可以使得负责应用层软件的开发人员不用去关心一个软件组件最终在整车中的哪个ECU中具体实现，即使得应用软件的开发可以独立于具体的ECU开发。从而，可以让应用软件开发人员专注于应用软件组件的开发。
VFB是AUTOSAR提供的所有通信机制的抽象。通过VFB，无论软件组件使用的是在ECU内部的通信还是在ECU之间的通信，对于应用软件的开发者而言，没有本质区别。内部通信与外部通信的区别只有等到系统级设计与配置阶段，将软件组件分配到不同的ECU之后才会体现出来。最终，VFB的真实通信实现可以由RTE和基础软件来保证，所以，RTE是AUTOSAR VFB的具体实现。
通过对通信机制的抽象，可以使得当一个系统的软件组件之间的通信关系确定之后，通过VFB就可以在开发前期将它们虚拟集成完成系统仿真与测试工作。2.5 AUTOSAR方法论
AUTOSAR方法论（AUTOSAR Methodology）中车用控制器软件的开发涉及系统级、ECU级和软件组件级。系统级主要考虑系统功能需求、硬件资源、系统约束，然后建立系统架构；ECU级根据抽象后的信息对ECU进行配置；系统级和ECU级设计的同时，伴随着软件组件级的开发。上述每个环节都有良好的通信接口，并使用统一的arxml（AUTOSAR Extensible Markup Language）描述文件，以此构建了AUTOSAR方法论。AUTOSAR方法论中“自顶向下”的软件组件设计与VFB实现方法示意如图2.16所示，而对于单个ECU内部的系统实现方法示意如图2.17所示。图2.16 AUTOSAR方法论——“自顶向下”的软件组件设计与VFB实现方法示意图2.17 AUTOSAR方法论——单个ECU内部的系统实现方法示意
在开发之前，需要先编写系统配置输入描述文件，其包含以下三部分内容。
①软件组件描述（SW-Component Description）：包含系统中所涉及的软件组件的接口信息，例如数据类型、端口接口、端口等。
②ECU资源描述（ECU Resource Description-HW only）：包含系统中每个ECU所需要的处理器及其外设、传感器、执行器等信息。
试读结束[说明：试读内容隐藏了图片]