[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2022104747A1 - 一种访问io设备的方法及装置 - Google Patents

一种访问io设备的方法及装置 Download PDF

Info

Publication number
WO2022104747A1
WO2022104747A1 PCT/CN2020/130639 CN2020130639W WO2022104747A1 WO 2022104747 A1 WO2022104747 A1 WO 2022104747A1 CN 2020130639 W CN2020130639 W CN 2020130639W WO 2022104747 A1 WO2022104747 A1 WO 2022104747A1
Authority
WO
WIPO (PCT)
Prior art keywords
devices
various
access request
resource access
centralized controller
Prior art date
Application number
PCT/CN2020/130639
Other languages
English (en)
French (fr)
Inventor
胡涛
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN202211117922.1A priority Critical patent/CN115489459A/zh
Priority to JP2023530559A priority patent/JP2023550936A/ja
Priority to PCT/CN2020/130639 priority patent/WO2022104747A1/zh
Priority to EP20962038.4A priority patent/EP4238832A4/en
Priority to CN202080004241.7A priority patent/CN112566819B/zh
Publication of WO2022104747A1 publication Critical patent/WO2022104747A1/zh
Priority to US18/320,597 priority patent/US20230291604A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H04L12/40032—Details regarding a bus interface enhancer
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H04L12/40013—Details regarding a bus controller
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40078—Bus configuration
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Definitions

  • the present application is in the field of communication technologies, and in particular, relates to a method and apparatus for accessing an IO device.
  • IO input/output
  • IO input/output
  • IO devices can be various sensors such as temperature sensors, humidity sensors, etc., or various actuators such as motors.
  • These IO devices have many types of interfaces, such as a controller area network (CAN) interface, a local interconnect network (LIN) interface, and a Pulse Width Modulation (PWM) interface.
  • CAN controller area network
  • LIN local interconnect network
  • PWM Pulse Width Modulation
  • H-bridge bus (HB) interface analog-to-digital (AD) interface
  • DI digital input
  • DO digital output
  • the technical problem to be solved by the embodiments of the present application is to provide a method and apparatus for accessing IO devices, so as to solve the problem of poor flexibility and reliability when a centralized controller accesses various types of IO devices.
  • an embodiment of the present application provides a method for accessing an IO device, which may include:
  • the first centralized controller performs object modeling on various IO devices on the vehicle, generates standard models of the various IO devices, and generates a mapping configuration file between the various IO devices and the standard models;
  • the resource access request is sent to the first IO device.
  • a single standard model can be mapped to multiple IO devices of different models or different interfaces, so that when the centralized controller accesses an IO device, the corresponding IO device can be mapped.
  • the standard model sends resource access requests, and accurately sends resource access requests to the IO device through the mapping configuration file, completing the access to the IO device, without the need to adjust for different manufacturers, models, device models or interface types, thus greatly improving Flexibility and reliability for accessing IO devices.
  • the first centralized controller performs object modeling on various IO devices on the vehicle, generates standard models of the various IO devices, and generates the various IO devices and the Mapping configuration files for standard models, including:
  • the first centralized controller performs object-oriented modeling on various IO devices on the vehicle according to the types of various IO devices accessed by the application, and generates standard models of the various IO devices;
  • IO devices with different interfaces can be mapped to the same physical port, and through the physical port, different interface types can be implemented.
  • the standardized data corresponding to the standard model and the control data corresponding to the control device can be converted accordingly. It can achieve the effect of shielding the physical port type of IO devices, and can keep the upper-layer application unchanged in the development of different models, reduce the development difficulty, improve the reuse degree of application layer software, and facilitate the research and development and testing of vehicles; manufacturers, models, Model or interface changes only need to update the configuration data, which is convenient for upgrades.
  • the resource access request further includes first standardized data for controlling the first standard model
  • the method also includes:
  • the first centralized controller converts the first standardized data into first control data corresponding to the first IO device according to the conversion relationship;
  • the method further includes:
  • the first centralized controller receives the sampling data reported by the first IO device
  • the sampled data is converted into second standardized data corresponding to the first standard model according to the conversion relationship.
  • the resource access request includes the first IO device of the second IO device accessed by the user.
  • the method further includes:
  • the first centralized controller sends the resource access request to the second IO device through a communication layer link between the first centralized controller and the second centralized controller.
  • the application layer of the second centralized controller does not need to be changed, nor does it need to add a new communication interface, thereby improving the efficiency of cross-node access and reducing the cost of cross-node access.
  • an apparatus for accessing an IO device which may include:
  • the processing unit is used to perform object modeling on various IO devices on the vehicle, generate standard models of the various IO devices, and generate a mapping configuration file between the various IO devices and the standard models; according to the user's access
  • the operation generates a resource access request, the resource access request includes the first standard model of the first IO device accessed by the user;
  • a transceiver unit configured to send the resource access request to the first IO device according to the mapping configuration file.
  • the processing unit is specifically used for:
  • object-oriented modeling is performed on various IO devices on the vehicle for the application, and standard models of the various IO devices are generated;
  • the resource access request further includes first standardized data for controlling the first standard model
  • the processing unit is also used to:
  • the transceiver unit is further configured to send the first control data to the first IO device.
  • the transceiver unit is further used for:
  • the processing unit is further configured to convert the sampled data into second standardized data corresponding to the first standard model according to the conversion relationship.
  • the resource access request includes the second standard model of the second IO device accessed by the user
  • the transceiver unit is also used for:
  • the resource access request is sent to the second IO device through a communication layer link between the first centralized controller and the second centralized controller.
  • an embodiment of the present application provides a device for accessing an IO device, including:
  • the device abstraction layer is used to perform object modeling on various IO devices on the vehicle, generate standard models of the various IO devices, and generate mapping configuration files between the various IO devices and the standard models;
  • the application layer is configured to generate a resource access request according to the user's access operation, and send the resource access request to the device abstraction layer, where the resource access request includes the first standard model of the first IO device accessed by the user ;
  • the device abstraction layer is further configured to send the resource access request to the communication layer;
  • the communication layer is configured to send a control command to the driver layer through the transceiver according to the resource access request, and perform input and output operations on the IO device.
  • the driver layer is configured to, in response to the control command, send the sampled data obtained by the input and output operations to the communication layer;
  • the communication layer is further configured to send the sampled data to the device abstraction layer;
  • the device abstraction layer is further configured to convert the sampled data into standardized data corresponding to the standard model and send it to the application layer.
  • a computer-readable storage medium for storing a computer program, the computer program comprising instructions for performing the method in the first aspect or any one of possible implementations of the first aspect.
  • a computer program product comprising: computer program code, when the computer program code is run on a computer, the computer is made to execute the first aspect or any one of the first aspects methods in possible implementations.
  • FIG. 1 is a schematic diagram of an existing software architecture for accessing an IO device
  • FIG. 2 is a schematic flowchart of a method for accessing an IO device provided by an embodiment of the present application
  • FIG. 3 is a schematic diagram of a software architecture for accessing an IO device provided by an embodiment of the present application
  • FIG. 4 is a schematic diagram of modeling an IO device and a physical port according to an embodiment of the present application
  • FIG. 5 is a schematic flowchart of another method for accessing an IO device provided by an embodiment of the present application.
  • FIG. 6 is a schematic diagram of another software architecture for accessing an IO device provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of a hardware architecture for accessing an IO device provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of the composition of a device for accessing an IO device provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of the composition of another apparatus for accessing an IO device provided by an embodiment of the present application.
  • FIG. 1 is a schematic diagram of an existing software architecture for accessing an IO device. It includes an application layer, a communication layer (com layer) and a driver layer.
  • the application layer 100 is used for storing program codes and running related applications accessing the IO device. For example, it can be some control applications that control the IO devices on the vehicle, or some applications used for testing.
  • the application layer can send a resource access request to the communication layer.
  • the communication layer 200 is configured to send the resource access request sent by the application layer to the driver layer through the transceiver.
  • the driver layer 300 is used to drive related IO devices.
  • the embodiments of the present application provide a method and apparatus for accessing an IO device, so as to improve the flexibility and reliability of accessing and controlling the IO device.
  • the method and apparatus for accessing an IO device provided by the embodiments of the present application will be described in detail below with reference to FIG. 2 to FIG. 9 .
  • FIG. 2 is a schematic flowchart of a method for accessing an IO device provided by an embodiment of the present application; the method includes the following steps:
  • the first centralized controller performs object modeling on various IO devices on the vehicle, generates standard models of the various IO devices, and generates a mapping configuration file between the various IO devices and the standard models.
  • various IO devices on the vehicle may include various components on the vehicle that can be accessed or controlled, such as wipers, windows, lights, seats, doors, sunroofs, trunks, etc., and may also include various sensors such as distance sensors , temperature sensor, light sensor, gravity sensor, acceleration sensor, etc.
  • the IO device may also be other electronic control unit (electronic control unit, ECU for short) similar to the first centralized controller. Because different manufacturers and models may use different interfaces or models of IO devices. As a result, when the application layer needs to access IO devices, it needs to adapt to different manufacturers, models, device models, and interface types.
  • object modeling can be performed on various IO devices, for example, modeling of wipers.
  • All can issue resource access requests for the standardized and object-oriented standard model of "wiper".
  • mapping configuration files between various IO devices and standard models By generating mapping configuration files between various IO devices and standard models, the centralized controller can accurately issue resource access requests to the IO devices that need to be accessed or controlled, thereby completing access or control.
  • the mapping of a single standard model and multiple IO devices of different models or different interfaces can be realized, so that when the centralized controller accesses a certain IO device,
  • the resource access request can be sent to the standard model corresponding to the IO device, and the resource access request can be accurately sent to the IO device through the mapping configuration file to complete the access to the IO device, without the need for different manufacturers, models, device models or interfaces.
  • the type is adjusted, which greatly improves the flexibility and reliability of accessing IO devices.
  • FIG. 3 is a schematic diagram of a software architecture for accessing an IO device provided by an embodiment of the present application; including:
  • the device abstraction layer 10 is used to perform object modeling on various IO devices on the vehicle, generate standard models of the various IO devices, and generate a mapping configuration file between the various IO devices and the standard models;
  • the application layer 20 is configured to generate a resource access request according to the user's access operation, and send the resource access request to the device abstraction layer 10, where the resource access request includes the first IO device of the first IO device accessed by the user. standard model;
  • the device abstraction layer 10 is further configured to send the resource access request to the communication layer 30;
  • the communication layer 30 is configured to send a control command to the transceiver 40 according to the resource access request, and perform input and output operations on the IO device.
  • the driver layer 40 is configured to receive the resource access request forwarded by the transceiver, drive the IO device, and complete the input and output operations.
  • FIG. 4 is a schematic diagram of modeling an IO device and a physical port according to an embodiment of the present application
  • the device abstraction layer may include a device abstraction module 11 and a port abstraction module 12 .
  • the device abstraction module 11 can be oriented to applications such as vehicle control unit (VCU) software or body control module (BCM) according to the types of various IO devices accessed by the application.
  • VCU vehicle control unit
  • BCM body control module
  • Software, etc. perform object modeling on various IO devices on the vehicle, and generate standard models of the various IO devices; that is, device modeling is performed upward in the entire software architecture.
  • the port abstraction module 12 can model the physical ports for the IO devices according to the physical ports of the various IO devices, and configure the conversion relationship between the standardized data for controlling the standard model and the control data for controlling the IO devices. That is, port modeling is done downward in the entire software architecture. After the data is converted, it is forwarded through the forwarding plane, that is, the conversion from the IO interface to the Ethernet interface, and finally sent to various IO devices through the physical port.
  • the data sent by the first centralized controller and the data reported by the first IO device can be converted accordingly.
  • the resource access request further includes first standardized data for controlling the first standard model
  • the first centralized controller may convert the first standardized data into first control data corresponding to the first IO device according to the conversion relationship;
  • the first control data is then sent to the first IO device.
  • the first centralized controller may receive the sampled data reported by the first IO device;
  • the sampled data is then converted into second standardized data corresponding to the first standard model according to the conversion relationship.
  • the temperature and/or fitting formula used for AD calibration configuration can be changed through corresponding design tools such as management applications, and the level used for pwm configuration can be changed.
  • Change the threshold and/or calculation formula change the high and low threshold, high and low side configuration and/or calculation formula for output configuration, change the signal offset and/or calculation formula for Can dbc configuration, change the The switch and/or the high-low mapping of the DI configuration are changed, and then, when accessing the resources of the IO device, the port abstraction module 12 can perform AD fitting formula calculation, PWM frequency ratio conversion, and DI high and low values according to the settings completed by the configuration. Mapping, CAN/LIN signal conversion, high and low variable drive value mapping, HB constant current value mapping or Sent bus mapping to realize data conversion.
  • the physical port type of the IO device can be shielded, and the upper-layer application can be kept unchanged in the development of different vehicle models, which reduces the development difficulty, improves the reuse degree of the application layer software, and is beneficial to the research and development and testing of the vehicle; Changes in manufacturer, model, model or interface only need to update the configuration data, which is convenient for upgrades.
  • FIG. 5 is another method for accessing IO devices provided by the embodiments of the present application.
  • a schematic flowchart of the method of the device including the following steps:
  • the first centralized controller performs object modeling on various IO devices on the vehicle, generates standard models of the various IO devices, and generates a mapping configuration file between the various IO devices and the standard models.
  • S502 Generate a resource access request according to the user's access operation, where the resource access request includes the second standard model of the second IO device accessed by the user.
  • the first centralized controller sends the resource access request to the second IO device through a communication layer link between the first centralized controller and the second centralized controller.
  • FIG. 6 is another schematic diagram of a software architecture for accessing an IO device provided by an embodiment of the present application, including 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
  • the second controller includes a communication layer 230 and a driver layer 240 .
  • the second centralized controller may also include the device abstraction layer 210 and the application layer 220, but in the method for accessing IO devices across nodes in this embodiment of the present application, the application layer 220 does not need to be changed, nor need to add new Communication interface, thereby improving the efficiency of cross-node access and reducing the cost of cross-node access.
  • a specific process for accessing an IO device may include local access to the IO device and cross-node access to the IO device.
  • the process of local access (the first centralized controller accesses the first IO device) is as follows:
  • the application layer 120 generates a resource access request and sends it to the device abstraction layer 110;
  • the device abstraction layer 110 sends the resource access request to the communication layer 130; in this step, the device abstraction layer 110 can convert the first standardized data in the resource access request into control data of the first IO device;
  • the communication layer 130 sends corresponding control commands to the driver layer 140 through the transceiver to perform I/O operations on the first IO device; depending on the physical port, the transceiver here can be a general-purpose input/output (general-purpose input/output) , referred to as GPIO) transceiver or CAN transceiver and so on.
  • GPIO general-purpose input/output
  • the driver layer 140 accesses the first IO device in response to the control command, and sends the sample data obtained by the I/O operation to the communication layer 130;
  • the communication layer 130 passes the sample data to the device abstraction layer 130;
  • the device abstraction layer 130 standardizes the access sample data, converts it into second standardized data corresponding to the first standard model, and transmits it to the application layer 120 .
  • cross-node access (such as the first centralized controller 1 accessing the second IO device) is as follows:
  • the application layer 120 generates a resource access request and sends it to the device abstraction layer 110;
  • the device abstraction layer 110 sends the resource access request to the communication layer 130; in this step, the device abstraction layer 110 can convert the first standardized data in the resource access request into the control data of the first IO device;
  • the communication layer 130 sends a resource access request to the communication layer 230 of the second centralized controller
  • the communication layer 230 of the second centralized controller issues corresponding control commands to perform I/O operations on the second IO device;
  • the driver layer 240 of the second centralized controller accesses the second IO device, and transmits the sampled data obtained by the I/O operation to the communication layer 230;
  • the communication layer 230 of the second centralized controller then transfers the samples to the communication layer 130 of the first centralized controller;
  • the communication layer 130 passes the sample data to the device abstraction layer 130;
  • the device abstraction layer 130 normalizes the samples, converts them into normalized data corresponding to the second standard model, and transmits them to the application layer 120 .
  • FIG. 7 is a schematic diagram of a hardware architecture for accessing an IO device provided by an embodiment of the present application; as shown in FIG. 7 , the device for accessing an IO device includes a first centralized controller and a second centralized controller.
  • the controller is connected via Ethernet (ETH for short), and the first centralized controller includes a first microcontroller (micro controller unit, MPU for short) 310, a first microprocessor (micro processing unit, MCU for short) ) 320, the first Ethernet switch (LSW for short) 330 and the device abstraction module 340 (the device abstraction module 340 is a functional module corresponding to the device abstraction layer, which can be set independently, or can be combined with the first MCU320 or the first MPU310 integrated setting), the second centralized controller includes a second MPU410, a second MCU 420 and a second LSW 430 (which may also include a device abstraction module 440 or not).
  • the IO device accessed when the first centralized controller performs local access is the first IO device 350
  • the IO device accessed when the second centralized controller performs local access is the second IO device 450 .
  • the MCU can deploy applications with high real-time and high security level, and can also be responsible for resource access and data forwarding of IO devices.
  • MPU can be deployed for applications with high computational requirements such as ADAS, and LSW is used for backbone network communication.
  • the first MPU310 can deploy application functions related to automatic driving such as pre-collision warning function
  • the first MCU320 can deploy the VCU function
  • the second MPU410 can deploy the Advanced Driver Assistance Systems (ADAS) function
  • the second MPU410 can deploy the Advanced Driver Assistance Systems (ADAS) function.
  • the MCU 420 may deploy a battery management system (BMS) function.
  • BMS battery management system
  • the data of the first IO device 350 can be transmitted to the first MPU 310/the first MCU 320, and can also be transmitted to the second IO device 350 through the Ethernet interface.
  • the second MPU 410/second MCU 420 of the centralized controller is used to realize the cross-node access of the second centralized controller to the first IO device.
  • FIG. 8 is a schematic diagram of the composition of an apparatus for accessing an IO device provided by an embodiment of the present application; including:
  • the processing unit 1000 is configured to perform object modeling on various IO devices on the vehicle, generate standard models of the various IO devices, and generate a mapping configuration file between the various IO devices and the standard models;
  • the access operation generates a resource access request, and the resource access request includes the first standard model of the first IO device accessed by the user;
  • the transceiver unit 2000 is configured to send the resource access request to the first IO device according to the mapping configuration file.
  • processing unit 1000 is specifically configured to:
  • object-oriented modeling is performed on various IO devices on the vehicle for the application, and standard models of the various IO devices are generated;
  • the resource access request further includes first standardized data for controlling the first standard model
  • the processing unit 1000 is also used for:
  • the transceiver unit 2000 is further configured to send the first control data to the first IO device.
  • the transceiver unit 2000 is further configured to:
  • the processing unit 1000 is further configured to convert the sampled data into second standardized data corresponding to the first standard model according to the conversion relationship.
  • the resource access request includes the second standard model of the second IO device accessed by the user, and the transceiver unit 2000 Also used for:
  • the resource access request is sent to the second IO device through a communication layer link between the first centralized controller and the second centralized controller.
  • FIG. 9 is a schematic diagram of the composition of another apparatus for accessing an IO device provided by 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 through a bus 1140, the memory 1120 is used to store instructions, and the processor 1110 is used to execute the instructions stored in the memory 1120, so as to implement the first method in the methods corresponding to FIG. 2-6 above.
  • the steps performed by the centralized controller is performed by the centralized controller.
  • the processor 1110 is configured to execute the instructions stored in the memory 120 to control the transceiver 1130 to receive and transmit signals, and to complete the steps performed by the apparatus in the above method.
  • the memory 1120 may be integrated in the processor 1110, or may be provided separately from the processor 1110.
  • the function of the transceiver 1130 can be considered to be implemented by a transceiver circuit or a dedicated chip for transceiver.
  • the processor 1110 can be considered to be implemented by a dedicated processing chip, a processing circuit, a processor or a general-purpose chip.
  • a general-purpose computer may be used to implement the apparatus provided in the embodiments of the present application.
  • the program codes that will implement the functions of the processor 1110 and the transceiver 1130 are stored in the memory 1120, and a general-purpose processor implements the functions of the processor 1110 and the transceiver 1130 by executing the codes in the memory 120.
  • a computer-readable storage medium on which instructions are stored, and when the instructions are executed, implement the method executed by the first centralized controller in the above method embodiments.
  • a computer program product including an instruction is provided, and when the instruction is executed, the method executed by the first centralized controller in the above method embodiment is executed.
  • FIG. 9 Those skilled in the art can understand that, for the convenience of description, only one memory and a processor are shown in FIG. 9 . In an actual controller, there may be multiple processors and memories.
  • the memory may also be referred to as a storage medium or a storage device, etc., which is not limited in this embodiment of the present application.
  • the processor may be a central processing unit (Central Processing Unit, referred to as CPU), and the processor may also be other general-purpose processors, digital signal processors (Digital Signal Processing, referred to as DSP), Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • CPU Central Processing Unit
  • DSP Digital Signal Processing
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • the memory mentioned in the embodiments of the present invention may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.
  • the non-volatile memory may be a read-only memory (Read-Only Memory, referred to as ROM), a programmable read-only memory (Programmable ROM, referred to as PROM), an erasable programmable read-only memory (Erasable PROM, referred to as EPROM) , Electrically Erasable Programmable Read-Only Memory (Electrically EPROM, EEPROM for short) or flash memory.
  • the volatile memory may be Random Access Memory (RAM for short), which is used as an external cache memory.
  • RAM Static Random Access Memory
  • DRAM Dynamic RAM
  • SDRAM Synchronous DRAM
  • DDR SDRAM double data rate synchronous dynamic random access memory
  • ESDRAM enhanced synchronous dynamic random access memory
  • SLDRAM synchronous connection dynamic random access memory
  • Direct Rambus RAM Direct Rambus RAM
  • the processor is a general-purpose processor, DSP, ASIC, FPGA or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components
  • the memory storage module
  • memory described herein is intended to include, but not be limited to, these and any other suitable types of memory.
  • the bus may also include a power bus, a control bus, a status signal bus, and the like.
  • the various buses are labeled as buses in the figure.
  • each step of the above-mentioned method can be completed by a hardware integrated logic circuit in a processor or an instruction in the form of software.
  • the steps of the methods disclosed in conjunction with the embodiments of the present application may be directly embodied as executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.
  • the software modules may be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other storage media mature in the art.
  • the storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware. To avoid repetition, detailed description is omitted here.
  • the embodiment of the present application further provides a system, which includes the aforementioned first centralized controller and various IO devices, and may further include a second centralized controller and the like.
  • the size of the sequence numbers of the above-mentioned processes does not mean the sequence of execution, and the execution sequence of each process should be determined by its functions and internal logic, rather than the implementation process of the embodiments of the present application. constitute any limitation.
  • the disclosed system, apparatus and method may be implemented in other manners.
  • the apparatus embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented.
  • the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.
  • the above-mentioned embodiments it may be implemented in whole or in part by software, hardware, firmware or any combination thereof.
  • software it can be implemented in whole or in part 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 processes or functions described in the embodiments of the present application are generated.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be downloaded from a website site, computer, server, or data center Transmission to another website site, computer, server, or data center by wire (eg, coaxial cable, optical fiber, digital subscriber line) or wireless (eg, infrared, wireless, microwave, etc.).
  • the computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, a data center, or the like that includes an integration of one or more available media.
  • the usable media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid state drives), and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

一种访问IO设备的方法及装置。方法包括：第一集中控制器对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件（S201）；根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型（S202）；根据所述映射配置文件，将所述资源访问请求发送给所述第一IO设备（S203）。采用该方法，可提升集中控制器访问各种不同类型IO设备的灵活性和和可靠性。

Description

一种访问IO设备的方法及装置 技术领域
本申请通信技术领域，尤其涉及一种访问IO设备的方法及装置。
背景技术
随着智能化汽车和新能源汽车的发展,汽车电子电气架构从分离式向集中式演进，且控制器具有集中化的趋势。现在的车辆内通常设有几十甚至上百个控制器，以及数百个带有输入/输出(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设备时，灵活性和可靠性较差。
发明内容
本申请实施例所要解决的技术问题在于，提供一种访问IO设备的方法及装置，以解决集中控制器访问各种不同类型IO设备时，灵活性和可靠性较差的问题。
第一方面，本申请的实施例提供了一种访问IO设备的方法，可包括：
第一集中控制器对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件；
根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型；
根据所述映射配置文件，将所述资源访问请求发送给所述第一IO设备。
通过对各种IO设备进行对象化建模，可以实现单个标准模型与多个不同型号或不同接口的IO设备的映射，使得集中控制器在访问某个IO设备时，可以对该IO设备对应的标准模型发出资源访问请求，并通过映射配置文件准确的将资源访问请求发送至该IO设备，完成对该IO设备的访问，无需针对不同厂家、车型、设备型号或接口类型进行调整，从而大大提升了访问IO设备的灵活性和可靠性。
在一种可能的实现方式中，所述第一集中控制器对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件，包括：
所述第一集中控制器根据应用访问的各种IO设备的类型，面向应用对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型；
根据所述各种IO设备的物理端口，面向IO设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制IO设备的控制数据的转换关系。
通过向上建模使得应用在访问IO设备时可以通过访问标准模型实现，通过向下建模可以使得不同接口的IO设备与同一个物理端口进行映射，通过该物理端口便可以实现对不同接口类型的IO设备进行访问，在访问不同接口类型的IO设备时，将与标准模型对应的标准化数据和与控制设备对应的控制数据进行相应的转换即可。可以实现屏蔽IO设备的物理端口类型的效果，在不同车型中开发中可以保持上层应用不变，降低开发难度，提高了应用层软件的复用度，利于车辆的研发和测试；厂家、车型、型号或接口变化仅需更新配置数据，方便升级。
在一种可能的实现方式中，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
所述方法还包括：
所述第一集中控制器根据所述转换关系将所述第一标准化数据转换为所述第一IO设备对应的第一控制数据；
将所述第一控制数据发送给所述第一IO设备。
通过数据转换，在访问不同厂家、车型、型号或接口的IO设备时，只需要适应性的配置数据的转换关系即可。
在一种可能的实现方式中，所述方法还包括：
所述第一集中控制器接收所述第一IO设备上报的采样数据；
根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
在一种可能的实现方式中，当所述第一集中控制器需要访问第二集中控制器下的第二IO设备时，所述资源访问请求中包括所述用户访问的第二IO设备的第二标准模型，所述方法还包括：
所述第一集中控制器将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二IO设备。
通过这样的跨节点访问方式，第二集中控制器的应用层无需进行改动，也无需增加新的通信接口，从而提升了跨节点访问的效率，并降低了跨节点访问的成本。
第二方面，本申请的实施例提供了一种访问IO设备的装置，可包括：
处理单元，用于对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件；根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型；
收发单元，用于根据所述映射配置文件，将所述资源访问请求发送给所述第一IO设备。
在一种可能的实现方式中，所述处理单元具体用于：
根据应用访问的各种IO设备的类型，面向应用对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型；
根据所述各种IO设备的物理端口，面向IO设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制IO设备的控制数据的转换关系。
在一种可能的实现方式中，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
所述处理单元还用于：
根据所述转换关系将所述第一标准化数据转换为所述第一IO设备对应的第一控制数据；
所述收发单元还用于将所述第一控制数据发送给所述第一IO设备。
在一种可能的实现方式中，所述收发单元还用于：
接收所述第一IO设备上报的采样数据；
所述处理单元还用于根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
在一种可能的实现方式中，当所述装置需要访问第二集中控制器下的第二IO设备时，所述资源访问请求中包括所述用户访问的第二IO设备的第二标准模型，所述收发单元还用于：
将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二IO设备。
第三方面，本申请实施例提供了一种访问IO设备的装置，包括：
设备抽象层，用于对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件；
应用层，用于根据用户的访问操作生成资源访问请求，将所述资源访问请求发送给所述设备抽象层，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型；
所述设备抽象层还用于将所述资源访问请求发送给通信层；
所述通信层用于根据所述资源访问请求，通过收发器向驱动层发送控制命令，对IO设备进行输入输出的操作。
在一种可能的实现方式中，所述驱动层，用于响应于所述控制命令，将所述输入输出的操作获取到的采样数据发送给所述通信层；
所述通信层还用于将所述采样数据发送给所述设备抽象层；
所述设备抽象层还用于将所述采样数据转换为与所述标准模型对应的标准化数据并发送给所述应用层。
第四方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面中任一种可能实现方式中的方法的指令。
第五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第一方面或第一方面中任一种可能实现方式中的方法。
附图说明
为了更清楚地说明本申请实施例或背景技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图进行说明。
图1为现有的一种访问IO设备的软件架构示意图；
图2为本申请实施例提供的一种访问IO设备的方法的流程示意图；
图3为本申请实施例提供的一种访问IO设备的软件架构示意图；
图4为本申请实施例提供的一种对IO设备及物理端口建模的示意图；
图5为本申请实施例提供的另一种访问IO设备的方法的流程示意图；
图6为本申请实施例提供的另一种访问IO设备的软件架构示意图；
图7为本申请实施例提供的一种访问IO设备的硬件架构示意图；
图8为本申请实施例提供的一种访问IO设备的装置的组成示意图；
图9为本申请实施例提供的另一种访问IO设备的装置的组成示意图。
具体实施方式
下面结合本申请实施例中的附图对本申请的实施例进行描述。
本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
请参照图1，为现有的一种访问IO设备的软件架构示意图。其包括应用层、通信层(com层)和驱动层。
其中，应用层100用于存储程序代码及运行访问IO设备的相关应用。例如可以是一些控制车辆上的IO设备的控制类应用，也可以是一些用于测试的应用。当用户执行某个IO设备的资源访问操作时，应用层可以向通信层发送资源访问请求。
通信层200，用于将应用层发出的资源访问请求通过收发器发送至驱动层。
驱动层300，用于驱动相关的IO设备。
在该软件架构下，当需要访问某个IO设备时，需要在应用层10中指示具体的IO设备、接口类型、厂商、车型等设备间通信的细节。因此任意因素发生变动时，应用层10的应用也需要进行更新和调整，导致灵活性和可靠性较差，且在该架构下，需要跨节点访问其他集中控制器下的IO设备时，需要配置与其他集中控制器的通信接口，还需要改变其他集中控制器的控制代码等，访问效率低下。
因此，本申请实施例提供了一种访问IO设备的方法及装置，以提升访问和控制IO设备的灵活性和可靠性。下面结合图2到图9对本申请实施例提供的访问IO设备方法及装置进行详细说明。
请参见图2，为本申请实施例提供的一种访问IO设备的方法的流程示意图；包括如下步骤：
S201，第一集中控制器对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件。
其中，车辆上的各种IO设备可以包括车辆上各种可以访问或控制的部件如雨刮、车窗、灯光、座椅、车门、天窗、后备箱等，还可以包括各种传感器如距离传感器、温度传感器、光线传感器、重力传感器、加速度传感器等，此外IO设备还可以是与第一集中控制器类似的其他的电子控制单元(electronic control unit，简称ECU)。由于不同的厂家、车型可能使用不同接口或型号的IO设备。导致应用层需要访问IO设备时，需要针对不同的厂家、车型、设备型号、接口类型进行适配。因此，在本申请实施例中，可以对各种IO设备进行对象化建模，例如对雨刮进行建模，当应用需要访问或控制任意厂家或车型的任意型 号或接口类型的雨刮时，都可以针对“雨刮”这一标准化、对象化的标准模型发出资源访问请求。
S202，根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型。
S203，根据所述映射配置文件，将所述资源访问请求发送给所述第一IO设备。
集中控制器通过生成各种IO设备与标准模型的映射配置文件，应用可以将资源访问请求准确的下发至需要访问或控制的IO设备，从而完成访问或控制。
在本申请实施例中，通过对各种IO设备进行对象化建模，可以实现单个标准模型与多个不同型号或不同接口的IO设备的映射，使得集中控制器在访问某个IO设备时，可以对该IO设备对应的标准模型发出资源访问请求，并通过映射配置文件准确的将资源访问请求发送至该IO设备，完成对该IO设备的访问，无需针对不同厂家、车型、设备型号或接口类型进行调整，从而大大提升了访问IO设备的灵活性和可靠性。
请参见图3，为本申请实施例提供的一种访问IO设备的软件架构示意图；包括：
设备抽象层10，用于对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件；
应用层20，用于根据用户的访问操作生成资源访问请求，将所述资源访问请求发送给所述设备抽象层10，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型；
所述设备抽象层10还用于将所述资源访问请求发送给通信层30；
所述通信层30用于根据所述资源访问请求向收发器40发送控制命令，对IO设备进行输入输出的操作。
驱动层40，用于接收收发器转发的资源访问请求，驱动IO设备，完成输入输出的操作。
请参见图4，为本申请实施例提供的一种对IO设备及物理端口建模的示意图；
设备抽象层可以包括设备抽象模块11和端口抽象模块12。如图4所示，设备抽象模块11可以根据应用访问的各种IO设备的类型，面向应用如整车控制器(vehicle control unit，简称VCU)软件或车身控制器(body control module，简称BCM)软件等，对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型；即在整个软件架构中向上进行设备建模。
端口抽象模块12则可以根据所述各种IO设备的物理端口，面向IO设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制IO设备的控制数据的转换关系。即在整个软件架构中向下进行端口建模。数据通过转换后，再通过转发面转发即IO接口到以太网接口的转换，最后通过物理端口发送给各种IO设备。
通过向上建模使得应用在访问IO设备时可以通过访问标准模型实现，通过向下建模可以使得不同接口的IO设备与同一个物理端口进行映射，通过该物理端口便可以实现对不同接口类型的IO设备进行访问，在访问不同接口类型的IO设备时，将与标准模型对应的标准化数据和与控制设备对应的控制数据进行相应的转换即可。
结合图2所述的访问IO设备的方法，可以对第一集中控制器下发的数据以及第一IO 设备上报的数据进行相应的转换。
当第一集中控制器要访问第一IO设备时，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
所述第一集中控制器可以根据所述转换关系将所述第一标准化数据转换为所述第一IO设备对应的第一控制数据；
再将所述第一控制数据发送给所述第一IO设备。
而当第一集中控制器指示第一IO设备上报数据或第一IO设备主动上报数据时，所述第一集中控制器可以接收所述第一IO设备上报的采样数据；
再根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
例如，当厂家、车型、设备型号、接口类型需要进行变化时，可以通过相应的设计工具如管理应用对用于AD标定配置的温度和/或拟合公式进行变更，对用于pwm配置的高低门限和/或计算公式进行变更，对用于output配置的高低门限、高低边配置和/或计算公式进行变更，对用于Can dbc配置的信号偏移和/或计算公式进行变更，对用于DI配置的开关和/或高低映射进行变更，然后，在对IO设备进行资源访问时，端口抽象模块12可以根据配置完成的设置，进行AD拟合公式计算、PWM频占比转换、DI高低值映射、CAN/LIN信号转换、高低变驱动值映射、HB恒流值映射或Sent总线映射，从而实现数据的转换。
通过本实施例中的方法可以屏蔽IO设备的物理端口类型，在不同车型中开发中可以保持上层应用不变，降低开发难度，提高了应用层软件的复用度，利于车辆的研发和测试；厂家、车型、型号或接口变化仅需更新配置数据，方便升级。
基于图2-图4所述的方法和架构，在本申请实施例中，还提供了一种跨节点访问IO设备的方法，请参见图5，为本申请实施例提供的另一种访问IO设备的方法的流程示意图；包括如下步骤：
S501，第一集中控制器对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件。
S502，根据用户的访问操作生成资源访问请求,所述资源访问请求中包括所述用户访问的第二IO设备的第二标准模型。
S503，所述第一集中控制器将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二IO设备。
与图5所述方法对应的软件架构示意图可参见图6，为本申请实施例提供的另一种访问IO设备的软件架构示意图；包括第一集中控制器和第二集中控制器。第一集中控制器包括设备抽象层110、应用层120、通信层130及驱动层140，第二控制器包括通信层230及驱动层240。
需要说明的是，第二集中控制器也可以包括设备抽象层210和应用层220，但是在本申请实施例的跨节点访问IO设备的方法中，应用层220无需进行改动，也无需增加新的通信接口，从而提升了跨节点访问的效率，并降低了跨节点访问的成本。
基于图6所述的软件架构，具体的访问IO设备的流程可以包括IO设备的本地访问和IO设备的跨节点访问。
本地访问(第一集中控制器访问第一IO设备)流程如下：
应用层120生成资源访问请求并发送给设备抽象层110；
设备抽象层110将资源访问请求发送给通信层130；在该步骤中，设备抽象层110可以将资源访问请求中的第一标准化数据转换为第一IO设备的控制数据；
通信130层通过收发器向驱动层140发出相应的控制命令，对第一IO设备进行I/O操作；根据物理端口的不同，此处的收发器可以是通用输入输出(general-purpose input/output，简称GPIO)收发器或CAN收发器等。
驱动层140响应于控制命令，访问第一IO设备，并将I/O操作获取到的采样数据发送给所述通信层130；
通信层130将采样数据传递给设备抽象层130；
设备抽象层130将访问采样数据进行标准化，转换为与第一标准模型对应的第二标准化数据，再传递给应用层120。
跨节点访问(如第一集中控制器1访问第二IO设备)的流程如下：
应用层120生成资源访问请求并发送给设备抽象层110；
设备抽象层110将资源访问请求发送给通信层130；在该步骤中，设备抽象层110可以将资源访问请求中的第一标准化数据转换为第一IO设备的控制数据；
通信130层向第二集中控制器的通信层230发送资源访问请求；
第二集中控制器的通信层230发出相应的控制命令，对第二IO设备进行I/O操作；
第二集中控制器的驱动层240响应于控制命令，访问第二IO设备，并将I/O操作获取到的采样数据传递到通信层230；
第二集中控制器的通信层230再将采样传递给第一集中控制器的通信层130；
通信层130将采样数据传递给设备抽象层130；
设备抽象层130将采样进行标准化，转换为第二标准模型对应的标准化数据，再传递给应用层120。
上述软件架构对应的硬件架构可以参见图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。
其中，MCU可部署实时性和安全等级高的应用，还可以负责对IO设备进行资源访问和数据转发。MPU可部署ADAS等计算量要求较高的应用,LSW用于骨干网通信。
例如：第一MPU310可部署自动驾驶相关的应用功能如预碰撞预警功能，第一MCU320可部署VCU功能，第二MPU410可部署高级自动驾驶辅助系统(Advanced Driver Assistance Systems，简称ADAS)功能，第二MCU420可部署电池管理系统(battery management system， BMS)功能。
如图7中的虚线箭头所示，当对第一IO设备350进行本地访问时，第一IO设备350的数据可以传递给第一MPU310/第一MCU320,还可以通过以太网接口传递给第二集中控制器的第二MPU410/第二MCU420,以实现第二集中控制器对第一IO设备的跨节点访问。
需要说明的是，本实施例所述的方法不仅可以应用于车载IO设备的资源访问，也可应用于工业IO设备资源访问，本申请实施例不作任何限定。
请参见图8，为本申请实施例提供的一种访问IO设备的装置的组成示意图；包括：
处理单元1000，用于对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件；根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型；
收发单元2000，用于根据所述映射配置文件，将所述资源访问请求发送给所述第一IO设备。
可选地，所述处理单元1000具体用于：
根据应用访问的各种IO设备的类型，面向应用对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型；
根据所述各种IO设备的物理端口，面向IO设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制IO设备的控制数据的转换关系。
可选地，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
所述处理单元1000还用于：
根据所述转换关系将所述第一标准化数据转换为所述第一IO设备对应的第一控制数据；
所述收发单元2000还用于将所述第一控制数据发送给所述第一IO设备。
可选地，所述收发单元2000还用于：
接收所述第一IO设备上报的采样数据；
所述处理单元1000还用于根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
可选地，当所述装置需要访问第二集中控制器下的第二IO设备时，所述资源访问请求中包括所述用户访问的第二IO设备的第二标准模型，所述收发单元2000还用于：
将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二IO设备。
请参见图9，为本申请实施例提供的另一种访问IO设备的装置的组成示意图；如图9所示，该装置可以包括处理器1110、存储器1120和收发器1130。处理器1110、存储器1120和收发器1130通过总线1140连接，该存储器1120用于存储指令，该处理器1110用于执行该存储器1120存储的指令，以实现如上图2-6对应的方法中第一集中控制器执行的步骤。
处理器1110用于执行该存储器120存储的指令，以控制收发器1130接收和发送信号，完成上述方法中装置执行的步骤。所述存储器1120可以集成在所述处理器1110中，也可以与所述处理器1110分开设置。
作为一种实现方式，收发器1130的功能可以考虑通过收发电路或者收发的专用芯片实 现。处理器1110可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。
作为另一种实现方式，可以考虑使用通用计算机的方式来实现本申请实施例提供的装置。即将实现处理器1110，收发器1130功能的程序代码存储在存储器1120中，通用处理器通过执行存储1器120中的代码来实现处理器1110，收发器1130的功能。
该装置所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
作为本实施例的另一种形式，提供一种计算机可读存储介质，其上存储有指令，该指令被执行时实现上述方法实施例中第一集中控制器执行的方法。
作为本实施例的另一种形式，提供一种包含指令的计算机程序产品，该指令被执行时执行上述方法实施例中第一集中控制器执行的方法。
本领域技术人员可以理解，为了便于说明，图9中仅示出了一个存储器和处理器。在实际的控制器中，可以存在多个处理器和存储器。存储器也可以称为存储介质或者存储设备等，本申请实施例对此不做限制。
应理解，在本申请实施例中，处理器可以是中央处理单元(Central Processing Unit，简称CPU)，该处理器还可以是其他通用处理器、数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)、现成可编程门阵列(Field－Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。
还应理解，本发明实施例中提及的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(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)。
需要说明的是，当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)集成在处理器中。
应注意，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
该总线除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线。
还应理解，本文中涉及的第一、第二、第三、第四以及各种数字编号仅为描述方便进行的区分，并不用来限制本申请的范围。
应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种 情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
根据本申请实施例提供的方法，本申请实施例还提供一种系统，其包括前述的第一集中控制器和各种IO设备，进一步的还可以包括第二集中控制器等。
在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block，简称ILB)和步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质 可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘)等。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (14)

  1. 一种访问IO设备的方法，其特征在于，包括：
    第一集中控制器对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件；
    根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型；
    根据所述映射配置文件，将所述资源访问请求发送给所述第一IO设备。
  2. 根据权利要求1所述的方法，其特征在于，所述第一集中控制器对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件，包括：
    所述第一集中控制器根据应用访问的各种IO设备的类型，面向应用对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型；
    根据所述各种IO设备的物理端口，面向IO设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制IO设备的控制数据的转换关系。
  3. 根据权利要求2所述的方法，其特征在于，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
    所述方法还包括：
    所述第一集中控制器根据所述转换关系将所述第一标准化数据转换为所述第一IO设备对应的第一控制数据；
    将所述第一控制数据发送给所述第一IO设备。
  4. 根据权利要求2或3所述的方法，其特征在于，所述方法还包括：
    所述第一集中控制器接收所述第一IO设备上报的采样数据；
    根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
  5. 根据权利要求1-4任一项所述的方法，其特征在于，当所述第一集中控制器需要访问第二集中控制器下的第二IO设备时，所述资源访问请求中包括所述用户访问的第二IO设备的第二标准模型，所述方法还包括：
    所述第一集中控制器将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二IO设备。
  6. 一种访问IO设备的装置，其特征在于，包括：
    处理单元，用于对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件；根据用户的访问操作生成资源访问请求，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型；
    收发单元，用于根据所述映射配置文件，将所述资源访问请求发送给所述第一IO设备。
  7. 根据权利要求6所述的装置，其特征在于，所述处理单元具体用于：
    根据应用访问的各种IO设备的类型，面向应用对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型；
    根据所述各种IO设备的物理端口，面向IO设备进行物理端口的建模，并配置用于控制标准模型的标准化数据与控制IO设备的控制数据的转换关系。
  8. 根据权利要求7所述的装置，其特征在于，所述资源访问请求中还包括用于控制所述第一标准模型的第一标准化数据；
    所述处理单元还用于：
    根据所述转换关系将所述第一标准化数据转换为所述第一IO设备对应的第一控制数据；
    所述收发单元还用于将所述第一控制数据发送给所述第一IO设备。
  9. 根据权利要求7或8所述的装置，其特征在于，所述收发单元还用于：
    接收所述第一IO设备上报的采样数据；
    所述处理单元还用于根据所述转换关系将所述采样数据转换为所述第一标准模型对应的第二标准化数据。
  10. 根据权利要求7-9任一项所述的装置，其特征在于，当所述装置需要访问第二集中控制器下的第二IO设备时，所述资源访问请求中包括所述用户访问的第二IO设备的第二标准模型，所述收发单元还用于：
    将所述资源访问请求通过所述第一集中控制器与所述第二集中控制器之间的通信层链路，发送给所述第二IO设备。
  11. 一种访问IO设备的装置，其特征在于，包括：
    设备抽象层，用于对车辆上的各种IO设备进行对象化建模，生成所述各种IO设备的标准模型，并生成所述各种IO设备与标准模型的映射配置文件；
    应用层，用于根据用户的访问操作生成资源访问请求，将所述资源访问请求发送给所述设备抽象层，所述资源访问请求中包括所述用户访问的第一IO设备的第一标准模型；
    所述设备抽象层还用于将所述资源访问请求发送给通信层；
    所述通信层用于根据所述资源访问请求，通过收发器向驱动层发送控制命令，对IO设备进行输入输出的操作。
  12. 根据权利要求11所述的装置，其特征在于，
    所述驱动层，用于响应于所述控制命令，将所述输入输出的操作获取到的采样数据发送给所述通信层；
    所述通信层还用于将所述采样数据发送给所述设备抽象层；
    所述设备抽象层还用于将所述采样数据转换为与所述标准模型对应的标准化数据并发送给所述应用层。
  13. 一种访问IO设备的装置，其特征在于，包括：
    处理器、存储器和总线，所述处理器和存储器通过总线连接，其中，所述存储器用于存储一组程序代码，所述处理器用于调用所述存储器中存储的程序代码，执行如权利要求1-6任一项所述的方法。
  14. 一种计算机可读存储介质，其特征在于，包括：
    所述计算机可读存储介质中存储有指令，当其在计算机上运行时，实现如权利要求1-6任一项所述的方法。
PCT/CN2020/130639 2020-11-20 2020-11-20 一种访问io设备的方法及装置 WO2022104747A1 (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
CN202211117922.1A CN115489459A (zh) 2020-11-20 2020-11-20 一种访问io设备的方法及装置
JP2023530559A JP2023550936A (ja) 2020-11-20 2020-11-20 Ｉ／ｏデバイス・アクセス方法及び装置
PCT/CN2020/130639 WO2022104747A1 (zh) 2020-11-20 2020-11-20 一种访问io设备的方法及装置
EP20962038.4A EP4238832A4 (en) 2020-11-20 2020-11-20 METHOD AND APPARATUS FOR ACCESSING IO DEVICES
CN202080004241.7A CN112566819B (zh) 2020-11-20 2020-11-20 一种访问io设备的方法及装置
US18/320,597 US20230291604A1 (en) 2020-11-20 2023-05-19 I/O Device Access Method and Apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/130639 WO2022104747A1 (zh) 2020-11-20 2020-11-20 一种访问io设备的方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/320,597 Continuation US20230291604A1 (en) 2020-11-20 2023-05-19 I/O Device Access Method and Apparatus

Publications (1)

Publication Number Publication Date
WO2022104747A1 true WO2022104747A1 (zh) 2022-05-27

Family

ID=75034941

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/130639 WO2022104747A1 (zh) 2020-11-20 2020-11-20 一种访问io设备的方法及装置

Country Status (5)

Country Link
US (1) US20230291604A1 (zh)
EP (1) EP4238832A4 (zh)
JP (1) JP2023550936A (zh)
CN (2) CN115489459A (zh)
WO (1) WO2022104747A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120297379A1 (en) * 2011-05-17 2012-11-22 International Business Machines Corporation Vendor-independent resource configuration interface for self-virtualizing input/output device
CN103150152A (zh) * 2011-12-06 2013-06-12 广东新岸线计算机系统芯片有限公司 一种移动终端的外设电源管理方法和系统
CN109213143A (zh) * 2017-07-03 2019-01-15 百度（美国）有限责任公司 操作自动驾驶车辆的使用事件循环的集中调度系统
CN111949037A (zh) * 2020-08-26 2020-11-17 北京享云智汇科技有限公司 一种网联车自动驾驶系统及方法

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6434459B2 (en) * 1996-12-16 2002-08-13 Microsoft Corporation Automobile information system
US6055493A (en) * 1997-01-29 2000-04-25 Infovista S.A. Performance measurement and service quality monitoring system and process for an information system
JP3460593B2 (ja) * 1998-09-17 2003-10-27 株式会社デンソー 車両用制御装置
US7013250B2 (en) * 2000-03-14 2006-03-14 Honda Giken Kogyo Kabushiki Kaisha Simulator for automatic vehicle transmission controllers
DE10015114A1 (de) * 2000-03-28 2001-10-04 Bosch Gmbh Robert Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug
CA2354837C (en) * 2000-08-11 2005-01-04 Honda Giken Kogyo Kabushiki Kaisha Simulator for automatic vehicle transmission controllers
DE10137632A1 (de) * 2001-08-03 2003-02-27 Daimler Chrysler Ag Verfahren und System zum Auffinden eines Ortes in einer digitalen Karte
DE10206902A1 (de) * 2002-02-19 2003-09-11 Siemens Ag Engineeringverfahren und Engineeringsystem für industrielle Automatisierungssysteme
KR100611098B1 (ko) * 2003-12-12 2006-08-09 한국전자통신연구원 인터페이스 표준 모델을 이용한 위성 시뮬레이션 모델링시스템
CN100399274C (zh) * 2005-09-19 2008-07-02 联想(北京)有限公司 一种虚拟机系统输入/输出设备动态分配的方法及其设备
DE112009000155T5 (de) * 2008-01-24 2010-12-02 Autonetworks Technologies, Ltd., Yokkaichi-shi Einrichtungssteuervorrichtung und Einrichtungssteuerprogramm
TW200941350A (en) * 2008-03-18 2009-10-01 Wistron Corp Virtual interfacing device and related method for controlling the same
US8838332B2 (en) * 2009-10-15 2014-09-16 Airbiquity Inc. Centralized management of motor vehicle software applications and services
JP5406072B2 (ja) * 2010-02-18 2014-02-05 株式会社日立製作所 組込み制御装置
CN102136933B (zh) * 2010-09-30 2013-08-28 华为技术有限公司 设备管理方法、中间件及机器通信平台、设备和系统
US8955037B2 (en) * 2011-05-11 2015-02-10 Oracle International Corporation Access management architecture
JP5810205B1 (ja) * 2014-04-11 2015-11-11 松尾アソシエイト株式会社 車両運行管理システム
CN105610904B (zh) * 2015-12-17 2018-12-18 四川物联亿达科技有限公司 一种统一接入设备的接入服务系统
US10691852B2 (en) * 2016-07-14 2020-06-23 Stefanie Pulfer Model based analysis and control of a real-world system
CN107229584B (zh) * 2017-06-01 2020-03-13 西南电子技术研究所（中国电子科技集团公司第十研究所） 航空电子仿真测试平台i/o管理系统
EP3456577B1 (en) * 2017-09-13 2022-01-26 LG Electronics Inc. User interface apparatus for vehicle
CN109474912B (zh) * 2018-04-10 2022-02-18 西南大学 一种车载网关系统以及车载子系统的监控方法和装置
CN108770016B (zh) * 2018-06-04 2019-07-05 北京邮电大学 基于模板的5g端到端网络切片生成方法及装置
WO2019236755A1 (en) * 2018-06-06 2019-12-12 Intel Corporation Vehicle-to-everything session and service continuity in automotive edge computing systems
WO2020059957A1 (ko) * 2018-09-17 2020-03-26 주식회사 드림에이스 차량용 소프트웨어 제어 장치
DE102019217046A1 (de) * 2019-11-06 2021-06-17 Robert Bosch Gmbh System zum Austausch von Nachrichten durch eine Anwendungssoftware
CN111787049A (zh) * 2020-05-09 2020-10-16 苏州中科中霖电子科技有限公司 一种基于设备对象的物联网设备管理方法与系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120297379A1 (en) * 2011-05-17 2012-11-22 International Business Machines Corporation Vendor-independent resource configuration interface for self-virtualizing input/output device
CN103150152A (zh) * 2011-12-06 2013-06-12 广东新岸线计算机系统芯片有限公司 一种移动终端的外设电源管理方法和系统
CN109213143A (zh) * 2017-07-03 2019-01-15 百度（美国）有限责任公司 操作自动驾驶车辆的使用事件循环的集中调度系统
CN111949037A (zh) * 2020-08-26 2020-11-17 北京享云智汇科技有限公司 一种网联车自动驾驶系统及方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4238832A4 *

Also Published As

Publication number Publication date
CN112566819A (zh) 2021-03-26
JP2023550936A (ja) 2023-12-06
EP4238832A4 (en) 2023-12-06
EP4238832A1 (en) 2023-09-06
US20230291604A1 (en) 2023-09-14
CN115489459A (zh) 2022-12-20
CN112566819B (zh) 2022-09-16

Similar Documents

Publication Publication Date Title
WO2020216235A1 (zh) 车载网关的通信方法、车载网关及智能车辆
CN110535740B (zh) 信号处理方法、装置、存储介质及终端
US11972247B2 (en) Software upgrading method, apparatus, and system
EP2541846B1 (en) Communication method of gateway device supporting CAN - and Modbus protocol conversion and gateway device using the same
CN114268666A (zh) 支持面向服务架构soa的通用域控制器、车辆及交互系统
CN113141306A (zh) 一种诊断报文路由方法及其总线路由设备
JP2012530395A (ja) 車両通信インタフェース及びその作動方法
CN110497920A (zh) 信号处理方法、装置及系统
CN113191652A (zh) 一种基于以太网的车载信息交互系统
US11505139B2 (en) Method for providing sensor-based vehicle functions in a motor vehicle, and motor vehicle computing device and motor vehicle
KR20210064380A (ko) 자동차 전자 제어 기능을 실행하기 위한 시스템 및 방법, 및 자동차
CN114545906A (zh) 车载以太网网关及车辆
EP4235402A1 (en) Parameter configuration method, apparatus and system
WO2022104747A1 (zh) 一种访问io设备的方法及装置
CN114253182A (zh) 一种车辆的控制方法、系统及车辆
CN115567895A (zh) Ota软件更新数据传输方法及系统
US20210291763A1 (en) System and Method for Implementing Automobile Electronic Control Function
CN102923127A (zh) 一种电机控制器的标定系统以及混合动力汽车
CN117336113A (zh) 车辆控制系统的通信方法及相关装置
WO2023051057A1 (zh) 芯片升级方法及装置
EP4350511A1 (en) Method and apparatus for co-simulation
JP2024530431A (ja) オーバーザエア（ｏｔａ）アップグレード方法および装置
US20240273042A1 (en) Method and Apparatus for Accessing Vehicle Resource and Vehicle Controller
WO2024221404A1 (zh) 升级方法及相关装置
US20240140452A1 (en) Control method and apparatus

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20962038

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023530559

Country of ref document: JP

ENP Entry into the national phase

Ref document number: 2020962038

Country of ref document: EP

Effective date: 20230530

NENP Non-entry into the national phase

Ref country code: DE