I / O device access method and apparatus

Abstract

An embodiment of this application discloses an I / O device access method and apparatus. The method includes a first centralized controller performing object-oriented modeling on various I / O devices in a vehicle to generate standard models of the various I / O devices and generating a mapping configuration file between the various I / O devices and the standard models. The first centralized controller generates a resource access request based on a user's access operation, where the resource access request includes a first standard model of the first I / O device accessed by the user. The first centralized controller sends the resource access request to the first I / O device based on the mapping configuration file. According to the embodiment of this application, the flexibility and reliability of access to different types of I / O devices by the centralized controller can be improved.

Description

[Technical field]

[0001] This application relates to the field of communication technology, and in particular to an I / O device access method and apparatus. [Background technology]

[0002] With the development of intelligent vehicles and new energy vehicles, the electrical and electronic architecture of automobiles evolves from distributed to centralized, and there is a tendency to centralize controllers. Current vehicles usually have dozens to hundreds of controllers and hundreds of I / O devices with input / output (I / O) interfaces. These I / O devices may be various sensors, such as temperature sensors, humidity sensors, etc., or various actuators, such as motors. These I / O devices have multiple types of interfaces, such as controller area network (CAN) interface, local interconnect network (LIN) interface, pulse width modulation (PWM) interface, H-bridge bus (HB) interface, analog-to-digital (AD) conversion interface, digital input (DI) interface, digital output (DO) interface, etc. The flexibility and reliability are relatively low when accessing various I / O devices through a centralized controller. Summary of the Invention

[0003] The embodiments of this application provide an I / O device access method and apparatus to solve the technical problem of relatively low flexibility and reliability when accessing different types of I / O devices by a centralized controller.

[0004] According to a first aspect, an embodiment of the present application provides an I / O device access method, the method comprising:

[0005] The first centralized controller may perform object-oriented modeling on various I / O devices in the vehicle to generate standard models of the various I / O devices, and generate a mapping configuration file between the various I / O devices and the standard models.

[0006] A first centralized controller generates a resource access request based on an access operation of the user, the resource access request including a first standard model of a first I / O device to be accessed by the user.

[0007] The first centralized controller sends a resource access request to the first I / O device based on the mapping configuration file.

[0008] The object-oriented modeling is performed for various I / O devices, so that one standard model can be mapped to multiple I / O devices with different model numbers or different interfaces. Additionally, when accessing an I / O device, the centralized controller can send a resource access request to the standard model corresponding to the I / O device, and can accurately send the resource access request to the I / O device based on the mapping configuration file to complete the access to the I / O device, without needing to perform adjustments based on different vendors, vehicle models, device model numbers, or interface types. Therefore, the flexibility and reliability of access to the I / O device is greatly improved.

[0009] In a possible implementation, the first centralized controller performs object-oriented modeling on various I / O devices in the vehicle to generate standard models of the various I / O devices, and generates a mapping configuration file between the various I / O devices and the standard models.

[0010] The first centralized controller performs object-oriented modeling on various I / O devices in the vehicle for the application based on the types of the various I / O devices accessed by the application to generate standard models of the various I / O devices.

[0011] A first centralized controller performs physical port modeling for the I / O devices based on physical ports of various I / O devices, and sets a conversion relationship between standardized data used to control the standard model and control data used to control the I / O devices.

[0012] Upward modeling allows applications to access I / O devices by accessing the standard model. Downward modeling allows I / O devices with different interfaces to be mapped to the same physical port, and access to I / O devices with different types of interfaces can be implemented through that physical port. When accessing an I / O device with different types of interfaces, corresponding conversion is performed on the standardized data corresponding to the standard model and the control data corresponding to the control device. The effect of shielding the type of physical port of the I / O device can be implemented, and the upper layer application can be kept unchanged during the development of different vehicle models. This reduces the development difficulty, improves the degree of reuse of application layer software, and facilitates vehicle research, development, and testing. Additionally, only the configuration data needs to be updated when the vendor, vehicle model, model number, or interface is changed. This is convenient for upgrades.

[0013] In a possible implementation, the resource access request further includes first standardized data used to control the first standard model, and the method further includes:

[0014] The first centralized controller converts the first standardized data into first control data corresponding to the first I / O device based on the conversion relationship.

[0015] The first converged controller sends the first control data to the first I / O device.

[0016] Data conversion is performed. When accessing I / O devices from different vendors, in-vehicle with different vehicle models, or with different model numbers or different interfaces, only the conversion relationship between data needs to be adaptively set.

[0017] In a possible implementation, the method further includes:

[0018] A first centralized controller receives the sampling data reported by the first I / O device.

[0019] The first centralized controller converts the sampling data into second standardized data corresponding to the first standard model based on the conversion relationship.

[0020] In a possible implementation, when the first centralized controller needs to access a second I / O device under a second centralized controller, the resource access request includes a second standard model of the second I / O device to be accessed by the user, and the method further includes:

[0021] The first converged controller sends a resource access request to the second I / O device through a communication layer link between the first converged controller and the second converged controller.

[0022] This cross-node access method does not require modification of the application layer of the second centralized controller and does not require adding a new communication interface, which improves cross-node access efficiency and reduces cross-node access costs.

[0023] According to a second aspect, an embodiment of the present application provides an I / O device access apparatus, the apparatus comprising: a processing unit configured to: perform object oriented modeling on various I / O devices in a vehicle to generate standard models of the various I / O devices and generate a mapping configuration file between the various I / O devices and the standard models; and generate a resource access request based on an access operation of a user, where the resource access request includes a first standard model of a first I / O device accessed by the user; and a transceiver unit configured to transmit a resource access request to the first I / O device based on the mapping configuration file.

[0024] In a possible implementation, the processing unit specifically comprises: performing object oriented modeling for various I / O devices in the vehicle for the application based on the types of the various I / O devices accessed by the application to generate standard models of the various I / O devices; The method is configured to perform physical port modeling for the I / O device based on physical ports of various I / O devices, and to set a conversion relationship between standardized data used to control the standard model and control data used to control the I / O device.

[0025] In a possible implementation, the resource access request further includes first standardized data used to control the first standard model.

[0026] The processing unit is The device is further configured to convert, based on the conversion relationship, the first standardized data into first control data corresponding to the first I / O device.

[0027] The transceiver unit is further configured to transmit the first control data to the first I / O device.

[0028] In a possible implementation, the transceiver unit is further configured to receive sampling data reported by the first I / O device.

[0029] The processing unit is further configured to convert the sampling data into second standardized data corresponding to the first standard model based on the conversion relationship.

[0030] In a possible implementation, when the apparatus needs to access a second I / O device under a second centralized controller, the resource access request includes a second standard model of the second I / O device to be accessed by the user, and the transceiver unit: The controller is further configured to transmit the resource access request to the second I / O device through a communication layer link between the first converged controller and the second converged controller.

[0031] According to a third aspect, an embodiment of the present application is an I / O device access apparatus, the apparatus comprising: A device abstraction layer configured to perform object-oriented modeling on various I / O devices in the vehicle to generate standard models of the various I / O devices and generate a mapping configuration file between the various I / O devices and the standard models; and an application layer configured to generate a resource access request based on an access operation of the user and send the resource access request to the device abstraction layer, the resource access request including a first standard model of a first I / O device accessed by the user.

[0032] The device abstraction layer is further configured to send a resource access request to the communication layer.

[0033] The communication layer is configured to send control commands, using the transceiver, to the driver layer based on resource access requests to perform input / output operations on the I / O devices.

[0034] In a possible implementation, the driver layer is configured to transmit sampling data acquired through input / output operations to the communication layer in response to control commands.

[0035] The communication layer is further configured to transmit the sampling data to the device abstraction layer.

[0036] The device abstraction layer is further configured to convert the sampling data into standardized data corresponding to the standard model and send the standardized data to the application layer.

[0037] According to a fourth aspect, a computer readable storage medium is provided, configured to store a computer program comprising instructions used to perform a method according to the first aspect or a possible implementation of the first aspect.

[0038] According to a fifth aspect, there is provided a computer program product comprising computer program code which, when executed on a computer, enables the computer to carry out a method according to the first aspect and any of the possibilities of the first aspect. [Brief description of the drawings]

[0039] In order to more clearly describe the technical solutions in the embodiments or background of this application, the following describes the accompanying drawings to illustrate the embodiments or background of this application.

[0040] [Figure 1] FIGURE 1 is a schematic diagram of an existing software architecture for accessing I / O devices.

[0041] [Diagram 2] 1 is a schematic flowchart of an I / O device access method according to an embodiment of the present application.

[0042] [Diagram 3] 1 is a schematic diagram of a software architecture for accessing an I / O device according to one embodiment of the present application.

[0043] [Figure 4] 1 is a schematic diagram of I / O device modeling and physical port modeling according to an embodiment of the present application.

[0044] [Diagram 5] 1 is a schematic flowchart of another I / O device access method according to an embodiment of the present application.

[0045] [Figure 6] FIG. 13 is a schematic diagram of another software architecture for accessing an I / O device according to an embodiment of the present application.

[0046] [Figure 7] 1 is a schematic diagram of a hardware architecture for accessing an I / O device according to one embodiment of the present application.

[0047] [Figure 8] 1 is a schematic configuration diagram of an I / O device access apparatus according to an embodiment of the present application.

[0048] [Figure 9] 1 is a schematic configuration diagram of another I / O device access apparatus according to an embodiment of the present application. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0049] Hereinafter, embodiments of this application will be described with reference to the accompanying drawings in the embodiments of this application.

[0050] The terms "comprise", "have", or other variations thereof in the specification, claims, and accompanying drawings of this application are intended to cover a non-exclusive inclusion, e.g., a process, method, system, product, or device that includes a series of steps or units is not limited to the recited steps or units, but may optionally further include unrecited steps or units, or may optionally further include other inherent steps or units of the process, method, product, or device.

[0051] Figure 1 is a schematic diagram of an existing software architecture for accessing I / O devices. The software architecture includes an application layer, a communication layer (com layer), and a driver layer.

[0052] The application layer 100 is configured to record program codes for accessing I / O devices and execute associated applications. For example, the applications may be some control applications for controlling I / O devices in a vehicle, or some applications for testing. When a user performs an operation for resource access to an I / O device, the application layer may send a resource access request to the communication layer.

[0053] The communication layer 200 is configured to transmit resource access requests sent by the application layer to the driver layer using a transceiver.

[0054] The driver layer 300 is configured to drive associated I / O devices.

[0055] In this software architecture, when an I / O device needs to be accessed, details of inter-device communication such as a specific I / O device, interface type, vendor, vehicle model, etc. need to be indicated to the application layer 10. When any factor changes, the application in the application layer 10 also needs to be updated and adjusted. As a result, flexibility and reliability are relatively low. Additionally, in this architecture, when an I / O device controlled by another centralized controller needs to be accessed in a cross-node manner, a communication interface for communicating with the other centralized controller needs to be set and the control code of the other centralized controller needs to be changed. As a result, access efficiency is low.

[0056] From this perspective, the embodiments of the present application provide an I / O device access method and apparatus to improve the flexibility and reliability of access and control of I / O devices. Hereinafter, the I / O device access method and apparatus provided in the embodiments of the present application will be described in detail with reference to Figs. 2 to 9.

[0057] 2 is a schematic flowchart of an I / O device access method according to an embodiment of the present application. The method includes the following steps:

[0058] S201: A first centralized controller performs object-oriented modeling on various I / O devices in a vehicle to generate standard models of the various I / O devices, and generates a mapping setting file between the various I / O devices and the standard models.

[0059] The various I / O devices in the vehicle may include various parts that may be accessed or controlled in the vehicle, such as wipers, windows, lights, seats, doors, sunroof, trunk, etc., and may further include various sensors, such as distance sensors, temperature sensors, light sensors, gravity sensors, acceleration sensors, etc. Additionally, the I / O devices may be another electronic control unit (ECU for short) similar to the first centralized controller. For different vendors and vehicle models, I / O devices with different interfaces or model numbers may be used. When the application layer needs to access the I / O devices, it needs to perform adaptation based on the various vendors, vehicle models, device model numbers, and interface types. Thus, in this embodiment of the application, object-oriented modeling may be performed for various I / O devices, for example, wipers. When an application needs to access or control wipers of any vendor, wipers of vehicles with any vehicle model, or wipers with any model number or interface type, a resource access request may be made to such a standardized object-oriented model of "wiper."

[0060] S202: Generate a resource access request based on an access operation of the user, where the resource access request includes a first standard model of a first I / O device to be accessed by the user.

[0061] S203: Send a resource access request to the first I / O device based on the mapping configuration file.

[0062] The centralized controller generates a mapping configuration file between various I / O devices and the standard model, so that applications can accurately deliver resource access requests to the I / O devices that they need to access or control to complete the access or control.

[0063] In this embodiment of the application, object-oriented modeling is performed for various I / O devices, so that one standard model can be mapped to multiple I / O devices with different model numbers or different interfaces. Additionally, when accessing an I / O device, the centralized controller can send a resource access request to the standard model corresponding to the I / O device, and based on the mapping configuration file, can accurately send the resource access request to the I / O device to complete the access to the I / O device, without needing to perform adjustments based on different vendors, vehicle models, device model numbers, or interface types. Therefore, the flexibility and reliability of access to the I / O device is greatly improved.

[0064] 3 is a schematic diagram of a software architecture for accessing an I / O device according to one embodiment of the present application. A device abstraction layer 10 configured to perform object-oriented modeling on various I / O devices in a vehicle to generate standard models of the various I / O devices and generate a mapping configuration file between the various I / O devices and the standard models; and an application layer 20 configured to generate a resource access request based on a user's access behavior and send the resource access request to the device abstraction layer 10, where the resource access request includes a first standard model of a first I / O device accessed by the user.

[0065] The device abstraction layer 10 is further configured to send a resource access request to the communications layer 30 .

[0066] The communication layer 30 is configured to send control commands using the transceiver to the driver layer 40 based on resource access requests to perform input / output operations on the I / O devices.

[0067] The driver layer 40 is configured to receive resource access requests forwarded by the transceiver and drive the I / O devices to complete input / output operations.

[0068] FIG. 4 is a schematic diagram of I / O device modeling and physical port modeling according to one embodiment of the present application.

[0069] The device abstraction layer may include a device abstraction module 11 and a port abstraction module 12. As shown in Fig. 4, the device abstraction module 11 may perform object-oriented modeling on various I / O devices in a vehicle to generate standard models of various I / O devices for applications such as vehicle control unit (VCU) software, body control module (BCM) software, etc. based on the types of various I / O devices accessed by the applications. That is, the device modeling is performed upwards throughout the software architecture.

[0070] The port abstraction layer 12 may perform physical port modeling for the I / O devices based on the physical ports of various I / O devices, and set up a conversion relationship between the standardized data used to control the standard model and the control data used to control the I / O devices. That is, the port modeling is performed downwards in the entire software architecture. After the data is converted, the data is forwarded through the forwarding plane. In other words, the I / O interface is converted into an Ethernet interface. Finally, the data is sent to various I / O devices through the physical ports.

[0071] Upward modeling allows an application to access an I / O device by accessing a standard model. Downward modeling allows I / O devices with different interfaces to be mapped to the same physical port, through which access to I / O devices with different types of interfaces can be implemented. When accessing an I / O device with different types of interfaces, corresponding transformations are performed on the standardized data corresponding to the standard model and the control data corresponding to the control device.

[0072] Referring to the I / O device access method described in FIG. 2, a corresponding transformation may be performed on the data delivered by the first converged controller and the data reported by the first I / O device.

[0073] When the first centralized controller needs to access the first I / O device, the resource access request further includes first standardized data used to control the first standard model.

[0074] The first centralized controller converts the first standardized data into first control data corresponding to the first I / O device based on the conversion relationship; The first control data may be sent to the first I / O device.

[0075] the first centralized controller receives the sampling data reported by the first I / O device when the first centralized controller indicates to the first I / O device to report data or when the first I / O device actively reports data; Based on the transformation relationship, the sampling data may be transformed into second standardized data corresponding to the first standard model.

[0076] For example, when a vendor, vehicle model, device model number, or interface type needs to be changed, a corresponding design tool such as a management application may be used to change the temperature and / or fitting formula used for AD calibration setting, change the high and low threshold and / or calculation formula used for PWM setting, change the high and low threshold, high and low edge setting and / or calculation formula used for output setting, change the signal offset and / or calculation formula used for CAN DBC setting, change the switching and / or high and low mapping used for DI setting. Then, when performing resource access to the I / O device, the port abstraction module 12 may implement data conversion based on the completed setting by performing calculation according to AD fitting formula, conversion based on PWM frequency ratio, DI high and low value mapping, CAN / LIN signal conversion, high side driver and low side driver value mapping, HB constant current value mapping, or SENT bus mapping.

[0077] According to the method in this embodiment, the type of physical port of the I / O device can be shielded, and the upper layer application can be kept unchanged during the development of different vehicle models. This reduces the development difficulty, improves the reusability of the application layer software, and facilitates the research, development, and testing of the vehicle. Additionally, when the vendor, vehicle model, model number, or interface is changed, only the configuration data needs to be updated, which is convenient for upgrades.

[0078] Based on the method and architecture described in Figures 2 to 4, an embodiment of this application further provides a cross-node I / O device access method. Figure 5 is a schematic flowchart of another I / O device access method according to this embodiment of this application. The method includes the following steps:

[0079] S501: A first centralized controller performs object-oriented modeling on various I / O devices in a vehicle to generate standard models of the various I / O devices, and generates a mapping setting file between the various I / O devices and the standard models.

[0080] S502: Generate a resource access request based on an access operation of the user, where the resource access request includes a second standard model of a second I / O device to be accessed by the user.

[0081] S503: The first converged controller sends a resource access request to the second I / O device through a communication layer link between the first converged controller and the second converged controller.

[0082] For a schematic diagram of a software architecture corresponding to the method of FIG. 5, see FIG. 6. FIG. 6 is a schematic diagram of another software architecture for accessing an I / O device, according to an embodiment of the present application. The software architecture includes a first centralized controller and a second centralized controller. The first centralized controller includes a device abstraction layer 110, an application layer 120, a communication layer 130, and a driver layer 140, and the second controller includes a communication layer 230 and a driver layer 240.

[0083] It should be noted that the second centralized controller may also include a device abstraction layer 210 and an application layer 220. However, the cross-node I / O device access method in this embodiment of the present application does not need to modify the application layer 220 and does not need to add a new communication interface, which improves cross-node access efficiency and reduces cross-node access cost.

[0084] Based on the software architecture shown in FIG. 6, a particular I / O device access procedure may include a local access to an I / O device and a cross-node access to an I / O device.

[0085] A local access procedure (first converged controller accessing first I / O device) is as follows.

[0086] The application layer 120 generates a resource access request and sends the resource access request to the device abstraction layer 110 .

[0087] The device abstraction layer 110 sends the resource access request to the communication layer 130. In this step, the device abstraction layer 110 may convert the first standardized data in the resource access request into control data corresponding to the first I / O device.

[0088] The communication layer 130 is configured to use a transceiver to send a corresponding control command to the driver layer 140 to perform an I / O operation on the first I / O device. Because the physical ports are different, the transceiver here can be a general-purpose input / output (GPIO) transceiver, a CAN transceiver, etc.

[0089] The driver layer 140 accesses the first I / O device in response to the control command and transmits sampling data acquired through the I / O operation to the communication layer 130.

[0090] The communication layer 130 communicates the sampling data with the device abstraction layer 132. 110 Transfer to.

[0091] Device Abstraction Layer 110standardizes the access sampling data, i.e., converts the sampling data into second standardized data corresponding to the first standard model, and then transfers the second standardized data to the application layer 120.

[0092] A cross-node access procedure (eg, a first converged controller 1 accesses a second I / O device) is as follows.

[0093] The application layer 120 generates a resource access request and sends the resource access request to the device abstraction layer 110 .

[0094] The device abstraction layer 110 sends the resource access request to the communication layer 130. In this step, the device abstraction layer 110 may convert the first standardized data in the resource access request into control data corresponding to the first I / O device.

[0095] The communication layer 130 sends the resource access request to the communication layer 230 of the first centralized controller.

[0096] The communication layer 230 of the second converged controller sends a corresponding control command to perform an I / O operation to the second I / O device.

[0097] The driver layer 240 of the second converged controller accesses the second I / O device in response to the control command and transfers the sampling data acquired by the I / O operation to the communication layer 230.

[0098] The communication layer 230 of the second centralized controller then forwards the sampling data to the communication layer 130 of the first centralized controller.

[0099] The communication layer 130 transfers the sampling data to the device abstraction layer 130 .

[0100] Device Abstraction Layer 110standardizes the sampling data, i.e., converts the sampling data into standardized data corresponding to the second standard model, and then transfers the standardized data to the application layer 120.

[0101] For a hardware architecture corresponding to the aforementioned software architecture, please refer to FIG. 7. FIG. 7 is a schematic diagram of a hardware architecture for accessing an I / O device according to an embodiment of this application. As shown in FIG. 7, the I / O device access apparatus includes a first centralized controller and a second centralized controller. The two centralized controllers are connected using Ethernet (ETH for short). The first centralized controller includes a first micro processing unit (MPU for short) 310, a first micro control unit (MCU for short) 320, and a first Ethernet switching module (ETH for short). Ethernet The first centralized controller includes a first I / O device switch (LSW) 330 and a device abstraction module 340 (the device abstraction module 340 is a functional module corresponding to a device abstraction layer, and may be disposed independently or may be integrated with the first MCU 320 or the first MPU 310). The second centralized controller includes a second MPU 410, a second MCU 420, and a second LSW 430 (which may or may not include a device abstraction module 440). The I / O device locally accessed by the first centralized controller is the first I / O device 350, and the I / O device locally accessed by the second centralized controller is the second I / O device 450.

[0102] The MCU may be deployed with applications that have high real-time performance and high security level, and may further be responsible for resource access and data transfer to I / O devices. The MPU may be deployed with applications such as ADAS that have high computational requirements. The LSW is used for backbone network communication.

[0103] For example, the first MPU 310 may be deployed with an autonomous driving related application function such as a pre-collision warning function, the first MCU 320 may be deployed with a VCU function, the second MPU 410 may be deployed with an advanced driver assistance systems (ADAS) function, and the MCU 420 may be deployed with a battery management system (BMS) function.

[0104] As shown by the dashed arrows in FIG. 7, data of the first I / O device 350 may be transferred to the first MPU 310 / first MCU 320 when the first I / O device 350 is accessed locally, or may be transferred to the second MPU 410 / second MCU 420 of the second converged controller through an Ethernet interface to implement cross-node access to the first I / O device by the second converged controller.

[0105] The method in this embodiment may be applied to resource access to an industrial I / O device as well as to resource access to an automotive I / O device, which is not limited to this embodiment of the present application.

[0106] FIG. 8 is a schematic diagram of an I / O device access apparatus according to an embodiment of the present application. A processing unit 1000 configured to perform object oriented modeling for various I / O devices in a vehicle to generate standard models of the various I / O devices and generate a mapping configuration file between the various I / O devices and the standard models, and generate a resource access request based on an access operation of a user, where the resource access request includes a first standard model of a first I / O device accessed by the user; and a transceiver unit 2000 configured to transmit a resource access request to the first I / O device based on the mapping configuration file.

[0107] Optionally, the processing unit 1000 specifically: performing object oriented modeling for various I / O devices in the vehicle for the application based on the types of the various I / O devices accessed by the application to generate standard models of the various I / O devices; The method is configured to perform physical port modeling for the I / O device based on physical ports of various I / O devices, and to set a conversion relationship between standardized data used to control the standard model and control data used to control the I / O device.

[0108] Optionally, the resource access request further comprises first standardization data used to control the first standard model.

[0109] The processing unit 1000 includes: The device is further configured to convert, based on the conversion relationship, the first standardized data into first control data corresponding to the first I / O device.

[0110] The transceiver unit 2000 is further configured to transmit the first control data to the first I / O device.

[0111] Optionally, the transceiver unit 2000 comprises: The sampling device is further configured to receive sampling data reported by the first I / O device.

[0112] The processing unit 1000 is further configured to convert the sampling data into second standardized data corresponding to the first standard model based on the conversion relationship.

[0113] Optionally, when the apparatus needs to access a second I / O device under a second centralized controller, the resource access request includes a second standard model of the second I / O device to be accessed by the user, and the transceiver unit 2000: The controller is further configured to transmit the resource access request to the second I / O device through a communication layer link between the first converged controller and the second converged controller.

[0114] 9 is a schematic block diagram of another I / O device access apparatus according to an embodiment of the present application. As shown in FIG. 9, the apparatus may include a processor 1110, a memory 1120, and a transceiver 1130. The processor 1110, the memory 1120, and the transceiver 1130 are connected using a bus 1140. The memory 1120 is configured to store instructions. The processor 1110 is configured to execute the instructions stored in the memory 1120 to implement the steps performed by the first centralized controller in the manner corresponding to FIG. 2 to FIG. 6.

[0115] The processor 1110 is configured to execute instructions stored in the memory 120, to receive signals or to control the transceiver 1130 to transmit signals, and to complete the steps performed by the device in the methods described above. The memory 1120 may be integrated with the processor 1110 or may be disposed separately from the processor 1110.

[0116] In one implementation, the functionality of the transceiver unit 1130 may be implemented using transceiver circuitry or a dedicated transceiver chip, and the processor 1110 may be implemented using a dedicated processing chip, processing circuitry, processor, or a general-purpose chip.

[0117] In another implementation, it may be considered that the apparatus provided in this embodiment of the application is implemented using a general purpose computer, i.e., program code for implementing the functions of the processor 1110 and the transceiver 1130 is stored in the memory 1120, and the general purpose processor implements the functions of the processor 1110 and the transceiver 1130 by executing the code in the memory 1120.

[0118] For the concept, description, detailed description and other steps of the apparatus related to the technical solution provided in this embodiment of this application, please refer to the description of the content of the method or other embodiments above, and the details will not be described again here.

[0119] In another form of this embodiment, a computer-readable storage medium is provided having instructions stored thereon that, when executed, perform the method performed by the first converged controller in the implementation of the method described above.

[0120] In another form of this embodiment, there is provided a computer program product including instructions that, when executed, perform a method performed by a first centralized controller in an embodiment of the method described above.

[0121] Those skilled in the art may understand that for ease of description, FIG. 9 shows only one memory and one processor. In an actual controller, there may be multiple processors and memories. The memory may also be referred to as a storage medium, a storage device, etc. This is not limited in this embodiment of the application.

[0122] It should be understood that in this embodiment of the application, the processor may be a central processing unit (CPU for short), which may further be another general-purpose processor, a digital signal processor (DSP for short), an application-specific integrated circuit (ASIC for short), a field-programmable gate array (FPGA for short), or another programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, etc.

[0123] Furthermore, it should be understood that the memory referred to in this embodiment of the present invention may be volatile or non-volatile memory, or may include volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM) and is used as an external cache. By way of non-limiting example, many forms of RAM may be used, such as static random access memory (static RAM, or SRAM for short), dynamic random access memory (dynamic RAM, or DRAM for short), synchronous dynamic random access memory (synchronous DRAM, or SDRAM for short), double data rate synchronous dynamic random access memory (double data rate SDRAM, or DDR SDRAM for short), enhanced synchronous dynamic random access memory (enhanced SDRAM, or ESDRAM for short), synchronous dynamic random access memory (synchlink DRAM, or SLDRAM for short), and direct rambus random access memory (direct rambus RAM, or DR RAM for short).

[0124] It should be noted that when the processor is a general purpose processor, a DSP, an ASIC, an FPGA, or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, the memory (storage module) may be integrated into the processor.

[0125] Note that memory as described herein includes, but is not limited to, these and any other suitable types of memory.

[0126] In addition to the data bus, the bus may further include a power bus, a control bus, a status signal bus, etc. However, for clarity of illustration, the various buses in the figures are marked as buses.

[0127] It should be further understood that the terms "first," "second," "third," "fourth," and various numerals in this specification are used merely for distinction purposes for ease of explanation and are not intended to limit the scope of this application.

[0128] It should be understood that the term "and / or" in this specification describes only the association relationship between associated objects, and three relationships may exist. For example, A and / or B may represent three cases: only A is present, both A and B are present, and only B is present. Additionally, the character " / " in this specification generally indicates an "or" relationship between associated objects.

[0129] In the implementation process, the steps in the aforementioned method may be implemented using integrated logic circuits of hardware in a processor, or using instructions in the form of software. The steps of the method disclosed with reference to the embodiments of this application may be directly executed by a hardware processor, or may be executed using a combination of hardware and software modules in a processor. The software modules may be located in a mature storage medium in the technical field, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the aforementioned method in combination with the hardware in the processor. To avoid repetition, the details will not be described again here.

[0130] According to the method provided in the examples of this application, an embodiment of this application further provides a system, which includes a first converged controller and various I / O devices, and may further include a second converged controller, etc.

[0131] The sequence numbers of the above processes do not mean the execution sequence in various embodiments of the present application. The execution sequence of the processes should be determined based on the functions and internal logic of the processes, and should not be construed as any limitation on the implementation process of the embodiments of this application.

[0132] Those skilled in the art will recognize that various illustrative logical blocks (ILBs for short) and steps described with reference to the embodiments disclosed in this specification may be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether a function is performed by hardware or computer software depends on the design constraints of a specific application and technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to go beyond the scope of this application.

[0133] In some embodiments provided in this application, it should be understood that the disclosed system, device, and method may be implemented in other ways. For example, the described device embodiment is merely an example. For example, the division into units is merely a logical functional division, and may be other divisions in actual implementation. For example, multiple units or components may be combined or integrated into another system, and some features may be ignored or not implemented. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be implemented through some interfaces. Indirect couplings or communication connections between devices or units may be implemented in electronic, mechanical, or other forms.

[0134] The units described as separate parts may or may not be physically separate, and the parts shown as units may or may not be physical units, may be located in one location, or may be distributed across multiple network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions in the embodiments.

[0135] Additionally, the functional units in the embodiments of the present application may be integrated into one processing unit, each of the units may exist physically alone, or two or more units may be integrated into one unit.

[0136] All or part of the aforementioned embodiments may be implemented using software, hardware, firmware, or any combination thereof. When software is used to implement the aforementioned embodiments, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the procedures or functions according to the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired (e.g., coaxial cable, optical fiber, or digital subscriber line) or wireless (e.g., infrared, radio, or microwave) manner. The computer-readable storage medium may be any available medium accessible by a computer, or a data storage device integrating one or more available media, such as a server or data center. Possible media include magnetic media (e.g., floppy disks, hard disks, or magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid state drives).

[0137] The above description is merely a specific implementation of this application, but is not intended to limit the scope of protection of this application. Any modifications or replacements that can be easily understood by those skilled in the art within the technical scope disclosed in this application shall be included in the scope of protection of this application. Therefore, the scope of protection of this application shall be subject to the scope of protection of the claims.

Claims

1. 1. An I / O device access method applied to a first converged controller for controlling access to various I / O devices in a vehicle, the first converged controller controlling standard models of the various I / O devices and a mapping configuration file between the various I / O devices and the standard models, the method comprising: generating a resource access request when the first converged controller accesses a first I / O device, the resource access request including first standardized data used to control a first standard model, the first standard model being included in the standard models of the various I / O devices; converting the first standardized data into first control data corresponding to the first I / O device based on the mapping setting file; transmitting the first control data to the first I / O device.

2. 2. The method of claim 1, wherein the mapping setting file between the various I / O devices and the standard model includes a conversion relationship between standardized data used to control the standard model and control data used to control the various I / O devices.

3. receiving sampling data reported by the first I / O device; The method according to claim 1 or 2, further comprising: converting the sampling data into second standardized data corresponding to the first standard model based on the mapping setting file.

4. The method according to any one of claims 1 to 3, wherein the standard models of the various I / O devices are generated by object-oriented modeling.

5. The method according to any one of claims 1 to 4, wherein the resource access request is generated based on a user's access behavior.

6. The method according to any one of claims 1 to 5, wherein the mapping configuration file is implemented by a configuration.

7. The method according to any one of claims 1 to 6, wherein the first I / O device is under the first converged controller.

8. When the first converged controller needs to access a second I / O device under a second converged controller, the resource access request includes standardized data used to control a second standard model of the second I / O device accessed by the user, and the method includes: converting the standardized data into control data corresponding to the second I / O device based on the mapping setting file; 6. The method of claim 5, further comprising: transmitting the control data to the second I / O device through a communications layer link between the first converged controller and the second converged controller.

9. 1. An I / O device access apparatus adapted to control access to various I / O devices in a vehicle, comprising:

1. A processor comprising: Controlling standard models of the various I / O devices and a mapping configuration file between the various I / O devices and the standard models; generating a resource access request when the apparatus accesses a first I / O device, the resource access request including first standardized data used to control a first standard model, the first standard model being included in the standard models of the various I / O devices; a processor configured to convert the first standardized data into first control data corresponding to the first I / O device based on the mapping setting file; a transceiver configured to transmit the first control data to the first I / O device based on the mapping configuration file.

10. 10. The apparatus of claim 9, wherein the mapping setting file between the various I / O devices and the standard model includes a conversion relationship between standardized data used to control the standard model and control data used to control the various I / O devices.

11. The transceiver includes: receiving sampling data reported by the first I / O device; 11. The apparatus according to claim 9 or 10, further configured to convert the sampling data into second standardized data corresponding to the first standard model based on the mapping setting file.

12. The apparatus according to any one of claims 9 to 11, wherein the standard models of the various I / O devices are generated by object-oriented modeling.

13. The apparatus according to any one of claims 9 to 12, wherein the resource access request is generated based on an access behavior of a user.

14. The apparatus of any one of claims 9 to 13, wherein the mapping configuration file is implemented by configuration.

15. The apparatus according to any one of claims 9 to 14, wherein the first I / O device is under a first centralized controller.

16. When the apparatus needs to access a second I / O device under a second converged controller, the resource access request includes standardized data used to control a second standard model of the second I / O device accessed by the user; The processor, The method is further configured to convert the standardized data into control data corresponding to the second I / O device based on the mapping setting file; The transceiver includes:

14. The apparatus of claim 13, further configured to transmit the control data to the second I / O device over a communications layer link between a first converged controller and the second converged controller.

17. 1. An I / O device access apparatus adapted to control access to various I / O devices in a vehicle, comprising: a device abstraction layer configured to control a standard model of the various I / O devices and a mapping configuration file between the various I / O devices and the standard model; an application layer configured to generate a resource access request when the apparatus accesses a first I / O device, the resource access request including first standardized data used to control a first standard model, the first standard model being included in the standard models of the various I / O devices; the device abstraction layer is further configured to convert the first standardized data into first control data corresponding to the first I / O device based on the mapping configuration file, and transmit the first control data to the first I / O device via a communication layer.

18. 20. The apparatus of claim 17, wherein the mapping setting file between the various I / O devices and the standard model includes a conversion relationship between standardized data used to control the standard model and control data used to control the various I / O devices.

19. the device abstraction layer receiving the sampling data reported by the communication layer; 19. The apparatus according to claim 17 or 18, further configured to convert the sampling data into second standardized data corresponding to the first standard model based on the mapping setting file.

20. The apparatus according to any one of claims 17 to 19, wherein the standard models of the various I / O devices are generated by object-oriented modeling.

21. The apparatus according to any one of claims 17 to 20, wherein the resource access request is generated based on an access behavior of a user.

22. The apparatus of any one of claims 17 to 21, wherein the mapping configuration file is implemented by a configuration.

23. The apparatus according to any one of claims 17 to 22, wherein the first I / O device is under a first centralized controller.

24. When the apparatus needs to access a second I / O device under a second converged controller, the resource access request includes standardized data used to control a second standard model of the second I / O device accessed by the user; The device abstraction layer comprises: converting the standardized data into control data corresponding to the second I / O device based on the mapping setting file; 22. The apparatus of claim 21, further configured to: transmit the control data to the second I / O device through a communications layer link between a first converged controller and the second converged controller.

25. An I / O device access apparatus, comprising: An apparatus comprising a processor, a memory and a bus, said processor and said memory being connected using said bus, said memory being configured to store a group of program codes, said processor calling said program codes stored in said memory to perform the method according to any one of claims 1 to 8.

26. 1. A computer-readable storage medium, comprising: The computer readable storage medium stores instructions which, when executed on a computer, implement the method of any one of claims 1 to 8.

27. The vehicle comprises an apparatus according to any one of claims 9 to 16 or an apparatus according to any one of claims 17 to 24.

Images