Autosar学习实录：2.1.BSW初探

         前面几篇了解了ASW和RTE的主要功能和角色，其中应用层ASW的功能由各个软件组件SWC(Softwarecomponent),封装了和部分或全部汽车电子功能，如大灯空调如何运转，和硬件没有关联，RTE(运行时环境)提供了基础软件层和应用层之间的信息交互以及通讯接口。
接下来聊聊Autosar架构中最繁杂的一部分BSW，根据不同的功能BSW可以被分为四部分，结构图如下:

        BSW(基础软件)提供了硬件驱动逻辑，和MCU强相关，因此想要知道BSW这4部分架构的由来，首先应该对MCU的功能有个全面的了解:

1.信号采集、输出
MCU最核心的一个功能就是集成了多种外设接口，这些接口拥有不同的输入输出功能，熟悉单片机的应该知道，MCU上的每一个引脚都被定义了对应的功能，可以通过编程控制实现不同的输入输出，上面提到的高低电平的输出是最常见的一种，除此之外还有很多，可以总结成如下几类:

• DO:MCU通用输出，MCU输出一个高电平或者低电平，常用于使能其它外设控制外围电路。 DI:MCU通用输入，和MCU连接的其它外设或者外围电路输出高电平或者低电平给MCU。
• ICU:输入捕获单元，监控输入信号的边沿跳变,触发中断，最常见的作用就是MCU用来接收外界发来的PWM方波信号的输入。
• PWM:同理有接收就有发送，PWM接口可以用来生成不同频率和占空比的方波信号，通常配合ICU用于外围电路的诊断。
• ADC:数模转换器，将模拟信号转换成数字信号，通常用于模拟量的采集，上面SOC中的电压值提就是通过ADC接口采集。

PS:决定MCU上的一个pin角是GPIO口还是其它接口，是由port中的配置决定的,这个我们后面再聊。
        这些信号由MCU采集之后传到应用层需要经过如下步骤:信号由MCU捕获，然后经过对应的driver驱动，将电平信号转化为二进制的数字信号，然后封装成为接口-Interface，给到RTE，就能供ASW调用。
        反之输出信号，由ASW给到RTE，RTE调用接口发送接口，然后经过driver驱动，通过MCU输出。于是我们将这些信号的接口放在一起统一抽象成为I/O Interface,就能形成如下的软件架构:

2.回顾SWC的部分，我们知道对于应用层SWC来说重要的东西就两个，输入信号和通讯输出（内部通讯：全局变量，外部通讯：COM），输入信号通常由上面说到I/O模块负责采集，全局变量理解起来比较简单，而外部通讯COM的则需要CAN支持。
    
     CAN通信: 用于ECU和整车或者其它ECU之间的信息交互，比如BMS算出来的SOC要反应在整车的中控屏上，这个时候就需要BMS通过CAN将数据传输给整车，另一方面，整车熄之前需要给BMS指令下高压，让电池包停止供电，这部分也是通过CAN来实现的。
     
     关于CAN通讯更详细的知识后面会有专门的章节讲解。
     
     SPI通信：对于一个ECU来说，应用层不同模块的功能算法加起来，所需要的信号可能有几十个甚至上百个，这些信号不能全靠MCU，毕竟MCU不一定有那么多Port口，加上MCU采集信号精度可能没有那么高，大部分MCU会增加额外的的芯片专门用于信号采集。而SPI通信就是MCU和这些额外芯片通信最常用的手段，这些芯片采集到的信号通过SPI传给MCU之后再传给RTE层。
     除此之外，随着这几年智能网联汽车的快速发展，像以太网（Eth）、帧中继(Fr)等高效 共享的通信在ECU中的使用开始变得普遍起来。
     
 同理，我们将这MCU中这两种通信方式也可以分解成为硬件+驱动+接口，如下图所示：
     

3.存储
    此外,写好编译的程序需要永久存放在MCU中,以及程序在MCU中运行,都需要分配到对应的存储空中间,MCU芯片内部存在固定大小的存储空间,这些空间该怎么分配,分多大,都需要根据ECU的功能和设计人为决定,此外,怎么样将一个数据写入内存或从内存中读取,这些都依赖MCU提供的对内存操作的接口,这部分
    内存分为性质不同,一般分为下面几种

•     FLASH(ROM):编译好的程序永久存放的位置,断电后里面的数据不会消失,下次上电后程序代码依然在,可以通过编译器擦除.
•     SRAM:程序运行时的位置(运行时候产生的变量和临时数据),断电里面的数据后会清空.
•     SFR:MCU自身内部数据存储区。

        最后，有些应用层的数据我们希望它存储起来，下电不消失，这需要我们抽象出操作NVM的接口放在RTE中，
                对应抽象出如下软件架构：

        除了上面提到的之外，MCU还有一些和应用层算法无关但维持MCU功能正常的所必须的功能
4.1.MCU时钟
    为了保证MCU和接口的正常运行，MCU内部需要有时钟定义，所谓时钟可以自行参考wiki，说一个简单但不一定恰当的理解，时钟信号决定了MCU上操作的先后顺序，比如上面的信号捕获和输出，如果同一时间两个操作要同时进行，必然会有冲突，这个时候用时钟信号的上升沿指示信号捕获开始进行，高电平的持续时间指示捕获时长，下降沿指示信号输出开始，低电平的持续时间，代表信号输出时间。

MCU内部提供了对时钟修改的相关接口，以及时钟相关的模块

•     GPT 定时器,用作定时任务        
•     MCU-clock 时钟/分频     
•     WTDG  看门狗,防止系统陷入死循环

PS：关于定时器/看门狗这些模块后续会深入讲解,目前可以把它理解为保证MCU正常运行的内部系统设置。

4.2.系统OS
任务调度 中断处理 状态管理（EcuM）
        单片机上电之后所以能够按照设定自动运行，这依赖于系统OS的任务调度，比如需要通过一个Port口采集一个电压信号，电压值更新的快慢很重要，电压数据更新的速度取决于Port口采集的速度，可以在OS中指定port口10ms采集一次，或者100ms采集一次，或者1s采集一次等等。
另外一种情况，我们ECU和外部通信时，需要实时响应外部请求，这里的响应是可以通过系统OS的中断处理来实现。
        最后,像电脑一样,我们可以控制MCU什么时候运行,什么时候休眠,什么时候关闭,这个依赖于系统OS的状态管理。
存储故障信息的DEM

        基于上面的功能，我们可以知道所有模块的正常运行都需要依赖OS，因此我们将OS里面这四大功能抽象出来架构如下：

5.CDD
        另外，上面提到和MCU一起协同工作的复杂芯片，会提供一系列的功能接口，MCU使用这些接口和芯片交互，这部分接口实现的，在Autosar架构中称为CDD(Complex Device Driver)。

        CAN通讯相关的接口按照功能可以进一步划分成为UDS/DCM/DEM/COM/Nm/SM这些模块，并且这些模块依赖于OS相关的服务，因此模块结构可以做如下调整：

这个时候在看autosar架构就能准确对应上: