Automatic mapping and protocol conversion system and method from hardware signal to service

Abstract

The invention discloses an automatic mapping and protocol conversion system and method from a hardware signal to a service, and relates to the technical field of hardware and software collaborative design, the system comprises a signal-to-service mapping module, a gateway layer protocol conversion module and a hardware abstraction module; a signal-to-service mapping module imports a DBC file to analyze CAN signal attributes, automatically generates SOME / IP interface definition, maps a periodic signal into an Event interface, maps a trigger signal into a Method interface, and optimizes and merges associated signals; the gateway layer protocol conversion module is deployed on a vehicle-mounted gateway to realize bidirectional conversion between a CAN signal and an Ethernet message; the hardware abstraction module hides hardware details, provides a standardized signal interface and supports plug and play of a sensor / actuator. According to the method, the problems of low manual mapping efficiency, poor compatibility, insufficient real-time performance and the like in the vehicle-mounted heterogeneous network are solved, the software and hardware collaborative development efficiency and the system expansibility are improved, and the method is suitable for scenes such as an intelligent automobile multi-domain controller and a central gateway.

Description

Technical Field

[0001] This invention relates to the field of hardware and software co-design technology, and in particular to an automated mapping and protocol conversion system and method for hardware signals to services. Background Technology

[0002] With the rapid development of automotive electronics technology towards intelligence and connectivity, the in-vehicle network architecture is evolving from the traditional distributed CAN bus architecture to a centralized Ethernet architecture, forming a heterogeneous network environment where multiple buses and protocols such as CAN, LIN, and Ethernet coexist. In this environment, signals generated by hardware devices (such as various sensors and actuators) need to interface with software services to realize various vehicle control functions and intelligent applications.

[0003] In existing technologies, the interface between hardware signals and software services mainly relies on engineers manually configuring mapping rules, that is, manually writing the mapping relationship from the CAN database (DBC) to SOME / IP (Automotive Ethernet Protocol) to convert hardware signals into an interface that the software service can recognize. However, this method has many drawbacks:

[0004] First, manual mapping is inefficient and has a high error rate. A smart car can have thousands of CAN signals. Manually writing mapping rules requires a lot of manpower and time, and is prone to problems such as signal ID matching errors and data type conversion errors. According to statistics, the error rate is as high as 15%-20%. At the same time, with the iteration and upgrading of vehicle models, the maintenance cost of mapping rules increases exponentially.

[0005] Secondly, heterogeneous hardware has poor compatibility. Hardware devices from different manufacturers use different communication protocols, data formats, and interface standards. Software services need to be customized for specific hardware. When hardware devices are replaced or hardware versions are upgraded, software services need to be re-adapted, making it impossible to achieve plug-and-play functionality and severely restricting the system's scalability.

[0006] Secondly, the real-time performance of protocol conversion is insufficient. Existing gateway layer signal conversion mostly uses general protocol stacks and has not been optimized for the real-time requirements of automotive scenarios. The conversion delay between CAN signals and Ethernet messages usually exceeds 100ms, which cannot meet the high real-time requirements of scenarios such as autonomous driving and active safety control.

[0007] Finally, the exposure of hardware details leads to high coupling between software and hardware. Software services directly depend on the specific characteristics of the hardware interface, such as register addresses and baud rates. When hardware devices are upgraded or replaced, software services need to be modified extensively or even redeveloped, which violates the software design principle of "high cohesion and low coupling" and increases development and maintenance costs. Summary of the Invention

[0008] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes an automated mapping and protocol conversion system and method for hardware signals to services.

[0009] In a first aspect, embodiments of the present invention provide an automated mapping and protocol conversion system for hardware signals to services, comprising:

[0010] The module consists of a signal-to-service mapping module, a gateway layer protocol conversion module, and a hardware abstraction module; among which:

[0011] The signal-to-service mapping module is used to import DBC files, parse the attribute information of CAN signals, and automatically map and generate SOME / IP interface definitions based on the attribute information.

[0012] The gateway layer protocol conversion module, deployed on the vehicle gateway, is used to realize bidirectional conversion between CAN signals and Ethernet messages according to the SOME / IP interface definition generated by the signal-to-service mapping module.

[0013] The hardware abstraction module, including device agents, driver managers, and plug-and-play managers, is used to hide the low-level details of hardware devices and provide standardized signal interfaces to the upper layers.

[0014] Furthermore, the SOME / IP interface definition is automatically generated based on the attribute information. The specific method includes mapping periodic CAN signals to Event interfaces and trigger-type CAN signals to Method interfaces.

[0015] Furthermore, the signal-to-service mapping module also includes a rule optimizer, which is used to identify associated signals from the same ECU or the same functional domain and merge the associated signals into a composite interface.

[0016] Furthermore, the SOME / IP interface definition generated by the signal-to-service mapping module is output as an ARXML format file. The ARXML format file conforms to the AUTOSAR standard and includes the service interface name, version, event interface definition, method interface definition, and data type mapping information.

[0017] Furthermore, the gateway layer protocol conversion module includes a CAN signal receiver / transmitter, a SOME / IP protocol stack, a conversion engine, and a priority queue; the CAN signal receiver / transmitter is used to receive CAN signals from hardware devices or send converted CAN signals to the actuator; the SOME / IP protocol stack is used to process Ethernet packet encapsulation, decapsulation, service discovery, and packet routing; the conversion engine is used to perform data format conversion, timing control, and error handling for signals and packets; and the priority queue is used to process high-priority signals.

[0018] Furthermore, the conversion engine employs a lookup table method to achieve fast mapping between signals and messages. This lookup table method is based on a predefined mapping rule table, which includes CAN signal ID, data length, SOME / IP service ID, event ID, method ID, and the correspondence between source and target data types, thereby achieving time complexity conversion.

[0019] Furthermore, the plug-and-play manager of the hardware abstraction module automatically identifies the hardware type by reading the hardware device descriptor, and the driver manager loads the matching device driver according to the identification result; the device agent provides a proxy instance for each hardware device, which is responsible for signal acquisition and conversion, and after converting the acquired signal into a standardized format, it is transmitted to the service mapping module.

[0020] Furthermore, the device agent of the hardware abstraction module provides standardized Init, ReadSignal, WriteSignal, and GetDeviceInfo interfaces, and the software service accesses the hardware device by calling the standardized interfaces.

[0021] Secondly, the present invention also discloses an automated mapping method for hardware signals to services based on the system, comprising the following steps:

[0022] Import the DBC file and parse the attribute information of the CAN signal. The attribute information includes the CAN signal ID, data type, period, maximum and minimum values, and the information of the ECU to which it belongs.

[0023] The interface type is mapped according to the period attribute of the CAN signal. When the period is greater than 0, it is mapped to the Event interface, and when the period is equal to 0, it is mapped to the Method interface.

[0024] Identify associated signals from the same ECU or the same functional domain, and merge the associated signals into a composite interface;

[0025] Generate SOME / IP interface definition files that conform to the AUTOSAR standard for protocol conversion at the gateway layer.

[0026] This invention also discloses a gateway layer protocol conversion method based on the system, including forward conversion and reverse conversion, wherein:

[0027] The forward conversion process includes: the CAN signal receiver / transmitter receives the CAN signal, the conversion engine converts the data format of the CAN signal according to the mapping rule table, and encapsulates the converted signal into a SOME / IP message containing the service ID, event ID and payload, and publishes it through the SOME / IP protocol stack;

[0028] The reverse conversion process includes: the SOME / IP protocol stack receiving the SOME / IP service request from the application layer, the conversion engine parsing the service request to obtain the corresponding parameter information, converting the parameter information into a CAN signal, and sending it to the corresponding actuator according to the signal ID through the CAN signal receiver / transmitter.

[0029] This invention discloses an automated hardware signal-to-service mapping and protocol conversion system. The system includes a signal-to-service mapping module, a gateway layer protocol conversion module, and a hardware abstraction module. The signal-to-service mapping module imports DBC files to parse CAN signal attributes, automatically generates SOME / IP interface definitions, maps periodic signals to Event interfaces and triggered signals to Method interfaces, and optimizes and merges associated signals. The gateway layer protocol conversion module is deployed on the vehicle gateway to achieve bidirectional conversion between CAN signals and Ethernet messages. The hardware abstraction module hides hardware details, provides standardized signal interfaces, and supports plug-and-play functionality for sensors / actuators. This invention solves the problems of low efficiency, poor compatibility, and insufficient real-time performance of manual mapping in heterogeneous vehicle networks, improves the efficiency of software and hardware collaborative development and system scalability, and is suitable for scenarios such as intelligent vehicle multi-domain controllers and central gateways. Attached Figure Description

[0030] Figure 1 This invention provides a structural block diagram of an automated hardware signal-to-service mapping and protocol conversion system according to an embodiment of the invention.

[0031] Figure 2 This is a schematic diagram of the automated mapping method from hardware signals to services provided in the embodiments of the present invention;

[0032] Figure 3 This is a schematic diagram of the gateway layer protocol conversion method of the system provided in the embodiments of the present invention;

[0033] Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0034] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0035] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0036] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0037] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0038] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0039] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0040] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides an automated mapping and protocol conversion system and method for hardware signals to services.

[0041] This embodiment provides an automated hardware signal-to-service mapping and protocol conversion system, such as Figure 1 It includes: a signal-to-service mapping module, a gateway layer protocol conversion module, and a hardware abstraction module; among which:

[0042] The signal-to-service mapping module is used to import DBC files, parse the attribute information of CAN signals, and automatically generate SOME / IP interface definitions based on the attribute information. In this embodiment, the automatic generation of SOME / IP interface definitions based on the attribute information specifically includes mapping periodic CAN signals to Event interfaces and trigger-type CAN signals to Method interfaces. The SOME / IP interface definitions generated by the signal-to-service mapping module are output as ARXML format files. The ARXML format files conform to the AUTOSAR standard and include service interface names, versions, Event interface definitions, Method interface definitions, and data type mapping information.

[0043] In this embodiment, the signal-to-service mapping module includes a DBC parser and an interface generator. The DBC parser is used to import the CAN bus database file (DBC) and the CAN network matrix (CANMatrix), and extract the complete attribute parameters of the CAN signals, including key information such as signal name, ID, data type, period, maximum and minimum values, sender, and receiver. The interface generator is used to automatically generate a service interface definition file (ARXML) based on the SOME / IP protocol according to preset mapping rules. The ARXML file follows the AUTOSAR standard and contains service interface name, version, event ID, method ID, data type, and communication parameters. The mapping rules strictly follow the principle that periodic CAN signals correspond to Event interfaces (subscribe-publish mode) and triggered CAN signals correspond to Method interfaces.

[0044] In some preferred embodiments, the signal-to-service mapping module further includes a rule optimizer for identifying associated signals from the same ECU or the same functional domain and merging the associated signals into a composite interface.

[0045] The gateway layer protocol conversion module, deployed on the vehicle gateway, is used to realize bidirectional conversion between CAN signals and Ethernet messages according to the SOME / IP interface definition generated by the signal-to-service mapping module.

[0046] In this embodiment, the gateway layer protocol conversion module includes a CAN signal receiver / transmitter, a SOME / IP protocol stack, a conversion engine, and a priority queue. The CAN signal receiver / transmitter is used to receive CAN signals from hardware devices or send converted CAN signals to the actuator. The SOME / IP protocol stack is used to process Ethernet packet encapsulation, decapsulation, service discovery, and packet routing. The conversion engine is used to perform data format conversion, timing control, and error handling for signals and packets. The priority queue is used to process high-priority signals.

[0047] In this embodiment, the conversion engine uses a lookup table method to achieve fast mapping between signals and messages. The lookup table method is based on a predefined mapping rule table, which includes CAN signal ID, data length, SOME / IP service ID, event ID, method ID, and source / target data type correspondence, thereby achieving time complexity conversion.

[0048] Specifically, the gateway layer protocol conversion module is deployed on the vehicle gateway (such as NXPS32G, TI Jacinto7, and other hardware platforms) to achieve bidirectional and efficient conversion between CAN signals and Ethernet messages, supporting real-time and reliability requirements. Its specific composition and conversion logic are as follows:

[0049] CAN signal receiver / transmitter: Connected to the CAN bus via the CAN controller, it is responsible for receiving CAN signals sent by hardware sensors or sending CAN control signals after inversion to the actuator; for LIN bus devices, it is connected to the module for signal conversion after being adapted by the hardware abstraction module.

[0050] SOME / IP protocol stack: Follows the SOME / IP protocol standard, handles Ethernet packet encapsulation, decapsulation, service discovery and packet routing, and supports the publication and invocation of SOA services;

[0051] The conversion engine has a built-in mapping rule table and priority queue. The mapping rule table is generated by the signal-to-service mapping module and uses a lookup table method to achieve fast signal mapping with O(1) time complexity. The priority queue allocates processing priority according to the importance of the signal, and core security signals are processed first. The conversion engine performs data format conversion, timing control and error handling. Data format conversion supports accurate conversion of various types such as integers and floating-point numbers with different bit lengths. Timing control ensures that the signal release frequency meets the requirements of the SOME / IP protocol. The error handling mechanism automatically fills in the default value and sends a fault notification when the signal is lost.

[0052] The hardware abstraction module, including a device agent, a driver manager, and a plug-and-play manager, hides the low-level details of hardware devices and provides standardized signal interfaces to the upper layers. In this embodiment, the plug-and-play manager of the hardware abstraction module automatically identifies the hardware type by reading the hardware device's descriptor, and the driver manager loads the matching device driver based on the identification result. The device agent provides a proxy instance for each type of hardware device, responsible for signal acquisition and conversion, converting the acquired signals into a standardized format and then passing the signals to the service mapping module. The device agent of the hardware abstraction module provides standardized Init, ReadSignal, WriteSignal, and GetDeviceInfo interfaces, which software services call to access hardware devices.

[0053] Specifically, the device agent is used to provide a dedicated agent instance for each hardware device (such as CAN sensor, LIN actuator, Ethernet camera, etc.), realize the unified abstraction of hardware devices, and be responsible for signal acquisition, conversion and transmission, converting the raw hardware signals into standardized format (structured data containing information such as signal name, value, timestamp, data type, etc.).

[0054] The driver manager is responsible for the entire lifecycle management of device drivers, including driver loading, unloading, version control and status monitoring. When a driver encounters an error, it will automatically restart and reinitialize the device.

[0055] The Plug and Play Manager automatically identifies the hardware type by reading the hardware device descriptors (such as the VID / PID of a USB device, and the manufacturer ID and device ID of a CAN sensor), triggering the driver manager to load the matching device driver, thus supporting hot-swapping of hardware devices.

[0056] Based on the same inventive concept, embodiments of the present invention also provide an automated mapping method for hardware signals to services based on the system, such as... Figure 2 This includes the following steps:

[0057] S101. Import the DBC file and parse the attribute information of the CAN signal. The attribute information includes the ID, data type, period, maximum and minimum values ​​of the CAN signal and the information of the ECU to which it belongs.

[0058] S102. Map the interface type according to the period attribute of the CAN signal. When the period is greater than 0, it is mapped to the Event interface, and when the period is equal to 0, it is mapped to the Method interface.

[0059] S103. Identify associated signals from the same ECU or the same functional domain, and merge the associated signals into a composite interface;

[0060] S104. Generate a SOME / IP interface definition file conforming to the AUTOSAR standard for protocol conversion at the gateway layer.

[0061] In some preferred embodiments, the present invention also provides a gateway layer protocol conversion method based on the system, such as... Figure 3 This includes forward conversion and reverse conversion, where:

[0062] S201. The forward conversion process includes: the CAN signal receiver / transmitter receives the CAN signal, the conversion engine performs data format conversion on the CAN signal according to the mapping rule table, and encapsulates the converted signal into a SOME / IP message containing the service ID, event ID and payload, and publishes it through the SOME / IP protocol stack;

[0063] S202. The reverse conversion process includes: the SOME / IP protocol stack receives the SOME / IP service request from the application layer, the conversion engine parses the service request to obtain the corresponding parameter information, converts the parameter information into a CAN signal, and sends it to the corresponding actuator according to the signal ID through the CAN signal receiver / transmitter.

[0064] To better understand the system disclosed in this implementation, the following explanation uses an in-vehicle system based on the NXPS32G gateway as an example.

[0065] The hardware and software selections for the NXPS32G gateway's in-vehicle system are as follows:

[0066] I. Hardware Environment

[0067] Gateway chip: NXPS32G274A, which includes 2 CANFD controllers, 2 Gigabit Ethernet interfaces, and supports multi-bus protocol conversion;

[0068] Sensor: A millimeter-wave radar connected to the CAN bus, used to collect distance signals between the vehicle and obstacles. The signal transmission period is 50ms, the CAN signal ID is 0x3A0, and the data type is a 16-bit unsigned integer.

[0069] Actuator: The window controller connected via LIN bus is used to receive window lifting control signals and perform window position adjustment functions.

[0070] II. Software Configuration

[0071] Signal-to-Service Mapping Module: Imports the DBC file corresponding to the millimeter-wave radar, parses and extracts the attribute parameters of the distance signal (signal name: radar_distance, ID=0x3A0, data type: UInt16, period=50ms), generates a SOME / IP interface definition file (ARXML) according to the mapping rules, and maps the distance signal to the Event interface (service ID=0x300, event ID=0x01, data type converted to Float32).

[0072] Gateway layer protocol conversion module: Configure the priority queue of the conversion engine, set the millimeter-wave radar distance signal as high priority, enter the correspondence between CAN signal ID=0x3A0 and SOME / IP service ID=0x300 and event ID=0x01 in the mapping rule table, and the data format conversion rule is UInt16→Float32;

[0073] Hardware abstraction module: The driver manager loads the millimeter-wave radar driver (can_radar_v2.1.ko) and the window controller driver (lin_window_v1.0.ko), and the millimeter-wave radar agent and the window controller agent complete the initialization configuration.

[0074] III. Operation Process

[0075] Forward conversion process:

[0076] The millimeter-wave radar sends CAN signals at a 50ms cycle, with signal ID=0x3A0 and data value=0x0064 (corresponding to a decimal distance of 100m).

[0077] The millimeter-wave radar agent of the hardware abstraction module acquires the CAN signal and converts it into standardized JSON format data.

[0078] The standardized signal is transmitted to the signal-to-service mapping module, which confirms that the mapping relationship is the Event interface (service ID=0x300, event ID=0x01).

[0079] The CAN signal receiver of the gateway layer protocol conversion module receives the raw CAN signal. The conversion engine parses the signal attributes according to the mapping rule table, performs data format conversion from UInt16 to Float32, and converts the data value 0x0064 to 100.0.

[0080] The SOME / IP protocol stack encapsulates the converted data into a SOME / IPEvent message, which includes Service ID=0x300, Event ID=0x01 and payload data 100.0, and sends it to the autonomous driving application layer service via Ethernet.

[0081] The autonomous driving application layer service receives and parses the SOME / IP message to obtain the millimeter-wave radar distance signal value of 100.0m, which is used for path planning and collision warning.

[0082] Reverse conversion process:

[0083] The application layer service initiates a window lift control request by calling the Method interface (Service ID=0x400, Method ID=0x02) and passing in the parameter "window position 50%".

[0084] The SOME / IP protocol stack receives the service request, decapsulates it, and transmits it to the conversion engine.

[0085] According to the mapping rule table, the conversion engine maps service ID=0x400 and method ID=0x02 to CAN signal ID=0x4B0, and converts 50% of the parameters into CAN signal data 0x32 (16-bit unsigned integer).

[0086] The CAN signal transmitter sends the CAN signal to the window controller via the LIN bus adapter;

[0087] After receiving the CAN signal, the window controller performs the corresponding operation, adjusting the window to the 50% position, and feeding back the execution result through the reverse path.

[0088] This embodiment discloses an automated hardware signal-to-service mapping and protocol conversion system. The system includes a signal-to-service mapping module, a gateway layer protocol conversion module, and a hardware abstraction module. The signal-to-service mapping module imports DBC files to parse CAN signal attributes, automatically generates SOME / IP interface definitions, maps periodic signals to Event interfaces, and trigger-based signals to Method interfaces, optimizing and merging associated signals. The gateway layer protocol conversion module is deployed on the vehicle gateway to achieve bidirectional conversion between CAN signals and Ethernet messages. The hardware abstraction module hides hardware details, provides standardized signal interfaces, and supports plug-and-play functionality for sensors / actuators. This invention solves the problems of low efficiency, poor compatibility, and insufficient real-time performance of manual mapping in heterogeneous vehicle networks, improves the efficiency of software and hardware collaborative development and system scalability, and is suitable for scenarios such as intelligent vehicle multi-domain controllers and central gateways.

[0089] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 4 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0090] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0091] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0092] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0093] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the methods described in the above embodiments. The computer-readable storage medium may be a volatile or non-volatile computer-readable storage medium.

[0094] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described method.

[0095] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0096] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0097] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0098] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0099] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0100] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0101] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0102] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0103] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0104] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. An automated mapping and protocol conversion system for hardware signals to services, characterized in that, include: The module consists of a signal-to-service mapping module, a gateway layer protocol conversion module, and a hardware abstraction module; among which: The signal-to-service mapping module is used to import DBC files, parse the attribute information of CAN signals, and automatically map and generate SOME / IP interface definitions based on the attribute information. The gateway layer protocol conversion module, deployed on the vehicle gateway, is used to realize bidirectional conversion between CAN signals and Ethernet messages according to the SOME / IP interface definition generated by the signal-to-service mapping module. The hardware abstraction module, including device agents, driver managers, and plug-and-play managers, is used to hide the low-level details of hardware devices and provide standardized signal interfaces to the upper layers.

2. The automated mapping and protocol conversion system according to claim 1, characterized in that, The SOME / IP interface definition is automatically generated based on the attribute information. The specific methods include mapping periodic CAN signals to Event interfaces and trigger-type CAN signals to Method interfaces.

3. The automated mapping and protocol conversion system according to claim 1, characterized in that, The signal-to-service mapping module also includes a rule optimizer, which is used to identify associated signals from the same ECU or the same functional domain and merge the associated signals into a composite interface.

4. The automated mapping and protocol conversion system according to claim 1, characterized in that, The SOME / IP interface definition generated by the signal-to-service mapping module is output in ARXML format. The ARXML format file conforms to the AUTOSAR standard and includes service interface name, version, event interface definition, method interface definition and data type mapping information.

5. The automated mapping and protocol conversion system according to claim 1, characterized in that, The gateway layer protocol conversion module includes a CAN signal receiver / transmitter, a SOME / IP protocol stack, a conversion engine, and a priority queue. The CAN signal receiver / transmitter is used to receive CAN signals from hardware devices or send converted CAN signals to the actuator. The SOME / IP protocol stack is used to process Ethernet packet encapsulation, decapsulation, service discovery, and packet routing. The conversion engine is used to perform data format conversion, timing control, and error handling for signals and packets. The priority queue is used to process high-priority signals.

6. The automated mapping and protocol conversion system according to claim 5, characterized in that, The conversion engine uses a lookup table method to achieve fast mapping between signals and messages. The lookup table method is based on a predefined mapping rule table, which includes CAN signal ID, data length, SOME / IP service ID, event ID, method ID, and source / target data type correspondence, thus achieving time complexity conversion.

7. The automated mapping and protocol conversion system according to claim 1, characterized in that, The plug-and-play manager of the hardware abstraction module automatically identifies the hardware type by reading the hardware device descriptor, and the driver manager loads the matching device driver according to the identification result; the device agent provides a proxy instance for each hardware device, which is responsible for signal acquisition and conversion, and after converting the acquired signal into a standardized format, it is transmitted to the service mapping module.

8. The automated mapping and protocol conversion system according to claim 1, characterized in that, The hardware abstraction module's device agent provides standardized Init, ReadSignal, WriteSignal, and GetDeviceInfo interfaces, through which software services access hardware devices.

9. An automated mapping method for hardware signals to services based on the system according to any one of claims 1-8, characterized in that, Includes the following steps: Import the DBC file and parse the attribute information of the CAN signal. The attribute information includes the CAN signal ID, data type, period, maximum and minimum values, and the information of the ECU to which it belongs. The interface type is mapped according to the period attribute of the CAN signal. When the period is greater than 0, it is mapped to the Event interface, and when the period is equal to 0, it is mapped to the Method interface. Identify associated signals from the same ECU or the same functional domain, and merge the associated signals into a composite interface; Generate SOME / IP interface definition files that conform to the AUTOSAR standard for protocol conversion at the gateway layer.

10. A gateway layer protocol conversion method based on the system according to any one of claims 1-8, characterized in that, This includes forward conversion and reverse conversion, where: The forward conversion process includes: the CAN signal receiver / transmitter receives the CAN signal, the conversion engine converts the data format of the CAN signal according to the mapping rule table, and encapsulates the converted signal into a SOME / IP message containing the service ID, event ID and payload, and publishes it through the SOME / IP protocol stack; The reverse conversion process includes: the SOME / IP protocol stack receiving the SOME / IP service request from the application layer, the conversion engine parsing the service request to obtain the corresponding parameter information, converting the parameter information into a CAN signal, and sending it to the corresponding actuator according to the signal ID through the CAN signal receiver / transmitter.

Images