将虚拟化IO架构和汽车应用集成在ECU的方法及系统

摘要

本发明公开了一种将虚拟化IO架构和汽车应用集成在ECU的方法及系统，ECU包括：硬件架构和软件架构，硬件架构包括：至少一个芯片系统，至少一个芯片系统中的每个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备，软件架构包括：在至少一个具有多处理器核的芯片系统上运行的多核操作系统。本发明由虚拟化IO驱动软件和虚拟机监控器实现将虚拟化IO架构和汽车应用集成在ECU上，运行环境由ECU中的硬件架构和实时操作系统提供，并可被对称地部署在硬件架构的各个具有多处理器核的芯片系统上，使得安装在电子控制单元上的各个汽车应用能够共享电子控制单元上的传感器、执行器和其它IO设备。

权利要求

1.一种将虚拟化IO架构和汽车应用集成在电子控制单元ECU的方法，所述ECU包括：硬件架构和软件架构，其特征在于，

所述硬件架构包括：至少一个芯片系统，至少一个所述芯片系统中的每个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备；

所述软件架构包括：在至少一个具有所述多处理器核的所述芯片系统上运行的多核操作系统，所述多核操作系统为运行在每个所述处理器核上的非对称多处理形式的实时操作系统所构成的操作系统；

将具有所述多处理器核的所述芯片系统中的一个处理器核作为主核，所述主核以外的处理器核作为从核，在所述主核上安装虚拟化IO驱动软件，在所述主核和每个所述从核上都安装一个虚拟机监控器软件，在每个所述虚拟机监控器软件上安装至少一个汽车应用，每个所述汽车应用包括：至少一个操作系统实体，每个所述汽车应用由所述汽车应用所处的处理器核上的实时操作系统进行汽车应用内部各个任务的调度，每个所述汽车应用通过所述汽车应用所处的处理器核上的虚拟机监控器软件读写IO设备；

当安装在同一个芯片系统上的多个汽车应用同时请求写同一个IO设备，或，当安装在同一个电子控制单元的不同芯片系统上的多个汽车应用同时请求控制同一个执行器的过程，具体包括：获取存储请求事件的队列数据结构，记为第二队列数据结构；获取第三汽车应用发送的写IO设备的写请求，记为第二写请求；基于所述第二写请求，得到需要写入IO设备里的数据，记为第二写入数据；对所述第二写请求和所述第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第二队列数据；获取第四汽车应用发送的写IO设备的写请求，记为第三写请求；基于所述第三写请求，得到需要写入IO设备里的数据，记为第三写入数据；对所述第三写请求和所述第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第三队列数据；对所述第二队列数据和所述第三队列数据进行处理，得到各个队列成员对应的执行动作，记为第二执行动作；对所述第二写入数据、所述第三写入数据和各个队列成员对应的所述第二执行动作进行处理，实现对IO设备的写操作，并得到报警标志；对所述第二队列数据和所述第三队列数据执行出队操作，得到存储请求事件的所述第二队列数据结构。

2.根据权利要求1所述的方法，其特征在于，还包括：所述汽车应用写IO设备的过程，具体包括：

获取第一汽车应用发送的写IO设备的写请求，记为第一写请求，以及获取存储请求事件的队列数据结构，记为第一队列数据结构；

基于所述第一写请求和所述第一队列数据结构，得到需要写入IO设备里的数据，记为第一写入数据，以及执行入队操作之后的队列数据，记为第一队列数据；

基于所述第一队列数据得到各个队列成员对应的执行动作，记为第一执行动作；

基于所述第一写入数据以及各个队列成员对应的所述第一执行动作，对IO设备执行写操作。

3.根据权利要求2所述的方法，其特征在于，还包括：对执行入队操作之后的队列数据执行出队操作，得到存储请求事件的所述第一队列数据结构。

4.根据权利要求1所述的方法，其特征在于，还包括：所述汽车应用读IO设备的过程，具体包括：

获取第二汽车应用发送的读IO设备的读请求；

基于所述读请求，得到需要读取的IO设备；

基于所述需要读取的IO设备，确定所述需要读取的IO设备的目标数据；

对所述目标数据进行处理，得到所述汽车应用读到的数据，实现对IO设备的读操作。

5.一种将虚拟化IO架构和汽车应用集成在电子控制单元ECU的系统，所述ECU包括：硬件架构和软件架构，其特征在于，

所述硬件架构包括：至少一个芯片系统，至少一个所述芯片系统中的每个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备；

所述软件架构包括：在至少一个具有所述多处理器核的所述芯片系统上运行的多核操作系统，所述多核操作系统为运行在每个所述处理器核上的非对称多处理形式的实时操作系统所构成的操作系统；

将具有所述多处理器核的所述芯片系统中的一个处理器核作为主核，所述主核以外的处理器核作为从核，在所述主核上安装虚拟化IO驱动软件，在所述主核和每个所述从核上都安装一个虚拟机监控器软件，在每个所述虚拟机监控器软件上安装至少一个汽车应用，每个所述汽车应用包括：至少一个操作系统实体，每个所述汽车应用由所述汽车应用所处的处理器核上的实时操作系统进行汽车应用内部各个任务的调度，每个所述汽车应用通过所述汽车应用所处的处理器核上的虚拟机监控器软件读写IO设备；

多应用执行单元，用于执行当安装在同一个芯片系统上的多个汽车应用同时请求写同一个IO设备，或，当安装在同一个电子控制单元的不同芯片系统上的多个汽车应用同时请求控制同一个执行器的过程；所述多应用执行单元具体包括：数据结构获取子单元，用于获取存储请求事件的队列数据结构，记为第二队列数据结构；第二写请求获取子单元，用于获取第三汽车应用发送的写IO设备的写请求，记为第二写请求；第一写入数据获取子单元，用于基于所述第二写请求，得到需要写入IO设备里的数据，记为第二写入数据；第二数据处理子单元，用于对所述第二写请求和所述第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第二队列数据；第三写请求获取子单元，用于获取第四汽车应用发送的写IO设备的写请求，记为第三写请求；第二写入数据获取子单元，用于基于所述第三写请求，得到需要写入IO设备里的数据，记为第三写入数据；第三数据处理子单元，用于对所述第三写请求和所述第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第三队列数据；第四数据处理子单元，用于对所述第二队列数据和所述第三队列数据进行处理，得到各个队列成员对应的执行动作，记为第二执行动作；第二写操作执行子单元，用于对所述第二写入数据、所述第三写入数据和各个队列成员对应的所述第二执行动作进行处理，实现对IO设备的写操作，并得到报警标志；第二出队操作执行子单元，用于对所述第二队列数据和所述第三队列数据执行出队操作，得到存储请求事件的所述第二队列数据结构。

6.根据权利要求5所述的系统，其特征在于，还包括：写单元，用于执行所述汽车应用写IO设备的过程；

所述写单元具体包括：

第一写请求获取子单元，用于获取第一汽车应用发送的写IO设备的写请求，记为第一写请求，以及获取存储请求事件的队列数据结构，记为第一队列数据结构；

写入数据确定子单元，用于基于所述第一写请求和所述第一队列数据结构，得到需要写入IO设备里的数据，记为第一写入数据，以及执行入队操作之后的队列数据，记为第一队列数据；

执行动作确定子单元，用于基于所述第一队列数据得到各个队列成员对应的执行动作，记为第一执行动作；

第一写操作执行子单元，用于基于所述第一写入数据以及各个队列成员对应的所述第一执行动作，对IO设备执行写操作。

7.根据权利要求6所述的系统，其特征在于，所述写单元还包括：第一出队操作执行子单元，用于对执行入队操作之后的队列数据执行出队操作，得到存储请求事件的所述第一队列数据结构。

8.根据权利要求5所述的系统，其特征在于，还包括：读单元，用于执行所述汽车应用读IO设备的过程；

所述读单元具体包括：

读请求获取子单元，用于获取第二汽车应用发送的读IO设备的读请求；

IO设备确定子单元，用于基于所述读请求，得到需要读取的IO设备；

读取数据确定子单元，用于基于所述需要读取的IO设备，确定所述需要读取的IO设备的目标数据；

第一数据处理子单元，用于对所述目标数据进行处理，得到所述汽车应用读到的数据，实现对IO设备的读操作。

说明书

将虚拟化IO架构和汽车应用集成在ECU的方法及系统

技术领域

[0001] 本发明涉及汽车电子技术领域，更具体的说，涉及一种将虚拟化IO架构和汽车应用集成在ECU(Electronic Control Unit，电子控制单元)的方法及系统。

背景技术

[0002] 随着自动驾驶等汽车应用数量的日益增长，面向服务架构(Service‑Oriented Architecture，SOA)和域控制器对汽车电子电气架构提出了很多新的要求。为保证自动驾
驶汽车的正常行驶，汽车嵌入式系统的软件架构需要满足这些新的要求，需要支持新应用
的集成，用于集成的软件方法应该保证处理器各个核的协同工作、保证传感器和执行器的
实时控制、保证各个汽车应用可以共享传感器执行器以及其它IO设备。

[0003] AUTOSAR架构作为汽车电子业界实施多年的标准架构，在涉及SOA通讯的电子控制单元(主要是计算层电子控制单元)上可以使用AdaptiveAUTOSAR框架和POSIX操作系统，而
在涉及实时性要求很高的传感器、执行器控制的电子控制单元(例如底盘域的转向、制动等
电子控制单元)上，通常使用经典AUTOSAR架构和AUTOSAR/OSEK操作系统，传感器、执行器和
其它IO设备由基础软件(BSW)进行抽象和控制。

[0004] 然而，无论是经典的AUTOSAR架构还是最新的AUTOSAR架构都有待完善(完善标准体系文件)和扩展(扩展架构接口)，以满足因汽车应用数量的增长、SOA和域控制器对汽车
电子电气架构提出的新的要求。

发明内容

[0005] 有鉴于此，本发明公开一种将虚拟化IO架构和汽车应用集成在ECU的方法及系统，以能够保证多个汽车应用和基础软件在电子控制单元上集成的可靠性和实时性，使得安装
在电子控制单元上的各个汽车应用能够共享电子控制单元上的传感器、执行器和其它IO设
备。

[0006] 一种将虚拟化IO架构和汽车应用集成在电子控制单元ECU的方法，所述ECU包括：硬件架构和软件架构，

[0007] 所述硬件架构包括：至少一个芯片系统，至少一个所述芯片系统中的每个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备；

[0008] 所述软件架构包括：在至少一个具有所述多处理器核的所述芯片系统上运行的多核操作系统，所述多核操作系统为运行在每个所述处理器核上的非对称多处理形式的实时
操作系统所构成的操作系统；

[0009] 将具有所述多处理器核的所述芯片系统中的一个处理器核作为主核，所述主核以外的处理器核作为从核，在所述主核上安装虚拟化IO驱动软件，在所述主核和每个所述从
核上都安装一个虚拟机监控器软件，在每个所述虚拟机监控器软件上安装至少一个汽车应
用，每个所述汽车应用包括：至少一个操作系统实体，每个所述汽车应用由所述汽车应用所
处的处理器核上的实时操作系统进行汽车应用内部各个任务的调度，每个所述汽车应用通
过所述汽车应用所处的处理器核上的虚拟机监控器软件读写IO设备。

[0010] 可选的，还包括：所述汽车应用写IO设备的过程，具体包括：

[0011] 获取第一汽车应用发送的写IO设备的写请求，记为第一写请求，以及获取存储请求事件的队列数据结构，记为第一队列数据结构；

[0012] 基于所述第一写请求和所述第一队列数据结构，得到需要写入IO设备里的数据，记为第一写入数据，以及执行入队操作之后的队列数据，记为第一队列数据；

[0013] 基于所述第一队列数据得到各个队列成员对应的执行动作，记为第一执行动作；

[0014] 基于所述第一写入数据以及各个队列成员对应的所述第一执行动作，对IO设备执行写操作。

[0015] 可选的，还包括：

[0016] 对执行入队操作之后的队列数据执行出队操作，得到存储请求事件的所述第一队列数据结构。

[0017] 可选的，还包括：所述汽车应用读IO设备的过程，具体包括：

[0018] 获取第二汽车应用发送的读IO设备的读请求；

[0019] 基于所述读请求，得到需要读取的IO设备；

[0020] 基于所述需要读取的IO设备，确定所述需要读取的IO设备的目标数据；

[0021] 对所述目标数据进行处理，得到所述汽车应用读到的数据，实现对IO设备的读操作。

[0022] 可选的，还包括：当安装在同一个芯片系统上的多个汽车应用同时请求写同一个IO设备，或，当安装在同一个电子控制单元的不同芯片系统上的多个汽车应用同时请求控
制同一个执行器的过程，具体包括：

[0023] 获取存储请求事件的队列数据结构，记为第二队列数据结构；

[0024] 获取第三汽车应用发送的写IO设备的写请求，记为第二写请求；

[0025] 基于所述第二写请求，得到需要写入IO设备里的数据，记为第二写入数据；

[0026] 对所述第二写请求和所述第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第二队列数据；

[0027] 获取第四汽车应用发送的写IO设备的写请求，记为第三写请求；

[0028] 基于所述第三写请求，得到需要写入IO设备里的数据，记为第三写入数据；

[0029] 对所述第三写请求和所述第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第三队列数据；

[0030] 对所述第二队列数据和所述第三队列数据进行处理，得到各个队列成员对应的执行动作，记为第二执行动作；

[0031] 对所述第二写入数据、所述第三写入数据和各个队列成员对应的所述第二执行动作进行处理，实现对IO设备的写操作，并得到报警标志；

[0032] 对所述第二队列数据和所述第三队列数据执行出队操作，得到存储请求事件的所述第二队列数据结构。

[0033] 一种将虚拟化IO架构和汽车应用集成在电子控制单元ECU的系统，所述ECU包括：硬件架构和软件架构，

[0034] 所述硬件架构包括：至少一个芯片系统，至少一个所述芯片系统中的每个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备；

[0035] 所述软件架构包括：在至少一个具有所述多处理器核的所述芯片系统上运行的多核操作系统，所述多核操作系统为运行在每个所述处理器核上的非对称多处理形式的实时
操作系统所构成的操作系统；

[0036] 将具有所述多处理器核的所述芯片系统中的一个处理器核作为主核，所述主核以外的处理器核作为从核，在所述主核上安装虚拟化IO驱动软件，在所述主核和每个所述从
核上都安装一个虚拟机监控器软件，在每个所述虚拟机监控器软件上安装至少一个汽车应
用，每个所述汽车应用包括：至少一个操作系统实体，每个所述汽车应用由所述汽车应用所
处的处理器核上的实时操作系统进行汽车应用内部各个任务的调度，每个所述汽车应用通
过所述汽车应用所处的处理器核上的虚拟机监控器软件读写IO设备。

[0037] 可选的，还包括：写单元，用于执行所述汽车应用写IO设备的过程；

[0038] 所述写单元具体包括：

[0039] 第一写请求获取子单元，用于获取第一汽车应用发送的写IO设备的写请求，记为第一写请求，以及获取存储请求事件的队列数据结构，记为第一队列数据结构；

[0040] 写入数据确定子单元，用于基于所述第一写请求和所述第一队列数据结构，得到需要写入IO设备里的数据，记为第一写入数据，以及执行入队操作之后的队列数据，记为第
一队列数据；

[0041] 执行动作确定子单元，用于基于所述第一队列数据得到各个队列成员对应的执行动作，记为第一执行动作；

[0042] 第一写操作执行子单元，用于基于所述第一写入数据以及各个队列成员对应的所述第一执行动作，对IO设备执行写操作。

[0043] 可选的，所述写单元还包括：

[0044] 第一出队操作执行子单元，用于对执行入队操作之后的队列数据执行出队操作，得到存储请求事件的所述第一队列数据结构。

[0045] 可选的，还包括：读单元，用于执行所述汽车应用读IO设备的过程；

[0046] 所述读单元具体包括：

[0047] 读请求获取子单元，用于获取第二汽车应用发送的读IO设备的读请求；

[0048] IO设备确定子单元，用于基于所述读请求，得到需要读取的IO设备；

[0049] 读取数据确定子单元，用于基于所述需要读取的IO设备，确定所述需要读取的IO设备的目标数据；

[0050] 第一数据处理子单元，用于对所述目标数据进行处理，得到所述汽车应用读到的数据，实现对IO设备的读操作。

[0051] 可选的，还包括：多应用执行单元，用于执行当安装在同一个芯片系统上的多个汽车应用同时请求写同一个IO设备，或，当安装在同一个电子控制单元的不同芯片系统上的
多个汽车应用同时请求控制同一个执行器的过程；

[0052] 所述多应用执行单元具体包括：

[0053] 数据结构获取子单元，用于获取存储请求事件的队列数据结构，记为第二队列数据结构；

[0054] 第二写请求获取子单元，用于获取第三汽车应用发送的写IO设备的写请求，记为第二写请求；

[0055] 第一写入数据获取子单元，用于基于所述第二写请求，得到需要写入IO设备里的数据，记为第二写入数据；

[0056] 第二数据处理子单元，用于对所述第二写请求和所述第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第二队列数据；

[0057] 第三写请求获取子单元，用于获取第四汽车应用发送的写IO设备的写请求，记为第三写请求；

[0058] 第二写入数据获取子单元，用于基于所述第三写请求，得到需要写入IO设备里的数据，记为第三写入数据；

[0059] 第三数据处理子单元，用于对所述第三写请求和所述第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第三队列数据；

[0060] 第四数据处理子单元，用于对所述第二队列数据和所述第三队列数据进行处理，得到各个队列成员对应的执行动作，记为第二执行动作；

[0061] 第二写操作执行子单元，用于对所述第二写入数据、所述第三写入数据和各个队列成员对应的所述第二执行动作进行处理，实现对IO设备的写操作，并得到报警标志；

[0062] 第二出队操作执行子单元，用于对所述第二队列数据和所述第三队列数据执行出队操作，得到存储请求事件的所述第二队列数据结构。

[0063] 从上述的技术方案可知，本发明公开了一种将虚拟化IO架构和汽车应用集成在ECU的方法及系统，ECU包括：硬件架构和软件架构，硬件架构包括：至少一个芯片系统，至少
一个芯片系统中的每个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的
IO设备，软件架构包括：在至少一个具有多处理器核的芯片系统上运行的多核操作系统，该
多核操作系统为运行在每个处理器核上的非对称多处理形式的实时操作系统所构成的操
作系统，在该软件架构中的至少一个具有多处理器核的芯片系统上实施如下方法：将具有
多处理器核的芯片系统中的一个处理器核作为主核，该芯片系统中的其他的处理器核作为
从核，在主核上安装虚拟化IO驱动软件，在主核和每个从核上都安装一个虚拟机监控器软
件，在每个虚拟机监控器软件上安装至少一个汽车应用，每个汽车应用由其所处的处理器
核上的实时操作系统进行汽车应用内部各个任务的调度，并通过虚拟机监控器软件读写IO
设备。本发明由虚拟化IO驱动软件和虚拟机监控器软件实现将虚拟化IO架构和汽车应用集
成在ECU上，运行环境由ECU中的硬件架构和实时操作系统提供，并且可以被对称地部署在
硬件架构的各个具有多处理器核的芯片系统上，因此，本发明能够保证多个汽车应用和基
础软件在电子控制单元上集成的可靠性和实时性，使得安装在电子控制单元上的各个汽车
应用能够共享电子控制单元上的传感器、执行器和其它IO设备。

附图说明

[0064] 为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本
发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据
公开的附图获得其他的附图。

[0065] 图1为本发明实施例公开的一种整车电子控单元抽象类示意图；

[0066] 图2为本发明实施例公开的一种一个电子控制单元和一电机(执行器)连接的实例性汽车结构示意图；

[0067] 图3为本发明实施例公开的一种ECU示例性结构示意图；

[0068] 图4为本发明实施例公开的一种汽车应用写IO设备的方法流程图；

[0069] 图5为本发明实施例公开的一种汽车应用读IO设备的方法流程图；

[0070] 图6为本发明实施例公开的一种当安装在同一个SOC上的多个汽车应用同时请求写同一个IO设备，或，当安装在同一个ECU的不同SOC上的多个汽车应用同时请求控制同一
个执行器时的方法流程图；

[0071] 图7为本发明实施例公开的一种写单元的结构示意图；

[0072] 图8为本发明实施例公开的一种读单元的结构示意图；

[0073] 图9为本发明实施例公开的一种多应用执行单元的结构示意图。

具体实施方式

[0074] 为使汽车嵌入式系统的软件架构满足SOA和域控制器对汽车电子电气架构提出的新的要求，并能够支持这些新增汽车应用的集成，用于集成的软件方法应该保证处理器各
个核的协同工作，保证传感器和执行器的实时控制，保证各个汽车应用可以共享传感器、执
行器以及其它IO设备。现有的技术方案主要包括如下三类：

[0075] 第一类方案：基础软件的全部功能被分配给一个应用；

[0076] 第二类方案：给每个应用分配基础软件全部功能的一个子集(至少一个应用分配得到的是基础软件功能的一个非空真子集)；

[0077] 第三类方案：基础软件的全部功能被分配给每一个应用。

[0078] 本发明的发明人经过研究后发现，上述三类方案存在如下问题：

[0079] 第一类方案，只有一个应用可以和IO设备进行交互，因此，汽车嵌入式系统的实用性较低，尤其是底盘域电子控制单元，由于底盘域电子控制单元的应用通常都涉及与多个
传感器和执行器的交互，因此当只有一个应用可以和IO设备进行交互时，底盘域电子控制
单元的实用性降低。

[0080] 第二类方案，各个汽车应用分别可以和一部分IO设备进行交互，这样虽然可以较好地实现应用的并发性协同运行，但是在应对以下场景时不够灵活，例如新增加的汽车应
用需要访问一个已经分配给原有应用的IO设备，或者例如需要调整一个IO设备的分配，而
这两种场景在SOA经常出现，因此第二类方案没有实现各个应用设计之间的解耦。

[0081] 第三类方案，实现了基础软件设计和应用设计的解耦，使得每个应用都独享IO设备，这技术方案在类似的领域(例如汽车智能座舱)已有实现，例如一些基于Linux操作系统
和特定硬件实现的中间层软件，使得Linux上的各个应用能够共享该硬件的IO设备和DSP
(Digital Signal Process，数字信号处理)、硬件加速器等功能。第三类方案在对时延有较
高要求的传感器滤波、执行器控制，尤其是以电机为执行器的位置闭环控制、速度闭环控
制、电流闭环控制的实时性上性能不足甚至不能满足技术要求，例如汽车底盘域的电子控
制单元需要使用硬实时性操作系统(AUTOSAR/OSEK或其他RTOS(实时操作系统)，不能直接
使用Linux的虚拟化方法)。

[0082] 为解决上述三类技术方案存在的问题，本发明提供一种将虚拟化IO架构和汽车应用集成在ECU的方法及系统，在提高“汽车嵌入式系统实用性”(第一类方案的缺陷)同时，既
能支持“各个应用设计之间的解耦”(第二类方案的缺陷)，又能满足“实时性控制”(第三类
方案的缺陷)的要求。

[0083] 为便于理解本发明所要保护的技术方案，从应用场景上对本发明与已有技术方案的区别做出说明：依据职责，可以将电子控制单元(Electronic Control Unit，ECU)划分为
两大类，A类可称为计算层电子控制单元(如图1中示出的ECU‑A0～A1)，主要负责驾驶算法
的决策、云端通讯、图像处理等，B类可称为IO层电子控制单元(如图1中示出的ECU‑B0～
B5)，主要负责传感器、执行器的控制，如前所述，这两类电子控制单元对软件的需求不同，
因此有不同的适用的软件架构，目前已有的虚拟化技术方案的应用场景是A类电子控制单
元，本发明的应用场景是B类电子控制单元，其中，A类电子控制单元和B类电子控制单元通
过CAN(Controller Area Network，控制器局域网络)总线或实时以太网连接。

[0084] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于
本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他
实施例，都属于本发明保护的范围。

[0085] 本发明实施例公开了一种将虚拟化IO架构和汽车应用集成在ECU的方法及系统，ECU包括：硬件架构和软件架构，硬件架构包括：至少一个芯片系统，至少一个芯片系统中的
每个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备，软件架构
包括：在至少一个具有多处理器核的芯片系统上运行的多核操作系统，该多核操作系统为
运行在每个处理器核上的非对称多处理形式的实时操作系统所构成的操作系统，在该软件
架构中的至少一个具有多处理器核的芯片系统上实施如下方法：将具有多处理器核的芯片
系统中的一个处理器核作为主核，该芯片系统中的其他的处理器核作为从核，在主核上安
装虚拟化IO驱动软件，在主核和每个从核上都安装一个虚拟机监控器软件，在每个虚拟机
监控器软件上安装至少一个汽车应用，每个汽车应用由其所处的处理器核上的实时操作系
统进行汽车应用内部各个任务的调度，并通过虚拟机监控器软件读写IO设备。本发明由虚
拟化IO驱动软件和虚拟机监控器实现将虚拟化IO架构和汽车应用集成在ECU上，运行环境
由ECU中的硬件架构和实时操作系统提供，并且可以被对称地部署在硬件架构的各个具有
多处理器核的芯片系统上，因此，本发明能够保证多个汽车应用和基础软件在电子控制单
元上集成的可靠性和实时性，使得安装在电子控制单元上的各个汽车应用能够共享电子控
制单元上的传感器、执行器和其它IO设备。

[0086] 本发明公开的一种将虚拟化IO架构和汽车应用集成在ECU的方法，ECU包括：硬件架构和软件架构。

[0087] 其中，ECU中的硬件架构包括：至少一个芯片系统(System On Chip，SOC)，至少一个芯片系统中的每个芯片系统包括：多个处理器核(Core)以及用于与传感器或执行器进行
接口的IO(Input/Output，输入输出)设备。

[0088] IO设备可以是AD采样器、SPI(Serial Peripheral Interface，串行外设接口)串口通讯装置、通用IO、PWM(Pulse width modulation，脉冲宽度调制)信号发生器、SENT
(Single Edge Nibble Transmission)接口、PSI5(Peripheral Subsystem Interface，外
设传感器接口)或者其他形式的IO设备。

[0089] 其中，SENT，是美国机动车工程师学会SAE推出的一种点对点的、单向传输的方案，被用来在汽车中的传感器和电子控制单元之间传输高清传感器数据。

[0090] SENT用于汽车应用的总线接口，该接口提供高度可靠和快速的数据传输。

[0091] 在实际应用中，硬件架构中还包括：内存、非易失存储设备、汽车局域网通讯总线和其它硬件设备。

[0092] 在与ECU连接的外部传感器和执行器配置方面，如图2所示，本实施范例中一个ECU和一个电机通过插接的形式连接，ECU可以通过图3中的PWM0或者PWM1来控制该电机输出力
矩。

[0093] 为便于理解，举例说明ECU中的硬件架构，在图3所示的ECU10中，硬件架构11包括两个芯片系统，分别为：SOC0和SOC1，其中，SOC0包括3个处理器核，分别为：Core0、Core1和
Core2，以及1个PWM输出设备PWM0和1个ADC采样输入设备ADC0。SOC1包括2个处理器核，分别
为：Core3和Core4，以及1个PWM输出设备PWM1。

[0094] ECU10中的软件架构12包括：在至少一个具有多处理器核的芯片系统上运行的多核操作系统，多核操作系统为运行在每个处理器核上的非对称多处理形式(Asymmetric 
multiprocessing，AMP)的实时操作系统所构成的操作系统，将每个具有多处理器核的芯片
系统中的一个处理器核作为主核，主核以外的处理器核作为从核，在主核上安装虚拟化IO
驱动软件，在主核和每个从核上都安装一个虚拟机监控器软件(Virtual Machine 
Monitor，VMM)，在每个虚拟机监控器软件上安装至少一个汽车应用(OsApplicaiton)，每个
汽车应用包括：至少一个操作系统实体(OsObject)，每个汽车应用由该汽车应用所处的处
理器核上的实时操作系统进行汽车应用内部各个任务的调度，每个汽车应用通过该汽车应
用所处的处理器核上的虚拟机监控器软件读写IO设备。

[0095] 其中，操作系统实体是专有名词，操作系统实体包括：操作系统任务、事件、应用、中断、资源、自旋锁、计数器和警报等。

[0096] 非对称多处理形式是多核操作系统的一种处理模式，指每个处理器核运行一个独立的操作系统或者同一个操作系统的独立实例(instantiation)。除了非对称多处理形式
以外，常见的多核操作系统处理模式还有对称多处理(SMP)、混合多处理(BMP)等。

[0097] 为便于理解，举例说明ECU中的软件架构，在图3所示的ECU中，SOC0的3个处理器核上部署了非对称式的实时操作系统OS0、OS1和OS2，Core0上安装虚拟化IO驱动软件
VmDriver0，Core0上安装1个虚拟机监控器软件VMM0，Core1上安装1个虚拟机监控器软件
VMM1，Core2上安装1个虚拟机监控器软件VMM2。在每个虚拟机监控器软件上安装了1个、2个
或者多个汽车应用(OsApplication)。在本实施例中，VMM0上安装了2个汽车应用APP0和
APP1，VMM1上安装了2个汽车应用APP2和APP3，VMM2上安装了2个汽车应用APP4和APP5，每个
汽车应用包括1个、2个或者多个操作系统任务，还可以包括操作系统资源、事件等其它操作
系统实体(OsObject)。APP0～APP5由OS0～OS2调度，APP0和APP1可以通过VMM0读设备ADC0、
写设备PWM0，APP2和APP3可以通过VMM1读设备ADC0、写设备PWM0，APP4和APP5可以通过VMM2
读设备ADC0、写设备PWM0。

[0098] 在图3所示实施例中，SOC1的2个处理器核上部署了非对称式的实时操作系统OS3和OS4，Core3上安装虚拟化IO驱动软件VmDriver1，Core3上安装1个虚拟机监控器软件
VMM3，Core4上安装1个虚拟机监控器软件VMM4。在每个虚拟机监控器软件上安装了1个、2个
或者多个汽车应用。在本实施例中，VMM3上安装了1个汽车应用APP6，VMM4上安装了2个汽车
应用APP7和APP8，每个汽车应用包括1个、2个或者多个操作系统任务，还可以包括操作系统
资源、事件等其它操作系统实体。APP6～APP8由OS3和OS4调度，APP6可以通过VMM3写设备
PWM1，APP7和APP8可以通过VMM4写设备PWM1。

[0099] 综上可知，本发明公开了一种将虚拟化IO架构和汽车应用集成在ECU的方法，ECU包括：硬件架构和软件架构，硬件架构包括：至少一个芯片系统，至少一个芯片系统中的每
个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备，软件架构包
括：在至少一个具有多处理器核的芯片系统上运行的多核操作系统，该多核操作系统为运
行在每个处理器核上的非对称多处理形式的实时操作系统所构成的操作系统，在该软件架
构中的至少一个具有多处理器核的芯片系统上实施如下方法：将具有多处理器核的芯片系
统中的一个处理器核作为主核，该芯片系统中的其他的处理器核作为从核，在主核上安装
虚拟化IO驱动软件，在主核和每个从核上都安装一个虚拟机监控器软件，在每个虚拟机监
控器软件上安装至少一个汽车应用，每个汽车应用由其所处的处理器核上的实时操作系统
进行汽车应用内部各个任务的调度，并通过虚拟机监控器软件读写IO设备。本发明由虚拟
化IO驱动软件和虚拟机监控器实现将虚拟化IO架构和汽车应用集成在ECU上，运行环境由
ECU中的硬件架构和实时操作系统提供，并且可以被对称地部署在硬件架构的各个具有多
处理器核的芯片系统上，因此，本发明能够保证多个汽车应用和基础软件在电子控制单元
上集成的可靠性和实时性，使得安装在电子控制单元上的各个汽车应用能够共享电子控制
单元上的传感器、执行器和其它IO设备。

[0100] 实施方式一

[0101] 为进一步优化上述实施例，参见图4，本发明实施例公开了一种汽车应用写IO设备的方法流程图，该方法包括：

[0102] 步骤S101、获取第一汽车应用发送的写IO设备的写请求，记为第一写请求，以及获取存储请求事件的队列数据结构，记为第一队列数据结构；

[0103] 步骤S102、基于第一写请求和第一队列数据结构，得到需要写入IO设备里的数据，记为第一写入数据，以及执行入队操作之后的队列数据，记为第一队列数据；

[0104] 步骤S103、基于第一队列数据得到各个队列成员对应的执行动作，记为第一执行动作；

[0105] 步骤S104、基于第一写入数据以及各个队列成员对应的第一执行动作，对IO设备执行写操作。

[0106] 为进一步优化上述实施例，在步骤S104之后，还可以包括：

[0107] 步骤S105、对执行入队操作之后的队列数据执行出队操作，得到存储请求事件的第一队列数据结构。

[0108] 为便于理解图4所示实施例，结合图3，以APP2请求写PWM0的过程为例，对汽车应用写IO设备的过程进行说明，具体如下：

[0109] APP2运行于用户模式，VmDriver0和VMM1运行于特权模式，APP2请求写PWM0的占空比，调用OUT to IO device(VMM提供给用户的接口程序，由VMM实现，并由用户汽车应用调
用)，在Core1上进行上下文切换(upper‑lower context switching)，具体为：操作系统的
核心，即内核，在CPU(Central Processing Unit，中央处理器)上对进程或者线程进行切
换，上下文切换过程中的信息被保存在进程控制块中。然后VMM1执行两个操作：一是将APP2
需要写的占空比存储在输出缓冲区B1里；二是进行一次“入队”操作，将OUT to IO device
的ID存储在1个队列Q1里，其中，SOC上包含的IO设备及对应ID来自于电子控制单元硬件架
构，可以向各个APP开发者公开，缓冲区B1和队列Q1位于VmDriver0和VMM1的共享RAM里，对
二者的读写操作可以使用原子操作或者自旋锁等方式，以保证读写前后数据一致性。

[0110] 注：操作系统抽象的运行模式，对所执行程序的权限进行限制，可以概括分为：特权模式和用户模式。特权模式可以直接读写系统内核的资源；用户模式主要运行用户的应
用程序，需要切换到特权模式才能访问内核资源或执行内核提供给用户的接口程序。具体
地，不同操作系统可能将特权模式和用户模式更详细地分为1级、2级甚至多级。

[0111] 在Core0(主核)上，VmDriver0定义了一个动作列表方法，对应于Core1和Core2的2个动作列表实例ALI1和ALI2，定义了与每个从核和每个IO设备ID相对应的Core0执行动作。
VmDriver0周期性(例如100us)地轮询队列Q1和Q2(对应于Core2)中是否有成员。在本实施
范例中，Q1队列不为空，VmDriver0从队列中获取成员的ID，从缓冲区B1获取PWM0占空比，
ALI1动作列表里与PWM0的ID对应的执行动作是写PWM0的占空比，然后VmDriver0进行一次
Q1的“出队”操作，将本次APP2写PWM0的请求清除出队列。如果Q2队列不为空，VmDriver0也
会执行类似的操作，在本实施范例中，Q2队列为空，VmDriver0结束本次轮询。

[0112] 实施方式二

[0113] 为进一步优化上述实施例，参见图5，本发明实施例公开的一种汽车应用读IO设备的方法流程图，该方法包括：

[0114] 步骤S201、获取第二汽车应用发送的读IO设备的读请求；

[0115] 步骤S202、基于读请求，得到需要读取的IO设备；

[0116] 步骤S203、基于需要读取的IO设备，确定需要读取的IO设备的目标数据；

[0117] 步骤S204、对目标数据进行处理，得到汽车应用读到的数据，实现对IO设备的读操作。

[0118] 为便于理解图5所示实施例，结合图3，以APP2读ADC0的过程为例，对汽车应用读IO设备的过程进行说明，具体如下：

[0119] APP2运行于用户模式，VmDriver0与VMM1运行于特权模式。当VmDriver0完成了一次ADC0采样后，将采样结果存储在输入缓冲区B1里，B1位于VmDriver0和VMM1的共享RAM
(Random Access Memory，随机存取存储器)里，对B1的读写操作可以使用原子操作或者自
旋锁等方式来保证数据一致性。

[0120] 可以由VmDriver0产生Core1上的一个软件中断，APP2据此发出读ADC0的读请求，调用IN to IO device，在Core1上进行上下文切换，VMM1将输入缓冲区B1的数据拷贝给
APP2。

[0121] 也可以由APP2对ADC0设备进行轮询，即APP2周期性地调用IN to IO device，在Core1上进行上下文切换，VMM1周期性地将输入缓冲区B1的数据拷贝给APP2，即使缓冲区B1
的数据并没有被VmDriver0更新。VMM可以给APP提供Group IN to IO device的接口，使得
可以在一次上下文切换中完成多个IO设备的读操作。

[0122] 实施方式三

[0123] 当安装在同一个SOC上的多个汽车应用同时请求写同一个IO设备时，通常这种竞争情况在执行器控制上是不允许的，在本发明中，VMM可以报警给汽车应用，并且硬件上不
发生总线故障。

[0124] 因此，为进一步优化上述实施例，参见图6，本发明实施例公开的一种当安装在同一个SOC上的多个汽车应用同时请求写同一个IO设备，或，当安装在同一个ECU的不同SOC上
的多个汽车应用同时请求控制同一个执行器时的方法流程图，该方法包括：

[0125] 步骤S301、获取存储请求事件的队列数据结构，记为第二队列数据结构；

[0126] 步骤S302、获取第三汽车应用发送的写IO设备的写请求，记为第二写请求；

[0127] 步骤S303、基于第二写请求，得到需要写入IO设备里的数据，记为第二写入数据；

[0128] 步骤S304、对第二写请求和第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第二队列数据；

[0129] 步骤S305、获取第四汽车应用发送的写IO设备的写请求，记为第三写请求；

[0130] 步骤S306、基于第三写请求，得到需要写入IO设备里的数据，记为第三写入数据；

[0131] 步骤S307、对第三写请求和第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第三队列数据；

[0132] 需要特别说明的是，步骤S302～步骤S304顺序执行，对应一个汽车应用，步骤S305～步骤S307顺序执行，对应另一个汽车应用，步骤S302～步骤S304与步骤S305～步骤S307
是并行执行的。

[0133] 步骤S308、对第二队列数据和第三队列数据进行处理，得到各个队列成员对应的执行动作，记为第二执行动作；

[0134] 步骤S309、对第二写入数据、第三写入数据和各个队列成员对应的第二执行动作进行处理，实现对IO设备的写操作，并得到报警标志；

[0135] 步骤S310、对第二队列数据和第三队列数据执行出队操作，得到存储请求事件的第二队列数据结构。

[0136] 为便于理解图6所示实施例，结合图3，以APP2和APP4同时请求写PWM0为例，对当安装在同一个SOC上的多个汽车应用同时请求写同一个IO设备的过程进行说明，具体如下：

[0137] 假设，APP2、APP4运行于用户模式，VmDriver0、VMM1和VMM2运行于特权模式。VMM1定义缓冲区B1和队列Q1，位于与VmDriver0的共享RAM里。VMM2定义缓冲区B2和队列Q2，位于
与VmDriver0的共享RAM里。

[0138] APP2请求写PWM0的占空比，调用OUT to IO device，在Core1上进行上下文切换，然后VMM1执行两个操作：一是将APP2要写的占空比存储在输出缓冲区B1里；二是进行一次
“入队”操作，将OUT to IO device的ID存储在队列Q1里，缓冲区B1和队列Q1位于共享RAM
里，对二者的读写操作可以使用原子操作或者自旋锁等方式，以保证数据一致性。

[0139] 与APP2并行地，APP4也请求写PWM0的占空比，调用OUT to IO device，在Core2上进行上下文切换，然后VMM2执行两个操作：一是将APP4要写的占空比存储在输出缓冲区B2
里；二是进行一次“入队”操作，将OUT to IO device的ID存储在队列Q2里，缓冲区B2和队列
Q2位于共享RAM里，对二者的读写操作可以使用原子操作或者自旋锁等方式，以保证数据一
致性。

[0140] 在Core0上，VmDriver0有对应于Core1和Core2的2个动作列表实例ALI1和ALI2，定义了与每个从核和每个IO设备ID相对应的Core0执行动作。VmDriver0周期性(例如，100us)
地轮询队列Q1和Q2中是否有成员。如果Q1队列不为空，VmDriver0从队列中获取成员的ID，
从缓冲区B1获取PWM0占空比，ALI1动作列表里与PWM0的ID对应的执行动作是写PWM0的占空
比，然后VmDriver0进行一次Q1的“出队”操作，将本次APP2写PWM0的请求清除出队列。如果
Q2队列不为空，VmDriver0从队列中获取成员的ID，从缓冲区B2获取PWM0占空比，ALI2动作
列表里与PWM0的ID对应的执行动作是写PWM0的占空比，然后VmDriver0进行一次Q2的“出
队”操作，将本次APP4写PWM0的请求清除出队列。

[0141] 在1个轮询周期结束时，VmDriver0检测在本周期内是否对同一个IO设备进行了2次或2次以上的写操作，如果检测结果为真，则由VMM产生一个软件中断对相应Core上的APP
进行报警，各个APP可以选择屏蔽这个报警或者执行各自的报警处理，这取决于APP的设计。

[0142] 当安装在同一个电子控制单元ECU的不同SOC上的多个汽车应用同时请求控制同一个执行器时，也采用图6所示实施例实现。

[0143] 为便于理解，结合图3，以APP2和APP6竞争电机控制权为例，即APP2请求写PWM0、APP6同时请求写PWM1。通常这种竞争的情况在执行器控制上是不允许的，在本实施范例中，
VmDriver0和VmDriver1可以报警给汽车应用，并且SOC上不发生总线故障，SOC外部的总线
需要由电子控制单元通过对报警信息的处理来保证、或者由电机驱动电路的硬件安全机制
来保证、或者由二者协同保证。

[0144] APP2和APP6写PWM的过程与上述的实施方式三一样，类似地，VmDriver0或者VmDriver1在1个轮询周期结束时，检测在本周期内是否对同一个IO设备进行了2次或2次以
上的写操作；额外地，VmDriver0或者VmDriver1可以在1个或者连续多个轮询周期结束时，
检测是否有其它SOC的VmDriver对同一个设备进行了写操作，如果在这短时间内，有2个或
者2个以上的VmDriver对同一个设备进行了写操作，则VmDriver可以产生一个软件中断对
相应Core上的汽车软件进行报警。

[0145] 综上可知，本发明公开的一种将虚拟化IO架构和汽车应用集成在ECU的方法，ECU包括：硬件架构和软件架构，硬件架构包括：至少一个芯片系统，至少一个芯片系统中的每
个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备，软件架构包
括：在至少一个具有多处理器核的芯片系统上运行的多核操作系统，该多核操作系统为运
行在每个处理器核上的非对称多处理形式的实时操作系统所构成的操作系统，在该软件架
构中的至少一个具有多处理器核的芯片系统上实施如下方法：将具有多处理器核的芯片系
统中的一个处理器核作为主核，该芯片系统中的其他的处理器核作为从核，在主核上安装
虚拟化IO驱动软件，在主核和每个从核上都安装一个虚拟机监控器软件，在每个虚拟机监
控器软件上安装至少一个汽车应用，每个汽车应用由其所处的处理器核上的实时操作系统
进行汽车应用内部各个任务的调度，并通过虚拟机监控器软件读写IO设备。本发明由虚拟
化IO驱动软件和虚拟机监控器实现将虚拟化IO架构和汽车应用集成在ECU上，运行环境由
ECU中的硬件架构和实时操作系统提供，并且可以被对称地部署在硬件架构的各个具有多
处理器核的芯片系统上，因此，本发明能够保证多个汽车应用和基础软件在电子控制单元
上集成的可靠性和实时性，使得安装在电子控制单元上的各个汽车应用能够共享电子控制
单元上的传感器、执行器和其它IO设备。

[0146] 另外，本发明中各个汽车应用可以同时共享全部输入设备和不同的输出设备，各个汽车应用可以分时共享同一个输出设备。

[0147] 进一步，各个汽车应用在同时竞争同一个输出设备时，VMM可以报警给汽车应用，并且硬件上不发生总线故障。

[0148] 本发明保留了汽车应用静态部署在一个确定的控制器核上的特点，无需进行并行计算的设计，从而简化了汽车应用的实施。

[0149] 与上述方法实施例相对应，本发明还公开了一种将虚拟化IO架构和汽车应用集成在ECU的系统。

[0150] 本发明公开的一种将虚拟化IO架构和汽车应用集成在ECU的系统，ECU包括：硬件架构和软件架构。

[0151] 其中，ECU中的硬件架构包括：至少一个芯片系统(System On Chip，SOC)，至少一个芯片系统中的每个芯片系统包括：多个处理器核(Core)以及用于与传感器或执行器进行
接口的IO(Input/Output，输入输出)设备。

[0152] ECU10中的软件架构12包括：在至少一个具有多处理器核的芯片系统上运行的多核操作系统，多核操作系统为运行在每个处理器核上的非对称多处理形式(Asymmetric 
multiprocessing，AMP)的实时操作系统所构成的操作系统，将每个具有多处理器核的芯片
系统中的一个处理器核作为主核，主核以外的处理器核作为从核，在主核上安装虚拟化IO
驱动软件，在主核和每个从核上都安装一个虚拟机监控器软件(Virtual Machine 
Monitor，VMM)，在每个虚拟机监控器软件上安装至少一个汽车应用(OsApplicaiton)，每个
汽车应用包括：至少一个操作系统实体(OsObject)，每个汽车应用由该汽车应用所处的处
理器核上的实时操作系统进行汽车应用内部各个任务的调度，每个汽车应用通过该汽车应
用所处的处理器核上的虚拟机监控器软件读写IO设备。

[0153] 其中，操作系统实体是专有名词，操作系统实体包括：操作系统任务、事件、应用、中断、资源、自旋锁、计数器和警报等。

[0154] 综上可知，本发明公开了一种将虚拟化IO架构和汽车应用集成在ECU的系统，ECU包括：硬件架构和软件架构，硬件架构包括：至少一个芯片系统，至少一个芯片系统中的每
个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备，软件架构包
括：在至少一个具有多处理器核的芯片系统上运行的多核操作系统，该多核操作系统为运
行在每个处理器核上的非对称多处理形式的实时操作系统所构成的操作系统，在该软件架
构中的至少一个具有多处理器核的芯片系统上实施如下方法：将具有多处理器核的芯片系
统中的一个处理器核作为主核，该芯片系统中的其他的处理器核作为从核，在主核上安装
虚拟化IO驱动软件，在主核和每个从核上都安装一个虚拟机监控器软件，在每个虚拟机监
控器软件上安装至少一个汽车应用，每个汽车应用由其所处的处理器核上的实时操作系统
进行汽车应用内部各个任务的调度，并通过虚拟机监控器软件读写IO设备。本发明由虚拟
化IO驱动软件和虚拟机监控器实现将虚拟化IO架构和汽车应用集成在ECU上，运行环境由
ECU中的硬件架构和实时操作系统提供，并且可以被对称地部署在硬件架构的各个具有多
处理器核的芯片系统上，因此，本发明能够保证多个汽车应用和基础软件在电子控制单元
上集成的可靠性和实时性，使得安装在电子控制单元上的各个汽车应用能够共享电子控制
单元上的传感器、执行器和其它IO设备。

[0155] 实施方式一

[0156] 为进一步优化上述实施例，参见图7，本发明实施例公开的一种写单元的结构示意图，写单元用于执行汽车应用写IO设备的过程。

[0157] 写单元具体包括：

[0158] 第一写请求获取子单元401，用于获取第一汽车应用发送的写IO设备的写请求，记为第一写请求，以及获取存储请求事件的队列数据结构，记为第一队列数据结构；

[0159] 写入数据确定子单元402，用于基于第一写请求和第一队列数据结构，得到需要写入IO设备里的数据，记为第一写入数据，以及执行入队操作之后的队列数据，记为第一队列
数据；

[0160] 执行动作确定子单元403，用于基于第一队列数据得到各个队列成员对应的执行动作，记为第一执行动作；

[0161] 第一写操作执行子单元404，用于基于第一写入数据以及各个队列成员对应的第一执行动作，对IO设备执行写操作。

[0162] 为进一步优化上述实施例，

[0163] 写单元还可以包括：

[0164] 第一出队操作执行子单元，用于对执行入队操作之后的队列数据执行出队操作，得到存储请求事件的第一队列数据结构。

[0165] 实施方式二

[0166] 参见图8，本发明实施例公开的一种读单元的结构示意图，读单元，用于执行汽车应用读IO设备的过程。

[0167] 读单元具体包括：

[0168] 读请求获取子单元501，用于获取第二汽车应用发送的读IO设备的读请求；

[0169] IO设备确定子单元502，用于基于读请求，得到需要读取的IO设备；

[0170] 读取数据确定子单元503，用于基于需要读取的IO设备，确定需要读取的IO设备的目标数据；

[0171] 第一数据处理子单元504，用于对目标数据进行处理，得到汽车应用读到的数据，实现对IO设备的读操作。

[0172] 实施方式三

[0173] 参见图9，本发明实施例公开的一种多应用执行单元的结构示意图，多应用执行单元用于执行当安装在同一个芯片系统上的多个汽车应用同时请求写同一个IO设备，或，当
安装在同一个电子控制单元的不同芯片系统上的多个汽车应用同时请求控制同一个执行
器的过程。

[0174] 多应用执行单元具体可以包括：

[0175] 数据结构获取子单元601，用于获取存储请求事件的队列数据结构，记为第二队列数据结构；

[0176] 第二写请求获取子单元602，用于获取第三汽车应用发送的写IO设备的写请求，记为第二写请求；

[0177] 第一写入数据获取子单元603，用于基于第二写请求，得到需要写入IO设备里的数据，记为第二写入数据；

[0178] 第二数据处理子单元604，用于对第二写请求和第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第二队列数据；

[0179] 第三写请求获取子单元605，用于获取第四汽车应用发送的写IO设备的写请求，记为第三写请求；

[0180] 第二写入数据获取子单元606，用于基于第三写请求，得到需要写入IO设备里的数据，记为第三写入数据；

[0181] 第三数据处理子单元607，用于对第三写请求和第二队列数据结构进行处理，得到执行入队操作之后的队列数据，记为第三队列数据；

[0182] 第四数据处理子单元608，用于对第二队列数据和第三队列数据进行处理，得到各个队列成员对应的执行动作，记为第二执行动作；

[0183] 第二写操作执行子单元609，用于对第二写入数据、第三写入数据和各个队列成员对应的第二执行动作进行处理，实现对IO设备的写操作，并得到报警标志；

[0184] 第二出队操作执行子单元610，用于对第二队列数据和第三队列数据执行出队操作，得到存储请求事件的第二队列数据结构。

[0185] 综上可知，本发明公开的一种将虚拟化IO架构和汽车应用集成在ECU的系统，ECU包括：硬件架构和软件架构，硬件架构包括：至少一个芯片系统，至少一个芯片系统中的每
个芯片系统包括：多处理器核以及用于与传感器或执行器进行接口的IO设备，软件架构包
括：在至少一个具有多处理器核的芯片系统上运行的多核操作系统，该多核操作系统为运
行在每个处理器核上的非对称多处理形式的实时操作系统所构成的操作系统，在该软件架
构中的至少一个具有多处理器核的芯片系统上实施如下方法：将具有多处理器核的芯片系
统中的一个处理器核作为主核，该芯片系统中的其他的处理器核作为从核，在主核上安装
虚拟化IO驱动软件，在主核和每个从核上都安装一个虚拟机监控器软件，在每个虚拟机监
控器软件上安装至少一个汽车应用，每个汽车应用由其所处的处理器核上的实时操作系统
进行汽车应用内部各个任务的调度，并通过虚拟机监控器软件读写IO设备。本发明由虚拟
化IO驱动软件和虚拟机监控器实现将虚拟化IO架构和汽车应用集成在ECU上，运行环境由
ECU中的硬件架构和实时操作系统提供，并且可以被对称地部署在硬件架构的各个具有多
处理器核的芯片系统上，因此，本发明能够保证多个汽车应用和基础软件在电子控制单元
上集成的可靠性和实时性，使得安装在电子控制单元上的各个汽车应用能够共享电子控制
单元上的传感器、执行器和其它IO设备。

[0186] 另外，本发明中各个汽车应用可以同时共享全部输入设备和不同的输出设备，各个汽车应用可以分时共享同一个输出设备。

[0187] 进一步，各个汽车应用在同时竞争同一个输出设备时，VMM可以报警给汽车应用，并且硬件上不发生总线故障。

[0188] 本发明保留了汽车应用静态部署在一个确定的控制器核上的特点，无需进行并行计算的设计，从而简化了汽车应用的实施。

[0189] 需要说明的是，系统实施例中各组成部分的具体工作原理，请参见方法实施例对应部分，此处不再赘述。

[0190] 最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作
之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意
在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那
些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者
设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排
除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

[0191] 本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

[0192] 对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的
一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明
将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一
致的最宽的范围。