Parameter configuration method, system and device

Abstract

The invention provides a parameter configuration method, system and device which are used for decoupling public configuration and instance configuration and improving the parameter configuration efficiency so as to improve the development efficiency of vehicle functions. The method comprises the following steps: first, first development equipment performs public configuration to obtain public configuration data, and the public configuration data comprises parameters for resource allocation in a vehicle; then, the first development equipment sends public configuration data to the second development equipment; the first development equipment further performs instance configuration according to the public configuration data to obtain first instance configuration data; and then the first development device compiles according to the public configuration data and the first instance configuration data to obtain a first static library, the first static library and a second static library are used for writing in the chip to enable the chip to run according to the written configuration, and the second static library is obtained by compiling after the second development device performs instance configuration according to the public configuration data.

Description

Technical Field

[0001] The present application relates to the automotive field, and in particular to a parameter configuration method, system and device. Background Art

[0002] The automotive open system architecture (AUTOSAR) is a standard vehicle software architecture widely adopted in the industry.

[0003] For the configuration of each functional module in the vehicle, the original equipment manufacturer (OEM) usually puts forward requirements to the first-tier supplier (Tier-1). Tier-1 integrates the full configuration, generates the dynamic code of the full configuration, and then generates the base software static library. Tier-1 provides the OEM with interface files, and the OEM develops related services to compile and generate the OEM static library. The base software static library and the OEM static library are linked into an executable file and burned to the microcontroller unit (MCU).

[0004] During the vehicle development and configuration process, the number of parameters that need to be configured is large, and the requirements usually change quickly, resulting in low development efficiency. Therefore, how to achieve more efficient development has become an urgent problem to be solved. Summary of the invention

[0005] The present application provides a parameter configuration method, system and device for decoupling common configuration and instance configuration, improving parameter configuration efficiency, and thus improving vehicle function development efficiency.

[0006] In view of this, on the first aspect, the present application provides a parameter configuration method, the method comprising: first, a first development device performs a public configuration to obtain public configuration data, the public configuration data including parameters for resource allocation in a vehicle, such as the first development device can allocate hardware resources or software resources in the vehicle to generate corresponding configuration parameters; then, the first development device sends the public configuration data to the second development device, so that the second development device can perform instance configuration on the module it depends on based on the public configuration data; the first development device also performs instance configuration according to the public configuration data to obtain first instance configuration data; then, the first development device compiles according to the public configuration data and the first instance configuration data to obtain a first static library, the first static library and the second static library are used to write into a chip so that the chip runs according to the written configuration, and the second static library is compiled by the second development device after performing instance configuration according to the public configuration data.

[0007] In the implementation mode of the present application, the common configuration is configured by the first development device. After the common configuration is completed, the first development device and the second development device can respectively perform instance configuration, thereby decoupling the instance configuration of each developer, and the instance configuration of each developer can be performed synchronously, which can improve the configuration efficiency. Even if there are changes in the requirements for vehicle functions, faster function development can be achieved based on the efficient parameter configuration method.

[0008] In a possible implementation, the aforementioned first development device performs instance configuration according to the public configuration data to obtain the first instance configuration data, which may include: the first development device may perform software resource configuration during the configuration of the public configuration, such as allocating soft resources to each module. During the instance configuration process, the first development device may perform instance configuration based on the resources of at least one module (referred to as the first module for ease of distinction) included in the public configuration to obtain the first instance configuration data, and the at least one first module includes a module that has a dependency relationship with the first development device. Therefore, the first development device performs instance configuration after completing the public configuration, which realizes the decoupling of the public configuration and the instance configuration, so that the instance configuration processes of the modules that each party depends on can be performed in parallel, thereby improving the parameter configuration efficiency.

[0009] In a possible implementation, the aforementioned first instance configuration data includes at least one of the basic software layer BSW configuration, the runtime environment layer RTE configuration, or the software component SWC configuration. Therefore, the first development device can configure the BSW, RTE, or SWC configuration it relies on, such as the interface file required by SWC, so as to implement the function development on the first development device side.

[0010] In a possible implementation, the aforementioned first development device performs instance configuration according to the resources of at least one first module included in the common configuration to obtain first instance configuration data, which may include: the first development device performs instance configuration according to the resources of at least one first module included in the common configuration by reference or by model tree to obtain first instance configuration data, the reference method includes adding a reference item in the configuration model, the reference item is used to reference the instance configuration parameters, the model tree method includes modifying the configuration model, and configuring the instance parameters based on the modified configuration model. In the implementation of the present application, instance configuration can be performed by reference or by modifying the model tree, so as to adapt to the configuration method of decoupling the common configuration and the instance configuration.

[0011] In a possible implementation, the aforementioned public configuration data includes at least one of hardware resource configuration, system resource configuration, or resource configuration of at least one module, the hardware resource configuration includes at least one of chip type, number of chip cores, CAN protocol hardware resources, or storage resources, the system resource configuration includes task resources or memory resources, and the resource configuration of at least one module includes at least one of instance identification, number of instances, or precompiled macro switches of at least one module. In the implementation of the present application, the first development device can perform public configuration, and multiple resources can be configured, so that the functions of each chip in the vehicle can be realized based on the public configuration of the configuration.

[0012] In a possible implementation, the aforementioned first development device performs public configuration to obtain public configuration data, including: the first development device can receive demand data sent by the second development device; the first development device performs public configuration under the instruction of the demand data to obtain public configuration data. Therefore, the first development device can perform public configuration based on the demand of the second development device, thereby configuring a public configuration adapted to the demand, so as to facilitate subsequent function development.

[0013] In a possible implementation, the aforementioned first development device compiles according to the common configuration data and the first instance configuration data to obtain the first static library, which may include: the first development device generates the common configuration dynamic code and the first instance dynamic code according to the common configuration data and the first instance configuration data respectively; the first development device compiles according to the common configuration dynamic code, the first instance dynamic code and the static code to obtain the first static library, and the static code is used to provide the header files required for each module or each function. In the implementation of the present application, the first development device can generate dynamic code based on the common configuration and the instance configuration respectively, and compile the dynamic code so that it can be linked to an executable file later to realize the functional development of the chip.

[0014] In a possible implementation, the aforementioned method may further include: the first development device sends the first static library to the second development device, so that the second development device writes the first static library and the second static library into the chip. Therefore, the second development device may link the first static library and the second static library into an executable file and write the executable file into the chip, thereby realizing the functions to be executed by the chip.

[0015] In a possible implementation, the aforementioned method further includes: the first development device receives the second static library sent by the second development device; the first development device links the first static library and the second static library into an executable file and writes the executable file into the chip. Therefore, the first development device may also link the first static library and the second static library into an executable file and write the executable file into the chip, thereby realizing the function to be executed by the chip.

[0016] In a second aspect, the present application provides a parameter configuration method, including: first, a second development device receives public configuration data sent by a first development device, the public configuration data including parameters for resource allocation in a vehicle; then, the second development device performs instance configuration on a module on which it depends according to the public configuration data to obtain second instance configuration data; a second static library is compiled according to the second instance configuration data to obtain a second static library, the second static library and the first static library are used to write into a chip so that the chip runs according to the written configuration, the first static library is compiled by the first development device according to the public configuration data and the first instance configuration data, and the first instance configuration data includes the instance configuration performed by the first development device according to the public configuration data.

[0017] In the implementation mode of the present application, the common configuration is configured by the first development device. After the common configuration is completed, the first development device and the second development device can respectively perform instance configuration, thereby decoupling the instance configuration of each developer, and the instance configuration of each developer can be performed synchronously, which can improve the configuration efficiency. Even if there are changes in the requirements for vehicle functions, faster function development can be achieved based on the efficient parameter configuration method.

[0018] In a possible implementation, the aforementioned second development device may send demand data to the first development device, and the demand data is used to instruct the first development device to configure the public configuration data. Therefore, the second development device may make a demand to the first development device, so that the first development device may perform a public configuration based on the demand of the second development device, and obtain a public configuration that meets the demand of the second device.

[0019] In a possible implementation, the aforementioned second development device performs instance configuration according to the common configuration data to obtain the second instance configuration data, which may include: the second development device performs instance configuration according to resources of at least one second module included in the common configuration data to obtain the second instance configuration data, and the at least one second module includes a module having a dependency relationship with the second development device. In the implementation of the present application, the second development device may perform instance configuration on the modules it depends on, thereby realizing the functions required by the second development device.

[0020] In a possible implementation, the aforementioned second configuration data may include at least one of a basic software layer BSW configuration, a runtime environment layer RTE configuration, and a software component SWC configuration.

[0021] In a possible implementation, the aforementioned second development device performs instance configuration according to the resources of at least one second module included in the common configuration to obtain second instance configuration data, which may include: the second development device performs instance configuration according to the resources of at least one second module included in the common configuration by reference or by a model tree to obtain first instance configuration data, the reference method includes adding a reference item in the configuration model, the reference item is used to reference the instance configuration parameters, and the model tree method includes modifying the configuration model, and configuring the instance parameters based on the modified configuration model. In the implementation of the present application, instance configuration can be performed by reference or by modifying the model tree, so as to adapt to the configuration method of decoupling the common configuration and the instance configuration.

[0022] In a possible implementation, the aforementioned public configuration data includes at least one of hardware resource configuration, system resource configuration, or resource configuration of at least one module, the hardware resource configuration includes at least one of chip type, number of chip cores, CAN protocol hardware resources, or storage resources, the system resource configuration includes task resources or memory resources, and the resource configuration of at least one module includes at least one of instance identification, number of instances, or precompiled macro switches of at least one module. In the implementation of the present application, the first development device can perform public configuration, and multiple resources can be configured, so that the functions of each chip in the vehicle can be realized based on the public configuration of the configuration.

[0023] In a possible implementation, the aforementioned method may further include: the second development device receives the first static library sent by the first development device; the second development device links the first static library and the second static library into an executable file and writes the executable file into the chip. Therefore, the second development device may link the first static library and the second static library into an executable file and write the executable file into the chip, thereby realizing the function to be executed by the chip.

[0024] In a possible implementation, the aforementioned method may further include: the second development device sends the second static library to the first development device, so that the first development device writes the first static library and the second static library into the chip. Therefore, the first development device may also link the first static library and the second static library into an executable file and write the executable file into the chip, thereby realizing the function to be executed by the chip.

[0025] In a third aspect, the present application provides a parameter configuration device, which can be used to execute the steps executed by the first development device in the first aspect and any possible implementation manner provided in the first aspect.

[0026] In a possible design, the present application may divide the parameter configuration device into functional modules according to the first aspect and any possible implementation method provided in the first aspect. For example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module.

[0027] Exemplarily, the present application may divide the parameter configuration device into a transceiver module and a processing module according to the function. The description of the possible technical solutions and beneficial effects executed by each functional module divided above can refer to the technical solutions provided by the first aspect or its corresponding possible implementation methods, which will not be repeated here.

[0028] In another possible design, the parameter configuration device includes: a memory and a processor, the memory and the processor are coupled. The memory is used to store computer instructions, and the processor is used to call the computer instructions to execute the method provided in the first aspect or its corresponding possible implementation.

[0029] In a fourth aspect, the present application provides a parameter configuration device, which can be used to execute the steps executed by the second development device in the second aspect and any possible implementation manner provided in the second aspect.

[0030] In a possible design, the present application may divide the parameter configuration device into functional modules according to the above second aspect and any possible implementation method provided in the second aspect. For example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module.

[0031] Exemplarily, the present application may divide the parameter configuration device into a transceiver module and a processing module according to the function. The description of the possible technical solutions and beneficial effects executed by each of the functional modules divided above can refer to the technical solutions provided by the second aspect or its corresponding possible implementation methods, which will not be repeated here.

[0032] In another possible design, the parameter configuration device includes: a memory and a processor, the memory and the processor are coupled. The memory is used to store computer instructions, and the processor is used to call the computer instructions to execute the method provided in the second aspect or its corresponding possible implementation.

[0033] In a fifth aspect, the present application provides a parameter configuration system, which may include a first development device and a second development device, wherein the first development device can be used to execute the method steps of the aforementioned first aspect or any optional implementation scheme of the first aspect, and the second development device can be used to execute the method steps of the aforementioned second aspect or any optional implementation scheme of the second aspect.

[0034] In a sixth aspect, the present application provides a computer-readable storage medium, such as a non-transient computer-readable storage medium, on which a computer program (or instruction) is stored, and when the computer program (or instruction) is executed on a computer device, the computer device executes the method provided in the first aspect or its corresponding possible implementation, or executes the method provided in the second aspect or its corresponding possible implementation.

[0035] In a seventh aspect, the present application provides a computer program product which, when executed on a computer device, enables the method provided in the first aspect or its corresponding possible implementation to be executed, or enables the method provided in the second aspect or its corresponding possible implementation to be executed.

[0036] In an eighth aspect, the present application provides a chip system, comprising: a processor, the processor being used to call and run a computer program stored in a memory from the memory, to execute a method provided in the first aspect or its corresponding possible implementation manner, or to execute a method provided in the second aspect or its corresponding possible implementation manner.

[0037] It can be understood that any of the systems, devices, computer storage media, computer program products or chip systems provided above can be applied to the corresponding methods provided in the first aspect or the second aspect.

[0038] For the specific implementation steps of the third to eighth aspects of the present application and various possible implementation methods, as well as the beneficial effects brought about by each possible implementation method, please refer to the description of the various possible implementation methods in the first or second aspect, and will not be repeated here one by one. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 A schematic diagram of the structure of a vehicle provided for this application;

[0040] Figure 2 A schematic diagram of the structure of another vehicle provided for this application;

[0041] Figure 3 A schematic diagram of the system architecture of a CP classic platform deployed on a vehicle provided in this application;

[0042] Figure 4 A flow chart of a parameter configuration method provided in this application;

[0043] Figure 5 A flow chart of another parameter configuration method provided by this application;

[0044] Figure 6 A flow chart of another parameter configuration method provided by this application;

[0045] Figure 7 A flow chart of another parameter configuration method provided by this application;

[0046] Figure 8 A flow chart of another parameter configuration method provided by this application;

[0047] Fig. 9 A flow chart of another parameter configuration method provided by this application;

[0048] Fig.10 A flow chart of another parameter configuration method provided by this application;

[0049] Fig.11 A flow chart of another parameter configuration method provided by this application;

[0050] Fig.12 A flow chart of another parameter configuration method provided by this application;

[0051] Fig.13 A flow chart of another parameter configuration method provided by this application;

[0052] Fig.14 A flow chart of another parameter configuration method provided by this application;

[0053] Fig.15 A flow chart of another parameter configuration method provided by this application;

[0054] Fig.16 A schematic diagram of the structure of a parameter configuration device provided in this application;

[0055] Fig.17 A schematic diagram of the structure of another parameter configuration device provided by the present application;

[0056] Fig.18 A schematic diagram of the structure of another parameter configuration device provided in this application. DETAILED DESCRIPTION

[0057] The following will describe the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0058] In order to facilitate the understanding of this solution, the present application embodiment first combines Figure 1 For an introduction to the structure of the vehicle provided in this application, please refer to Figure 1 , Figure 1 A schematic diagram of the structure of a vehicle provided in an embodiment of the present application, Figure 1 1 is a functional block diagram of a vehicle 100 provided in an embodiment of the present application. The vehicle 100 may be configured in a fully or partially autonomous driving mode. For example, the vehicle 100 may obtain environmental information about its surroundings through the perception system 120, and obtain an autonomous driving strategy based on the analysis of the surrounding environmental information to achieve fully autonomous driving, or present the analysis results to the user to achieve partially autonomous driving.

[0059] The vehicle 100 may include various subsystems, such as an infotainment system 110, a perception system 120, a decision control system 130, a drive system 140, and a computing platform 150. Optionally, the vehicle 100 may include more or fewer subsystems, and each subsystem may include multiple components. In addition, each subsystem and component of the vehicle 100 may be interconnected by wire or wirelessly.

[0060] In some embodiments, the infotainment system 110 may include a communication system 111 , an entertainment system 112 , and a navigation system 113 .

[0061] The communication system 111 may include a wireless communication system 111, which can communicate wirelessly with one or more devices directly or via a communication network. For example, the wireless communication system 111 can use 3G cellular communication, such as CDMA, EVDO, GSM / GPRS, or 4G cellular communication, such as LTE, or 5G cellular communication. The wireless communication system 111 can communicate with a wireless local area network (WLAN) using WiFi. In some embodiments, the wireless communication system 146 can communicate directly with the device using an infrared link, Bluetooth, or ZigBee. The wireless communication system 111 may include one or more dedicated short range communications (DSRC) devices, which may include public and / or private data communications between vehicles and / or roadside stations.

[0062] The entertainment system 112 may include a central control screen, a microphone and a speaker. The user can listen to the radio and play music in the car based on the entertainment system 112; or connect the mobile phone to the vehicle and realize the projection of the mobile phone on the central control screen. The central control screen may be touch-sensitive, and the user can operate by touching the screen. In some cases, the user's voice signal can be obtained through the microphone, and the user can control certain aspects of the vehicle 100 based on the analysis of the user's voice signal, such as adjusting the temperature in the car. In other cases, music can be played to the user through the speaker.

[0063] The navigation system 113 may include a map service provided by a map provider, thereby providing navigation of the driving route for the vehicle 100. The navigation system 113 may be used in conjunction with the vehicle's global positioning system 121 and inertial measurement unit 122. The map service provided by the map provider may be a two-dimensional map or a high-precision map.

[0064] The perception system 120 may include several sensors that sense information about the environment around the vehicle 100. For example, the perception system 120 may include a global positioning system 121 (the global positioning system may be a GPS system, or a Beidou system or other positioning systems), an inertial measurement unit (IMU) 122, a laser radar 123, a millimeter wave radar 124, an ultrasonic radar 125, and a camera 126. The perception system 120 may also include sensors of the internal systems of the monitored vehicle 100 (for example, an in-vehicle air quality monitor, a fuel gauge, an oil temperature gauge, etc.). Sensor data from one or more of these sensors can be used to detect objects and their corresponding characteristics (position, shape, direction, speed, etc.). Such detection and recognition are key functions for the safe operation of the vehicle 100.

[0065] The global positioning system 121 may be used to determine the geographic location of the vehicle 100 .

[0066] The inertial measurement unit 122 is used to sense the position and orientation changes of the vehicle 100 based on inertial acceleration. In some embodiments, the inertial measurement unit 122 may be a combination of an accelerometer and a gyroscope.

[0067] The LiDAR 123 may utilize laser light to sense objects in the environment in which the vehicle 100 is located. In some embodiments, the LiDAR 123 may include one or more laser sources, a laser scanner, and one or more detectors, among other system components.

[0068] The millimeter wave radar 124 may utilize radio signals to sense objects in the surrounding environment of the vehicle 100. In some embodiments, in addition to sensing objects, the millimeter wave radar 124 may also be used to sense the speed and / or heading of the objects.

[0069] The ultrasonic radar 125 may sense objects around the vehicle 100 using ultrasonic signals.

[0070] The camera device 126 may be used to capture image information of the surrounding environment of the vehicle 100. The camera device 126 may include a monocular camera, a binocular camera, a structured light camera, a panoramic camera, etc. The image information acquired by the camera device 126 may include static image information or video stream information.

[0071] The decision control system 130 includes a computing system 131 for analyzing and making decisions based on the information obtained by the perception system 120. The decision control system 130 also includes a vehicle controller 132 for controlling the power system of the vehicle 100, and a steering system 133, a throttle 134 and a braking system 135 for controlling the vehicle 100.

[0072] The computing system 131 may process and analyze various information acquired by the perception system 120 in order to identify targets, objects and / or features in the surrounding environment of the vehicle 100. The targets may include pedestrians or animals, and the objects and / or features may include traffic signals, road boundaries and obstacles. The computing system 131 may use object recognition algorithms, Structure from Motion (SFM) algorithms, video tracking and other technologies. In some embodiments, the computing system 131 may be used to map the environment, track objects, estimate the speed of objects, and so on. The computing system 131 may analyze the various information acquired and derive a control strategy for the vehicle.

[0073] The vehicle controller 132 can be used to coordinate and control the vehicle's power battery and engine 141 to improve the power performance of the vehicle 100.

[0074] The steering system 133 may be used to adjust the forward direction of the vehicle 100. For example, in one embodiment, it may be a steering wheel system.

[0075] The throttle 134 is used to control the operating speed of the engine 141 and thus the speed of the vehicle 100 .

[0076] The braking system 135 is used to control the deceleration of the vehicle 100. The braking system 135 can use friction to slow down the rotation speed of the wheel 144. In some embodiments, the braking system 135 can convert the kinetic energy of the wheel 144 into electric current. The braking system 135 can also take other forms to slow down the rotation speed of the wheel 144 to control the speed of the vehicle 100.

[0077] The drive system 140 includes components that provide power movement for the vehicle 100. In one embodiment, the drive system 140 may include an engine 141, an energy source 142, a transmission system 143, and wheels 144. The engine 141 may be an internal combustion engine, an electric motor, an air compression engine, or a combination of other types of engines, such as a hybrid engine composed of a gasoline engine and an electric motor, or a hybrid engine composed of an internal combustion engine and an air compression engine. The engine 141 converts the energy source 142 into mechanical energy.

[0078] Examples of energy source 142 include gasoline, diesel, other petroleum-based fuels, propane, other compressed gas-based fuels, ethanol, solar panels, batteries, and other sources of electricity. Energy source 142 may also provide energy to other systems of vehicle 100.

[0079] The transmission system 143 can transmit mechanical power from the engine 141 to the wheels 144. The transmission system 143 may include a gearbox, a differential, and a drive shaft. In one embodiment, the transmission system 143 may also include other devices, such as a clutch. Among them, the drive shaft may include one or more shafts that can be coupled to one or more wheels 144.

[0080] Some or all functions of the vehicle 100 are controlled by a computing platform 150. The computing platform 150 may include at least one processor 151 that may execute instructions 153 stored in a non-transitory computer-readable medium such as a memory 152. In some embodiments, the computing platform 150 may also be a plurality of computing devices that control individual components or subsystems of the vehicle 100 in a distributed manner.

[0081] The processor 151 may be any conventional processor, such as a commercially available CPU. Alternatively, the processor 151 may also include a graphics processing unit (GPU), a field programmable gate array (FPGA), a system on chip (SOC), an application-specific integrated circuit (ASIC), or a combination thereof. The processor 151 may be located on a device remote from the vehicle and communicate wirelessly with the vehicle.

[0082] In some embodiments, the memory 152 may include instructions 153 (e.g., program logic) that may be executed by the processor 151 to perform various functions of the vehicle 100. The memory 152 may also include additional instructions, including instructions to send data to, receive data from, interact with, and / or control one or more of the infotainment system 110, the perception system 120, the decision control system 130, and the drive system 140.

[0083] In addition to instructions 153, memory 152 may also store data such as road maps, route information, the vehicle's location, direction, speed, and other similar vehicle data, as well as other information. Such information may be used by vehicle 100 and computing platform 150 during operation of vehicle 100 in autonomous, semi-autonomous, and / or manual modes.

[0084] The computing platform 150 may control functions of the vehicle 100 based on input received from various subsystems, such as the drive system 140, the perception system 120, and the decision control system 130. For example, the computing platform 150 may utilize input from the decision control system 130 in order to control the steering system 133 to avoid an obstacle detected by the perception system 120. In some embodiments, the computing platform 150 may be operable to provide control over many aspects of the vehicle 100 and its subsystems.

[0085] Alternatively, one or more of the above-mentioned components may be installed or associated separately from the vehicle 100. For example, the memory 152 may exist partially or completely separately from the vehicle 100. The above-mentioned components may be communicatively coupled together in a wired and / or wireless manner.

[0086] Optionally, the above components are only examples. In actual applications, the components in the above modules may be added or deleted according to actual needs. Figure 1 It should not be understood as limiting the embodiments of the present application.

[0087] An autonomous vehicle traveling on a road, such as vehicle 100 above, can identify objects in its surrounding environment to determine adjustments to the current speed. The objects can be other vehicles, traffic control devices, or other types of objects. In some examples, each identified object can be considered independently, and based on the object's respective characteristics, such as its current speed, acceleration, spacing from the vehicle, etc., can be used to determine the speed to be adjusted by the autonomous vehicle.

[0088] Optionally, the vehicle 100 or a sensing and computing device associated with the vehicle 100 (e.g., computing system 131, computing platform 150) can predict the behavior of the identified object based on the characteristics of the identified object and the state of the surrounding environment (e.g., traffic, rain, ice on the road, etc.). Optionally, each identified object depends on the behavior of each other, so all the identified objects can also be considered together to predict the behavior of a single identified object. The vehicle 100 can adjust its speed based on the predicted behavior of the identified object. In other words, the autonomous vehicle can determine what stable state the vehicle will need to adjust to (e.g., accelerate, decelerate, or stop) based on the predicted behavior of the object. In this process, other factors can also be considered to determine the speed of the vehicle 100, such as the lateral position of the vehicle 100 in the road it is traveling on, the curvature of the road, the proximity of static and dynamic objects, etc.

[0089] In addition to providing instructions to adjust the speed of the autonomous vehicle, the computing device may also provide instructions to modify the steering angle of vehicle 100 so that the autonomous vehicle follows a given trajectory and / or maintains a safe lateral and longitudinal distance from objects near the autonomous vehicle (e.g., cars in adjacent lanes on the road).

[0090] The vehicle 100 may be a car, a truck, a motorcycle, a bus, a ship, an airplane, a helicopter, a lawn mower, an entertainment vehicle, an amusement park vehicle, construction equipment, a tram, a golf cart, a train, etc., and the embodiments of the present application do not make any particular limitation.

[0091] Figure 2 A system architecture diagram of a vehicle 100 based on some embodiments is shown, where the vehicle 100 includes multiple vehicle integration units (VIU) 11, a telematic box (T-BOX) 12, a cockpit domain controller (CDC), a mobile data center (MDC) 14, and a vehicle domain controller (VDC) 15.

[0092] The vehicle 100 also includes multiple types of sensors disposed on the vehicle body, including: a laser radar 21, a millimeter wave radar 22, an ultrasonic radar 23, and a camera 24. Each type of sensor may include multiple sensors. It should be understood that although Figure 2 FIG. 1 shows the location layout of different sensors on the vehicle 100 , but Figure 2 The number and position layout of the sensors are only for illustration, and those skilled in the art can reasonably select the type, number and position layout of the sensors according to their needs.

[0093] exist Figure 2 Four VIUs are shown, it should be understood that Figure 2 The number and position of the VIUs are only an example, and those skilled in the art can select the appropriate number and position of the VIUs according to actual needs.

[0094] The vehicle integrated unit VIU 11 provides part or all of the data processing functions or control functions required by the vehicle components for the vehicle components. The VIU may have one or more of the following functions.

[0095] 1. Electronic control function, that is, VIU is used to implement the electronic control function provided by the electronic control unit (ECU) inside some or all vehicle components. For example, the control function required by a certain vehicle component, and another example is the data processing function required by a certain vehicle component. The ECU mentioned in the following embodiments of this application can be an ECU deployed at any position in the vehicle. This application exemplarily takes the chip as an ECU as an example. In non-vehicle application scenarios, the ECU mentioned below can also be replaced by an MCU or other chips. The specific details can be determined according to the actual application scenario, and will not be repeated below.

[0096] 2. The same functions as the gateway, that is, the VIU may also have some or all of the same functions as the gateway, such as protocol conversion function, protocol encapsulation and forwarding function, and data format conversion function.

[0097] 3. The function of processing data across vehicle components, that is, processing and calculating data obtained from actuators of multiple vehicle components.

[0098] It should be noted that the data involved in the above functions may include the operating data of the actuator in the vehicle parts, such as the motion parameters of the actuator, the working status of the actuator, etc. The data involved in the above functions may also be data collected by the data collection unit (e.g., sensitive element) of the vehicle parts, such as the road information collected by the sensitive element of the vehicle, or weather information, etc., which is not specifically limited in the embodiments of the present application.

[0099] exist Figure 2 In the example of the vehicle 100, the vehicle 100 can be divided into multiple domains, each of which has an independent domain controller. Specifically, Figure 2 In the figure, two domain controllers are shown: a cockpit domain controller CDC13 and a vehicle domain controller VDC 15.

[0100] The cockpit domain controller CDC 13 can be used to implement functional control of the cockpit area of ​​the vehicle 100. Vehicle components in the cockpit area may include a head-up display (HUD), an instrument panel, a radio, a central control screen, a navigation, a camera, etc.

[0101] The vehicle domain controller VDC 15 may be used to coordinate and control the vehicle's power battery and engine 141 to improve the power performance of the vehicle 100. In some embodiments, Figure 1 The vehicle controller 132 can realize various functions of VDC.

[0102] Figure 2The figure also shows a vehicle networking device T-BOX 12 and a mobile data center MDC 13. T-BOX 12 can be used to realize the communication connection between the vehicle 100 and the internal and external devices of the vehicle. T-BOX can obtain the data of the in-vehicle devices through the bus of the vehicle 100, and can also communicate with the user's mobile phone through a wireless network. In some embodiments, T-BOX 12 can be included in Figure 1 The mobile data center MDC 13 is used to output driving, transmission, steering and braking execution control instructions based on core control algorithms such as environment perception positioning, intelligent planning decision and vehicle motion control to achieve automatic control of the vehicle 100, and can also achieve human-computer interaction of vehicle driving information through a human-computer interaction interface. In some embodiments, Figure 1 The computing platform 150 in can implement various functions of MDC 13.

[0103] exist Figure 2 The four VIUs 11 in the network form a ring topology connection network, each VIU 11 is connected to the sensor in its neighboring position, and the T-BOX 12, CDC 13, MDC 14 and VDC 15 are connected to the ring topology connection network of the VIU. The VIU 11 can obtain information from each sensor and report the obtained information to the CDC 13, MDC 14 and VDC 15. Through the ring topology network, the T-BOX 12, CDC 13, MDC 14 and VDC 15 can also communicate with each other.

[0104] It should be understood that the above ring topology network connection is only an illustration, and those skilled in the art can select other appropriate VIU connection methods according to requirements.

[0105] The connection between VIUs can adopt, for example, Ethernet, the connection between VIU and T-BOX 12, CDC 13, MDC 14 and VDC 15 can adopt, for example, Ethernet or peripheral component interconnect express (PCIe) bus, and the connection between VIU and sensors can adopt, for example, controller area network (CAN), local interconnect network (LIN), FlexRay, multimedia data transmission (MOST) and the like.

[0106] The vehicle's AUTOSAR can be divided into AP AUTOSAR and CP AUTOSAR. CP AUTOSAR can also be called classic AUTOSAR. The method provided in this application can be applied to AP AUTOSAR or CP AUTOSAR platforms. Among them, CP has been widely used in traditional automotive embedded ECUs, and can meet the needs of scenarios including engine controllers, brake controllers, etc. with high functional safety and real-time requirements but low computing power requirements, while AP is a new architecture proposed to meet the needs of the next generation of intelligent connected vehicles. The method provided in this application can be applied to the AP platform or the CP platform. The following is an exemplary introduction using the application to the CP platform as an example. The CP platform mentioned below can also be replaced by the AP platform.

[0107] Figure 3 The schematic diagram of the CP AUTOSAR architecture is shown. CP AUTOSAR can be divided into multiple layers from top to bottom: application software layer, runtime environment layer, basic software layer. CP AUTOSAR runs on the microcontroller unit.

[0108] Application Software (ASW): software that implements specific application functions. ASW can contain multiple software components (SWC).

[0109] Runtime Environment (RTE): It separates the application software layer from the basic software layer and provides a running environment for the application layer software, such as process time slice scheduling, data exchange between application layer modules and between the application layer and the basic software layer.

[0110] Basic Software (BSW): The basic software layer includes the following parts:

[0111] Microcontroller Abstraction Layer (MCAL): It is the driver software directly related to the hardware, such as the operation of memory, communication registers, IO ports, etc.

[0112] ECU Abstraction Layer (ECUAL): unifies the basic functions and interfaces of the controller, such as parsing the content of CAN messages, forwarding gateway messages, controlling the memory read and write processes, etc.

[0113] Services Layer: Provides various background services for the application layer, such as network management, memory management, bus communication management services, and operating systems.

[0114] Complex Device Drivers (CDD): Provides users with the possibility to write their own special device driver software.

[0115] In addition, AUTOSAR also provides a configuration toolchain for each level, which is used to configure the ECU configuration and generate dynamic code. The specific function is to configure parameters for each module based on the AUTOSAR model and generate configuration code for the corresponding parameters.

[0116] The compilation process of AUTOSAR can be divided into preprocessing, compilation, assembly and linking, etc. After the configuration is linked into an executable file, it can be burned into the chip, such as burning into the FLASH of the vehicle's ECU.

[0117] Usually, due to the huge size of the AUTOSAR system, different development roles will be differentiated in the actual ECU development to complete the development of the entire ECU. For example, it can be divided into original equipment manufacturers (OEMs), Tier-1 suppliers, or final integrators. Usually, after the OEM puts forward its requirements, Tier-1 configures and compiles the parameters according to the OEM's requirements, and sends the configured parameters to the OEM. The OEM configures the parameters or interfaces of the modules it depends on and compiles them. The final integrator connects the compiled data of Tier-1 and OEM into an executable file and burns it into the chip.

[0118] It should be noted that in this application, the OEM, Tier-1 or final integrator can perform parameter configuration, compilation or burning and other steps through development tools or development equipment. The steps performed by the OEM, Tier-1 or final integrator mentioned in the following embodiments of this application can all be performed by the development tools or development equipment used by the OEM, Tier-1 or final integrator, that is, the steps performed by the OEM, Tier-1 or final integrator mentioned below can be replaced by the development tools or development equipment as the entity execution, which will not be repeated below.

[0119] For example, in some solutions, the OEM proposes system requirements to Tier-1; Tier-1 integrates full configuration; Tier-1 develops and generates dynamic code for full configuration; Tier-1 provides RTE interface files to OEM; Tier-1 develops SWC for Tier-1 related services; Tier-1 compiles RTE interface, full configuration dynamic code, full static code and Tier-1 related service SWC to generate base software static library; OEM develops SWC for OEM related services based on RTE interface provided by Tier-1; OEM compiles OEM related service SWC code to generate OEM static library. Finally, the integrator links the base software static library and OEM static library into an executable file, and burns the executable file into the MCU for verification and release.

[0120] The configuration process coupling between Tier-1 and OEM leads to a contradiction between the rapid changes in OEM requirements and the response cycle of Tier-1, which hinders the development efficiency of OEM. There is a dependency between Tier-1 and OEM. For example, Tier-1 relies on the system requirements of OEM to develop all the configurations of the underlying software; OEM relies on the RTE interface provided by Tier-1 to develop SWC. The final integrator relies on the static library of the underlying software provided by Tier-1 and the corresponding OEM static library. The iterative development and verification of OEM relies on the static library of the underlying software and the RTE interface file provided by Tier-1. The requirements of OEM change frequently. For example, adding a function requires adding a communication matrix. The new requirements need to be proposed to Tier-1, and then Tier-1 configures the full configuration, generates the RTE interface, and generates the static library of the underlying software and provides it to the OEM. Then the OEM develops the relevant SWC code, compiles, and verifies it. The process of OEM developing a function is long and depends on Tier-1. This hinders the development efficiency of OEM.

[0121] It can be understood that in the existing solutions, since there is no decoupling between Tier-1 and OEM, OEM relies on Tier-1's RTE interface and underlying software static library in the development process. When the OEM's requirements change, the OEM needs to put forward requirements to Tier-1. Only after Tier-1 provides RTE interface and underlying software static library can the OEM continue to develop functional SWC. In this way, the OEM's development efficiency is extremely low.

[0122] Therefore, the present application provides a parameter configuration method, which can reduce the degree of coupling between OEM and Tier-1, perform decoupled configuration at multiple stages in the ECU development or configuration process, and improve configuration efficiency.

[0123] First, for ease of understanding, the structure of a parameter configuration system provided by the present application is introduced. Figure 4, a structural diagram of a parameter configuration system provided by the present application is described as follows.

[0124] The parameter configuration system provided in the present application may include an OEM and a Tier-1. A wired or wireless communication connection is established between the OEM and the Tier-1 for data transmission.

[0125] In this application, the OEM can put forward requirements for the functions to be implemented, configure the modules it depends on, and compile them.

[0126] Tier-1 can configure public parameters based on OEM requirements, configure the modules it depends on, compile the configured data, and send the configured public parameters to the OEM so that the OEM can configure the modules it depends on based on the public configuration data.

[0127] Optionally, a final integrator may also be included. The functions of the final integrator may be integrated into the OEM, or may be integrated into the Tier-1, or may be a separately set development device, etc. The final integrator may be used to link the data compiled by the OEM and the data compiled by the Tier-1 into an executable file and write it into the chip.

[0128] The following is a detailed description of the steps performed by each device.

[0129] See also Figure 5 , a flow chart of a parameter configuration method provided in this application is described as follows.

[0130] It should be noted that the method provided in this application may include multi-party interaction. This application exemplarily introduces OEM (also known as the second development equipment) and Tier-1 (also known as the first development equipment) as examples.

[0131] 501. Tier-1 performs public configuration.

[0132] When Tier-1 determines that it is necessary to configure parameters of the vehicle, it can perform public configuration to obtain public configuration data, which may include parameters for resource allocation in the vehicle.

[0133] Among them, Tier-1 can actively trigger public configuration, or after receiving demand data sent by OEM, public configuration can be triggered by the demand data. In this application, for example, Tier-1 receives demand data sent by OEM, and the demand data can be used to instruct Tier-1 to perform public configuration to obtain public configuration data.

[0134] For example, Tier-1 can configure hardware resources for the ASW, BSW or RTE layer of each ECU in the vehicle, such as allocating storage resources, instance ID and other information to each module.

[0135] In a possible implementation, the OEM may send demand data to Tier-1, and the demand data may be used to instruct Tier-1 to perform public configuration. The demand data may carry resource requirements to be configured, such as hardware resource requirements or storage resource requirements. After receiving the demand data, Tier-1 may perform public configuration based on the demand data, thereby allocating hardware resources in the vehicle and obtaining public configuration data.

[0136] Specifically, the public configuration data may include one or more of the following: hardware resource configuration, system resource configuration, or at least one of the resource configurations of at least one module, the hardware resource configuration includes the chip type, the number of chip cores, CAN protocol hardware resources, or at least one of the storage resources, the system resource configuration includes task resources or memory resources, and the resource configuration of at least one module includes at least one of the instance identifier, number of instances, or pre-compiled macro switches of at least one module.

[0137] 502. Tier-1 sends public configuration data to OEM.

[0138] After the Tier-1 configuration obtains the public configuration data, it sends the public configuration data to the OEM.

[0139] Among them, Tier-1 can send the full amount of public configuration data to the OEM, or only send the public configuration data required by the OEM. The specific adjustment can be made according to the actual application scenario, and this application does not limit this.

[0140] In addition, Tier-1 also has fixed static codes, namely source files, which are usually used to implement the logic of each module in the chip. Tier-1 can also send header files in the static code to OEMs so that OEMs can call algorithms or other content in the static code through the header files to implement the required functions.

[0141] 503. Tier-1 performs instance configuration according to the public configuration data to obtain first instance configuration data.

[0142] After Tier-1 performs public configuration to obtain public configuration data, instance configuration can be performed based on the public configuration data. Specifically, the parameters of each module that Tier-1 depends on can be configured to obtain instance configuration data, which is referred to as first instance configuration data for ease of distinction.

[0143] For example, the first instance configuration data obtained by the Tier-1 configuration may include at least one of the BSW configuration, RTE configuration, or SWC configuration on which it depends.

[0144] In addition, Tier-1 can configure instances in a variety of ways, such as by reference or by model tree. The reference method includes adding reference items to the configuration model, and the reference items are used to reference instance configuration parameters. The model tree method includes modifying the configuration model and configuring instance parameters based on the modified configuration model.

[0145] It should be noted that the present application does not limit the execution order of step 502 and step 503, that is, Tier-1 can execute step 502 first, or step 503 first, or execute step 502 and step 503 at the same time. The specific order can be determined according to the actual application scenario. This is only an exemplary description and is not intended to be limiting.

[0146] 504. Tier-1 compiles according to the common configuration data and the first instance configuration data to obtain a first static library.

[0147] After Tier-1 performs instance configuration to obtain the first instance configuration, a common configuration dynamic code and a first instance configuration dynamic code can be generated according to the common configuration data and the first instance configuration data, respectively. The common configuration dynamic code and the first instance configuration dynamic code are then compiled, that is, the common configuration dynamic code and the first instance configuration dynamic code are compiled into binary data to obtain a static library, which is called the first static library for easy distinction.

[0148] Optionally, when Tier-1 is compiled, static code can also be compiled at the same time. That is, the common configuration dynamic code, the first instance configuration dynamic code and the static code can be compiled, and the static code can include all or part of the global static code. Therefore, during the compilation process, multiple configurations required for chip operation can be compiled to obtain a complete static library.

[0149] 505. The OEM performs instance configuration according to the public configuration data to obtain second instance configuration data.

[0150] After the OEM receives the public configuration data sent by Tier-1, it can perform instance configuration on the modules it depends on according to the instance configuration resources included in the public configuration data to obtain instance configuration data, which is called second instance configuration data for easy distinction.

[0151] Specifically, the OEM may perform instance configuration according to resources of at least one second module included in the public configuration data, and the at least one second module may include a module having a dependency relationship with the OEM.

[0152] Optionally, the OEM configures one or more of the dynamic code for BSW, the dynamic code for RTE, or the RTE interface file required for SWC.

[0153] 506. The OEM compiles according to the second instance configuration data to obtain a second static library.

[0154] After the OEM performs instance configuration to obtain the second instance configuration data, dynamic code can be generated according to the second instance configuration data, which is referred to as the second instance configuration dynamic code, and the second instance configuration dynamic code is compiled to obtain a static library, which is referred to as the second static library for easy distinction.

[0155] 507. Write the second static library and the first static library into the chip.

[0156] After the first static library and the second static library are compiled, the first static library and the second static library can be linked into an executable file and burned into the chip.

[0157] In a possible implementation, step 507 may be performed by the OEM. Tier-1 may send the first static library to the OEM, and the OEM may link the first static library and the second static library into an executable file and burn the executable file into the chip.

[0158] In a possible implementation, step 507 may be performed by Tier-1. After compiling the second static library, the OEM may send the second static library to Tier-1, and Tier-1 may link the first static library and the second static library into an executable file and burn it into the chip.

[0159] In addition, in another possible implementation, step 507 may also be performed by a third-party device. If a third-party device can be set, Tier-1 may send the first static library to the third-party device, and the OEM may send the second static library to the third-party device, and the third-party device may link the first static library and the second static library into an executable file and burn it into the chip.

[0160] In the implementation manner of the present application, during the parameter configuration process, Tier-1 can first perform public configuration and send the public configuration data to the OEM. The OEM can perform instance configuration based on the received public configuration data, and Tier-1 can also perform instance configuration alone. That is, in the configuration phase, it is divided into public configuration and instance configuration. The public configuration is configured by Tier-1, and the instance configuration is configured by Tier-1 and OEM respectively. The instance phases are decoupled from each other. Therefore, the instance configuration process of Tier-1 and OEM is decoupled, and instance configuration can be performed in parallel, which can improve configuration efficiency.

[0161] The above is an introduction to the method flow provided by the present application. The following is a more detailed introduction to the method provided by the present application in combination with specific application scenarios.

[0162] See also Figure 6 , a flow chart of another parameter configuration method provided by the present application is described as follows.

[0163] The method provided in this application can be divided into multiple parts, such as Figure 6 The parts shown in the figure are performed by Tier-1, the parts performed by OEM, and the parts performed by the final integrator.

[0164] Specifically, the OEM sends system requirements to Tier-1, and Tier-1 performs common configuration according to the system requirements sent by the OEM. Then, Tier-1 and the OEM can respectively perform instance configuration based on the common configuration.

[0165] After Tier-1 performs public configuration, it can perform instance configuration on the modules that Tier-1 depends on according to the public configuration data to obtain the bottom software instance configuration, that is, the first instance configuration data. The bottom software dynamic code is generated based on the configured bottom software instance configuration and the public configuration. The bottom software dynamic code is compiled into a bottom software static library, that is, the first static library.

[0166] Based on the full or partial public configuration sent by Tier-1, the OEM can perform instance configuration on the module that the OEM depends on according to the received data to obtain the OEM instance configuration, that is, the second instance configuration data. The OEM instance configuration is used to generate dynamic code, and the dynamic code is compiled into an OEM static library.

[0167] The final integrator links the base software static library and the OEM static library into an executable binary file. The final integrator can be an OEM, a Tier-1, or a third-party device that is set up separately. The binary file can be burned into the vehicle's ECU.

[0168] Specifically, taking the configuration applied to a vehicle as an example, the steps performed by the OEM and Tier-1 can be as follows: Figure 7 shown.

[0169] Steps performed by the OEM may include:

[0170] First, define the network and generate a system requirements file in .arxml format or other formats. For example, OEMs can generate vehicle hardware resource requirements and public configuration requirements.

[0171] Receive the public configuration data of Tier-1 configuration, and configure the BSW configuration and RTE configuration that the OEM depends on.

[0172] Generate OEM instance dynamic code.

[0173] Define and implement SWC business configuration related to OEM business.

[0174] Deploy the OEM's SWC configuration.

[0175] Compile OEM instance dynamic code and OEM SWC code to form OEM static library files.

[0176] Send OEM static library files to the final integrator.

[0177] The steps performed by Tier-1 may include:

[0178] Receive system requirement files sent by OEM and perform public configuration according to the system requirements proposed by OEM.

[0179] The configured public configuration data is sent to the OEM.

[0180] Configure the BSW configuration and RTE configuration of Tier-1 according to the common configuration data.

[0181] Generates public configuration dynamic code and Tier-1 instance dynamic code.

[0182] Define and implement SWC services related to Tier-1 services.

[0183] Deploy Tier-1 SWC services.

[0184] Compile the public configuration dynamic code, static code, Tier-1 instance dynamic code, and Tier-1 SWC business code to obtain the bottom software static library file.

[0185] And send the base software static library file to the final integration room.

[0186] The following is a more detailed description of the steps performed by OEM and Tier-1 respectively.

[0187] Generally, the parameter configuration process can be divided into the configuration phase, the code generation phase, and the compilation phase.

[0188] During the configuration phase, this application is divided into public configuration and instance configuration. The public configuration is configured by Tier-1, and the instance configuration is configured by Tier-1 and OEM respectively. The configuration phases are decoupled from each other.

[0189] In the code generation stage, the configuration has been divided into common configuration and instance configuration; in the code generation stage, Tier-1 and OEM independently generate their own dynamic code and RTE interface, so that they are unaware of each other's existence, completing decoupling, independent development and evolution.

[0190] During the compilation phase, since the generated codes are different, the files responsible for compilation are also different. Tier-1 compiles the public configuration dynamic code + static code + Tier-1 instance dynamic code + SWC of the business developed by Tier-1 into a Tier-1 static library, and OEM compiles the OEM instance dynamic code + SWC of the business developed by OEM into an OEM static library.

[0191] Each stage is described in more detail below.

[0192] 1. Configuration Phase

[0193] like Figure 8 As shown in Figure 1, the OEM generates requirements and proposes system requirements to Tier-1, which may include the required hardware requirements and public configuration requirements.

[0194] Tier-1 is responsible for configuring the public configuration. Specifically, it can be configured for the hardware resources in the vehicle. For modules that require multiple configuration instance solutions, such as using multiple instance solutions for RTE and BSW modules, Tier-1 can be responsible for allocating multiple instances for Tier-1 and OEMs, assigning unique instance numbers to each instance of each module, etc., and sending public configuration data to the OEM.

[0195] Specifically, the common configuration may include but is not limited to one or more of the following:

[0196] Hardware common configuration: one or more of the following: chip type, number of cores used, CAN hardware configuration (such as CAN hardware controller configuration, Hoh configuration), storage hardware configuration, etc.;

[0197] System (OS) common configuration: task configuration, memory protection, etc.;

[0198] The common configuration of each module: one or more of the module instances, the instance ID of each instance, the number of instances, the pre-compiled macro switches of each module, etc.

[0199] 2. Instance Configuration Phase

[0200] like Fig. 9 As shown, Tier-1 is responsible for configuring the specific business configuration of the Tier-1 instance, and OEM is responsible for configuring the specific business configuration of the OEM instance.

[0201] There are many ways to configure the instance, such as a reference method or a model tree configuration method.

[0202] In the reference mode: the configuration model maintains the original structure, adds an instance configuration item page, and configures simple instance information on the instance configuration item page. The business uses the reference mode to reference the instance configuration. The business that references a certain instance is the business of the instance. For example, Fig.10 As shown, reference items can be added to each module, and the instance configured for each module can be referenced through the reference items.

[0203] In the model tree configuration mode: you can modify the configuration model to expand the module's business configuration set from the original 1 to n, and each business configuration set is an instance. Fig.11 As shown in the figure, add the instance configuration of Tier-1 and OEM configuration to the module that needs instance configuration.

[0204] 3. Code Generation Phase

[0205] OEMs and Tier-1s generate their own dynamic codes based on the public configuration and their own instance configurations.

[0206] The OEM's dynamic code includes the dynamic code of the configuration of the BSW module that the OEM relies on, the dynamic code of the RTE configuration, and the RTE interface file required by the OEM's SWC.

[0207] The dynamic code of Tier-1 includes the dynamic code of the common configuration, the dynamic code of the configuration of the BSW module that Tier-1 depends on, the dynamic code of the RTE configuration, and the interface file of the RTE required by the SWC of Tier-1.

[0208] Before the code generation stage, you can define the structure. In the code generation stage, you can generate dynamic code based on the definition of the structure.

[0209] For example, for a multi-instance module, the InstanceType structure can be abstracted. In the overall configuration structure, the number of Instances is determined according to the number of instances in the public configuration, reflecting multiple instances.

[0210] If it can be expressed as:

[0211]

[0212]

[0213] Among them, each field indicates: CanIf_PublicInfoType is the dynamic code generated by the public configuration of the CanIf module, CanIf_InstanceType is the dynamic code generated by the instance configuration of the CanIf module. CanIf_ConfigType is a global structure that stores the CanIf public configuration and CanIf instance configuration.

[0214] The method for allocating the ID of each instance may include: taking the communication module in the vehicle as an example, each communication interface has a parameter such as Pdu Id, which uniquely identifies a Pdu. When the communication interface parameter remains unchanged, the Pdu Id needs to carry InstanceId information to indicate which instance the Pdu belongs to. Since each instance can generate a dynamic code separately, the Pdu Id cannot be allocated arbitrarily. In the present invention, an extended PduId allocation method and a maximum Pdu number allocation method are proposed.

[0215] Extended PduId allocation method: Mask the InstanceId in the PduId to the high byte of the PduId. For example, PduId = (instanceId << (16-nbit)) | instancePduId. The instanceId is a global configuration and has been allocated in the public configuration. The instancePduId is the PduId of the Pdu in the Instance. It is a unique configuration for the instance. In this way, the InstanceId information can be parsed from the PduId.

[0216] Maximum Pdu number allocation method: In the public configuration, a maximum number of Pdus is allocated to each instance. For example, if the maximum number of Pdus allocated to the Tier-1 CanIf instance is 1000, then the Tier-1 CanIf instance must not be configured with more than 1000 Pdus. If the maximum number of Pdus allocated to the OEM CanIf instance is 2000, then the OEM CanIf instance must not be configured with more than 2000 Pdus. If the PduId falls within a certain range, it is the Pdu of a certain instance.

[0217] In addition to the ID allocation method, the communication interface can also be extended. The existing AUTOSAR does not support multiple instances, and there is no instance ID information in the communication interface. The communication interface can be extended to add instance ID parameters to indicate the instance.

[0218] The above example is a method for processing a communication stack ID in multiple instances, which can also be replaced by a storage stack or other stacks, etc., which will not be described in detail here.

[0219] 4. Compile + Link + Integration Phase

[0220] like Fig.12As shown in the figure, Tier-1 compiles static code + common configuration dynamic code + Tier-1 instance dynamic code to generate the base software static library. OEM only compiles OEM instance dynamic code to generate OEM static library. The compilation process is independent of each other. The final integrator links the base software static library compiled by Tier-1 and the OEM static library compiled by OEM into a complete executable binary.

[0221] For example, according to the structure definition in the code generation phase, how to initialize the instance information of CanIf into CanIf_ConfigType is an important part of the multi-instance solution. In the stage of generating global configuration code, fill the global variable name of the instance into CanIf_ConfigType. In the compilation phase, after compiling the Tier-1 static library and the OEM static library, link them, such as Fig.13 As shown, a full binary executable file is generated.

[0222] In the registration phase, instance variable names are not filled. When generating dynamic code, the module's global CanIf_ConfigType does not fill in the variable addresses of all instances. The module initialization action is completed by the AutoSar ECUM module through configuration. The registration information is configured in the ECUM module, and the instance information is registered in the module's global ConfigType, such as Fig.14 shown.

[0223] For example, the registration process can be expressed as:

[0224]

[0225]

[0226] 5. Burn + Run

[0227] For example, Fig.15 As shown in the figure, after compiling and linking into a complete executable binary, the binary can be burned into the MCU for operation. During the development process, Tier-1 is responsible for the development of Tier-1 instances, and OEM is responsible for the development of OEM instances. During operation, taking the sending of Can messages as an example, when Tier-1 services send Can messages, they will only access the configuration data of the global configuration and the configuration data of the Tier-1 instance; when OEM services send Can messages, they will only access the configuration data of the global configuration and the configuration data of the OEM instance.

[0228] Specifically, take the sending of a newly added Can service message by OEM as an example.

[0229] The parameter configuration part in the vehicle is divided into public configuration and instance configuration. The public configuration is the configuration for the hardware resources in the vehicle, and the instance configuration is the configuration for each operating module in the vehicle. The public configuration is configured by Tier-1 and distributed to OEMs; the instance configuration is a private configuration, and each instance configuration is maintained independently. For example, the OEM instance configuration is maintained by the OEM, and the Tier-1 instance configuration is maintained by Tier-1. The business development between Tier-1 and OEM is decoupled from each other.

[0230] When OEM adds new business functions during the development iteration process, it needs to add Can messages as the carrier of communication services. Then OEM does not need to strongly rely on Tier-1 in the method provided by this application. In the instance part, it can independently develop, test and verify, etc., which can speed up the development rhythm.

[0231] Specific steps that the OEM may perform may include:

[0232] After making a request to Tier-1, receive the public configuration sent by Tier-1.

[0233] Configure the OEM instance, add the Can message signal, and add the Can message routing information.

[0234] Regenerate OEM instance dynamic code, including OEM instance BSW dynamic code and OEM instance RTE dynamic code.

[0235] Develop SWC code for corresponding functions.

[0236] Compile OEM static library.

[0237] Combined with the static library of the underlying software provided by the previous Tier-1, it is linked into a complete binary executable file.

[0238] Burn the complete binary executable file into the MCU for testing and functional verification.

[0239] Therefore, in the implementation manner of the present application, after Tier-1 performs public configuration, the OEM can perform instance configuration based on the received public configuration. That is, the configuration of the AUTOSAR module is divided into public configuration and instance configuration, which can realize the secondary development decoupling technology of multiple instances. During the development process, all development parties only rely on public configurations with lower frequency of changes for development. The development processes are independent of each other and no longer strongly dependent, which effectively improves the development efficiency of each party. Reduce the mutual dependence between OEM and Tier-1 during the secondary development process, thereby improving their respective development efficiency. At the same time, since each party maintains its own key assets such as configuration, the confidentiality of their respective configurations can also be improved.

[0240] The above is an introduction to the method flow provided by the present application. The following is an introduction to the device for executing the method flow in combination with the above method flow.

[0241] See also Fig.16 , a schematic diagram of a parameter configuration device provided in the present application, which can be used to perform the aforementioned Figures 5 to 15 In the steps performed by Tier-1, the parameter configuration device may specifically include:

[0242] The processing module 1601 is used to perform public configuration and obtain public configuration data, where the public configuration data includes parameters for resource allocation in the vehicle. For example, the first development device can allocate hardware resources or software resources in the vehicle and generate corresponding configuration parameters;

[0243] The transceiver module 1602 is used to send the common configuration data to the second development device, so that the second development device can perform instance configuration on the module it depends on based on the common configuration data; the first development device also performs instance configuration according to the common configuration data to obtain first instance configuration data;

[0244] Processing module 1601 is also used to compile according to the public configuration data and the first instance configuration data to obtain a first static library. The first static library and the second static library are used to write into the chip so that the chip runs according to the written configuration. The second static library is compiled by the second development device after the instance configuration is performed according to the public configuration data.

[0245] In a possible implementation, the processing module 1601 is specifically used to: in the process of configuring the public configuration, software resource configuration can be performed, such as allocating soft resources to each module, and in the process of instance configuration, the first development device can perform instance configuration based on the resources of at least one module (referred to as the first module for easy distinction) included in the public configuration to obtain the first instance configuration data, and the at least one first module includes a module with a dependency relationship with the first development device. Therefore, the first development device performs instance configuration after completing the public configuration, realizing the decoupling of the public configuration and the instance configuration, so that the instance configuration process of the modules that each party depends on can be parallelized, thereby improving the parameter configuration efficiency.

[0246] In a possible implementation, the aforementioned first instance configuration data includes at least one of the basic software layer BSW configuration, the runtime environment layer RTE configuration, or the software component SWC configuration. Therefore, the first development device can configure the BSW, RTE, or SWC configuration it relies on, such as the interface file required by SWC, so as to implement the function development on the first development device side.

[0247] In one possible implementation, the processing module 1601 is specifically used for: the first development device performs instance configuration according to the resources of at least one first module included in the common configuration through a reference method or a model tree method to obtain first instance configuration data, the reference method includes adding a reference item in the configuration model, and the reference item is used to reference the instance configuration parameters, and the model tree method includes modifying the configuration model and configuring the instance parameters based on the modified configuration model.

[0248] In a possible implementation, the aforementioned public configuration data includes at least one of hardware resource configuration, system resource configuration, or resource configuration of at least one module, the hardware resource configuration includes at least one of chip type, number of chip cores, CAN protocol hardware resources, or storage resources, the system resource configuration includes task resources or memory resources, and the resource configuration of at least one module includes at least one of instance identifier, number of instances, or precompiled macro switch of at least one module.

[0249] In one possible implementation, the processing module 1601 is specifically used to: generate a common configuration dynamic code and a first instance dynamic code according to the common configuration data and the first instance configuration data, respectively; compile according to the common configuration dynamic code, the first instance dynamic code and the static code to obtain a first static library, and the static code is used to provide the header files required for each module or each function.

[0250] In a possible implementation, the transceiver module 1602 is further configured to send the first static library to the second development device, so that the second development device writes the first static library and the second static library into the chip.

[0251] In a possible implementation, the transceiver module 1602 is further used to receive the second static library sent by the second development device; the processing module 1601 is further used to link the first static library and the second static library into an executable file and write the executable file into the chip.

[0252] See also Fig.17 , a schematic diagram of another parameter configuration device provided in the present application, which can be used to perform the aforementioned Figures 5 to 15 The steps performed by the OEM in the parameter configuration device may specifically include:

[0253] The transceiver module 1701 is used to receive the public configuration data sent by the first development device, where the public configuration data includes parameters for resource allocation in the vehicle;

[0254] The processing module 1702 is used to perform instance configuration on the module it depends on according to the common configuration data to obtain second instance configuration data;

[0255] Processing module 1702 is also used to compile according to the second instance configuration data to obtain a second static library. The second static library and the first static library are used to write into the chip so that the chip runs according to the written configuration. The first static library is compiled by the first development device according to the public configuration data and the first instance configuration data. The first instance configuration data includes the instance configuration performed by the first development device according to the public configuration data.

[0256] In a possible implementation manner, the transceiver module 1701 is further configured to send requirement data to the first development device, where the requirement data is used to instruct the first development device to configure the common configuration data.

[0257] In a possible implementation, the processing module 1702 is further configured to perform instance configuration according to resources of at least one second module included in the common configuration data to obtain second instance configuration data, wherein the at least one second module includes a module having a dependency relationship with the second development device.

[0258] In a possible implementation, the aforementioned second configuration data may include at least one of a basic software layer BSW configuration, a runtime environment layer RTE configuration, and a software component SWC configuration.

[0259] In one possible implementation, processing module 1702 is specifically used for the second development device to perform instance configuration according to the resources of at least one second module included in the common configuration through a reference method or a model tree method to obtain first instance configuration data. The reference method includes adding a reference item in the configuration model, and the reference item is used to reference the instance configuration parameters. The model tree method includes modifying the configuration model and configuring the instance parameters based on the modified configuration model.

[0260] In a possible implementation, the aforementioned public configuration data includes at least one of hardware resource configuration, system resource configuration, or resource configuration of at least one module, the hardware resource configuration includes at least one of chip type, number of chip cores, CAN protocol hardware resources, or storage resources, the system resource configuration includes task resources or memory resources, and the resource configuration of at least one module includes at least one of instance identifier, number of instances, or precompiled macro switch of at least one module.

[0261] In a possible implementation, the transceiver module 1701 is further used to receive the first static library sent by the first development device; the second development device links the first static library and the second static library into an executable file and writes it into the chip. Therefore, the second development device can link the first static library and the second static library into an executable file and write it into the chip, thereby realizing the functions that the chip needs to execute.

[0262] In a possible implementation, the transceiver module 1701 is also used for the second development device to send the second static library to the first development device, so that the first development device writes the first static library and the second static library into the chip. Therefore, the first development device can also link the first static library and the second static library into an executable file and write them into the chip, thereby realizing the functions that the chip needs to execute.

[0263] like Fig.18 FIG. 1 is a schematic diagram of the hardware structure of a computer device 180 provided in an embodiment of the present application. The computer device 180 can be used to implement the functions of the first development device or the second development device, such as Tire-1 or OEM.

[0264] Fig.18 The computer device 180 shown may include: a processor 1801 , a memory 1802 , a communication interface 1803 , and a bus 1804 . The processor 1801 , the memory 1802 , and the communication interface 1803 may be connected via a bus 1804 .

[0265] The processor 1801 is the control center for generating the computer device 180, and may be a general-purpose central processing unit (CPU) or other general-purpose processors, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0266] As an example, the processor 1801 may include one or more CPUs, such as Fig.18 CPU 0 and CPU 1 are shown in .

[0267] The memory 1802 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

[0268] In one possible implementation, the memory 1802 may exist independently of the processor 1801. The memory 1802 may be connected to the processor 1801 via a bus 1804 and used to store data, instructions, or program codes. When the processor 1801 calls and executes the instructions or program codes stored in the memory 1802, the parameter configuration method provided in the embodiment of the present application can be implemented.

[0269] In another possible implementation, the memory 1802 may also be integrated with the processor 1801 .

[0270] The communication interface 1803 is used for connecting the computer device 180 with other devices through a communication network, and the communication network may be Ethernet, a radio access network (RAN), a wireless local area network (WLAN), etc. The communication interface 1803 may include a receiving unit for receiving data and a sending unit for sending data.

[0271] The bus 1804 may be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.18 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0272] It should be pointed out that Fig.18 The structure shown in the figure does not constitute a limitation on the computer device 180, except Fig.18 In addition to the components shown, computer device 180 may include more or fewer components than shown, or combine certain components, or arrange components differently.

[0273] Optionally, the aforementioned Fig.18 The parameter configuration device shown in is a chip.

[0274] The present application also provides a digital processing chip. The digital processing chip integrates the Figure 6-Figure 14The parameter configuration device or its functional circuit and one or more interfaces shown in the digital processing chip. When the digital processing chip integrates a memory, the digital processing chip can complete the method steps of any one or more embodiments in the aforementioned embodiments. When the digital processing chip does not integrate a memory, it can be connected to an external memory through a communication interface. The digital processing chip implements the actions performed by the control device in the aforementioned embodiments according to the program code stored in the external memory.

[0275] The present application also provides a computer program product which, when executed on a computer, enables the computer to execute the above Figure 5-Figure 15 The illustrated embodiment describes the steps performed by the parameter configuration device.

[0276] The data transmission device provided in the embodiment of the present application may be a chip, and the chip includes: a processing unit and a communication unit, the processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, a pin or a circuit. The processing unit may execute the computer execution instructions stored in the storage unit, so that the chip in the server executes the above Figure 5-Figure 15 The data transmission method described in the illustrated embodiment. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, etc. The storage unit may also be a storage unit located outside the chip in the wireless access device, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), etc.

[0277] Specifically, the aforementioned processing unit or processor may be a central processing unit (CPU), a neural-network processing unit (NPU), a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0278] The processor mentioned in any of the above can be a general-purpose central processing unit, a microprocessor, an ASIC, or one or more processors for controlling the above Figure 5-Figure 15 The steps of a program are performed by an integrated circuit.

[0279] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0280] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0281] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0282] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)), etc.

[0283] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

Claims

1. A parameter configuration method, characterized in that: The method comprises: The first development device performs public configuration to obtain public configuration data, wherein the public configuration data includes parameters for resource allocation in the vehicle; The first development device sends the common configuration data to the second development device; The first development device performs instance configuration according to the public configuration data to obtain first instance configuration data; The first development device compiles according to the public configuration data and the first instance configuration data to obtain a first static library. The first static library and the second static library are used to write into the chip so that the chip runs according to the written configuration. The second static library is compiled by the second development device after performing instance configuration according to the public configuration data.

2. The method according to claim 1, characterized in that: The first development device performs instance configuration according to the public configuration data to obtain first instance configuration data, including: The first development device performs instance configuration according to resources of at least one first module included in the common configuration to obtain the first instance configuration data, wherein the at least one first module includes a module having a dependency relationship with the first development device.

3. The method according to claim 2, characterized in that The first instance configuration data includes at least one of a basic software layer BSW configuration, a runtime environment layer RTE configuration, or a software component SWC configuration.

4. The method according to claim 2 or 3, characterized in that: The first development device performs instance configuration according to resources of at least one first module included in the common configuration to obtain the first instance configuration data, including: The first development device performs instance configuration according to the resources of at least one first module included in the common configuration through a reference method or a model tree method to obtain the first instance configuration data. The reference method includes adding a reference item in the configuration model, and the reference item is used to reference the instance configuration parameters. The model tree method includes modifying the configuration model and configuring the instance parameters based on the modified configuration model.

5. The method according to any one of claims 1 to 4, characterized in that The public configuration data includes at least one of hardware resource configuration, system resource configuration or resource configuration of at least one module, the hardware resource configuration includes at least one of chip type, number of chip cores, CAN protocol hardware resources or storage resources, the system resource configuration includes task resources or memory resources, and the resource configuration of at least one module includes at least one of instance identifier, number of instances or pre-compiled macro switch of at least one module.

6. The method according to any one of claims 1 to 5, characterized in that The first development device performs public configuration to obtain public configuration data, including: The first development device acquires the demand data sent by the second development device; The first development device performs common configuration under the instruction of the requirement data to obtain the common configuration data.

7. The method according to any one of claims 1 to 6, characterized in that The first development device compiles according to the common configuration data and the first instance configuration data to obtain a first static library, including: The first development device generates a common configuration code according to the common configuration data, and generates a first instance dynamic code according to the first instance configuration data; The first development device compiles the common configuration dynamic code, the first instance dynamic code and the static code to obtain the first static library, and the static code is used to provide a header file.

8. The method according to any one of claims 1 to 7, characterized in that The method further comprises: The first development device sends the first static library to the second development device, so that the second development device writes the first static library and the second static library into the chip.

9. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: The first development device receives the second static library sent by the second development device; The first development device links the first static library and the second static library into an executable file and writes the executable file into the chip.

10. A parameter configuration method, characterized in that: include: The second development device receives the public configuration data sent by the first development device, wherein the public configuration data includes parameters for resource allocation in the vehicle; The second development device performs instance configuration according to the public configuration data to obtain second instance configuration data; A second static library is compiled according to the second instance configuration data. The second static library and the first static library are used to write into the chip so that the chip runs according to the written configuration. The first static library is compiled by the first development device according to the public configuration data and the first instance configuration data. The first instance configuration data includes the instance configuration performed by the first development device according to the public configuration data.

11. The method according to claim 10, characterized in that The method further comprises: The second development device sends requirement data to the first development device, where the requirement data is used to instruct the first development device to configure the common configuration data.

12. The method according to claim 10 or 11, characterized in that: The second development device performs instance configuration according to the common configuration data to obtain second instance configuration data, including: The second development device performs instance configuration according to resources of at least one second module included in the common configuration data to obtain the second instance configuration data, wherein the at least one second module includes a module having a dependency relationship with the second development device.

13. The method according to claim 12, characterized in that The second configuration data includes at least one of a basic software layer BSW configuration, a runtime environment layer RTE configuration, and a software component SWC configuration.

14. The method according to claim 12 or 13, characterized in that The second development device performs instance configuration according to resources of at least one second module included in the common configuration to obtain the second instance configuration data, including: The second development device performs instance configuration according to the resources of at least one second module included in the common configuration through a reference method or a model tree method to obtain the first instance configuration data. The reference method includes adding a reference item in the configuration model, and the reference item is used to reference the instance configuration parameters. The model tree method includes modifying the configuration model and configuring the instance parameters based on the modified configuration model.

15. The method according to any one of claims 10 to 14, characterized in that The public configuration data includes at least one of hardware resource configuration, system resource configuration or resource configuration of at least one module, the hardware resource configuration includes at least one of chip type, number of chip cores, CAN protocol hardware resources or storage resources, the system resource configuration includes task resources or memory resources, and the resource configuration of at least one module includes at least one of instance identifier, number of instances or pre-compiled macro switch of at least one module.

16. The method according to any one of claims 10 to 15, characterized in that The method further comprises: The second development device receives the first static library sent by the first development device; The second development device links the first static library and the second static library into an executable file and writes the executable file into the chip.

17. The method according to claim 16, characterized in that The method further comprises: The second development device sends the second static library to the first development device, so that the first development device writes the first static library and the second static library into the chip.

18. A parameter configuration device, characterized in that: include: A transceiver module, used to execute the step of receiving data or sending data executed by the first development device as claimed in any one of claims 1 to 9; as well as A processing module, used to execute the step of processing data executed by the first development device as claimed in any one of claims 1 to 9.

19. A parameter configuration device, characterized in that: include: A transceiver module, used to execute the step of receiving data or sending data executed by the second development device as claimed in any one of claims 10 to 17; as well as A processing module, used to execute the step of processing data executed by the second development device as claimed in any one of claims 10 to 17.

20. A parameter configuration device, characterized in that: The method comprises a processor coupled to a memory, wherein the memory stores a program, and when the program instructions stored in the memory are executed by the processor, the steps of the method according to any one of claims 1 to 9 or 10 to 17 are implemented.

21. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, which, when executed by a processor, causes the processor to perform the method according to any one of claims 1 to 9 or 10 to 17.

22. A computer program product, characterized in that The computer program product comprises software code for performing the steps of the method of any one of claims 1 to 9 or 10 to 17.

23. A parameter configuration system, characterized in that: include: A first development device, configured to perform the steps of the first development device as claimed in any one of claims 1 to 9; as well as The second development device is configured to execute the steps executed by the second development device as claimed in any one of claims 10 to 17.

Images