Adaptation method and apparatus for control device, and storage medium
By transmitting private messages between the vehicle model switcher and the control device, the problem of matching configuration data of ECUs across different vehicle models was solved, the compatibility of common software packages was achieved, R&D costs were reduced, and production efficiency was improved.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- YINWANG INTELLIGENT TECHNOLOGIES CO LTD
- Filing Date
- 2024-12-10
- Publication Date
- 2026-06-18
Smart Images
Figure CN2024138065_18062026_PF_FP_ABST
Abstract
Description
Adaptation method and device of control equipment, storage medium TECHNICAL FIELD
[0001] The present application relates to the technical field of vehicles, in particular to an adaptation method and device of control equipment, and a storage medium. BACKGROUND
[0002] With the development of automobile intelligence, the vehicle-mounted electronic control unit (ECU) undertakes more and more software functions, and current vehicle production is mostly based on vehicle models for development to quickly launch vehicle models to meet market demand. Each vehicle model generally has many differences (such as one or more of control parameters, communication matrix, and electrical / electronic architecture (EE)), thus requiring many differentiated development needs for vehicle component ECUs. Among them, for independent ECUs (such as intelligent driving domain controllers), more and more vehicle models need to be adapted, thus providing independent components (software and hardware) for each vehicle model will bring great research and development costs.
[0003] Currently, a common trunk (i.e., a common code branch) development software development strategy is adopted to maximize the reuse of the same code, implement multi-vehicle common hardware and software delivery, and achieve ECU-level platform delivery by generating unified components to reduce inventory and production spare parts processes, thus having good economic benefits. Among them, the common hardware and software support multi-vehicle development mode, and the industry generally separates software and data, i.e., carrying multiple sets of vehicle model configuration data in a set of software. The multiple sets of vehicle model configuration data are used in combination with the set of software to achieve corresponding functions.
[0004] Currently, the same set of software carries multiple sets of configuration data, which needs to be switched to a specific vehicle model on the vehicle production line. The specific implementation is that, in the ECU electrical inspection link, a configuration word is written through a unified diagnostic services (UDS) diagnostic instrument, the ECU parses the configuration word and selects the correct vehicle model configuration data from the multiple sets of vehicle model configuration data. Since the ECU needs to be configured through the UDS, the bearing link, diagnostic logic address, and diagnostic secret key of the UDS must be the same as the ECU, otherwise the UDS cannot access the ECU, causing the configuration data of the ECU and the vehicle to be mismatched, so that the ECU cannot work correctly. SUMMARY
[0005] The present application discloses an adaptation method and device of control equipment, and a storage medium, which can realize normal use of a common software package by the control equipment.
[0006] In a first aspect, embodiments of this application provide a method for adapting a control device, applied to a vehicle control device. The control device includes first software installed and stores configuration data corresponding to various vehicle types. The first software supports combinations with the configuration data corresponding to the various vehicle types to adapt to different vehicle types. The method includes: the control device receiving a first message from a vehicle model switcher using a first communication medium, the first message indicating a first vehicle type. The first message is sent by the vehicle model switcher in a broadcast or multicast format, and its format is compatible with the first communication medium. The control device is connected to the vehicle model switcher via the first communication medium. Based on the first message, the control device further determines target configuration data to be combined with the first software, the target configuration data being configuration data corresponding to a first vehicle type, which belongs to the aforementioned various vehicle types.
[0007] In this embodiment, the vehicle model switcher uses a first communication medium to send a first message to the control device in a broadcast or multicast manner. This first message indicates the first vehicle type. Based on the first message, the control device determines the target configuration data currently combined with the first software to achieve the corresponding function of the first software. Data transmission between the vehicle model switcher and the control device is based on private messages. This solves the problem in the prior art where the UDS bearer link, diagnostic logic address, and diagnostic key must be identical to those of the ECU to enable UDS access to the ECU, thus expanding the scope of shared hardware and software.
[0008] In one possible implementation, the first communication medium is any of the following: controller area network (CAN), Ethernet (ETH), or CAN flexible data-rate (CANFD).
[0009] In one possible implementation, the target configuration data includes at least one of the following: application list, network configuration, UDS configuration, key and certificate, vehicle control parameters, sensor configuration parameters, and communication matrix.
[0010] The application list refers to the list of launched programs. Network configuration includes, for example, Ethernet IP addresses, media access control addresses (MAC addresses), and virtual local area networks (VLANs). UDS configuration refers to UDS protocol parameters, logical addresses, identification (ID) definitions, alarm code definitions, and routine definitions. Keys and certificates refer to the keys and certificates used for encryption. Vehicle control parameters may include, for example, vehicle length, width, wheelbase, weight, and dynamic parameters corresponding to different control algorithms. Sensor configuration parameters may include, for example, sensor type, number, port, Internet Protocol (IP) address, and installation location. The communication matrix refers to the complete set of communication messages between the ECU and other vehicle components, such as a CAN communication matrix or an ETH communication matrix.
[0011] In one possible implementation, the vehicle model switcher includes a first module and a second module, the second module being located within the vehicle and connected to each other. The second module is connected to a control device via a first communication medium. The control device uses the first communication medium to receive a first message from the second module, the first message being derived by the second module based on data from the first module.
[0012] In this example, the vehicle model switcher includes a first module and a second module, with the second module located inside the vehicle. This allows for message transmission based on existing vehicle modules, offering great flexibility and convenience.
[0013] Optionally, the first module can be a device that can be connected to the vehicle. For example, the first module can be a diagnostic tool, etc. The second module can be another vehicle ECU that is connected to the control equipment. For example, the second module can be an on-board gateway, etc.
[0014] In another possible implementation, the vehicle model switcher is located outside the vehicle and is a device that supports communication via a first communication medium.
[0015] In this example, the vehicle model switcher is a standalone module. This allows for pre-operation without being installed on the entire vehicle, thus not affecting the overall vehicle production time.
[0016] Optionally, the vehicle model switcher is a CAN generator. Accordingly, the first communication medium is CAN. Alternatively, the vehicle model switcher can be an ETH generator. Accordingly, the first communication medium is ETH.
[0017] In one possible implementation, the first message includes a first field indicating at least one of the following: vehicle platform type, vehicle type, vehicle type and model year, and powertrain type.
[0018] Among these, vehicle platform type refers to the platform on which the vehicle was developed. For example, Volkswagen vehicles use platforms such as the Modular Quebec Platform (MQB). Model year refers to the minor updates and improvements made to a vehicle each year. Powertrain type refers to the form of power source for the vehicle, generally categorized based on the power source, primarily into three types: gasoline, hybrid, and pure electric.
[0019] In another possible implementation, the first message includes a second field, which is encoded based on at least one of the following: vehicle platform type, vehicle type, vehicle type and model year, and powertrain type. For example, the second field could be 01 or 02.
[0020] In one possible implementation, the control device is an electronic control unit (ECU).
[0021] In one possible implementation, the control device also determines the vehicle mode as factory mode. This eliminates functional safety hazards. Factory mode refers to the mode used by the vehicle in a factory, typically for initial vehicle configuration and commissioning.
[0022] In one possible implementation, the control device also loads the target configuration data. This allows the control device to use the target configuration data.
[0023] Secondly, embodiments of this application provide a method for adapting a control device, which is applied to a vehicle model switcher. The vehicle model switcher is connected to the control device via a first communication medium. The control device has first software installed and stores configuration data corresponding to multiple vehicle types. The first software supports combining the configuration data corresponding to multiple vehicle types to adapt to multiple vehicle types. The method includes: the vehicle model switcher generating a first message indicating a first vehicle type, which belongs to multiple vehicle types. The vehicle model switcher also uses the first communication medium to send the first message in a broadcast or multicast format, the message format of which is adapted to the first communication medium.
[0024] In this embodiment, the vehicle model switcher uses a first communication medium to send a first message to the control device in a broadcast or multicast manner. This first message indicates the first vehicle type. Based on the first message, the control device determines the target configuration data currently combined with the first software to achieve the corresponding function of the first software. Data transmission between the vehicle model switcher and the control device is based on private messages. This solves the problem in the prior art where the UDS bearer link, diagnostic logic address, and diagnostic key must be identical to those of the ECU to enable UDS access to the ECU, thus expanding the scope of shared hardware and software.
[0025] In one possible implementation, the vehicle model switcher includes a first module and a second module, the second module being located within the vehicle and connected to each other. The second module is connected to a control device via a first communication medium. The second module of the vehicle model switcher obtains a first message based on data from the first module. The second module of the vehicle model switcher transmits the first message in a broadcast or multicast manner using the first communication medium.
[0026] In another possible implementation, the vehicle model switcher is located outside the vehicle and is a device that supports communication via a first communication medium.
[0027] In one possible implementation, the first communication medium is any of the following: Controller Area Network (CAN), Ethernet (ETH), or Variable Rate CAN (CANFD).
[0028] For other implementation methods, please refer to the description in the first section, which will not be repeated here.
[0029] Thirdly, embodiments of this application provide an adapter for a control device, including a processor and a memory; wherein the memory is used to store program code, and the processor is used to call the program code to execute a method as provided in any possible implementation of the first aspect.
[0030] Fourthly, embodiments of this application provide an adapter for a control device, including a processor and a memory; wherein the memory is used to store program code, and the processor is used to call the program code to execute a method as provided in any possible implementation of the second aspect.
[0031] Fifthly, embodiments of this application provide an adaptation system for a control device, including an adaptation device for a control device as described in the third aspect, and an adaptation device for a control device as described in the fourth aspect.
[0032] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the method provided in any possible implementation of the first aspect, or the method provided in any possible implementation of the second aspect.
[0033] In a seventh aspect, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform a method as provided in any possible implementation of the first aspect, or a method as provided in any possible implementation of the second aspect.
[0034] Eighthly, embodiments of this application provide a vehicle including an adapter for the control device as described in the third aspect.
[0035] It is understood that the apparatus described in the third aspect, the apparatus described in the fourth aspect, the system described in the fifth aspect, the computer-readable storage medium described in the sixth aspect, the computer program product described in the seventh aspect, and the vehicle described in the eighth aspect are all used to perform the methods provided in any of the first and second aspects. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description
[0036] The accompanying drawings used in the embodiments of this application are described below.
[0037] Figure 1 is a schematic diagram of the architecture of an in-vehicle software system applicable to an embodiment of this application;
[0038] Figure 2 is a schematic diagram of a scenario of an adaptation system for a control device provided in an embodiment of this application;
[0039] Figure 3a is a schematic diagram of an adaptation system for a control device provided in an embodiment of this application;
[0040] Figure 3b is a schematic diagram of an adaptation system for another control device provided in an embodiment of this application;
[0041] Figure 4 is a flowchart illustrating a method for adapting a control device according to an embodiment of this application;
[0042] Figure 5a is a schematic diagram of an adaptation of a control device provided in an embodiment of this application;
[0043] Figure 5b is a schematic diagram of another control device provided in an embodiment of this application;
[0044] Figure 6 is a schematic diagram of the adaptation process of another control device provided in an embodiment of this application;
[0045] Figure 7 is a schematic diagram of the structure of an adapter device for a control device provided in an embodiment of this application. Detailed Implementation
[0046] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.
[0047] For ease of understanding, the following examples illustrate some concepts related to the embodiments of this application for reference. As follows:
[0048] 1. Vehicle type
[0049] Based on vehicle size, they can be divided into: small cars, micro cars, compact cars, mid-size cars, high-end cars, luxury cars, sedans, car-derived vans (CDVs), multi-purpose vehicles (MPVs), and sport utility vehicles (SUVs).
[0050] According to the power type of the vehicle, it can be divided into: pure electric vehicle (EV) (also known as pure electric), range-extended electric vehicle (REEV) and plug-in hybrid electric vehicle (PHEV), etc.
[0051] 2. Shared hardware and software
[0052] For example, it could mean that a supplier uses the same hardware and software in multiple vehicle models for delivery.
[0053] 3. UDS Diagnostic Instrument
[0054] A UDS diagnostic tool is a specialized device for automotive diagnostics, communicating based on the UDS protocol. Its main functions include communicating with the vehicle's ECU (Electronic Control Unit) to read and clear fault codes, transmit data (reading and writing various parameters to the ECU for vehicle performance tuning and troubleshooting), and perform authentication.
[0055] The UDS diagnostic tool connects to the vehicle's bus system via the on-board diagnostics (OBD) interface, sending diagnostic requests and receiving responses from the ECUs. The format of diagnostic requests and responses is uniformly defined by the UDS protocol, ensuring compatibility and standardization between different devices and ECUs.
[0056] 4. Controller Area Network (CAN) Protocol
[0057] The CAN protocol is a serial communication protocol primarily used in the automotive industry. It has become an international standard and is widely used in automotive computer control systems and embedded industrial control local area networks.
[0058] 5. Ethereum (ETH)
[0059] Ethernet access refers to the combination of Ethernet technology and structured cabling to serve as an access network for public telecommunications networks, directly providing users with a transmission channel for various services based on the IP protocol. Ethernet technology is essentially a Layer 2 media access control technology that can be transmitted over Category 5 cable and can also be combined with other access media to form various broadband access technologies.
[0060] 6. Variable Rate CAN (CANflexible data-rate, CANFD)
[0061] CANFD is a variant of the CAN communication protocol that supports high-speed data transmission while maintaining low cost and simplicity. CANFD uses a high bit rate to transmit data, allowing for higher data throughput, and is generally compatible with existing CAN hardware.
[0062] 7. CAN Generator
[0063] A CAN generator is used to send CAN messages.
[0064] The above exemplary description of the concepts can be applied to the embodiments described below.
[0065] The system architecture of the embodiments of this application will be described in detail below with reference to the accompanying drawings. Please refer to Figure 1, which is a schematic diagram of the architecture of an in-vehicle software system applicable to the embodiments of this application. The system is described using an automated driving system (ADS) of a vehicle as an example. As shown in Figure 1, the vehicle's ECU includes intelligent driving algorithm software, operation maintenance (OM), operating system (OS), middleware OS, and system on chip (SoC).
[0066] This includes intelligent driving algorithm software for vehicles, such as perception, decision-making, and control.
[0067] Vehicle OM (Operational Management) can include ECU management functions such as upgrades, diagnostics, log export, and secure deletion.
[0068] The vehicle's base operating system primarily provides modules for computing hardware resource virtualization, OS kernel scheduling and device abstraction, and memory management; these all fall under the category of general-purpose operating systems. Currently, at the base operating system level, Linux and QNX are the main alternatives.
[0069] Analogous to the Android open-source project (AOSP) for mobile operating systems, the middleware OS provides features such as application (APP) modularization, communication, scheduling, over-the-air (OTA) download technology, artificial intelligence (AI), and abstraction of heterogeneous computing power. The middleware OS further abstracts the capabilities of the basic OS, providing standardized autonomous driving computing platform interfaces for APPs, specifically for autonomous driving scenarios.
[0070] In a narrow sense, a vehicle's System-on-a-Chip (SoC) is a chip integration that integrates the core of an information system onto a single chip. In a broader sense, an SoC is a micro-system. An SoC is typically defined as integrating a microprocessor, analog intellectual property (IP) cores, digital IP cores, and memory (or off-chip memory control interfaces) onto a single chip.
[0071] As shown in Figure 1, the ECU also stores configuration data corresponding to various vehicle types (e.g., datasets for vehicle type 1 and vehicle type 2 shown in Figure 1). The aforementioned intelligent driving algorithm software supports combining these configuration data corresponding to various vehicle types to adapt to different vehicle types (e.g., dataset for vehicle type 1 in Figure 1 corresponds to vehicle type 1, and dataset for vehicle type 2 corresponds to vehicle type 2), thereby realizing intelligent driving functions. The base dataset shown in Figure 1 refers to configurations independent of vehicle type, such as SoC configuration data.
[0072] The architecture of the embodiments of this application is described below. Please refer to Figure 2, which is a schematic diagram of an adaptation system for a control device applicable to an embodiment of this application. The system includes a vehicle 201 and a vehicle type switcher 202. Wherein:
[0073] Vehicle 201 is a device with communication and computing capabilities, capable of providing mobility services to users. Vehicle 201 can provide an environment for deploying software, hardware, or a combination of both. For example, software can be installed on vehicle 201. Furthermore, vehicle 201 has an interface for connecting hardware, through which hardware can be connected. Also, vehicle 201 has an environment for installing hardware drivers.
[0074] The vehicle model switcher 202 is a device that can be connected to the vehicle 201. Exemplarily, the vehicle model switcher is connected to the control equipment of the vehicle 201 via a first communication medium. Optionally, the first communication medium is any of the following: Controller Area Network (CAN), Ethernet (ETH), or Variable Rate CAN (CANFD).
[0075] The following describes two implementation methods of the vehicle model switcher 202.
[0076] In one possible implementation, as shown in Figure 3a, the vehicle model switcher 202 includes a first module and a second module, the second module being located within the vehicle 201. The first module and the second module are connected, and the second module is connected to a control device via a first communication medium.
[0077] In another possible implementation, as shown in Figure 3b, the vehicle model switcher 202 is a device independent of the vehicle 201. In other words, the vehicle model switcher is a separate module.
[0078] Currently, in the ECU electrical diagnostic process, the UDS bearer link, diagnostic logic address, and diagnostic key must be identical to those of the ECU bearer link, diagnostic logic address, and diagnostic key. Otherwise, the UDS cannot access the ECU, causing the ECU to be unaware of the vehicle configuration word and unable to switch. Furthermore, if the ECU's default vehicle dataset does not match the vehicle's overall configuration, the ECU cannot use the shared software package, resulting in the ECU malfunctioning. Based on this, this application provides a control device adaptation method, apparatus, and storage medium. The control device can determine the target configuration data compatible with the current vehicle model based on the vehicle model message sent by the vehicle model switcher, thereby enabling the use of the shared software package. This eliminates the need for UDS access to the ECU, expanding the application scope of the shared software package.
[0079] The architecture of the embodiments of this application has been described above. The methods of the embodiments of this application will be described in detail below.
[0080] Referring to Figure 4, a flowchart illustrating a control device adaptation method according to an embodiment of this application is shown. Optionally, this method can be applied to the aforementioned control device adaptation system, such as the control device adaptation system shown in Figure 2. The control device adaptation method shown in Figure 4 may include steps 401-402. Steps 401-402 are as follows:
[0081] 401. The vehicle type switcher uses a first communication medium to send a first message to the control device in the form of broadcast or multicast. The first message is used to indicate a first vehicle type. The message format of the first message is compatible with the first communication medium. Accordingly, the control device receives the first message.
[0082] The first communication medium can be any of the following: CAN, ETH, or CANFD.
[0083] The vehicle model switcher can be a device connected to the vehicle. The control device can be the current vehicle's control device. For example, the control device could be the vehicle's ECU.
[0084] Broadcast is a communication method that sends data to all hosts on a network without specifying the recipient's address; all hosts on the same network (such as the control device in this solution) will receive the broadcast message. Multicast is a communication method that sends data to a specific group of recipients; only hosts that have joined the specific group will receive the multicast message.
[0085] The message format of the first message is compatible with the first communication medium, which means that the first message can be transmitted through the first communication medium.
[0086] The first vehicle type can be any of the following: small car, mid-size car, high-end car, luxury car, SUV, etc. Alternatively, the first vehicle type can be an EV or a REEV, etc.
[0087] In this example, the vehicle model switcher uses a first communication medium to send a first message to the control device in the form of broadcast or multicast. That is, data transmission between the vehicle model switcher and the control device is based on private messages. However, because the UDS standard requires ensuring the UDS bearer link, the diagnostic logic address and diagnostic key must be identical to the ECU's bearer link, diagnostic logic address, and diagnostic key to enable UDS access to the ECU. Therefore, this solves the problem in existing technologies that require ensuring the UDS bearer link, diagnostic logic address, and diagnostic key are identical to the ECU's bearer link, diagnostic logic address, and diagnostic key to enable UDS access to the ECU, thus expanding the scope of shared hardware and software.
[0088] In one possible implementation, the first message includes a first field indicating at least one of the following: vehicle platform type, vehicle type, vehicle type and model year, and powertrain type.
[0089] Among these, vehicle platform type refers to the platform on which the vehicle was developed. For example, Volkswagen vehicles use platforms such as MQB. For an explanation of vehicle types, please refer to the glossary above; it will not be repeated here. Model year refers to the minor updates and improvements made to a vehicle each year. Powertrain type refers to the form of power source for the vehicle, generally categorized based on the power source, primarily into three types: gasoline, hybrid, and pure electric.
[0090] As exemplified, Table 1 shows an example of a first message provided in an embodiment of this application:
[0091] Table 1
[0092] In one possible implementation, the first message includes a second field, which can be encoded based on one or more of the following: vehicle platform type, vehicle type, vehicle type and model year, and powertrain type. For example, the second field could be 01 or 02, etc.
[0093] As exemplary, Table 2 shows another example of a first message provided in the embodiments of this application:
[0094] Table 2
[0095] In one possible implementation, prior to step 401, the method further includes: a vehicle model switcher generating a first message. For example, the vehicle model switcher obtains a first vehicle type and generates a first message based on the first vehicle type.
[0096] 402. The control device determines the target configuration data for the current combination with the first software based on the first message.
[0097] The control device includes first software installed, which also stores configuration data corresponding to various vehicle types. This first software supports combining the configuration data corresponding to each of the various vehicle types to adapt to different vehicle types. The target configuration data is the configuration data corresponding to a first vehicle type, which belongs to one of the aforementioned vehicle types.
[0098] In one possible implementation, the target configuration data includes at least one of the following: application list, network configuration, UDS configuration, key and certificate, vehicle control parameters, sensor configuration parameters, and communication matrix.
[0099] The application list refers to the list of launched programs. Network configuration includes, for example, Ethernet IP addresses, MAC addresses, VLANs, etc. UDS configuration refers to UDS protocol parameters, logical addresses, data ID definitions, alarm code definitions, routine definitions, etc. Keys and certificates refer to the keys and certificates used for encryption. Vehicle control parameters may include, for example, vehicle length, width, wheelbase, weight, and dynamic parameters corresponding to different control algorithms. Sensor configuration parameters may include, for example, sensor type, number, port, IP address, installation location, etc. The communication matrix refers to the complete set of communication messages between the ECU and other vehicle components, such as a CAN communication matrix or an ETH communication matrix.
[0100] In one possible implementation, the control device parses the first message and then determines the target configuration data for the current combination with the first software.
[0101] In one possible implementation, the first message is encrypted. The control device first decrypts the first message to obtain a decrypted first message, and then parses the decrypted first message. Of course, the first message can also be unencrypted. This solution does not impose any restrictions on this.
[0102] In one possible implementation, the method further includes: the control device loading the target configuration data. This allows the control device to use the target configuration data.
[0103] In one possible implementation, before step 401, the method further includes: the control device determining the vehicle mode as factory mode. That is, the adaptation method of the control device is applicable to the vehicle's factory mode. This eliminates functional safety hazards. Factory mode refers to the mode used by the vehicle in a factory, generally for initial vehicle configuration and debugging. It is understood that vehicle mode also includes customer mode, i.e., the mode corresponding to the vehicle when a consumer uses it.
[0104] In this embodiment, the vehicle model switcher uses a first communication medium to send a first message to the control device in a broadcast or multicast manner. This first message indicates the first vehicle type. Based on the first message, the control device determines the target configuration data currently combined with the first software to achieve the corresponding function of the first software. Data transmission between the vehicle model switcher and the control device is based on private messages. This solves the problem in the prior art where the UDS bearer link, diagnostic logic address, and diagnostic key must be identical to those of the ECU to enable UDS access to the ECU, thus expanding the scope of shared hardware and software.
[0105] The adaptation method of the control device provided in the embodiments of this application will be described in detail below with reference to Embodiment 1 and Embodiment 2.
[0106] Example 1
[0107] Referring to Figure 3a, the vehicle model switcher in this example includes a first module and a second module. The first module and the second module are connected. The first module is located outside the vehicle, and the second module is located inside the vehicle. The second module and the control device are connected via a first communication medium. This first communication medium can be, for example, any one of CAN, ETH, or CANFD.
[0108] Optionally, the first module can be a device that can be connected to the vehicle. For example, the first module can be a diagnostic tool, etc. The second module can be another vehicle ECU that is connected to the control equipment. For example, the second module can be an on-board gateway, etc.
[0109] Referring to Figure 5a, the vehicle is powered on. The vehicle's control equipment starts. The first module of the vehicle model switcher sends data to the second module. The second module generates a first message based on this data, which indicates the vehicle type. Then, the second module sends the first message to the control device via a first communication medium. The control device parses the first message to determine the target configuration data currently combined with the first software. Subsequently, the control device loads the target configuration data to implement the functions of the first software.
[0110] Optionally, the process shown in Figure 5a may also include, for example, the diagnostic instrument reading the hardware version information and software version information of the control device.
[0111] Optionally, the process shown in Figure 5a further includes: the diagnostic tool connecting to the ECU and writing a configuration word. The ECU parses the configuration word and selects the correct vehicle configuration data. For example, this process may also include the installation of the vehicle manufacturer's key and certificate.
[0112] In this example, the vehicle model switcher includes a first module and a second module, with the second module located inside the vehicle. This allows for message transmission based on existing vehicle modules, offering great flexibility and convenience.
[0113] Example 2
[0114] Referring to Figure 3b, the vehicle model switcher in this example is a stand-alone module. The vehicle model switcher is located outside the vehicle and is a device that supports communication via a first communication medium. The vehicle model switcher and the control device are connected via the first communication medium.
[0115] Optionally, the vehicle model switcher is a CAN generator. Accordingly, the first communication medium is CAN. Referring to Figure 5b, the vehicle is powered on. The CAN generator sends a first message to the control device via CAN, which indicates the vehicle type. The control device parses the first message to determine the target configuration data currently combined with the first software. Then, the control device loads the target configuration data.
[0116] Of course, the vehicle type switcher can also be an ETH generator. Accordingly, the first communication medium is ETH.
[0117] In this example, the vehicle model switcher is a standalone module. This allows for pre-operation without being installed on the entire vehicle, thus not affecting the overall vehicle production time.
[0118] Referring to Figure 6, a flowchart illustrating a control device adaptation method according to an embodiment of this application is provided. This control device adaptation method can be applied to a vehicle factory mode, such as in a vehicle ECU electrical testing production line. This example uses an ECU as the control device. The vehicle model switcher can be the vehicle model switcher shown in Figure 5a or Figure 5b above. Exemplarily, the method may include steps 601-606, as follows:
[0119] 601. The vehicle model switcher sends a first message to the ECU, which indicates the first vehicle type. Accordingly, the ECU receives the first message.
[0120] 602. The ECU confirms whether the first vehicle type indicated by the first message is consistent with the preset vehicle type.
[0121] This preset vehicle type can also be called the default vehicle type. For example, if the current production line mainly tests SUVs, then the preset vehicle type is SUV.
[0122] 603. If the first vehicle type indicated by the first message is inconsistent with the preset vehicle type, the ECU determines the target configuration data of the current combination with the first software installed in the ECU based on the first message.
[0123] The target configuration data is the configuration data corresponding to the first vehicle type.
[0124] Optionally, the ECU determines the dataset index (number, etc.) to be selected from the dataset. Then, the ECU determines the target configuration data based on the aforementioned dataset index.
[0125] 604. The ECU loads the target configuration data.
[0126] 605. The ECU restarts the preset process and uses the target configuration data.
[0127] For example, the preset process includes at least one of the following: network configuration process, diagnostic configuration process, and sensor management process.
[0128] This allows for immediate effect of model switching, reducing the impact on production line cycle time.
[0129] Alternatively, step 605 could also involve the ECU executing a power-down procedure. For example, a reset could be selected based on production line time requirements.
[0130] 606. If the first vehicle type indicated by the first message is consistent with the preset vehicle type, the ECU does not perform any processing. That is, the ECU waits to receive new messages, etc.
[0131] Understandably, steps 601-606 above can be repeated in factory mode, allowing for recovery from erroneous operations.
[0132] Referring to FIG7, a schematic diagram of the hardware structure of an adapter device for a control device provided in an embodiment of this application is shown. The device 700 shown in FIG7 includes one or more processors 701 (a processor is illustrated in the figure).
[0133] Processor 701 is a circuit with signal processing capabilities. In one implementation, processor 701 can be a circuit with instruction read and execute capabilities, such as a central processing unit (CPU), microprocessor, graphics processing unit (GPU) (which can be understood as a type of microprocessor), or digital signal processor (DSP). In another implementation, processor 701 can implement certain functions through the logical relationships of hardware circuits. These logical relationships of hardware circuits are fixed or reconfigurable. For example, processor 701 can be a hardware circuit implemented as an ASIC or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above modules. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as a type of ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), or deep learning processing unit (DPU). The processor 701 is used to execute related programs to implement the functions required by the units in the adaptation device of the control device in the embodiments of this application, or to execute the adaptation method of the control device in the method embodiments of this application.
[0134] Optionally, the device 700 may also include a memory (e.g., memory 703, memory 704, memory 705) (shown as dashed lines in the figure). The memory is used to store instructions executed by the processor 701, or to store input data required by the processor 701 to execute instructions, or to store data generated after the processor 701 executes instructions.
[0135] Optionally, the memory may be located within the one or more processors (e.g., memory 703), or outside the one or more processors (e.g., memory 704, memory 705), or may include a storage portion located within the one or more processors and a storage portion located outside the one or more processors.
[0136] In this embodiment, the memory (e.g., memory 703, memory 704, memory 705) may include, but is not limited to, cache, read-only memory (ROM), random access memory (RAM), synchronous dynamic random access memory (SDRAM), hard disk drive (HDD) or solid-state drive (SSD), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), etc. Memory is any other medium capable of carrying or storing desired program code having an instruction or data structure form and accessible by a computer, but is not limited thereto. The memory in this embodiment may also be a circuit or any other device capable of implementing storage functions for storing computer programs or instructions, and / or data.
[0137] Optionally, the device 700 may also include a communication interface 702 (shown as a dashed line in the figure). The processor 701 and the communication interface 702 are coupled together. The communication interface 702 can be a transceiver or interface circuit, a bus, a module, or other type of communication interface.
[0138] The memory can store programs. When the program stored in the memory is executed by the processor 701, the processor 701 and the communication interface 702 are used to execute the various steps of the adaptation method of the control device according to the embodiments of this application.
[0139] As can be seen, each module in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms or a portion of the processing circuits in these processors.
[0140] Furthermore, the modules in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these modules are integrated together as a System-on-Chip (SoC). The SoC may include at least one processor for implementing any of the above methods or for implementing the functions of the modules of the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and AI processor, CPU and GPU, etc.
[0141] It should be noted that although the device 700 shown in FIG. 7 only illustrates the memory, processor, and communication interface, those skilled in the art should understand that in specific implementations, device 700 may also include other devices necessary for normal operation. Furthermore, depending on specific needs, those skilled in the art should understand that device 700 may also include hardware devices for implementing other additional functions. Moreover, those skilled in the art should understand that device 700 may only include the devices necessary for implementing the embodiments of this application, and not necessarily all the devices shown in FIG. 7.
[0142] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer or processor, cause the computer or processor to perform one or more steps of any of the above methods.
[0143] This application also provides a computer program product containing instructions. When the computer program product is run on a computer or processor, it causes the computer or processor to perform one or more steps of any of the methods described above.
[0144] It should be understood that in the description of this application, unless otherwise stated, " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B can represent A or B; where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. Additionally, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" do not necessarily imply difference. In this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being better or more advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.
[0145] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The coupling, direct coupling, or communication connection shown or discussed between each other may be indirect coupling or communication connection through some interfaces, apparatuses, or units, and may be electrical, mechanical, or other forms.
[0146] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0147] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be read-only memory (ROM), random access memory (RAM), or magnetic media, such as floppy disks, hard disks, magnetic tapes, magnetic disks, or optical media, such as digital versatile discs (DVDs), or semiconductor media, such as solid-state disks (SSDs).
[0148] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.
Claims
1. A method for adapting a control device, characterized in that, A control device for vehicles, wherein the control device is equipped with first software and also stores configuration data corresponding to various vehicle types, the first software supporting combinations with the configuration data corresponding to the various vehicle types to adapt to the various vehicle types, the method comprising: The control device receives a first message from the vehicle type switcher using a first communication medium. The first message indicates a first vehicle type. The first message is a message sent by the vehicle type switcher in the form of broadcast or multicast. The message format of the first message is adapted to the first communication medium. The control device is connected to the vehicle type switcher via the first communication medium. Based on the first message, the target configuration data for the current combination with the first software is determined. The target configuration data is the configuration data corresponding to the first vehicle type, and the first vehicle type belongs to the multiple vehicle types.
2. The method according to claim 1, characterized in that, The vehicle model switcher includes a first module and a second module. The second module is located inside the vehicle. The first module and the second module are connected. The second module is connected to the control device via the first communication medium. The step of receiving a first message from the vehicle model switcher using a first communication medium includes: The first message is received from the second module using the first communication medium. The first message is obtained by the second module based on data from the first module.
3. The method according to claim 1, characterized in that, The vehicle model switcher is located outside the vehicle and is a device that supports communication via the first communication medium.
4. The method according to any one of claims 1 to 3, characterized in that, The first communication medium is any one of the following: Controller Area Network (CAN), Ethernet (ETH), Variable Rate CAN (CANFD).
5. The method according to any one of claims 1 to 4, characterized in that, The target configuration data includes at least one of the following: Application list, network configuration, UDS configuration, keys and certificates, vehicle control parameters, sensor configuration parameters, and communication matrix.
6. The method according to any one of claims 1 to 5, characterized in that, The first message includes a first field, which indicates at least one of the following information: Vehicle platform type, vehicle type, vehicle type and model year, powertrain type.
7. The method according to any one of claims 1 to 5, characterized in that, The first message includes a second field, which is encoded based on at least one of the following: vehicle platform type, vehicle type, vehicle type and model year, and powertrain type.
8. The method according to any one of claims 1 to 7, characterized in that, The control device is an electronic control unit (ECU).
9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: Set the vehicle mode to factory mode.
10. A method for adapting a control device, characterized in that, An application is made in a vehicle model switcher, wherein the vehicle model switcher is connected to a control device via a first communication medium, the control device is equipped with first software, and the control device also stores configuration data corresponding to multiple vehicle types. The first software supports combining the configuration data corresponding to the multiple vehicle types to adapt to the multiple vehicle types. The method includes: Generate a first message, the first message being used to indicate a first vehicle type, the first vehicle type belonging to the multiple vehicle types; The first message is sent in the form of broadcast or multicast using the first communication medium, and the message format of the first message is adapted to the first communication medium.
11. The method according to claim 10, characterized in that, The vehicle model switcher includes a first module and a second module. The second module is located inside the vehicle. The first module and the second module are connected. The second module is connected to the control device via the first communication medium. The generation of the first message includes: The first message is obtained based on data from the first module; Sending the first message using the first communication medium in a broadcast or multicast manner includes: The first message is sent via the second module in the form of broadcast or multicast using the first communication medium.
12. The method according to claim 10, characterized in that, The vehicle model switcher is located outside the vehicle and is a device that supports communication via the first communication medium.
13. The method according to any one of claims 10 to 12, characterized in that, The first communication medium is any one of the following: Controller Area Network (CAN), Ethernet (ETH), Variable Rate CAN (CANFD).
14. A control device, characterized in that, The control device is used to implement the adaptation method of the control device as described in any one of claims 1 to 9.
15. A vehicle model switcher, characterized in that, The vehicle model switcher is used to implement the adaptation method of the control device as described in any one of claims 10 to 13.
16. An adaptation system for a control device, characterized in that, It includes the control device as described in claim 14 and the vehicle model switcher as described in claim 15.
17. A vehicle, characterized in that, Includes the control device as described in claim 14.