CN108647040A - 一种基于PEPS系统的Bootloader架构及刷写方法 - Google Patents

Abstract

本发明公开了一种基于PEPS系统的Bootloader架构及刷写方法，该Bootloader架构主要包括Bootloader启动管理模块、Bootloader应用程序、Bootloader运行环境模块、内存管理模块、Flash驱动模块、EEPROM驱动模块、诊断模块以及安全模块。其对应的刷写方法主要包括以下步骤：(1)预编程步骤：编程前的CAN网络准备；(2)主编程步骤：下载应用软件或应用数据；(3)后编程步骤：重同步CAN网络。本发明提供的Bootloader架构具有Bootloader代码所占空间小、Flash编程效率高、具有自校验，自诊断功能等优点，能够保证Bootloader功能的完整性及软件的安全性。

Description

一种基于PEPS系统的Bootloader架构及刷写方法

技术领域

本发明涉及软件系统架构，具体涉及Bootloader架构。

背景技术

无钥匙进入及启动系统简称PEPS(Passive Entry Passive Start)系统，是适应汽车防盗系统发展而推出的一款新型智能电子防盗系统，它采用先进的RFID(无线射频识别)技术，实现无需按动遥控器即可进入车内以及一键启动发动机等功能。PEPS具有更加智能化的门禁管理，更高的防盗性能，已经成为汽车电子防盗系统应用的主流。

PEPS控制盒通常安装在汽车内部，汽车一旦下了产线，很难再拆下PEPS控制盒，所以通过烧录器来更新PEPS应用程序是一件十分困难的事情。通过Bootloader来更新PEPS应用程序是一个方便可行的办法，但目前应用于PEPS系统的Bootloader还存在许多不足的地方：

(1)Bootloader架构较混乱，缺乏有条理性的架构以保证功能的完整性及软件的安全性。同时合理分配Bootloader和PEPS应用程序的内存空间也是十分重要的，要保证在不同情况下确保Bootloader能够正常使用。

(2)在Bootloader刷写流程方面，也存在着很大的随意性，可能会导致软件的部分功能缺失或者软件不可用。

(3)很多Bootloader都是针对制定的MCU设计的，由于受限于硬件，软件的移植性较差，尤其在汽车上的PEPS系统应用方面。

发明内容

针对现有PEPS系统中Bootloader所存在的不足，需要一种新的Bootloader架构方案。

为此，本发明的所要解决的问题是提供一种基于PEPS系统的Bootloader架构，并针对该Bootloader架构提供一种Bootloader架构的刷写方法，由此来克服现有技术所存在的不足。

为了解决上述问题，本发明提供的基于PEPS系统的Bootloader架构，其包括Bootloader启动管理模块、Bootloader应用程序、Bootloader运行环境模块、内存管理模块、Flash驱动模块、EEPROM驱动模块、诊断模块以及安全模块；

所述Bootloader启动管理模块用于初始化运行环境，判断进入Bootloader还是应用程序；

所述Bootloader应用程序用于下载流程的特定实现；

所述Bootloader运行环境模块用于管理并调度其它模块，完成下载功能；

所述内存管理模块用于管理下载流程中需要使用的存储器；

所述Flash驱动模块用于提供Flash擦除、编程和读取；

所述EEPROM驱动模块用于提供EEPROM擦除、编程和读取接口；

所述诊断模块用于提供下载流程所需的所有的诊断通信服务；

所述安全模块用于提供安全访问服务和下载数据完整性验证。

进一步的，所述Bootloader启动管理模块，使得ECU在上电/复位后，首先执行Bootloader引导代码，控制Bootloader执行一些基本的初始化，然后检查外部重编程请求标志是否已设置，如果标志已被设置，继续执行Bootloader；如果当前没有重编程请求，则检验应用程序的状态；如果应用程序是有效的，Bootloader则启动应用程序；如果应用程序是无效的，则继续执行Bootloader。

进一步的，所述的Bootloader应用程序，通过CAN网络进行下载，若CAN网络节点中的节点彼此相似，则同时对多个类似节点下载程序；若CAN网络节点中的节点彼此没有相似性，则通过点对点的数据传输来完成对于每个节点的程序下载；在CAN网络进行程序下载时，还对CAN网络中的数据传输及目标节点的Flash进行自更新，以及还在目标节点中设置内置校验程序，并向发送方返回校验后的结果，实现了CAN网络中两个节点相互通信。

进一步的，所述的Bootloader应用程序通过CAN网络进行下载时，基于CAN报文的相应的ID触发进入启动加载模式，该此报文所携带的信息可让一个或多个节点同时进入启动加载模式。

进一步的，所述的Bootloader运行环境模块，统一采用在系统上电或复位后，从地址0xFFFE处取它的第一条指令。

进一步的，所述的内存管理模块，将ECU可用的Flash存储空间由应用程序和Bootloader共享，并将Bootloader的Flash存储空间占用控制到最小；同将ECU上可用的RAM可被Bootloader完全占用，也可被应用程序完全占用。

进一步的，所述的Flash驱动模块，将完整的Flash驱动代码或其关键部分在下载过程中下载到MCU的RAM缓冲中，并在下载完成后，Flash驱动代码须在返回正常工作模式之前从RAM缓冲中移除。

进一步的，所述的Flash驱动可提供相应的API供Bootloader调用，至少需要以下4个例程：

初始化：在Flash驱动被下载到ECU后，Bootloader调用初始化例程，为Flash编程执行具体硬件的初始化；

去初始化：在下载完成后，Bootloader调用去初始化例程，执行具体硬件操作，完成Flash重编程；

擦除：Bootloader调用擦除例程，以擦除请求的Flash区域；

写入：Bootloader使用Flash驱动的写例程，以对所有下载数据进行编程。

进一步的，所述的EEPROM驱动模块，可将完整的EEP驱动代码或其关键部分在下载过程中下载到MCU的RAM，并软件更新完成后，将EEP驱动代码在返回正常工作模式之前从RAM中移除。

进一步的，所述的EEP驱动可提供相应的API供Bootloader调用，至少需要以下4个例程：

初始化：在EEP驱动被下载到RAM后，Bootloader调用初始化例程，为EEP编程执行具体硬件的初始化；

去初始化：在下载完成后，Bootloader调用去初始化例程，执行具体硬件操作，防止EEP被意外改写；

擦除：Bootloader调用擦除例程，以擦除请求的EEP区域；

写入：Bootloader使用EEP驱动的写函数，将数据写入EEP。

进一步的，所述的诊断模块，在ECU上电/复位后，首先执行Bootloader引导代码；Bootloader执行一些基本的初始化，然后检查外部重编程请求标志是否已设置：如果标志已被设置，Bootloader继续进一步执行；如果当前没有重编程请求，则检验应用程序的状态，如果应用程序有效，Bootloader则启动应用程序，应用程序在默认会话模式中启动；如果应用程序无效，ECU在默认会话模式继续执行Bootloader并且等待切换至扩展会话模式，最后进入编程会话模式；

如果ECU正处于扩展会话模式，收到进入编程会话模式的请求后，应用程序须设立外部的重编程请求标志并且须执行复位；编程会话模式可以通过ECU复位或默认会话模式服务请求或者编程会话模式超时离开。

进一步的，所述的安全模块，主要包括安全访问和完整性验证两个部分：针对安全访问部分，在重编程步骤被解锁前，需要成功通过安全访问程序；针对完整性验证部分，每个逻辑块由一个CRC32值进行保护，在下载后，Bootloader必须确认当前块的所有数据字节被正确传输和写入。

为了解决上述问题，本发明提供Bootloader架构刷写方法，其主要包括以下步骤：

(1)预编程步骤：编程前的CAN网络准备；

(2)主编程步骤：下载应用软件或应用数据；

(3)后编程步骤：重同步CAN网络。

进一步的，所述预编程步骤为要下载的ECU做重编程前的CAN网络准备，同时也做好提高下载速度的准备，其请求报文能采用的是物理寻址，或功能寻址。

进一步的，所述主编程步骤中主编程时序为单个ECU编程事件的应用，相应的服务请求使用物理寻址。

本发明提供的Bootloader架构具有Bootloader代码所占空间小、Flash编程效率高、具有自校验，自诊断功能等优点，能够保证Bootloader功能的完整性及软件的安全性。

同时，所提供的刷写流程分为预编程流程、主编程流程、后编程流程等三个子编程流程，具有条理清晰、功能完整等特点。

再者，该Bootloader架构及刷写流程可有效解决现有车载PEPS控制器不易拆卸，因而导致不能在线升级的问题。

附图说明

以下结合附图和具体实施方式来进一步说明本发明。

图1为本发明的PEPS系统示意图；

图2为本发明的系统架构和主刷写流程图；

图3为本发明的Bootloader架构的详细示意图；

图4为本发明的ECU启动时序图；

图5为本发明的诊断会话概况图；

图6为本发明的预编程流程图；

图7为本发明的编程流程图；

图8为本发明的后编程流程图。

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合具体图示，进一步阐述本发明。

参见图1，在本实例涉及到的PEPS系统中，PEPS控制器10需要与车身控制模块11、ABS模块12、EMS模块13、IPK模块14以及IMMO防盗基站15进行通讯，且与车身控制模块、ABS模块、EMS模块、IPK模块之间采用CAN通讯，与IMMO防盗基站之间采用LIN通讯。

据此，本实例根据PEPS系统的特性来设计适用性和移植性较强的Bootloader架构及相应的刷写流程。

参见图图3，本实例给出的基于PEPS系统的Bootloader架构100包括内存管理110、Bootloader启动管理120、Flash驱动130、EEPROM驱动140、安全模块150、诊断模块160、Bootloader应用程序170、Bootloader运行环境180。

对于本Bootloader架构中的内存管理模块110，主要用于管理下载流程中需要使用的存储器。如图2所示，由于ECU可用的Flash存储空间由应用程序和Bootloader共享，故本内存管理模块110进行内存管理时，使得Bootloader的Flash存储空间占用必须做到最小化；ECU上可用的RAM可被Bootloader完全占用，也可被应用程序完全占用。

对于本Bootloader架构中的Bootloader启动管理(即启动时序)模块120，用于初始化运行环境，判断进入Bootloader还是应用程序。

本Bootloader启动管理模块120实现基本功能的过程为：如图4所示，本启动管理模块能够在ECU上电/复位后，使得ECU首先执行Bootloader引导代码；Bootloader执行一些基本的初始化，然后检查外部重编程请求标志是否已设置，如果标志已被设置，继续执行Bootloader；如果当前没有重编程请求，则检验应用程序的状态。如果应用程序是有效的，Bootloader则启动PEPS系统应用程序；如果PEPS系统应用程序是无效的，则继续执行Bootloader。

本Bootloader架构中的Flash驱动模块130，主要用于提供Flash擦除、编程和读取功能。该Flash驱动模块130具体依赖于PEPS系统硬件的模块，提供对MCU的Flash进行擦写的功能。对于Flash存储的内容需进行保护，以防无意的擦除和重写，可将Flash驱动模块的关键代码存放在MCU的存储器之外。据此，本实例中将完整的Flash驱动代码或其关键部分不存储在MCU的Flash存储器中，而是在下载过程中下载到MCU的RAM缓冲中，在下载完成后，Flash驱动代码须在返回正常工作模式之前从RAM缓冲中移除。

再者，本实例中的Flash驱动模块还提供相应的API供Bootloader调用，至少包括以下4个例程：

初始化：在Flash驱动被下载到ECU后，Bootloader调用初始化例程，为Flash编程执行具体硬件的初始化。

去初始化：在下载完成后，Bootloader调用去初始化例程，执行具体硬件操作，完成Flash重编程。

擦除：Bootloader调用擦除例程，以擦除请求的Flash区域。

写入：Bootloader使用Flash驱动的写例程，以对所有下载数据进行编程。

本Bootloader架构中的EEPROM驱动模块(EEP Driver)140，用于提供EEPROM擦除、编程和读取接功能。

据此，本实例通过将EEP驱动的关键代码存放在MCU的存储器之外，由此实现对EEP存储的内容进行保护，以防无意的擦除和重写。具体实现时，本实例将完整的EEP驱动代码或其关键部分并不存储在MCU的Flash存储器中，而是在下载过程中下载到MCU的RAM。软件更新完成后，EEP驱动代码须在返回正常工作模式之前从RAM中移除。

再者，本实例中的EEP驱动模块还提供相应的API以供Bootloader调用，且至少包括以下4个例程：

初始化：在EEP驱动被下载到RAM后，Bootloader调用初始化例程，为EEP编程执行具体硬件的初始化。

去初始化：在下载完成后，Bootloader调用去初始化例程，执行具体硬件操作，防止EEP被意外改写。

擦除：Bootloader调用擦除例程，以擦除请求的EEP区域。

写入：Bootloader使用EEP驱动的写函数，将数据写入EEP。

本Bootloader架构中的安全模块150，用于提供安全访问服务和下载数据完整性验证，以保证Bootloader架构的安全性能。该安全模块150对Flash编程应该进行保护，防止未经授权的下载尝试，保证安全访问。

本安全模块150主要包括安全访问和完整性验证两个部分。针对安全访问部分，即在重编程步骤被解锁前，必须成功通过安全访问程序；针对完整性验证部分，每个逻辑块由一个CRC32值进行保护，在下载后，Bootloader必须确认当前块的所有数据字节被正确传输和写入。

具体的，基于本安全模块在进一步的重编程步骤被解锁前，必须成功通过安全访问程序。如果超过两次安全访问失败后，ECU不需要产生延时机。ECU上电/复位后需要等待1秒，才可以对接收第一个“请求种子”报文。对于完整性验证问题，每个逻辑块由一个CRC32值进行保护。在下载后，Bootloader必须确认当前块的所有数据字节被正确传输和写入，使用CRC32算法作为验证例程。当例程标识符为校验例程的例程控制服务请求被接收到，Bootloader调用验证例程，计算下载数据字节的CRC32值。将计算结果与在服务请求消息中被传送至ECU的参考校验值进行比较，检验例程在Flash驱动和应用程序下载中使用。

本Bootloader架构中的诊断模块160，主要用于提供诊断通信会话模式管理和重编程过程相关诊断服务的需求。

如图5所示，本诊断模块160的实现与运行过程为：在ECU上电/复位后，首先执行Bootloader引导代码。Bootloader执行一些基本的初始化，然后检查外部重编程请求标志是否已设置。如果标志已被设置，那么即使应用程序是有效的，Bootloader也会继续进一步执行；如果当前没有重编程请求，则检验应用程序的状态，如果应用程序是有效的，Bootloader则启动应用程序，应用程序在默认会话模式中启动；如果应用程序无效，ECU在默认会话模式继续执行Bootloader并且等待切换至扩展会话模式，最后进入编程会话模式。

如果ECU正处于扩展会话模式，收到进入编程会话模式的请求后，应用程序须设立外部的重编程请求标志并且须执行复位。编程会话模式可以通过ECU复位或默认会话模式服务请求或者编程会话模式超时离开。

本Bootloader架构中的Bootloader应用程序170，用于下载流程的特定实现。可通过CAN网络实施程序下载，具体的实现如下：

(1)针对单一节点和一系列节点下载程序

CAN网络是多主节点的串行总线，一个CAN网络中可能存在许多固件类似的节点，由于CAN网络的特性，网络中有报文传输时这些节点都能同时接收到，若一次能同时对多个这样类似的节点下载程序，有效提高下载效率。对于CAN网络节点中的节点彼此没有相似性的情况，对于每个节点的程序下载，必须通过点对点的数据传输来完成。

(2)节点的智能化

在CAN网络中实现程序的下载，本实例中进一步增加如下两个步骤：CAN网络中的数据传输及目标节点的Flash的自更新，还在目标节点中设置了内置校验程序，并向发送方返回校验后的结果，以实现CAN网络中两个节点相互通信。

(3)进入Bootloader模式

启动加载模式的进入是由一些事件触发的，本实例中采用一个CAN报文的相应的ID作为触发事件，此报文所携带的信息可让一个或多个节点同时进入启动加载模式。

(4)对Bootloader的要求

本实例中提供的Bootloader应用程序实现以下功能：ECU软件下载和升级、标定数据的再编程、重要参数整定后的写入、操作者的身份验证、生产文件的格式变换和生成、生产文件的完整性和安全性的保障机制、界面友好、工作速度能够符合生产节拍要求等。并形成以下评价指标：

Bootloader代码所占的空间小；

Flash编程效率高；

具有自校验，自诊断功能。

本Bootloader架构中的Bootloader运行环境180，用于管理并调度其它模块，完成下载功能。

由于在嵌入式系统中，Bootloader严重地依赖于硬件，而PEPS控制器多数选用飞思卡尔16位MCU，为保证在系列飞思卡尔16位MCU上准确的执行Bootloader程序，本实例统一采用在系统上电或复位后，都从地址0xFFFE处取它的第一条指令。基于CPU构建的嵌入式系统通常都有固态存储设备(如ROM、EEPROM或Flash等)被映射到这个预先安排的地址上，因此在系统上电后，CPU将首先执行Bootloader程序，由此可以准确、安全的调度各模块之间有条不紊的工作，完成下载功能。

根据上述方案构成的基于PEPS系统的Bootloader架构通过各个模块之间的相互有机配合，可有效保证Bootloader功能的完整性及软件的安全性。

再者，本Bootloader架构为安全功能提供了接口来保护Flash下载过程，能够确保避免以下问题：

Error1：传输和编程错误；

Error2：未经批准的下载尝试；

Error3：非来自于合法源的软件下载尝试；

Error4：在ECU应用程序开发过程中未经批准的对ECU应用程序代码和/或数据的读取，以保护供应商和OEM的技术。

针对该基于PEPS系统的Bootloader架构，本实例还进一步提供相应的Bootloader刷写流程。

参见图2，及图5-图8，该Bootloader刷写流程主要包括三个子编程流程：预编程流程、主编程流程和后编程流程。

一、预编程流程，预编程步骤用来为要下载的ECU做重编程前的CAN网络准备。此步骤也包含了提高下载速度的准备，请求报文能采用的是物理寻址，或功能寻址。如图6所示，具体刷写流程如下：

a)诊断会话控制0x10 0x03：在ECU可以被重编程之前，网络中DTC及常规通信的设置须被关闭。因此，所有连接到网络中的ECU须以非默认诊断会话模式启动，此请求使用功能寻址方式。与此请求服务同时，外部重编程工具必须开始传输设备在线报文，以使网络中所有ECU保持在扩展会话模式；

b)控制DTC设置0x85 0x02：通过DTC设置类型设为“关闭”的控制DTC设置服务请求，用来在重编程过程中禁止ECU检测和存储DTC。此请求使用功能寻址来关闭网路中所有ECU的默认DT存储设置；

c)通信控制0x28 0x03 0x01：通过通信控制服务请求，所有网络中连接的ECU禁止常规、非诊断报文的发送。在常规报文发送禁止时，ECU接收并处理输入报文，但是不发送响应报文。通过禁止常规报文的发送，总线的全部带宽均用来下载，所以下载不会被非诊断报文干扰；

d)读取数据0x22 0xxx 0xyy：在禁止正常通信后，读取被编程的ECU的状态(如：编程的应用软件和数据)。从被编程的ECU读取服务器标识数据，标识如应用软件标识、应用数据标识、Bootloader软件标识。读取数据服务为可选服务，读取的内容由ECU供应商定义。

e)诊断会话控制0x10 0x02：ECU中下载过程由切换到编程会话模式服务请求启动。当ECU处于应用程序时，此服务请求致使ECU从应用程序至Bootloader的转换。

二、主编程流程，在预编程步骤之后，是主编程步骤，功能是下载应用软件或应用数据。主编程时序是单个ECU编程事件的应用，因此所有服务的请求都使用物理寻址。如图7所示，具体刷写流程如下：

a)诊断会话控制0x10 0x02：在收到一个寻址方式为物理寻址，子功能为编程会话的诊断会话控制(0x10)服务后，ECU启动Bootloader，并分配编程所需的所有资源。ECU需先发送肯定响应再执行跳转到编程模式动作。

b)安全访问0x27 0x05/0x06：ECU须在Flash重编程前准许下载工具的安全访问。为了解锁ECU，下载工具必须首先向ECU请求种子。然后，下载工具和ECU都计算秘钥，下载工具将秘钥发送给ECU。ECU将它的密钥值与从下载工具中接收的密钥值进行比较。如果二值相等，则ECU解锁成功；

c)下载Flash Driver数据到RAM驱动：下载APP数据、标定数据、或Flash驱动都遵循相同的流程。一个下载文件中可能包含多个Segment，每个Segment下载需要用到请求下载服务(SID＝0x34)→数据传输服务(SID＝0x36)→退出下载服务(SID＝0x37)。每个Segment由多个地址连续的字节组成，Segment的下载由0x34服务启动，所有Segment的数据字节通过一个或多个0x36服务传输数据，当前Segment内的所有字节传输完完毕后，由0x37服务结束当前Segment下载；

d)例程控制-启动例程检查0x31 0x01 0xF0 0x01：在一个逻辑块的所有段都传输到ECU后，须启动例程检查来确保下载数据的完整性。当ECU处于引导加载程序时，此服务请求致使ECU从引导加载程序至Flash Driver的转换；

e)例程控制-启动擦除内存0x31 0x01 0xFF 0x00：参数为0xFF 0x00的例程控制服务请求可以擦除被请求的逻辑块。在擦除Flash驱动的擦除例程被调用前，请求擦除的逻辑块的有效状态位必须设为无效。这样可以在Flash过程没有成功结束时阻止意外执行应用程序；

f)下载APP数据到Flash，下载过程0x34，0x36，0x37：应用软件或者数据的每一个连续的数据块(也叫段，可能是一个完整的应用软件或者数据，也可能是应用软件或者数据的一部分)下载到ECU非易失性内存中，都是遵循下面的服务顺序完成数传输：

1)请求下载(0x34)；

2)传输数据(0x36)；

3)请求传输退出(0x37)。

单个应用软件或数据块可能需要多个数据传输(0x36)请求报文来完成传输(当数据块长度超出网络层缓存大小时，就会出现这种情况)。

三、后编程流程，重同步CAN网络。如图8所示，具体刷写流程如下：

a)例程控制–启动逻辑块兼容性检查0x31 0x01 0xFF 0x01：为保证重编程的逻辑块一致并兼容，例如所有逻辑块使用兼容的接口和格式，例程控制请求在最后一个逻辑块下载完后发送ECU。通过此服务，可以执行确保例如应用数据与应用软件兼容或两个软件模块间接口匹配的检查。没有执行此检查的标准方法，检查方法取决于ECU应用程序的需要。确认只有在检查成功时，应用程序才可以启动；

b)ECU复位0x11 0x01：诊断仪使用物理寻址，发送一个复位类型为硬复位的ECU复位(0x11)服务请求报文到CAN网络上。

通过ECU复位服务请求将使ECU结束重编程过程，返回到正常的操作模式。内存驱动代码必须从RAM缓存中完全清除，避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。

c)诊断会话控制0x10 0x01：诊断仪发送一个会话类型为默认会话的诊断会话控制(0x10)服务请求报文到CAN网络上。所有的ECU接收到诊断会话控制(0x10)，而进入到默认会话模式。此请求通过功能寻址发送，请求发送给所有包含在编程事件中或因此而进入非默认会话模式的ECU。跳转到默认会话模式，表示通信控制(0x28)服务和控制上DTC设置(0x85)服务也将复位到默认状态。

由此构成的Bootloader刷写流程功能完整，可有效适用于本Bootloader架构。

以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (15)

1.基于PEPS系统的Bootloader架构，其特征在于，包括Bootloader启动管理模块、Bootloader应用程序、Bootloader运行环境模块、内存管理模块、Flash驱动模块、EEPROM驱动模块、诊断模块以及安全模块；

所述Bootloader启动管理模块用于初始化运行环境，判断进入Bootloader还是应用程序；

所述Bootloader应用程序用于下载流程的特定实现；

所述Bootloader运行环境模块用于管理并调度其它模块，完成下载功能；

所述内存管理模块用于管理下载流程中需要使用的存储器；

所述Flash驱动模块用于提供Flash擦除、编程和读取；

所述EEPROM驱动模块用于提供EEPROM擦除、编程和读取接口；

所述诊断模块用于提供下载流程所需的所有的诊断通信服务；

所述安全模块用于提供安全访问服务和下载数据完整性验证。

2.根据权利要求1所述的Bootloader架构，其特征在于，所述Bootloader启动管理模块，使得ECU在上电/复位后，首先执行Bootloader引导代码，控制Bootloader执行一些基本的初始化，然后检查外部重编程请求标志是否已设置，如果标志已被设置，继续执行Bootloader；如果当前没有重编程请求，则检验应用程序的状态；如果应用程序是有效的，Bootloader则启动应用程序；如果应用程序是无效的，则继续执行Bootloader。

3.根据权利要求1所述的Bootloader架构，其特征在于，所述的Bootloader应用程序，通过CAN网络进行下载，若CAN网络节点中的节点彼此相似，则同时对多个类似节点下载程序；若CAN网络节点中的节点彼此没有相似性，则通过点对点的数据传输来完成对于每个节点的程序下载；在CAN网络进行程序下载时，还对CAN网络中的数据传输及目标节点的Flash进行自更新，以及还在目标节点中设置内置校验程序，并向发送方返回校验后的结果，实现了CAN网络中两个节点相互通信。

4.根据权利要求1所述的Bootloader架构，其特征在于，所述的Bootloader应用程序通过CAN网络进行下载时，基于CAN报文的相应的ID触发进入启动加载模式，该此报文所携带的信息可让一个或多个节点同时进入启动加载模式。

5.根据权利要求1所述的Bootloader架构，其特征在于，所述的Bootloader运行环境模块，统一采用在系统上电或复位后，从地址0xFFFE处取它的第一条指令。

6.根据权利要求1所述的Bootloader架构，其特征在于，所述的内存管理模块，将ECU可用的Flash存储空间由应用程序和Bootloader共享，并将Bootloader的Flash存储空间占用控制到最小；同将ECU上可用的RAM可被Bootloader完全占用，也可被应用程序完全占用。

7.根据权利要求1所述的Bootloader架构，其特征在于，所述的Flash驱动模块，将完整的Flash驱动代码或其关键部分在下载过程中下载到MCU的RAM缓冲中，并在下载完成后，Flash驱动代码须在返回正常工作模式之前从RAM缓冲中移除。

8.根据权利要求7所述的Bootloader架构，其特征在于，所述的Flash驱动可提供相应的API供Bootloader调用，至少需要以下4个例程：

初始化：在Flash驱动被下载到ECU后，Bootloader调用初始化例程，为Flash编程执行具体硬件的初始化；

去初始化：在下载完成后，Bootloader调用去初始化例程，执行具体硬件操作，完成Flash重编程；

擦除：Bootloader调用擦除例程，以擦除请求的Flash区域；

写入：Bootloader使用Flash驱动的写例程，以对所有下载数据进行编程。

9.根据权利要求1所述的Bootloader架构，其特征在于，所述的EEPROM驱动模块，可将完整的EEP驱动代码或其关键部分在下载过程中下载到MCU的RAM，并软件更新完成后，将EEP驱动代码在返回正常工作模式之前从RAM中移除。

10.根据权利要求9所述的Bootloader架构，其特征在于，所述的EEP驱动可提供相应的API供Bootloader调用，至少需要以下4个例程：

初始化：在EEP驱动被下载到RAM后，Bootloader调用初始化例程，为EEP编程执行具体硬件的初始化；

去初始化：在下载完成后，Bootloader调用去初始化例程，执行具体硬件操作，防止EEP被意外改写；

擦除：Bootloader调用擦除例程，以擦除请求的EEP区域；

写入：Bootloader使用EEP驱动的写函数，将数据写入EEP。

11.根据权利要求1所述的Bootloader架构，其特征在于，所述的诊断模块，在ECU上电/复位后，首先执行Bootloader引导代码；Bootloader执行一些基本的初始化，然后检查外部重编程请求标志是否已设置：如果标志已被设置，Bootloader继续进一步执行；如果当前没有重编程请求，则检验应用程序的状态，如果应用程序有效，Bootloader则启动应用程序，应用程序在默认会话模式中启动；如果应用程序无效，ECU在默认会话模式继续执行Bootloader并且等待切换至扩展会话模式，最后进入编程会话模式；

如果ECU正处于扩展会话模式，收到进入编程会话模式的请求后，应用程序须设立外部的重编程请求标志并且须执行复位；编程会话模式可以通过ECU复位或默认会话模式服务请求或者编程会话模式超时离开。

12.根据权利要求1所述的Bootloader架构，其特征在于，所述的安全模块，主要包括安全访问和完整性验证两个部分：针对安全访问部分，在重编程步骤被解锁前，需要成功通过安全访问程序；针对完整性验证部分，每个逻辑块由一个CRC32值进行保护，在下载后，Bootloader必须确认当前块的所有数据字节被正确传输和写入。

13.一种Bootloader架构刷写方法，其特征在于，主要包括以下步骤：

(1)预编程步骤：编程前的CAN网络准备；

(2)主编程步骤：下载应用软件或应用数据；

(3)后编程步骤：重同步CAN网络。

14.根据权利要求13所述的Bootloader架构刷写方法，其特征在于，所述预编程步骤为要下载的ECU做重编程前的CAN网络准备，同时也做好提高下载速度的准备，其请求报文能采用的是物理寻址，或功能寻址。

15.根据权利要求13所述的Bootloader架构刷写方法，其特征在于，所述主编程步骤中主编程时序为单个ECU编程事件的应用，相应的服务请求使用物理寻址。