Data processing method and related equipment
Patent Information
- Application Number
- CN202280100008.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2022-09-29
- Publication Date
- 2025-04-18
AI Technical Summary
In the automotive open system architecture, multiple changes to application software modules by OEMs result in parts suppliers needing to frequently regenerate and integrate the operating environment, increasing delivery pressure and reducing the efficiency of application updates.
By obtaining user-generated configuration files and private library files, and using modeling tools and compilers to generate open library files, OEMs are allowed to independently update and integrate application software modules, reducing dependence on the basic software layer and improving update efficiency.
It realizes that parts suppliers only need to update the private library files in the basic software layer to complete the generation and integration of the running environment, which improves the efficiency of application updates and reduces the need for frequent adaptation of basic software.
Smart Images

Figure CN119856492A_ABST
Abstract
Description
A data processing method and related equipment Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a data processing method and related equipment. Background Art
[0002] AUTOSAR (Automotive Open System Architecture) is an alliance dedicated to developing automotive electronic software standards.
[0003] The AUTOSAR architecture is mainly divided into three layers: application layer (AppL), runtime environment (RTE) and basic software layer (BSW). Original equipment manufacturers (OEMs), such as automobile manufacturers, are responsible for providing AppL, while component suppliers are responsible for providing RTE, BSW and integration services.
[0004] However, during the R&D phase, OEMs will make multiple changes to the application software (i.e., AppL) or peripheral devices, which requires component suppliers to regenerate RTE and integrate multiple times. This undoubtedly increases the delivery pressure on component suppliers and greatly reduces the efficiency of application updates.
[0005] Summary of the Invention
[0006] The present invention provides a data processing method and related devices for improving the efficiency of application updates. The present invention also provides corresponding computer devices, computer-readable storage media, chip systems, and computer program products.
[0007] The first aspect of the present application provides a data processing method, which includes: obtaining a configuration file and a private library file generated by a first user; generating an open library file based on an application software module and a configuration file generated by a second user; and compiling the private library file and the open library file to obtain an executable file.
[0008] In this application, the first user is a parts supplier, such as an ECU supplier. The first user is responsible for providing BSW, so the first user will be responsible for providing and delivering configuration files and private library files. The second user is the OEM, which is responsible for updating the application software module (software component, SWC) in AppL, that is, the second user will update the application software module in AppL. The computer device uses modeling tools, configuration tools, Matlab or Simulink tools to generate open library files based on the updated SWC and the configuration file generated by the first user, and finally compiles the private library file and the open library file to obtain an executable file that can run on the ECU. The OEM completes the independent update of SWC and integration.
[0009] Regarding the first aspect, when the original equipment manufacturer updates the application software module, the component supplier only needs to make corresponding updates to the private library files that cannot be opened in the basic software layer. The original equipment manufacturer can complete the generation and integration of the operating environment by itself through the configuration files and private library files provided by the component supplier, thereby improving the efficiency of application updates.
[0010] In a possible implementation manner of the first aspect, the configuration file includes a software layer configuration file and an application layer configuration file, and the software layer configuration file includes an encrypted hidden configuration file.
[0011] In this possible implementation, the application layer configuration file is an AUTOSAR configuration file (AUTOSAR extensible markup language, ARXML) file, specifically an atomic service SWC configuration file and a device abstraction SWC configuration file. The software layer configuration file may be an ARXML configuration file related to the RTE / operating system (OS). For hidden configuration files, the first user does not allow the second user to access or operate them, so as to ensure the confidentiality of the first user's technology.
[0012] In a possible implementation of the first aspect, the open library file includes an application layer library file, an operating environment library file, and an operating system library file; the above-mentioned step of generating the open library file based on the application software module and configuration file generated by the second user includes: performing framework modeling based on the application software module and the application layer configuration file to generate a framework configuration file; performing behavior modeling based on the framework configuration file to generate an application layer library file; and compiling the framework configuration file and the software layer configuration file to generate an operating environment library file and an operating system library file.
[0013] In this possible implementation method, the open library files include the application layer library file (SWC.a), the runtime environment library file (RTE.a) and the operating system library file (OS.a). The application layer configuration file (atomic service SWC configuration file and device abstraction SWC configuration file) is used as part of the input. Combined with the updated SWC, the modeling tool is used to model the overall framework of the application layer and export the framework configuration file. The framework configuration file can be an ARXML file of a single SWC. The computer device continues to use the framework configuration file and uses Matlab or Simulink tools to perform behavioral modeling, generate relevant code, and finally compile the application layer library file (SWC.a). Based on the framework configuration file and the software layer configuration file, the configuration tool is used to generate code to compile the runtime environment library file (RTE.a) and the operating system library file (OS.a), thereby improving the feasibility of the solution.
[0014] In a possible implementation manner of the first aspect, the private library file includes a software layer library file, a hardware abstraction library file, a device abstraction library file, and an atomic service library file.
[0015] In this possible implementation, the private library files specifically include the software layer library file (BSW.a), the hardware abstraction library file (MCAL.a), the device abstraction library file (SWC.a) and the atomic service library file (SWC.a), which improves the feasibility of the solution.
[0016] In a possible implementation of the first aspect, the step of obtaining the configuration file and the private library file generated by the first user includes obtaining the configuration file and the private library file generated by the first user through a proxy interface.
[0017] In this possible implementation, the service interfaces in BSW are moved to AppL, and the second user can call these interfaces in AppL by himself. That is, the second user can obtain the configuration files and private library files generated by the first user through various proxy interfaces, reducing the frequency of the first user adapting BSW according to the needs of the second user.
[0018] In a possible implementation of the first aspect, the method further includes: obtaining a first configuration file generated by a first user and an encrypted second configuration file; updating the first configuration file and generating an updated library file based on the second configuration file and the updated first configuration file; and compiling based on the updated library file to obtain a new executable file.
[0019] In this possible implementation, the OEM can also independently configure the communication protocol stack or the diagnostic protocol stack, thereby improving the feasibility of the solution.
[0020] A second aspect of the present application provides a data processing method, which includes: obtaining a private file and an application layer configuration file generated by a first user; generating a first private library file and a software layer configuration file based on the private file; and generating a second private library file based on the application layer configuration file, so that a second user can generate an executable file based on the application layer configuration file, the software layer configuration file, the first private library file, and the second private library file.
[0021] In this application, the first user will pre-generate the private files and application layer configuration files of BSW. The private files can specifically be the controller area network (CAN) communication matrix (data base CAN, DBC) file and the Ethernet communication AUTOSAR configuration file (AUTOSAR extensible markup language, ARXML) file. The DBC file can specifically include CAN bus files and local interconnect network (LIN) bus files, etc. The application layer configuration file is an ARXML file, which can specifically be the atomic service SWC configuration file and the device abstraction SWC configuration file.
[0022] After obtaining the DBC file, use the configuration tool to configure it and generate dynamic code, and then use the compiler and / or linker to compile the first private library file. In addition, the software layer configuration file can also be exported from the configuration tool. The software layer configuration file can be an ARXML configuration file related to RTE / OS.
[0023] Regarding the second aspect, when the original equipment manufacturer updates the application software module, the component supplier only needs to make corresponding updates to the private library files that cannot be opened in the basic software layer. The original equipment manufacturer can complete the generation and integration of the operating environment by itself through the configuration files and private library files provided by the component supplier, thereby improving the efficiency of application updates.
[0024] In a possible implementation manner of the second aspect, the software layer configuration file includes an encrypted hidden configuration file, and the method further includes: encrypting a portion of the configuration files in the software layer configuration file to obtain the encrypted hidden configuration file.
[0025] In this possible implementation, the software layer configuration file may be an ARXML configuration file related to the RTE / operating system (OS). For hidden configuration files, the first user does not allow the second user to access or operate them, so as to ensure the confidentiality of the first user's technology.
[0026] In a possible implementation of the second aspect, the step of generating the second private library file based on the application layer configuration file includes performing behavior modeling based on the application layer configuration file to generate the second private library file.
[0027] In this possible implementation, after obtaining the application layer configuration file, Matlab or Simulink tools can be used to perform behavioral modeling on the application layer configuration file to generate a second private library file, thereby improving the feasibility of the solution.
[0028] In a possible implementation manner of the second aspect, the first private library file includes a software layer library file and a hardware abstraction library file, and the second private library file includes a device abstraction library file and an atomic service library file.
[0029] In this possible implementation method, the first private library file can specifically be a software layer library file (BSW.a) and a hardware abstract library file (MCAL.a), and the second private library file can specifically be a device abstract library file (SWC.a) and an atomic service library file (SWC.a), which improves the feasibility of the solution.
[0030] In a possible implementation manner of the second aspect, the method further includes: configuring a proxy interface, where the proxy interface is used for the second user to obtain the application layer configuration file, the software layer configuration file, the first private library file, and the second private library file.
[0031] In this possible implementation, the service interfaces in BSW are moved to AppL, and the second user can call these interfaces in AppL by himself. That is, the second user can obtain the configuration files and private library files generated by the first user through various proxy interfaces, reducing the frequency of the first user adapting BSW according to the needs of the second user.
[0032] In a possible implementation of the second aspect, the method further includes: obtaining an updated configuration file generated by the first user; splitting the updated configuration file to obtain a first configuration file and a second configuration file; and encrypting the second configuration file so that the second user generates a new executable file based on the first configuration file and the encrypted second configuration file.
[0033] In this possible implementation, the OEM can also independently configure the communication protocol stack or the diagnostic protocol stack, thereby improving the feasibility of the solution.
[0034] In a third aspect of the present application, a computer device is provided for executing the method of the first aspect or any possible implementation of the first aspect. Specifically, the computer device includes modules or units for executing the method of the first aspect or any possible implementation of the first aspect, such as an acquisition unit, a first generation unit, a second generation unit, and an update unit.
[0035] In a fourth aspect, the present application provides a computer device for executing the method of the second aspect or any possible implementation of the second aspect. Specifically, the computer device includes modules or units for executing the method of the second aspect or any possible implementation of the second aspect, such as an acquisition unit, a first generation unit, a second generation unit, an encryption unit, a configuration unit, and an update unit.
[0036] In a fifth aspect, the present application provides a computer device comprising a processor, a memory, and a computer-readable storage medium storing a computer program; the processor is coupled to the computer-readable storage medium, and a computer-executable instruction running on the processor, when the computer-executable instruction is executed by the processor, the processor executes the method as described in the first aspect or any possible implementation of the first aspect. Optionally, the computer device may further include an input / output (I / O) interface, and the computer-readable storage medium storing the computer program may be a memory.
[0037] In a sixth aspect, the present application provides a computer device comprising a processor, a memory, and a computer-readable storage medium storing a computer program; the processor is coupled to the computer-readable storage medium, and a computer-executable instruction running on the processor, when the computer-executable instruction is executed by the processor, the processor executes the method as described in the second aspect or any possible implementation of the second aspect. Optionally, the computer device may further include an input / output (I / O) interface, and the computer-readable storage medium storing the computer program may be a memory.
[0038] In a seventh aspect, the present application provides a computer-readable storage medium storing one or more computer-executable instructions. When the computer-executable instructions are executed by a processor, the processor executes a method as described in the first aspect or any possible implementation of the first aspect.
[0039] In an eighth aspect, the present application provides a computer-readable storage medium storing one or more computer-executable instructions. When the computer-executable instructions are executed by a processor, the processor executes a method as described in the second aspect or any possible implementation of the second aspect.
[0040] In a ninth aspect, the present application provides a computer program product storing one or more computer-executable instructions. When the computer-executable instructions are executed by a processor, the processor executes a method as described in the first aspect or any possible implementation of the first aspect.
[0041] In a tenth aspect, the present application provides a computer program product that stores one or more computer-executable instructions. When the computer-executable instructions are executed by a processor, the processor executes a method as described in the second aspect or any possible implementation of the second aspect.
[0042] In the eleventh aspect of the present application, a chip system is provided, which includes at least one processor and an interface, the interface being used to receive data and / or signals, and the at least one processor being used to support a computer device in implementing the functions involved in the above-mentioned first aspect or any possible implementation of the first aspect. In one possible design, the chip system may also include a memory, which is used to store program instructions and data necessary for the computer device. The chip system may be composed of a chip, or may include a chip and other discrete devices.
[0043] The twelfth aspect of the present application provides a chip system, which includes at least one processor and an interface, the interface is used to receive data and / or signals, and the at least one processor is used to support a computer device to implement the functions involved in the above-mentioned second aspect or any possible implementation of the second aspect. In one possible design, the chip system may also include a memory, which is used to store program instructions and data necessary for the computer device. The chip system can be composed of a chip, or it can include a chip and other discrete devices.
[0044] In an embodiment of the present application, when the original equipment manufacturer's application software module is updated, the component supplier only needs to make corresponding updates to the private library files that cannot be opened in the basic software layer. The original equipment manufacturer can complete the generation and integration of the operating environment by itself through the configuration files and private library files provided by the component supplier, thereby improving the efficiency of application updates. BRIEF DESCRIPTION OF THE DRAWINGS
[0045] Figure 1 is a schematic diagram of the automotive open system architecture;
[0046] FIG2A is a schematic diagram of an embodiment of a data processing method provided in an embodiment of the present application;
[0047] FIG2B is a schematic diagram of another embodiment of the data processing method provided in an embodiment of the present application;
[0048] FIG3 is a schematic diagram of the architecture of the configuration proxy interface provided in an embodiment of the present application;
[0049] FIG4 is a schematic diagram of the architecture of a configuration communication protocol stack provided in an embodiment of the present application;
[0050] FIG5 is a schematic diagram of another embodiment of the data processing method provided in an embodiment of the present application;
[0051] FIG6 is a schematic diagram of a generation process of an update library file provided in an embodiment of the present application;
[0052] FIG7 is a schematic diagram of the architecture of the configuration diagnosis protocol stack provided in an embodiment of the present application;
[0053] FIG8 is a schematic diagram of an embodiment of a computer device provided in an embodiment of the present application;
[0054] FIG9 is a schematic diagram of another embodiment of a computer device provided in an embodiment of the present application;
[0055] FIG10 is a schematic diagram of another embodiment of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0056] The following describes the embodiments of the present application in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of the present application, rather than all the embodiments. Those skilled in the art will appreciate that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.
[0057] The terms "first," "second," and the like in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are 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," as well as any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to these processes, methods, products, or apparatus.
[0058] The present application provides a data processing method and related devices for improving the efficiency of application updates. The present application also provides corresponding computer devices, computer-readable storage media, chip systems, and computer program products. These are described in detail below.
[0059] The following examples illustrate the application scenarios involved in the embodiments of the present application.
[0060] In the automotive open system architecture (AUTOSAR), such as the AUTOSAR classic platform (AUTOSAR CP), the automotive electronics software architecture is abstracted into four layers to achieve separation between application and hardware modules. As shown in Figure 1, these layers, from top to bottom, are: application layer (AppL), runtime environment (RTE), basic software layer (BSW), and microcontroller. The BSW is the underlying software layer, independent of function, while the RTE is the runtime environment for AUTOSAR application software. The BSW also includes multiple software modules (hereinafter referred to as modules): system services module, onboard device abstraction module, microcontroller driver module, memory services module, memory hardware abstraction module, memory driver module, communication services module, communication hardware abstraction module, communication driver module, input / output hardware abstraction module, input / output driver module, and complex driver module. These different software modules can be configured independently, but the same software module cannot be split according to business needs.
[0061] The AUTOSAR design and development process consists of three phases: system configuration, electronic control unit (ECU) design and configuration, and code generation. The first phase defines the system configuration file, including selecting hardware and software components and defining overall system constraints. AUTOSAR reduces the initial system design workload by using information exchange formats and module description files. The input for system configuration is an Extensible Markup Language (XML) file, and the output is a system configuration description file. The primary function of system configuration is to map software component requirements to the ECU. The second phase extracts information related to individual ECU resources from the system configuration description file and generates an ECU extraction file. The ECU is configured based on this extraction file, generating an ECU configuration description file. This file contains all the information for a specific ECU. The final phase, code generation, involves generating and compiling code based on the configuration specified in the ECU configuration description file, and then linking the relevant code to form an executable file.
[0062] In actual applications, component suppliers (such as ECU suppliers) are responsible for providing the BSW and RTE. Original equipment manufacturers (OEMs), such as vehicle manufacturers, are responsible for providing the AppL, such as the application software component (SWC). SWC is the application software in the AUTOSAR CP. Component suppliers are also responsible for integration, completing the AUTOSAR design and development process. However, during the product development phase, OEMs may request multiple changes and updates to the SWC, communication protocol stack, or diagnostic protocol stack. Accordingly, component suppliers must configure the BSW and RTE, model the framework, and finally compile the integration according to each requirement.
[0063] The data processing method provided in the embodiment of the present application is described in detail below in combination with the description of the above application scenarios.
[0064] The data processing method provided in the embodiment of the present application includes three application scenarios: OEM independently updates SWC; OEM independently configures the communication protocol stack; OEM independently configures the diagnostic protocol stack.
[0065] Scenario 1:
[0066] When an OEM updates a SWC, it will add, delete, and modify the SWC, including changes to the number of runnables and scheduling cycles. Runnable is the definition of a runnable in AUTOSAR CP. Under the AUTOSAR CP architecture, the task mapping (mapping runnables to defined tasks) in the RTE and operating system (OS) needs to be reconfigured and generated. In the above scenario, as shown in Figures 2A and 2B, an embodiment of the data processing method provided in the present application includes:
[0067] 201. Obtain a private file and an application layer configuration file generated by a first user.
[0068] Taking a computer device executing the data processing method provided in an embodiment of the present application as an example, first, a private file and an application layer configuration file generated by a first user are obtained, wherein the first user is a component supplier, such as an ECU supplier, and the first user is responsible for providing BSW. Then the first user will pre-generate the private file and application layer configuration file of the BSW. The private file can specifically be a controller area network (CAN) communication matrix (data base CAN, DBC) file and an Ethernet communication AUTOSAR configuration file (AUTOSAR extensible markup language, ARXML) file, wherein the DBC file is a file that describes the CAN message, and the ARXML file is an engineering configuration file used to transmit information in AUTOSAR. The DBC file can specifically include a CAN bus file and a local interconnect network (LIN) bus file, etc. The application layer configuration file is an ARXML file, which can specifically be an atomic service SWC configuration file and a device abstraction SWC configuration file.
[0069] 202. Generate a first private library file and a software layer configuration file based on the private file.
[0070] After the computer device obtains the DBC file, it uses the configuration tool to configure it and generate dynamic code, and then uses the compiler and / or linker to compile a first private library file. The first private library file can specifically be a software layer library file (such as BSW.a) and a hardware abstract library file (such as MCAL.a).
[0071] In addition, the computer device may also export a software layer configuration file from the configuration tool. The software layer configuration file may be an ARXML configuration file related to the RTE / OS.
[0072] Optionally, the software layer configuration file also includes an encrypted hidden configuration file. After the computer device obtains the software layer configuration file, it will also encrypt part of the configuration files in the software layer configuration file to obtain the encrypted hidden configuration file.
[0073] Exemplarily, based on the various software modules of BSW, the software layer configuration files include a communication module (COM) configuration file, a large data communication module (LdCOM) configuration file, an RTE configuration file, an ECU configuration module (ECUC) configuration file, an OS configuration file, and a platform configuration file.
[0074] The RTE configuration file refers to the SWC configuration file on the RTE. The COM configuration file, LdCOM configuration file, and RTE configuration file are all open to the second user. The entire ARXML file does not need to be encrypted or hidden. The ECUC configuration file, OS configuration file, and platform configuration file are hidden configuration files. The first user does not allow the second user to access or operate them to ensure the confidentiality of the first user's technology.
[0075] Specifically, the EcuC configuration file only opens two configuration items: ECUC ConfigSet and ECUC Patition Collection, which are used for the second user to add protocol data unit (Pdu) messages and SWC configuration. The ECUC Hardware configuration item in the EcuC configuration file needs to be hidden and encrypted.
[0076] The entire OS configuration file and platform configuration file are hidden and encrypted. For the OS configuration file, the second user can add a runnable to the task defined by the first user. In the "RTE TaskMapping" editor, the Mappings page is opened, while the Partitions page is hidden.
[0077] 203. Generate a second private library file based on the application layer configuration file.
[0078] After the computer device obtains the application layer configuration file, it can use Matlab or Simulink tools to perform behavioral modeling on the application layer configuration file to generate a second private library file, where the second private library file can specifically be a device abstract library file (such as SWC.a) and an atomic service library file (such as SWC.a).
[0079] Optionally, the computer device can also configure a proxy interface in AUTOSAR and move the service interface in BSW to AppL. The second user can then call these interfaces in AppL. That is, the second user can obtain the application layer configuration file, software layer configuration file, first private library file, and second private library file generated by the first user through various proxy interfaces.
[0080] Specifically, as shown in Figure 3, there are three SWC applications in the application layer: OEM SWC1, OEM SWC2, and OEM SWC3. By configuring proxy interfaces such as the scalable service-oriented middleware over IP (someip) service proxy SWC, the non-volatile memory (NvM) proxy SWC, the diagnostic communication manager (DCM) proxy SWC, and the vehicle health management (VHM) proxy SWC (framework service), SWC applications can directly access modules such as LdCOM, NvM, and DCM in the BSW through the above proxy interfaces and RTE. The impact of changes is limited to the RTE, and no configuration changes are required on the BSW.
[0081] Among them, someip is a protocol of in-vehicle Ethernet, DCM and NvM are standard modules in AUTOSAR CP. Those skilled in the art can understand their functions and implementation methods, and will not be repeated in the embodiments of this application.
[0082] The above steps are steps for operating the computer device by the first user. The following describes steps for operating the computer device by the second user.
[0083] 204. Obtain a configuration file and a private library file generated by the first user.
[0084] The computer device obtains the configuration file and private library file generated by the first user from the BSW through the proxy interface and stores them in the AppL. The configuration file includes the aforementioned software layer configuration file and application layer configuration file. Specifically, the software layer configuration file is an ARXML configuration file related to the RTE / OS, and the application layer configuration file is an atomic service SWC configuration file and a device abstraction SWC configuration file. Optionally, the software layer configuration file also includes an encrypted hidden configuration file. The private library files include the aforementioned first and second private library files, namely, the software layer library file, the hardware abstraction library file, the device abstraction library file, and the atomic service library file.
[0085] The specific description of the configuration file and the private library file generated by the first user can be referred to the above embodiment, and the embodiments of the present application will not be repeated here.
[0086] 205. Generate an open library file based on the application software module and configuration file generated by the second user.
[0087] In the above scenario, the OEM will add, delete, and modify the SWC, that is, the second user will update the application software module in the AppL. The computer device generates an open library file based on the updated SWC and the configuration file generated by the first user using a modeling tool, configuration tool, Matlab, or Simulink tool.
[0088] Specifically, the open library files include application layer library files (such as SWC.a), runtime environment library files (such as RTE.a) and operating system library files (such as OS.a). The computer device uses the application layer configuration file (atomic service SWC configuration file and device abstract SWC configuration file) as part of the input, and combines it with the updated SWC to use the modeling tool to model the overall framework of the application layer and export the framework configuration file. The framework configuration file can be an ARXML file of a single SWC. The computer device continues to use the framework configuration file, performs behavioral modeling through Matlab or Simulink tools, generates relevant code, and finally compiles the application layer library file (such as SWC.a), and uses the configuration tool to generate code based on the framework configuration file and the software layer configuration file to compile the runtime environment library file (such as RTE.a) and the operating system library file (such as OS.a).
[0089] 206. Compile the private library file and the open library file to obtain an executable file.
[0090] After the above steps, the computer device obtains the application layer library file (such as SWC.a), the runtime environment library file (such as RTE.a), the operating system library file (such as OS.a), the software layer library file (such as BSW.a), the hardware abstraction library file (such as MCAL.a), the device abstraction library file (such as SWC.a) and the atomic service library file (such as SWC.a). The computer device compiles the files through the compiler / linker to obtain the entire executable file (such as ECU.hex). The executable file can be run on the ECU, thereby completing the independent update of the SWC and the integration of the second user OEM.
[0091] In an embodiment of the present application, when the original equipment manufacturer's application software module is updated, the component supplier only needs to make corresponding updates to the private library files that cannot be opened in the basic software layer. The original equipment manufacturer can independently complete the generation and integration of the operating environment through the configuration files and private library files provided by the component supplier, thereby improving the efficiency of application updates and reducing the frequency of component suppliers adapting BSW according to OEM needs.
[0092] Scenario 2:
[0093] As shown in Figure 4, when an OEM independently configures the communication protocol stack, it replaces the legacy ECU connected via the bus (CAN / LIN protocol stack). This means a change to the local communication matrix, requiring the component supplier to reconfigure the communication protocol stack of the BSW. Typically, the SWC in the legacy ECU service at the application layer will also change, requiring the regeneration of the RTE and / or OS. When an OEM replaces a legacy ECU, the legacy ECU atomic services at the application layer, as well as communication protocol stack-related modules in the OS, BSW, and MCAL (such as COM, CAN transport protocol (CanTp), CAN network management (CanNm), CAN driver (CanDrv), CAN transceiver (CanTrev), and the legacy ECU connected via the vehicle domain controller hardware (VDC HW)) all need to be adapted. In this case, it is not possible to move all protocol stack-related modules up to the application layer via the proxy interface.
[0094] Among them, SDV atomic services are atomic services defined in the software defined vehicle (SDV) specification, COM, CanTp, CanNm, CanDrv, and CanTrev are standard modules in AUTOSAR CP. Those skilled in the art can understand their functions and implementation methods, and will not be repeated in the embodiments of this application.
[0095] In the above scenario, as shown in FIG5 , an embodiment of the data processing method provided in an embodiment of the present application further includes:
[0096] 501. Obtain an update configuration file generated by a first user.
[0097] The computer device obtains an updated configuration file, which is a configuration file adapted and updated by the first user based on the replacement of the Legacy ECU by the second user.
[0098] 502. Split the update configuration file to obtain a first configuration file and a second configuration file.
[0099] 503. Encrypt the second configuration file.
[0100] After the computer device obtains the update configuration file, it will also split the update configuration file, such as the configuration files of the Can interface (CanIf), Lin interface (LinIf) and protocol data unit routing (PduR) modules, to obtain a first configuration file and a second configuration file.
[0101] Table 1
[0102] CAN / LIN support scenarios require open module configuration. Support message and signal changes. Support changing a signal in a Can / Lin message. SWC / RTE / Com. Support modifying the Can / Lin message ID (receive / send). CanIf / LinIf. Support modifying the Can message sending mode. Com. Support modifying the Can / Lin message sending period. Com. Support message and signal addition. Support adding a Can / Lin message in a sending / receiving node. SWC / RTE / LinIf / CanIf / PduR / Com. Support adding a signal in a Can / Lin message. SWC / RTE / LinIf / CanIf / PduR / Com. Support message and signal deletion. Support deleting a signal in a Can / Lin message. SWC / RTE / LinIf / CanIf / PduR / Com. Support deleting a Can / Lin message in a sending / receiving node. SWC / RTE / LinIf / CanIf / PduR / Com.
[0103] Among them, the first configuration file can be open to the second user for configuration, specifically it can be a partial configuration file of modules such as CanIf, LinIf and PduR. The second configuration file is a configuration file that the first user wants to keep confidential, such as another part of the configuration file of modules such as CanIf, LinIf and PduR. The computer device can use the configuration tool to hide it on the entire configuration file update interface and encrypt the ARXML of the second configuration file. The first configuration file can be open to the second user without additional processing.
[0104] As shown in Table 1, in different scenarios, the updated configuration files of CanIf, LinIf, and PduR are encrypted and can be opened to the second user, so that the second user can generate the library file of a single module by himself and complete the configuration and overall integration of the unencrypted part of the open module.
[0105] Among them, CanIf, LinIf, and PduR are standard modules in AUTOSAR CP. Those skilled in the art can understand their functions and implementation methods, and will not be described in detail in the embodiments of this application.
[0106] The above steps are steps for operating the computer device by the first user. The following describes steps for operating the computer device by the second user.
[0107] 504. Obtain a first configuration file generated by a first user and an encrypted second configuration file.
[0108] 505. Update the first configuration file, and generate an update library file based on the second configuration file and the updated first configuration file.
[0109] After the computer device obtains the first configuration file and the second configuration file, because the second configuration file has been hidden and encrypted, the second user can only add, delete, and modify the first configuration file, but cannot modify the second configuration file, and the updated first configuration file cannot conflict with the second configuration file. That is, the computer device processes the information of the first configuration file through the configuration tool, such as configuration information such as signal transmission and reception and mapping relationships, to obtain an updated first configuration file.
[0110] Furthermore, the computer device also needs to generate an updated library file based on the second configuration file and the updated first configuration file, that is, generate dynamic code based on the second configuration file and the updated first configuration file, and compile it into an updated library file of a single module (for example, a .a / .o file), which can be a CanIf.o, LinIf.o or PduR.o file.
[0111] For example, referring to FIG6 , the first user completes the configuration of the first configuration file (BSW-A), and the second user completes the configuration of the second configuration file (BSW-B). After the first configuration file is encrypted, the second user exports the update library file (eg, Pb_cfg.o) through the configuration tool.
[0112] 506. Compile based on the updated library file to obtain a new executable file.
[0113] After the computer device receives the updated library files, steps 204-206 can be re-executed. The computer device obtains the library files (BSW.a) and mcal.a) delivered by the first user (excluding modules that require modification by the second user, such as CanIf, LinIf, or PduR), as well as the SWC.a and ARXML files delivered by the first user. The second user then uses a configuration tool on the computer device to build a framework, imports it into the RTE and OS, and finally compiles the updated library files together to obtain a new executable file (e.g., a .hex / .elf file).
[0114] Scenario 3:
[0115] As shown in Figure 7, when the OEM configures the diagnostic protocol stack, it provides the ARXML configuration file and library files (e.g., .a files) for the application SWC to the parts supplier. The parts supplier then develops the static code in the diagnostic module (DIAG) based on the OEM's requirements and configures and compiles the DCM and diagnostic event manager (DEM) of the BSW. Ultimately, the parts supplier completes the integrated compilation. Therefore, even if the DIAG module is open to the OEM and the OEM is expected to develop its own code, the BSW on the parts supplier side still needs to be reconfigured and compiled in certain scenarios.
[0116] In the above scenario, steps 501 to 506 in the data processing method shown in FIG. 5 may still be performed.
[0117] 501. Obtain an update configuration file generated by a first user.
[0118] 502. Split the update configuration file to obtain a first configuration file and a second configuration file.
[0119] 503. Encrypt the second configuration file.
[0120] 504. Obtain the first configuration file and the encrypted second configuration file.
[0121] 505. Update the first configuration file, and generate an update library file based on the second configuration file and the updated first configuration file.
[0122] 506. Compile based on the updated library file to obtain a new executable file.
[0123] The updated configuration file is the configuration file adapted and updated by the first user based on the second user's configuration of the diagnostic protocol stack. The second configuration file is the configuration file that the first user wishes to keep confidential, such as partial configuration files for modules such as the DCM, DEM, function inhibition manager (FiM), and NvM. After the computer device obtains the first and second configuration files, it needs to process the information in the first configuration file using a configuration tool, such as processing configuration information such as fault codes, freeze frames, and function inhibition, to obtain the updated first configuration file.
[0124] Furthermore, the computer device also needs to generate an updated library file based on the second configuration file and the updated first configuration file, that is, generate dynamic code based on the second configuration file and the updated first configuration file, and compile it into an updated library file of a single module (for example, a .a / .o file), which can be specifically a DEM.o file. The computer device obtains the library files such as BSW.a (excluding modules that need to be changed by the second user, such as DEM) and mcal.a delivered by the first user, as well as the library files and ARXML files of the application layer diagnostic communication module (SWC_APP_DCM) delivered by the first user. The second user uses the configuration tool on the computer device to model the framework, import it into the RTE and OS, and finally compiles the updated library files together to obtain a new executable file (for example, a .hex / .elf file).
[0125] As shown in Table 2, in different scenarios, for example, when changing the DCM service (DCM Service), diagnostic data identifier (DID), routine identifier (RID), diagnostic trouble code (DTC), freeze frame (FreezeFrame), extended data (Extended Data), NvM block (NvM Block) and function identifier (FID), the modules marked with "x" need to be changed. Among them, SWC_APP_DCM is still provided by the first user, and part of the content of DCM, DEM, FiM and NvM can be opened to the second user after encryption, so that the second user can generate the library file of a single module by himself, completing the configuration of the unencrypted part of the open module and the overall integration.
[0126] Among them, DEM, FiM, and NvM Block are standard modules in AUTOSAR CP, DID is diagnosis-related data in AUTOSAR CP, RID is diagnosis-related routine in AUTOSAR CP, DTC is diagnostic trouble code in AUTOSAR CP, FreezeFrame is diagnostic freeze frame in AUTOSAR CP, FID is function ID in FiM module, SWC_APP_DCM is a customized DCM agent in the application layer. Those skilled in the art can understand its function and implementation method, and will not be described in detail in the embodiments of this application.
[0127] The specific implementation method can refer to the embodiment described in Figure 5, and the embodiments of this application will not be repeated.
[0128] The embodiment of the present application uses a configuration tool to implement a post-compilation (PB) function, and combined with the configuration hiding function of the configuration tool, vertically splits the module configuration file into two ARXML files, a first configuration file and a second configuration file. The second configuration file is configured by the component supplier, and the first configuration file is configured by the OEM. The OEM is not allowed to make any changes to the second configuration file, and supports customers to add, delete, and modify the first configuration file, providing OEMs with the freedom to configure BSW-related modules while protecting the technology of component suppliers.
[0129] Table 2
[0130] Change scenario SWC_APP_DCMDCMDEMFiMNvM Add DCM Servicexx Delete DCM Servicexx Modify DCM Servicexx Enable / disable DCM service internal attributexx Add DIDxx Delete DIDxx Modify DIDxx Enable / disable DID internal attributexx Add RIDxx Delete RIDxx Modify RIDxx Enable / disable RID internal attributexx Add DTCx x Delete DTCx x Modify DTCx x Add FreezeFramex xx Delete FreezeFramex xx Modify FreezeFramex xx Add Extended Datax xx Delete Extended Datax xx Modify Extended Datax xx Add NvM Blockx xx Delete NvM Blockx xx Modify NvM Blockx xx Add FIDx x Delete FIDx x Modify FIDx x
[0131] It should be understood that the ".x file" described in the embodiments of the present application means a file with the suffix "x" (also called file extension). For example, a ".hex file" means a file with the suffix "hex", specifically an executable file, and a ".a file" means a file with the suffix "a", specifically a library file. Those skilled in the art can understand the specific meaning of similar descriptions.
[0132] The above describes the data processing method provided in the embodiment of the present application. The following describes the related equipment provided in the embodiment of the present application in conjunction with the accompanying drawings.
[0133] As shown in FIG8 , an embodiment of a computer device 800 provided in an embodiment of the present application includes:
[0134] The acquisition unit 801 is configured to acquire a configuration file and a private library file generated by a first user; the acquisition unit 801 may execute step 201 in the above method embodiment.
[0135] The first generating unit 802 is configured to generate an open library file based on the application software module and configuration file generated by the second user; the first generating unit 802 may execute step 202 in the above method embodiment.
[0136] The second generating unit 803 is used to compile the private library file and the open library file to obtain an executable file. The second generating unit 803 can execute step 203 in the above method embodiment.
[0137] Optionally, the configuration file includes a software layer configuration file and an application layer configuration file, and the software layer configuration file includes an encrypted hidden configuration file.
[0138] Optionally, the open library files include application layer library files, runtime environment library files and operating system library files; the first generation unit 802 is specifically used to perform framework modeling based on the application software module and the application layer configuration file to generate a framework configuration file; perform behavior modeling based on the framework configuration file to generate an application layer library file; compile the framework configuration file and the software layer configuration file to generate a runtime environment library file and an operating system library file.
[0139] Optionally, private library files include software layer library files, hardware abstraction library files, device abstraction library files, and atomic service library files.
[0140] Optionally, the acquiring unit 801 is specifically configured to acquire a configuration file and a private library file generated by the first user through a proxy interface.
[0141] Optionally, the computer device 800 also includes an update unit 804: the acquisition unit 801 is also used to obtain a first configuration file generated by a first user and an encrypted second configuration file; the update unit 804 is used to update the first configuration file and generate an updated library file based on the second configuration file and the updated first configuration file; and compile based on the updated library file to obtain a new executable file.
[0142] As shown in FIG9 , an embodiment of a computer device 900 provided in an embodiment of the present application includes:
[0143] The acquisition unit 901 is configured to acquire the private file and application layer configuration file generated by the first user; the acquisition unit 901 may execute step 204 in the above method embodiment.
[0144] The first generating unit 902 is configured to generate a first private library file and a software layer configuration file based on the private file; the first generating unit 902 may execute step 205 in the above method embodiment.
[0145] The second generating unit 903 is configured to generate a second private library file based on the application layer configuration file, so that the second user can generate an executable file based on the application layer configuration file, the software layer configuration file, the first private library file, and the second private library file. The second generating unit 903 can execute step 206 in the above method embodiment.
[0146] Optionally, the software layer configuration file includes an encrypted hidden configuration file, and the computer device 900 further includes an encryption unit 904: the encryption unit 904 is configured to encrypt part of the configuration file in the software layer configuration file to obtain an encrypted hidden configuration file.
[0147] Optionally, the second generating unit 903 is specifically configured to perform behavior modeling based on the application layer configuration file to generate a second private library file.
[0148] Optionally, the first private library file includes a software layer library file and a hardware abstraction library file, and the second private library file includes a device abstraction library file and an atomic service library file.
[0149] Optionally, the computer device 900 further includes a configuration unit 905 ; the configuration unit 905 is used to configure a proxy interface, and the proxy interface is used for the second user to obtain an application layer configuration file, a software layer configuration file, a first private library file, and a second private library file.
[0150] Optionally, the computer device also includes an update unit 906; the acquisition unit 901 is further used to obtain an update configuration file generated by the first user; the update unit 906 is used to split the update configuration file to obtain a first configuration file and a second configuration file; and encrypt the second configuration file so that the second user generates a new executable file based on the first configuration file and the encrypted second configuration file.
[0151] The computer device 800 and the computer device 900 provided in the embodiments of the present application can be understood by referring to the corresponding contents of the aforementioned data processing method embodiment part, and will not be repeated here.
[0152] As shown in Figure 10, a possible logical structure diagram of a computer device 1000 provided in an embodiment of the present application is shown. The computer device 1000 includes: a processor 1001, a communication interface 1002, a memory 1003 and a bus 1004. The processor 1001 may include a central processing unit (CPU), or a CPU and a graphics processing unit (GPU) and an embedded neural network processor (NPU) and at least one of other types of processors. The processor 1001, the communication interface 1002 and the memory 1003 are interconnected via a bus 1004. In an embodiment of the present application, the processor 1001 is used to control and manage the actions of the computer device 1000, for example, the processor 1001 is used to perform steps 201 to 206 in Figure 2A, and steps 501 to 506 in Figure 5 and / or other processes for the technology described herein. The communication interface 1002 is used to support the computer device 1000 to communicate. The memory 1003 is used to store program code and data of the computer device 1000.
[0153] The processor 1001 may be a central processing unit (CPU), a general-purpose processor (GPOR), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device (PLD), a transistor logic device (TLD), a hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like. The bus 1004 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, for example. The bus may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, FIG. 10 shows only one thick line, but this does not imply that there is only one bus or only one type of bus.
[0154] In another embodiment of the present application, a computer-readable storage medium is provided, in which computer-executable instructions are stored. When at least one processor of a device executes the computer-executable instructions, the device executes the data processing method described in the above embodiment.
[0155] In another embodiment of the present application, a computer program product is also provided, which includes computer execution instructions, which are stored in a computer-readable storage medium; at least one processor of the device can read the computer execution instructions from the computer-readable storage medium, and at least one processor executes the computer execution instructions so that the device executes the data processing method described in the embodiment.
[0156] In another embodiment of the present application, a chip system is provided, which includes at least one processor and an interface, the interface being used to receive data and / or signals, and the at least one processor being used to support the implementation of the data processing method described in the embodiment. In one possible design, the chip system may also include a memory, which is used to store program instructions and data necessary for the computer device. The chip system may be composed of a chip or may include a chip and other discrete devices.
[0157] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of this application.
[0158] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0159] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0160] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.
[0161] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.
[0162] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the contributing part or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.
Claims
1. A data processing method, characterized in that: include: Obtaining a configuration file and a private library file generated by the first user; generating an open library file based on the application software module generated by the second user and the configuration file; The private library file and the open library file are compiled to obtain an executable file.
2. The method according to claim 1, characterized in that The configuration files include a software layer configuration file and an application layer configuration file, and the software layer configuration file includes an encrypted hidden configuration file.
3. The method according to claim 2, characterized in that The open library files include application layer library files, operating environment library files and operating system library files; Generating the open library file based on the application software module generated by the second user and the configuration file includes: Performing framework modeling based on the application software module and the application layer configuration file to generate a framework configuration file; Performing behavior modeling based on the framework configuration file to generate the application layer library file; The framework configuration file and the software layer configuration file are compiled to generate the operating environment library file and the operating system library file.
4. The method according to any one of claims 1 to 3, characterized in that The private library files include software layer library files, hardware abstraction library files, device abstraction library files and atomic service library files.
5. The method according to any one of claims 1 to 4, characterized in that Obtaining the configuration file and private library file generated by the first user includes: The configuration file and private library file generated by the first user are obtained through the proxy interface.
6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Obtaining a first configuration file and an encrypted second configuration file generated by the first user; updating the first configuration file, and generating an update library file based on the second configuration file and the updated first configuration file; Compile based on the updated library file to obtain a new executable file.
7. A data processing method, characterized in that: include: Obtaining a private file and an application layer configuration file generated by the first user; Generate a first private library file and a software layer configuration file based on the private file; A second private library file is generated based on the application layer configuration file, so that a second user can generate an executable file based on the application layer configuration file, the software layer configuration file, the first private library file and the second private library file.
8. The method according to claim 7, characterized in that The software layer configuration file includes an encrypted hidden configuration file, and the method further includes: Part of the configuration files in the software layer configuration file is encrypted to obtain an encrypted hidden configuration file.
9. The method according to claim 7 or 8, characterized in that Generating a second private library file based on the application layer configuration file includes: Behavior modeling is performed based on the application layer configuration file to generate the second private library file.
10. The method according to any one of claims 7 to 9, characterized in that The first private library file includes a software layer library file and a hardware abstract library file, and the second private library file includes a device abstract library file and an atomic service library file.
11. The method according to any one of claims 7 to 10, characterized in that The method further comprises: An agent interface is configured, where the agent interface is used for the second user to obtain the application layer configuration file, the software layer configuration file, the first private library file, and the second private library file.
12. The method according to any one of claims 7 to 11, characterized in that The method further comprises: Obtaining an updated configuration file generated by the first user; Splitting the update configuration file to obtain a first configuration file and a second configuration file; The second configuration file is encrypted so that the second user can generate a new executable file based on the first configuration file and the encrypted second configuration file.
13. A computer device, characterized in that: include: an acquiring unit, configured to acquire a configuration file and a private library file generated by a first user; a first generating unit, configured to generate an open library file based on the application software module generated by the second user and the configuration file; The second generating unit is used to compile the private library file and the open library file to obtain an executable file.
14. The device according to claim 13, characterized in that The configuration files include a software layer configuration file and an application layer configuration file, and the software layer configuration file includes an encrypted hidden configuration file.
15. The device according to claim 14, characterized in that The open library files include application layer library files, operating environment library files and operating system library files; The first generating unit is specifically configured to perform framework modeling based on the application software module and the application layer configuration file to generate a framework configuration file; perform behavior modeling based on the framework configuration file to generate the application layer library file; The framework configuration file and the software layer configuration file are compiled to generate the operating environment library file and the operating system library file.
16. The device according to any one of claims 13 to 15, characterized in that The private library files include software layer library files, hardware abstraction library files, device abstraction library files and atomic service library files.
17. The device according to any one of claims 13 to 16, characterized in that The acquisition unit is specifically configured to acquire the configuration file and the private library file generated by the first user through the proxy interface.
18. The device according to any one of claims 13 to 17, characterized in that The computer device further comprises an updating unit: The acquiring unit is further configured to acquire a first configuration file generated by the first user and an encrypted second configuration file; The updating unit is configured to update the first configuration file and generate an update library file based on the second configuration file and the updated first configuration file; Compile based on the updated library file to obtain a new executable file.
19. A computer device, characterized in that: include: an acquiring unit, configured to acquire a private file and an application layer configuration file generated by a first user; A first generating unit, configured to generate a first private library file and a software layer configuration file based on the private file; The second generating unit is configured to generate a second private library file based on the application layer configuration file, so that a second user can generate an executable file based on the application layer configuration file, the software layer configuration file, the first private library file, and the second private library file.
20. The device according to claim 19, characterized in that The software layer configuration file includes an encrypted hidden configuration file, and the computer device further includes an encryption unit: The encryption unit is used to encrypt part of the configuration files in the software layer configuration file to obtain an encrypted hidden configuration file.
21. The device according to claim 19 or 20, characterized in that The second generating unit is specifically configured to perform behavior modeling based on the application layer configuration file to generate the second private library file.
22. The device according to any one of claims 19 to 21, characterized in that The first private library file includes a software layer library file and a hardware abstract library file, and the second private library file includes a device abstract library file and an atomic service library file.
23. The device according to any one of claims 19 to 22, characterized in that The computer device further includes a configuration unit; The configuration unit is used to configure a proxy interface, and the proxy interface is used for the second user to obtain the application layer configuration file, the software layer configuration file, the first private library file, and the second private library file.
24. The apparatus according to any one of claims 19 to 23, characterized in that The computer device further comprises an updating unit; The obtaining unit is further configured to obtain an update configuration file generated by the first user; The updating unit is used to split the update configuration file to obtain a first configuration file and a second configuration file; The second configuration file is encrypted so that the second user can generate a new executable file based on the first configuration file and the encrypted second configuration file.
25. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 or 7 to 12 is implemented.
26. A chip system, characterized in that: The method comprises at least one processor and an interface, wherein the interface is used to receive data and / or signals, and the at least one processor is configured to execute the method according to any one of claims 1-6 or 7-12.