一种访问IO设备的方法及装置与流程

一种访问io设备的方法及装置
技术领域
1.本申请通信技术领域，尤其涉及一种访问io设备的方法及装置。


背景技术：

2.随着智能化汽车和新能源汽车的发展,汽车电子电气架构从分离式向集中式演进，且控制器具有集中化的趋势。现在的车辆内通常设有几十甚至上百个控制器，以及数百个带有输入/输出(input/ouput，简称io)接口的io设备。这些io设备可以是各种传感器如温度传感器、湿度传感器等，也可以是各种执行器如电机等。这些io设备具有众多类型的接口，例如控制器局域网络(controller area network，简称can)接口、局域互联网络(local interconnect network，简称lin)接口、脉冲宽度调制(pulse width modulation，简称pwm)接口、h桥(h
‑
bridge bus，简称hb)接口、模数转换(analog
‑
to
‑
digital，简称ad)接口、数字输入(digital input，简称di)接口、数字输出(digital output，简称do)接口等。这使得在集中控制器上访问各种不同的io设备时，灵活性和可靠性较差。


技术实现要素：

3.本申请实施例所要解决的技术问题在于，提供一种访问io设备的方法及装置，以解决集中控制器访问各种不同类型io设备时，灵活性和可靠性较差的问题。
4.第一方面，本申请的实施例提供了一种访问io设备的方法，可包括：
5.第一集中控制器对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型，并生成所述各种io设备与标准模型的映射配置文件；
6.根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一io设备的第一标准模型；
7.根据所述映射配置文件，将所述资源访问请求发送给所述第一io设备。
8.通过对各种io设备进行对象化建模，可以实现单个标准模型与多个不同型号或不同接口的io设备的映射，使得集中控制器在访问某个io设备时，可以对该io设备对应的标准模型发出资源访问请求，并通过映射配置文件准确的将资源访问请求发送至该io设备，完成对该io设备的访问，无需针对不同厂家、车型、设备型号或接口类型进行调整，从而大大提升了访问io设备的灵活性和可靠性。
9.在一种可能的实现方式中，所述第一集中控制器对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型，并生成所述各种io设备与标准模型的映射配置文件，包括：
10.所述第一集中控制器根据应用访问的各种io设备的类型，面向应用对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型；
11.根据所述各种io设备的物理端口，面向io设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制io设备的控制数据的转换关系。
12.通过向上建模使得应用在访问io设备时可以通过访问标准模型实现，通过向下建
模可以使得不同接口的io设备与同一个物理端口进行映射，通过该物理端口便可以实现对不同接口类型的io设备进行访问，在访问不同接口类型的io设备时，将与标准模型对应的标准化数据和与控制设备对应的控制数据进行相应的转换即可。可以实现屏蔽io设备的物理端口类型的效果，在不同车型中开发中可以保持上层应用不变，降低开发难度，提高了应用层软件的复用度，利于车辆的研发和测试；厂家、车型、型号或接口变化仅需更新配置数据，方便升级。
13.在一种可能的实现方式中，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
14.所述方法还包括：
15.所述第一集中控制器根据所述转换关系将所述第一标准化数据转换为所述第一io设备对应的第一控制数据；
16.将所述第一控制数据发送给所述第一io设备。
17.通过数据转换，在访问不同厂家、车型、型号或接口的io设备时，只需要适应性的配置数据的转换关系即可。
18.在一种可能的实现方式中，所述方法还包括：
19.所述第一集中控制器接收所述第一io设备上报的采样数据；
20.根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
21.在一种可能的实现方式中，当所述第一集中控制器需要访问第二集中控制器下的第二io设备时，所述资源访问请求中包括所述用户访问的第二io设备的第二标准模型，所述方法还包括：
22.所述第一集中控制器将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二io设备。
23.通过这样的跨节点访问方式，第二集中控制器的应用层无需进行改动，也无需增加新的通信接口，从而提升了跨节点访问的效率，并降低了跨节点访问的成本。
24.第二方面，本申请的实施例提供了一种访问io设备的装置，可包括：
25.处理单元，用于对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型，并生成所述各种io设备与标准模型的映射配置文件；根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一io设备的第一标准模型；
26.收发单元，用于根据所述映射配置文件，将所述资源访问请求发送给所述第一io设备。
27.在一种可能的实现方式中，所述处理单元具体用于：
28.根据应用访问的各种io设备的类型，面向应用对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型；
29.根据所述各种io设备的物理端口，面向io设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制io设备的控制数据的转换关系。
30.在一种可能的实现方式中，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
31.所述处理单元还用于：
32.根据所述转换关系将所述第一标准化数据转换为所述第一io设备对应的第一控制数据；
33.所述收发单元还用于将所述第一控制数据发送给所述第一io设备。
34.在一种可能的实现方式中，所述收发单元还用于：
35.接收所述第一io设备上报的采样数据；
36.所述处理单元还用于根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
37.在一种可能的实现方式中，当所述装置需要访问第二集中控制器下的第二io设备时，所述资源访问请求中包括所述用户访问的第二io设备的第二标准模型，所述收发单元还用于：
38.将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二io设备。
39.第三方面，本申请实施例提供了一种访问io设备的装置，包括：
40.设备抽象层，用于对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型，并生成所述各种io设备与标准模型的映射配置文件；
41.应用层，用于根据用户的访问操作生成资源访问请求，将所述资源访问请求发送给所述设备抽象层，所述资源访问请求中包括所述用户访问的第一io设备的第一标准模型；
42.所述设备抽象层还用于将所述资源访问请求发送给通信层；
43.所述通信层用于根据所述资源访问请求，通过收发器向驱动层发送控制命令，对io设备进行输入输出的操作。
44.在一种可能的实现方式中，所述驱动层，用于响应于所述控制命令，将所述输入输出的操作获取到的采样数据发送给所述通信层；
45.所述通信层还用于将所述采样数据发送给所述设备抽象层；
46.所述设备抽象层还用于将所述采样数据转换为与所述标准模型对应的标准化数据并发送给所述应用层。
47.第四方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面中任一种可能实现方式中的方法的指令。
48.第五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第一方面或第一方面中任一种可能实现方式中的方法。
附图说明
49.为了更清楚地说明本申请实施例或背景技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图进行说明。
50.图1为现有的一种访问io设备的软件架构示意图；
51.图2为本申请实施例提供的一种访问io设备的方法的流程示意图；
52.图3为本申请实施例提供的一种访问io设备的软件架构示意图；
53.图4为本申请实施例提供的一种对io设备及物理端口建模的示意图；
54.图5为本申请实施例提供的另一种访问io设备的方法的流程示意图；
55.图6为本申请实施例提供的另一种访问io设备的软件架构示意图；
56.图7为本申请实施例提供的一种访问io设备的硬件架构示意图；
57.图8为本申请实施例提供的一种访问io设备的装置的组成示意图；
58.图9为本申请实施例提供的另一种访问io设备的装置的组成示意图。
具体实施方式
59.下面结合本申请实施例中的附图对本申请的实施例进行描述。
60.本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
61.请参照图1，为现有的一种访问io设备的软件架构示意图。其包括应用层、通信层(com层)和驱动层。
62.其中，应用层100用于存储程序代码及运行访问io设备的相关应用。例如可以是一些控制车辆上的io设备的控制类应用，也可以是一些用于测试的应用。当用户执行某个io设备的资源访问操作时，应用层可以向通信层发送资源访问请求。
63.通信层200，用于将应用层发出的资源访问请求通过收发器发送至驱动层。
64.驱动层300，用于驱动相关的io设备。
65.在该软件架构下，当需要访问某个io设备时，需要在应用层10中指示具体的io设备、接口类型、厂商、车型等设备间通信的细节。因此任意因素发生变动时，应用层10的应用也需要进行更新和调整，导致灵活性和可靠性较差，且在该架构下，需要跨节点访问其他集中控制器下的io设备时，需要配置与其他集中控制器的通信接口，还需要改变其他集中控制器的控制代码等，访问效率低下。
66.因此，本申请实施例提供了一种访问io设备的方法及装置，以提升访问和控制io设备的灵活性和可靠性。下面结合图2到图9对本申请实施例提供的访问io设备方法及装置进行详细说明。
67.请参见图2，为本申请实施例提供的一种访问io设备的方法的流程示意图；包括如下步骤：
68.s201，第一集中控制器对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型，并生成所述各种io设备与标准模型的映射配置文件。
69.其中，车辆上的各种io设备可以包括车辆上各种可以访问或控制的部件如雨刮、车窗、灯光、座椅、车门、天窗、后备箱等，还可以包括各种传感器如距离传感器、温度传感器、光线传感器、重力传感器、加速度传感器等，此外io设备还可以是与第一集中控制器类似的其他的电子控制单元(electronic control unit，简称ecu)。由于不同的厂家、车型可能使用不同接口或型号的io设备。导致应用层需要访问io设备时，需要针对不同的厂家、车型、设备型号、接口类型进行适配。因此，在本申请实施例中，可以对各种io设备进行对象化建模，例如对雨刮进行建模，当应用需要访问或控制任意厂家或车型的任意型号或接口类型的雨刮时，都可以针对“雨刮”这一标准化、对象化的标准模型发出资源访问请求。
70.s202，根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一io设备的第一标准模型。
71.s203，根据所述映射配置文件，将所述资源访问请求发送给所述第一io设备。
72.集中控制器通过生成各种io设备与标准模型的映射配置文件，应用可以将资源访问请求准确的下发至需要访问或控制的io设备，从而完成访问或控制。
73.在本申请实施例中，通过对各种io设备进行对象化建模，可以实现单个标准模型与多个不同型号或不同接口的io设备的映射，使得集中控制器在访问某个io设备时，可以对该io设备对应的标准模型发出资源访问请求，并通过映射配置文件准确的将资源访问请求发送至该io设备，完成对该io设备的访问，无需针对不同厂家、车型、设备型号或接口类型进行调整，从而大大提升了访问io设备的灵活性和可靠性。
74.请参见图3，为本申请实施例提供的一种访问io设备的软件架构示意图；包括：
75.设备抽象层10，用于对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型，并生成所述各种io设备与标准模型的映射配置文件；
76.应用层20，用于根据用户的访问操作生成资源访问请求，将所述资源访问请求发送给所述设备抽象层10，所述资源访问请求中包括所述用户访问的第一io设备的第一标准模型；
77.所述设备抽象层10还用于将所述资源访问请求发送给通信层30；
78.所述通信层30用于根据所述资源访问请求向收发器40发送控制命令，对io设备进行输入输出的操作。
79.驱动层40，用于接收收发器转发的资源访问请求，驱动io设备，完成输入输出的操作。
80.请参见图4，为本申请实施例提供的一种对io设备及物理端口建模的示意图；
81.设备抽象层可以包括设备抽象模块11和端口抽象模块12。如图4所示，设备抽象模块11可以根据应用访问的各种io设备的类型，面向应用如整车控制器(vehicle control unit，简称vcu)软件或车身控制器(body control module，简称bcm)软件等，对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型；即在整个软件架构中向上进行设备建模。
82.端口抽象模块12则可以根据所述各种io设备的物理端口，面向io设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制io设备的控制数据的转换关系。即在整个软件架构中向下进行端口建模。数据通过转换后，再通过转发面转发即io接口到以太网接口的转换，最后通过物理端口发送给各种io设备。
83.通过向上建模使得应用在访问io设备时可以通过访问标准模型实现，通过向下建模可以使得不同接口的io设备与同一个物理端口进行映射，通过该物理端口便可以实现对不同接口类型的io设备进行访问，在访问不同接口类型的io设备时，将与标准模型对应的标准化数据和与控制设备对应的控制数据进行相应的转换即可。
84.结合图2所述的访问io设备的方法，可以对第一集中控制器下发的数据以及第一io设备上报的数据进行相应的转换。
85.当第一集中控制器要访问第一io设备时，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
86.所述第一集中控制器可以根据所述转换关系将所述第一标准化数据转换为所述第一io设备对应的第一控制数据；
87.再将所述第一控制数据发送给所述第一io设备。
88.而当第一集中控制器指示第一io设备上报数据或第一io设备主动上报数据时，所述第一集中控制器可以接收所述第一io设备上报的采样数据；
89.再根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
90.例如，当厂家、车型、设备型号、接口类型需要进行变化时，可以通过相应的设计工具如管理应用对用于ad标定配置的温度和/或拟合公式进行变更，对用于pwm配置的高低门限和/或计算公式进行变更，对用于output配置的高低门限、高低边配置和/或计算公式进行变更，对用于can dbc配置的信号偏移和/或计算公式进行变更，对用于di配置的开关和/或高低映射进行变更，然后，在对io设备进行资源访问时，端口抽象模块12可以根据配置完成的设置，进行ad拟合公式计算、pwm频占比转换、di高低值映射、can/lin信号转换、高低变驱动值映射、hb恒流值映射或sent总线映射，从而实现数据的转换。
91.通过本实施例中的方法可以屏蔽io设备的物理端口类型，在不同车型中开发中可以保持上层应用不变，降低开发难度，提高了应用层软件的复用度，利于车辆的研发和测试；厂家、车型、型号或接口变化仅需更新配置数据，方便升级。
92.基于图2
‑
图4所述的方法和架构，在本申请实施例中，还提供了一种跨节点访问io设备的方法，请参见图5，为本申请实施例提供的另一种访问io设备的方法的流程示意图；包括如下步骤：
93.s501，第一集中控制器对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型，并生成所述各种io设备与标准模型的映射配置文件。
94.s502，根据用户的访问操作生成资源访问请求,所述资源访问请求中包括所述用户访问的第二io设备的第二标准模型。
95.s503，所述第一集中控制器将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二io设备。
96.与图5所述方法对应的软件架构示意图可参见图6，为本申请实施例提供的另一种访问io设备的软件架构示意图；包括第一集中控制器和第二集中控制器。第一集中控制器包括设备抽象层110、应用层120、通信层130及驱动层140，第二控制器包括通信层230及驱动层240。
97.需要说明的是，第二集中控制器也可以包括设备抽象层210和应用层220，但是在本申请实施例的跨节点访问io设备的方法中，应用层220无需进行改动，也无需增加新的通信接口，从而提升了跨节点访问的效率，并降低了跨节点访问的成本。
98.基于图6所述的软件架构，具体的访问io设备的流程可以包括io设备的本地访问和io设备的跨节点访问。
99.本地访问(第一集中控制器访问第一io设备)流程如下：
100.应用层120生成资源访问请求并发送给设备抽象层110；
101.设备抽象层110将资源访问请求发送给通信层130；在该步骤中，设备抽象层110可以将资源访问请求中的第一标准化数据转换为第一io设备的控制数据；
102.通信130层通过收发器向驱动层140发出相应的控制命令，对第一io设备进行i/o操作；根据物理端口的不同，此处的收发器可以是通用输入输出(general
‑
purpose input/output，简称gpio)收发器或can收发器等。
103.驱动层140响应于控制命令，访问第一io设备，并将i/o操作获取到的采样数据发送给所述通信层130；
104.通信层130将采样数据传递给设备抽象层130；
105.设备抽象层130将访问采样数据进行标准化，转换为与第一标准模型对应的第二标准化数据，再传递给应用层120。
106.跨节点访问(如第一集中控制器1访问第二io设备)的流程如下：
107.应用层120生成资源访问请求并发送给设备抽象层110；
108.设备抽象层110将资源访问请求发送给通信层130；在该步骤中，设备抽象层110可以将资源访问请求中的第一标准化数据转换为第一io设备的控制数据；
109.通信130层向第二集中控制器的通信层230发送资源访问请求；
110.第二集中控制器的通信层230发出相应的控制命令，对第二io设备进行i/o操作；
111.第二集中控制器的驱动层240响应于控制命令，访问第二io设备，并将i/o操作获取到的采样数据传递到通信层230；
112.第二集中控制器的通信层230再将采样传递给第一集中控制器的通信层130；
113.通信层130将采样数据传递给设备抽象层130；
114.设备抽象层130将采样进行标准化，转换为第二标准模型对应的标准化数据，再传递给应用层120。
115.上述软件架构对应的硬件架构可以参见图7，为本申请实施例提供的一种访问io设备的硬件架构示意图；如图7所示，访问io设备的装置包括第一集中控制器和第二集中控制器，两者通过以太网(ethernet，简称eth)连接，第一集中控制器中包括第一微控制器(micro controller unit，简称mpu)310、第一微处理器(micro processing unit，简称mcu)320、第一以太网交换模块(ethernet switch，简称lsw)330和设备抽象模块340(设备抽象模块340为设备抽象层对应的功能模块，其可以独立设置，也可以与第一mcu320或第一mpu310集成设置)，第二集中控制器中包括第二mpu410、第二mcu420和第二lsw430(也可以包括一个设备抽象模块440或不包括)。第一集中控制器进行本地访问时访问的io设备为第一io设备350，第二集中控制器进行本地访问时访问的io设备为第二io设备450。
116.其中，mcu可部署实时性和安全等级高的应用，还可以负责对io设备进行资源访问和数据转发。mpu可部署adas等计算量要求较高的应用,lsw用于骨干网通信。
117.例如：第一mpu310可部署自动驾驶相关的应用功能如预碰撞预警功能，第一mcu320可部署vcu功能，第二mpu410可部署高级自动驾驶辅助系统(advanced driver assistance systems，简称adas)功能，第二mcu420可部署电池管理系统(battery management system，bms)功能。
118.如图7中的虚线箭头所示，当对第一io设备350进行本地访问时，第一io设备350的数据可以传递给第一mpu310/第一mcu320,还可以通过以太网接口传递给第二集中控制器的第二mpu410/第二mcu420,以实现第二集中控制器对第一io设备的跨节点访问。
119.需要说明的是，本实施例所述的方法不仅可以应用于车载io设备的资源访问，也
可应用于工业io设备资源访问，本申请实施例不作任何限定。
120.请参见图8，为本申请实施例提供的一种访问io设备的装置的组成示意图；包括：
121.处理单元1000，用于对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型，并生成所述各种io设备与标准模型的映射配置文件；根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一io设备的第一标准模型；
122.收发单元2000，用于根据所述映射配置文件，将所述资源访问请求发送给所述第一io设备。
123.可选地，所述处理单元1000具体用于：
124.根据应用访问的各种io设备的类型，面向应用对车辆上的各种io设备进行对象化建模，生成所述各种io设备的标准模型；
125.根据所述各种io设备的物理端口，面向io设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制io设备的控制数据的转换关系。
126.可选地，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
127.所述处理单元1000还用于：
128.根据所述转换关系将所述第一标准化数据转换为所述第一io设备对应的第一控制数据；
129.所述收发单元2000还用于将所述第一控制数据发送给所述第一io设备。
130.可选地，所述收发单元2000还用于：
131.接收所述第一io设备上报的采样数据；
132.所述处理单元1000还用于根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
133.可选地，当所述装置需要访问第二集中控制器下的第二io设备时，所述资源访问请求中包括所述用户访问的第二io设备的第二标准模型，所述收发单元2000还用于：
134.将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二io设备。
135.请参见图9，为本申请实施例提供的另一种访问io设备的装置的组成示意图；如图9所示，该装置可以包括处理器1110、存储器1120和收发器1130。处理器1110、存储器1120和收发器1130通过总线1140连接，该存储器1120用于存储指令，该处理器1110用于执行该存储器1120存储的指令，以实现如上图2
‑
6对应的方法中第一集中控制器执行的步骤。
136.处理器1110用于执行该存储器120存储的指令，以控制收发器1130接收和发送信号，完成上述方法中装置执行的步骤。所述存储器1120可以集成在所述处理器1110中，也可以与所述处理器1110分开设置。
137.作为一种实现方式，收发器1130的功能可以考虑通过收发电路或者收发的专用芯片实现。处理器1110可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。
138.作为另一种实现方式，可以考虑使用通用计算机的方式来实现本申请实施例提供的装置。即将实现处理器1110，收发器1130功能的程序代码存储在存储器1120中，通用处理器通过执行存储1器120中的代码来实现处理器1110，收发器1130的功能。
139.该装置所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
140.作为本实施例的另一种形式，提供一种计算机可读存储介质，其上存储有指令，该指令被执行时实现上述方法实施例中第一集中控制器执行的方法。
141.作为本实施例的另一种形式，提供一种包含指令的计算机程序产品，该指令被执行时执行上述方法实施例中第一集中控制器执行的方法。
142.本领域技术人员可以理解，为了便于说明，图9中仅示出了一个存储器和处理器。在实际的控制器中，可以存在多个处理器和存储器。存储器也可以称为存储介质或者存储设备等，本申请实施例对此不做限制。
143.应理解，在本申请实施例中，处理器可以是中央处理单元(central processing unit，简称cpu)，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processing，简称dsp)、专用集成电路(application specific integrated circuit，简称asic)、现成可编程门阵列(field－programmable gate array，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。
144.还应理解，本发明实施例中提及的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read
‑
only memory，简称rom)、可编程只读存储器(programmable rom，简称prom)、可擦除可编程只读存储器(erasable prom，简称eprom)、电可擦除可编程只读存储器(electrically eprom，简称eeprom)或闪存。易失性存储器可以是随机存取存储器(random access memory，简称ram)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的ram可用，例如静态随机存取存储器(static ram，简称sram)、动态随机存取存储器(dynamic ram，简称dram)、同步动态随机存取存储器(synchronous dram，简称sdram)、双倍数据速率同步动态随机存取存储器(double data rate sdram，简称ddr sdram)、增强型同步动态随机存取存储器(enhanced sdram，简称esdram)、同步连接动态随机存取存储器(synchlink dram，简称sldram)和直接内存总线随机存取存储器(direct rambus ram，简称dr ram)。
145.需要说明的是，当处理器为通用处理器、dsp、asic、fpga或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)集成在处理器中。
146.应注意，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
147.该总线除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线。
148.还应理解，本文中涉及的第一、第二、第三、第四以及各种数字编号仅为描述方便进行的区分，并不用来限制本申请的范围。
149.应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
150.在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器
执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
151.根据本申请实施例提供的方法，本申请实施例还提供一种系统，其包括前述的第一集中控制器和各种io设备，进一步的还可以包括第二集中控制器等。
152.在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
153.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block，简称ilb)和步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
154.在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
155.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
156.另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
157.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘)等。
158.以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵
盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。