WO2024065347A1 - 一种数据处理方法及相关设备 - Google Patents

一种数据处理方法及相关设备 Download PDF

Info

Publication number
WO2024065347A1
WO2024065347A1 PCT/CN2022/122389 CN2022122389W WO2024065347A1 WO 2024065347 A1 WO2024065347 A1 WO 2024065347A1 CN 2022122389 W CN2022122389 W CN 2022122389W WO 2024065347 A1 WO2024065347 A1 WO 2024065347A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
configuration file
library
private
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/122389
Other languages
English (en)
French (fr)
Inventor
赵玉龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to PCT/CN2022/122389 priority Critical patent/WO2024065347A1/zh
Priority to CN202280100008.8A priority patent/CN119856492A/zh
Publication of WO2024065347A1 publication Critical patent/WO2024065347A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H04N19/517—Processing of motion vectors by encoding
    • H04N19/52—Processing of motion vectors by encoding by predictive encoding

Definitions

  • the present application relates to the field of computer technology, and in particular to a data processing method and related equipment.
  • the automotive open system architecture (AUTOSAR) is an alliance dedicated to developing automotive electronic software standards.
  • the AUTOSAR architecture is mainly divided into three levels: application software layer (AppL), runtime environment (RTE) and basic software layer (BSW).
  • AppL application software layer
  • RTE runtime environment
  • BSW basic software layer
  • OEM original equipment manufacturers
  • parts suppliers are responsible for providing RTE, BSW and integration services.
  • the embodiments of the present application provide a data processing method and related devices for improving the efficiency of application updates.
  • the embodiments of the present application also provide corresponding computer devices, computer-readable storage media, chip systems, and computer program products.
  • 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.
  • the first user is a component 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 generates an open library file based on the updated SWC and the configuration file generated by the first user using a modeling tool, a configuration tool, Matlab or Simulink tool, 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 the SWC and the integration.
  • the component supplier 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.
  • the configuration file includes a software layer configuration file and an application layer configuration file
  • the software layer configuration file includes an encrypted hidden configuration file
  • the application layer configuration file is an AUTOSAR configuration file (AUTOSAR extensible markup language, ARXML) file, which may specifically be 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).
  • OS operating system
  • 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: generating the open library file based on the application software module and the 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 the framework configuration file; performing behavior modeling based on the framework configuration file to generate the application layer library file; compiling the framework configuration file and the software layer configuration file to generate the operating environment library file and the operating system library file.
  • the open library files include application layer library files (SWC.a), runtime environment library files (RTE.a) and operating system library files (OS.a).
  • the application layer configuration files (atomic service SWC configuration files and device abstraction SWC configuration files) are used as partial inputs.
  • a modeling tool is used to model the overall framework of the application layer and export the framework configuration file.
  • the framework configuration file can specifically be an ARXML file of a single SWC. The computer device continues to use the framework configuration file, and the behavior modeling is performed through Matlab or Simulink tools to generate relevant codes.
  • the application layer library file (SWC.a) is compiled, and the configuration tool is used to generate code based on the framework configuration file and the software layer configuration file to compile the runtime environment library file (RTE.a) and the operating system library file (OS.a), thereby improving the feasibility of the solution.
  • the private library files include a software layer library file, a hardware abstraction library file, a device abstraction library file, and an atomic service library file.
  • the private library files specifically include software layer library files (BSW.a), hardware abstract library files (MCAL.a), device abstract library files (SWC.a) and atomic service library files (SWC.a), which improves the feasibility of the solution.
  • BSW.a software layer library files
  • MCAL.a hardware abstract library files
  • SWC.a device abstract library files
  • SWC.a atomic service library files
  • 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.
  • the service interface in BSW is 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.
  • 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.
  • the OEM can also independently configure the communication protocol stack, or independently configure the diagnostic protocol stack, thereby improving the feasibility of the solution.
  • 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; generating 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 first user will pre-generate private files and application layer configuration files of BSW.
  • the private files can specifically be controller area network (CAN) communication matrix (data base CAN, DBC) files and Ethernet communication AUTOSAR configuration files (AUTOSAR extensible markup language, ARXML) files.
  • DBC files 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 an atomic service SWC configuration file and a device abstraction SWC configuration file.
  • 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.
  • the component supplier when the OEM's application software module is updated, the component supplier only needs to make corresponding updates to the private library files that are not open to the public in the basic software layer.
  • the OEM can generate and integrate 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.
  • the software layer configuration file includes an encrypted hidden configuration file
  • the method further includes: encrypting a portion of the configuration files in the software layer configuration file to obtain the encrypted hidden configuration file.
  • the software layer configuration file may be an ARXML configuration file related to the RTE/operating system (OS).
  • OS operating system
  • the first user does not allow the second user to access or operate it, so as to achieve the technical confidentiality of the first user.
  • 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.
  • 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.
  • the first private library file includes a software layer library file and a hardware abstraction library file
  • the second private library file includes a device abstraction library file and an atomic service library file.
  • 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.
  • BSW.a software layer library file
  • MCAL.a hardware abstract library file
  • SWC.a device abstract library file
  • SWC.a atomic service library file
  • the method further includes: configuring a proxy interface, where 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.
  • the service interface in BSW is 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.
  • the method further includes: obtaining an update configuration file generated by the first user; splitting the update 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.
  • the OEM can also independently configure the communication protocol stack, or independently configure the diagnostic protocol stack, thereby improving the feasibility of the solution.
  • a computer device for executing the method in the first aspect or any possible implementation of the first aspect.
  • the computer device includes a module or unit for executing the method in 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.
  • a computer device for executing the method in the second aspect or any possible implementation of the second aspect.
  • the computer device includes a module or unit for executing the method in 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.
  • the present application provides a computer device, which includes 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.
  • the computer device may also include an input/output (I/O) interface, and the computer-readable storage medium storing the computer program may be a memory.
  • 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.
  • the computer device may also include an input/output (I/O) interface, and the computer-readable storage medium storing the computer program may be a memory.
  • the seventh aspect of the present application provides a computer-readable storage medium storing one or more computer-executable instructions.
  • the processor executes a method as described in the first aspect or any possible implementation of the first aspect.
  • a computer-readable storage medium that stores one or more computer-executable instructions.
  • the processor executes a method as described in the second aspect or any possible implementation of the second aspect.
  • a ninth aspect of the present application provides a computer program product storing one or more computer-executable instructions.
  • the processor executes a method as described in the first aspect or any possible implementation of the first aspect.
  • the tenth aspect of the present application provides a computer program product storing one or more computer-executable instructions.
  • the processor executes a method as described in the second aspect or any possible implementation of the second aspect.
  • a chip system which includes at least one processor and an interface, the interface is used to receive data and/or signals, and at least one processor is used to support a computer device to implement the functions involved in the above-mentioned first aspect or any possible implementation of the first aspect.
  • 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 chips, or it can include chips and other discrete devices.
  • 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 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.
  • 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 chips, or it can include chips and other discrete devices.
  • the component supplier 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.
  • FIG1 is a schematic diagram of an automotive open system architecture
  • FIG2A is a schematic diagram of an embodiment of a data processing method provided in an embodiment of the present application.
  • FIG2B is a schematic diagram of another embodiment of a data processing method provided in an embodiment of the present application.
  • FIG3 is a schematic diagram of the architecture of the configuration proxy interface provided in an embodiment of the present application.
  • FIG4 is a schematic diagram of the architecture of a configuration communication protocol stack provided in an embodiment of the present application.
  • FIG5 is a schematic diagram of another embodiment of a data processing method provided in an embodiment of the present application.
  • FIG6 is a schematic diagram of a generation process of an update library file provided in an embodiment of the present application.
  • FIG7 is a schematic diagram of the architecture of a configuration diagnosis protocol stack provided in an embodiment of the present application.
  • FIG8 is a schematic diagram of an embodiment of a computer device provided in an embodiment of the present application.
  • FIG9 is a schematic diagram of another embodiment of a computer device provided in an embodiment of the present application.
  • FIG. 10 is a schematic diagram of another embodiment of a computer device provided in an embodiment of the present application.
  • the embodiments of the present application provide a data processing method and related devices for improving the efficiency of application updates.
  • the embodiments of the present application also provide corresponding computer devices, computer-readable storage media, chip systems, and computer program products, etc. The following are detailed descriptions.
  • AUTOSAR such as the AUTOSAR classic platform (AUTOSAR CP)
  • ASDL application layer
  • RTE runtime environment
  • BSW basic software layer
  • microcontroller microcontroller
  • BSW also includes multiple software modules (hereinafter referred to as modules): system service module, onboard device abstract module, microcontroller driver module, memory service module, memory hardware abstract module, memory driver module, communication service module, communication hardware abstract module, communication driver module, input and output hardware abstract module, input and output driver module and complex driver module.
  • modules software modules: system service module, onboard device abstract module, microcontroller driver module, memory service module, memory hardware abstract module, memory driver module, communication service module, communication hardware abstract module, communication driver module, input and output hardware abstract module, input and output driver module and complex driver module.
  • the AUTOSAR design and development process is divided into three stages: system configuration stage, electronic control unit (ECU) design and configuration stage, and code generation stage.
  • the first stage defines the system configuration file, including the selection of hardware and software components and the definition of the constraints of the entire system.
  • AUTOSAR reduces the workload of initial system design by using information exchange formats and module description files.
  • the input of the system configuration is an extensible markup language (XML) type file, and the output is a system configuration description file.
  • the main function of the system configuration is to map the requirements of the software components to the ECU.
  • the second stage is to extract the information related to the resources of a single ECU according to the system configuration description file, and generate an ECU extraction file with the extracted information.
  • the ECU is configured according to this extraction file to generate an ECU configuration description file.
  • the description file contains all the information of a specific ECU.
  • the last stage, code generation, is to generate code, compile code, and connect related codes to form an executable file based on the configuration specified by the ECU configuration description file.
  • component suppliers such as ECU suppliers
  • OEMs original equipment manufacturers
  • AppL application software modules
  • SWC application software modules
  • SWC is the application software in AUTOSAR CP.
  • component suppliers are also responsible for integration to complete the AUTOSAR design and development process.
  • OEMs may require multiple changes and updates to SWC, communication protocol stacks, or diagnostic protocol stacks. Accordingly, component suppliers need to configure BSW and RTE, model the framework, and perform final integration compilation according to each requirement.
  • 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.
  • an embodiment of the data processing method provided in the embodiment of the present application includes:
  • a private file and an application layer configuration file generated by a first user are obtained, wherein the first user is a parts supplier, such as an ECU supplier, and the first user is responsible for providing BSW. Then, the first user will pre-generate a private file and an application layer configuration file of the BSW.
  • the private file may specifically be a controller area network (CAN) communication matrix (DBC) file and an Ethernet communication AUTOSAR configuration file (ARXML) file, wherein the DBC file is a file describing a CAN message, and the ARXML file is an engineering configuration file used to transmit information in AUTOSAR.
  • the DBC file may 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 may specifically be an atomic service SWC configuration file and a device abstract SWC configuration file.
  • the computer device 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).
  • the computer device may also export a software layer configuration file from the configuration tool, and the software layer configuration file may be an ARXML configuration file related to the RTE/OS.
  • the software layer configuration file also includes an encrypted hidden configuration file.
  • 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.
  • the software layer configuration files include communication module (communication, COM) configuration file, large data communication module (large data communication, LdCOM) configuration file, RTE configuration file, ECU configuration module (ECU configuration, ECUC) configuration file, OS configuration file and platform (platform) configuration file.
  • communication module communication, COM
  • large data communication module large data communication, LdCOM
  • RTE configuration file RTE configuration file
  • ECU configuration module ECU configuration, ECUC
  • OS configuration file OS configuration file
  • platform (platform) configuration file platform
  • 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, and 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 achieve the confidentiality of the first user's technology.
  • the EcuC configuration file only opens two configuration items, namely, ECUC configuration settings (ECUC ConfigSet) and ECUC partition collection (ECUC Pattern Collection), which are used for the second user to add protocol data unit (Pdu) messages and SWC configurations.
  • ECUC configuration settings ECUC ConfigSet
  • ECUC partition collection ECUC Pattern Collection
  • the ECUC hardware (ECUC Hardware) configuration items in the EcuC configuration file need to be hidden and encrypted.
  • the entire OS configuration file and platform configuration file are hidden and encrypted.
  • the second user can add a runnable to the task defined by the first user, opening the Mappings page in the "RTE Task Mapping" editor, while the Partitions page is hidden.
  • the computer device 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).
  • 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).
  • the computer device can also configure a proxy interface in AUTOSAR and move the service interface in BSW to AppL, so that the second user can call these interfaces in AppL by himself, 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.
  • a proxy interface in AUTOSAR and move the service interface in BSW to AppL, so that the second user can call these interfaces in AppL by himself, 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.
  • SWC applications there are three SWC applications in the application layer, namely OEM SWC1, OEM SWC2 and OEM SWC3.
  • proxy interfaces such as scalable service-oriented middleware over IP (someip) service proxy SWC, non-volatile memory (NvM) proxy SWC, diagnostic service diagnostic communication manager (DCM) proxy SWC and vehicle health management (VHM) proxy SWC (framework service)
  • SWC applications can directly access modules such as LdCOM, NvM and DCM in BSW through the above proxy interfaces and RTE. The impact of changes is limited to RTE, and there is no need to make configuration changes to BSW.
  • DCM and NvM are standard modules in AUTOSAR CP.
  • steps for the first user to operate the computer device are steps for the first user to operate the computer device.
  • steps for the second user to operate the computer device are steps for the first user to operate the computer device.
  • the computer device obtains the configuration file and private library file generated by the first user from the BSW through the proxy interface to AppL, wherein the configuration file includes the above-mentioned software layer configuration file and application layer configuration file, that is, the software layer configuration file is an ARXML configuration file related to RTE/OS, and the application layer configuration file is an atomic service SWC configuration file and a device abstraction SWC configuration file.
  • the software layer configuration file also includes an encrypted hidden configuration file.
  • the private library file includes the above-mentioned first private library file and the second private library file, that is, the software layer library file, the hardware abstraction library file, the device abstraction library file and the atomic service library file.
  • the OEM will add, delete, and modify the SWC, that is, the second user will update the application software module in AppL, and the computer device will generate an open library file using a modeling tool, a configuration tool, Matlab, or Simulink tool based on the updated SWC and the configuration file generated by the first user.
  • 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 uses the modeling tool to perform overall framework modeling of the application layer in combination with the updated SWC, and exports the framework configuration file.
  • the framework configuration file can specifically 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).
  • 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).
  • 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 it through the compiler/linker to obtain the entire executable file (such as ECU.hex).
  • the executable file can be run on the ECU, thereby the second user OEM completes the independent update of SWC and integration.
  • the component supplier 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, which improves the efficiency of application updates and reduces the frequency of component suppliers adapting BSW according to OEM needs.
  • the OEM when the OEM independently configures the communication protocol stack, the OEM will replace the traditional ECU (Legacy ECU) connected through the bus (CAN/LIN protocol stack), which means the change of the local communication matrix.
  • the component supplier needs to reconfigure the communication protocol stack of BSW.
  • the SWC in the Legacy ECU service of the application layer will also change, and the RTE and/or OS need to be regenerated.
  • the legacy ECU atomic service in the application layer, the 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 through the vehicle domain controller hardware (VDC HW) need to be adapted. In this case, it is impossible to move all the protocol stack related modules to the application layer through the proxy interface.
  • COM CAN transport protocol
  • CanNm CAN network management
  • CanDrv CAN driver
  • VDC HW vehicle domain controller hardware
  • SDV atomic service is the atomic service 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 the embodiments of this application will not be repeated here.
  • an embodiment of the data processing method provided in an embodiment of the present application further includes:
  • the computer device obtains an update configuration file, which is a configuration file adapted and updated by the first user based on when the second user replaces the Legacy ECU.
  • the computer device 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.
  • 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.
  • CAN/LIN Support Scenarios Requires open module configuration Support message and signal changes
  • the Supports changing a signal in the Can/Lin message SWC/RTE/Com Support modification of Can/Lin message ID (receive/send) CanIf/LinIf Support modification of Can message sending mode Com Support modification of Can/Lin message sending cycle Com Support for additional messages and signals
  • the Supports reducing one signal in Can/Lin message SWC/RTE/LinIf/CanIf/PduR/Com Supports deleting Can/Lin messages at the sending/receiving node SWC/RTE/LinIf/CanIf/PduR/Com
  • the first configuration file can be open to the second user for configuration, and can specifically 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 hide it on the entire configuration file update interface through the configuration tool, and encrypt the ARXML of the second configuration file, while the first configuration file can be open to the second user without additional processing.
  • the updated configuration files of CanIf, LinIf and PduR can be encrypted and 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.
  • CanIf, LinIf, and PduR are standard modules in AUTOSAR CP. Those skilled in the art can understand their functions and implementation methods, and they will not be elaborated in the embodiments of this application.
  • steps for the first user to operate the computer device are steps for the first user to operate the computer device.
  • steps for the second user to operate the computer device are steps for the first user to operate the computer device.
  • the computer device 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 reception and transmission and mapping relationship, to obtain the updated first configuration file.
  • the configuration tool such as configuration information such as signal reception and transmission and mapping relationship
  • 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/.o file), which can be CanIf.o, LinIf.o or PduR.o file.
  • a single module for example, .a/.o file
  • 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).
  • the second user exports the update library file (eg, Pb_cfg.o) through the configuration tool.
  • the above steps 204-206 can be re-executed, and the computer device obtains the library files such as BSW.a (excluding modules that need to be changed by the second user, such as CanIf, LinIf or PduR), mcal.a, etc. delivered by the first user, and the SWC.a and ARXML files delivered by the first user.
  • the second user uses the configuration tool on the computer device to model the framework, imports the RTE and OS, and finally compiles the updated library files together to obtain a new executable file (such as a .hex/.elf file).
  • the OEM when the OEM configures the diagnostic protocol stack, the OEM will provide the ARXML configuration file and library file (such as .a file) of the application SWC to the parts supplier.
  • the parts supplier develops the static code in the diagnostic module (DIAG) according to the needs of the OEM and configures and compiles the DCM and diagnostic event manager (DEM) of the BSW.
  • DIAG diagnostic module
  • DEM diagnostic event manager
  • steps 501 - 506 in the data processing method shown in FIG. 5 may still be executed.
  • the updated configuration file is a configuration file adapted and updated by the first user based on the configuration of the diagnostic protocol stack by the second user
  • the second configuration file is a configuration file that the first user wishes to keep confidential, such as partial configuration files of modules such as DCM, DEM, function of inhibition manager (FiM) and NvM.
  • 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 (such as a .a/.o file), which can be 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 through the computer device to model the framework, import it into RTE and OS, and finally compiles the updated library files together to obtain a new executable file (such as a .hex/.elf file).
  • DCM Service DCM service
  • DID diagnostic data identifier
  • RID routine ID
  • DTC diagnostic trouble code
  • DTC freeze frame
  • FreezeFrame extended data
  • NvM module NvM Block
  • FID function identifier
  • the modules marked with "x" need to be changed, among which SWC_APP_DCM is still provided by the first user, and part of the contents 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, and complete the configuration of the unencrypted part of the open module and the overall integration.
  • 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 fault 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
  • 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, wherein 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.
  • the ".x file” described in the embodiments of the present application means a file with the suffix "x” (also called file extension, filename extension).
  • a ".hex file” means a file with the suffix "hex”, specifically an executable file
  • a ".a file” means a file with the suffix "a”, specifically a library file.
  • an embodiment of a computer device 800 provided in an embodiment of the present application includes:
  • the acquisition unit 801 is used to acquire the configuration file and the private library file generated by the first user; the acquisition unit 801 can execute step 201 in the above method embodiment.
  • the first generating unit 802 is used to generate an open library file based on the application software module and the configuration file generated by the second user; the first generating unit 802 can execute step 202 in the above method embodiment.
  • 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.
  • the configuration file includes a software layer configuration file and an application layer configuration file
  • the software layer configuration file includes an encrypted hidden configuration file
  • 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, and generate a framework configuration file; perform behavior modeling based on the framework configuration file, and 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.
  • private library files include software layer library files, hardware abstraction library files, device abstraction library files, and atomic service library files.
  • the acquisition unit 801 is specifically configured to acquire a configuration file and a private library file generated by the first user through a proxy interface.
  • 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 update library file based on the second configuration file and the updated first configuration file; and compile based on the update library file to obtain a new executable file.
  • 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 update library file based on the second configuration file and the updated first configuration file
  • compile based on the update library file to obtain a new executable file.
  • an embodiment of a computer device 900 provided in an embodiment of the present application includes:
  • the acquisition unit 901 is used to acquire the private file and application layer configuration file generated by the first user; the acquisition unit 901 can execute step 204 in the above method embodiment.
  • the first generating unit 902 is used to generate a first private library file and a software layer configuration file based on the private file; the first generating unit 902 can execute step 205 in the above method embodiment.
  • the second generating unit 903 is used to generate a second private library file based on the application layer configuration file, so that the second user generates 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.
  • the software layer configuration file includes an encrypted hidden configuration file
  • the computer device 900 further includes an encryption unit 904: the encryption unit 904 is used to encrypt part of the configuration files in the software layer configuration file to obtain an encrypted hidden configuration file.
  • 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.
  • the first private library file includes a software layer library file and a hardware abstract library file
  • the second private library file includes a device abstract library file and an atomic service library file.
  • 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.
  • the computer device also includes an updating unit 906; the acquiring unit 901 is further used to acquire an updated configuration file generated by the first user; the updating unit 906 is used to split the updated configuration file to obtain a first configuration file and a second configuration file; and encrypt the second configuration file so that the second user can generate a new executable file based on the first configuration file and the encrypted second configuration file.
  • 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.
  • 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 (neural-network processing unit, NPU) and at least one of other types of processors.
  • the processor 1001, the communication interface 1002 and the memory 1003 are interconnected through the bus 1004.
  • the processor 1001 is used to control and manage the actions of the computer device 1000, for example, the processor 1001 is used to execute steps 201 to 206 in FIG2A, and steps 501 to 506 in FIG5 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 codes and data of the computer device 1000 .
  • the processor 1001 can be a central processing unit, a general processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It can implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application.
  • the processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, and the like.
  • the bus 1004 can be a peripheral component interconnect standard (Peripheral Component Interconnect, PCI) bus or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, etc.
  • PCI peripheral component interconnect standard
  • EISA Extended Industry Standard Architecture
  • the bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in Figure 10, but it does not mean that there is only one bus or one type of bus.
  • a computer-readable storage medium in which computer-executable instructions are stored.
  • the device executes the data processing method described in the above embodiment.
  • a computer program product 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.
  • a chip system in another embodiment, includes at least one processor and an interface, the interface is used to receive data and/or signals, and at least one processor is used to support the data processing method described in the embodiment.
  • the chip system may also include a memory, the memory is used to store program instructions and data necessary for the computer device.
  • the chip system can be composed of chips, or it can include chips and other discrete devices.
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only schematic.
  • the division of the units is only a logical function division. There may be other division methods in actual implementation, 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.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
  • 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.
  • the technical solution of the present application can essentially or contribute to the 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 to enable a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application.
  • the aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk and other media that can store program code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

一种数据处理方法及相关设备，用于提升汽车开放系统架构的应用更新效率。本申请实施例方法包括：当原始设备制造商的应用软件模块更新时，零部件供应商只需要对基础软件层中不可开放的私密库文件进行相应的更新，原始设备制造商通过零部件供应商提供的配置文件和私密库文件就可以自行完成运行环境的生成和集成，提升了应用更新的效率。

Description

一种数据处理方法及相关设备 技术领域
本申请涉及计算机技术领域，具体涉及一种数据处理方法及相关设备。
背景技术
汽车开放系统架构(automotive open system architecture，AUTOSAR)是一家致力于制定汽车电子软件标准的联盟。
AUTOSAR架构主要分为三个层级：应用软件层(application layer，AppL)，运行环境(runtime environment，RTE)和基础软件层(basic software，BSW)，其中，原始设备制造商(original equipment manufacturer，OEM)，例如汽车整车制造商负责提供AppL，而零部件供应商负责提供RTE、BSW和集成服务。
但是在研发阶段，OEM会对应用软件(即AppL)或外围设备进行多次变更，这导致了零部件供应商也需要多次重新生成RTE和集成，这无疑增加了零部件供应商的交付压力，大大降低了应用更新的效率。
发明内容
本申请实施例提供数据处理方法及相关设备，用于提升了应用更新的效率。本申请实施例还提供了相应的计算机设备、计算机可读存储介质、芯片系统及计算机程序产品等。
本申请第一方面提供一种数据处理方法，该方法包括：获取第一用户生成的配置文件和私密库文件；基于第二用户生成的应用软件模块和配置文件生成开放库文件；对私密库文件和开放库文件进行编译，得到可执行文件。
本申请中，第一用户为零部件供应商，例如ECU供应商，第一用户负责提供BSW，那么第一用户会负责提供和交付配置文件和私密库文件，第二用户为OEM，负责AppL中的应用软件模块(software component，SWC)更新，即第二用户会对AppL中的应用软件模块进行更新，计算机设备基于更新后的SWC和第一用户生成的配置文件，使用建模工具、配置工具、Matlab或Simulink工具生成开放库文件，最后对私密库文件和开放库文件进行编译，得到可以在ECU上运行的可执行文件，OEM完成了独立更新SWC和集成。
该第一方面，当原始设备制造商的应用软件模块更新时，零部件供应商只需要对基础软件层中不可开放的私密库文件进行相应的更新，原始设备制造商通过零部件供应商提供的配置文件和私密库文件就可以自行完成运行环境的生成和集成，提升了应用更新的效率。
在第一方面的一种可能的实现方式中，配置文件包括软件层配置文件和应用层配置文件，软件层配置文件包括加密后的隐藏配置文件。
该种可能的实现方式中，应用层配置文件为AUTOSAR配置文件(AUTOSAR extensible markup language，ARXML)文件，具体可以为原子服务SWC配置文件和设备抽象SWC配置文件，软件层配置文件可以为与RTE/操作系统(operating system，OS)相关的ARXML配 置文件，对于隐藏配置文件，第一用户不允许第二用户访问或操作，以实现第一用户的技术保密。
在第一方面的一种可能的实现方式中，开放库文件包括应用层库文件、运行环境库文件和操作系统库文件；上述步骤：基于第二用户生成的应用软件模块和配置文件生成开放库文件包括：基于应用软件模块和应用层配置文件进行框架建模，生成框架配置文件；基于框架配置文件进行行为建模，生成应用层库文件；对框架配置文件和软件层配置文件进行编译，生成运行环境库文件和操作系统库文件。
该种可能的实现方式中，开放库文件包括应用层库文件(SWC.a)、运行环境库文件(RTE.a)和操作系统库文件(OS.a)，以应用层配置文件(原子服务SWC配置文件和设备抽象SWC配置文件)作为部分输入，结合更新后的SWC，使用建模工具进行应用层的整体框架建模，并导出框架配置文件，框架配置文件具体可以为单个SWC的ARXML文件，计算机设备继续使用框架配置文件，通过Matlab或Simulink工具进行行为建模，生成相关代码，最后编译出应用层库文件(SWC.a)，并基于框架配置文件和软件层配置文件进行使用配置工具生成代码，编译出运行环境库文件(RTE.a)和操作系统库文件(OS.a)，提升了方案的可实现性。
在第一方面的一种可能的实现方式中，私密库文件包括软件层库文件、硬件抽象库文件、设备抽象库文件和原子服务库文件。
该种可能的实现方式中，私密库文件具体包括软件层库文件(BSW.a)、硬件抽象库文件(MCAL.a)、设备抽象库文件(SWC.a)和原子服务库文件(SWC.a)，提升了方案的可实现性。
在第一方面的一种可能的实现方式中，上述步骤：获取第一用户生成的配置文件和私密库文件包括：通过代理接口获取第一用户生成的配置文件和私密库文件。
该种可能的实现方式中，将BSW中的服务接口上移至AppL，第二用户就可以自行在AppL中调用这些接口，即第二用户可以通过各种代理接口获取第一用户生成的配置文件和私密库文件，减少了第一用户根据第二用户需要适配BSW的频率。
在第一方面的一种可能的实现方式中，该方法还包括：获取第一用户生成的第一配置文件和加密后的第二配置文件；对第一配置文件进行更新，并基于第二配置文件和更新后的第一配置文件生成更新库文件；基于更新库文件进行编译，得到新的可执行文件。
该种可能的实现方式中，OEM还可以独立对通讯协议栈进行配置，或独立对诊断协议栈进行配置，提升了方案的可实现性。
本申请第二方面提供一种数据处理方法，该方法包括：获取第一用户生成的私密文件和应用层配置文件；基于私密文件生成第一私密库文件和软件层配置文件；基于应用层配置文件生成第二私密库文件，以使第二用户基于应用层配置文件、软件层配置文件、第一私密库文件和第二私密库文件生成可执行文件。
本申请中，第一用户会预先生成BSW的私密文件和应用层配置文件，私密文件具体可以为控制器域网(controller area network，CAN)通讯矩阵(data base CAN，DBC)文件和以太通信AUTOSAR配置文件(AUTOSAR extensible markup language，ARXML)文件，DBC 文件具体可以包括CAN总线文件和局域互联网络(local interconnect network，LIN)总线文件等，应用层配置文件为ARXML文件，具体可以为原子服务SWC配置文件和设备抽象SWC配置文件。
获取到DBC文件后，使用配置工具进行配置，并生成动态代码，然后使用编译器和/或链接器编译出第一私密库文件，此外，还可以从配置工具中导出软件层配置文件，软件层配置文件可以为与RTE/OS相关的ARXML配置文件。
该第二方面，当原始设备制造商的应用软件模块更新时，零部件供应商只需要对基础软件层中不可开放的私密库文件进行相应的更新，原始设备制造商通过零部件供应商提供的配置文件和私密库文件就可以自行完成运行环境的生成和集成，提升了应用更新的效率。
在第二方面的一种可能的实现方式中，软件层配置文件包括加密后的隐藏配置文件，该方法还包括：对软件层配置文件中的部分配置文件进行加密，得到加密后的隐藏配置文件。
该种可能的实现方式中，软件层配置文件可以为与RTE/操作系统(operating system，OS)相关的ARXML配置文件，对于隐藏配置文件，第一用户不允许第二用户访问或操作，以实现第一用户的技术保密。
在第二方面的一种可能的实现方式中，上述步骤：基于应用层配置文件生成第二私密库文件包括：基于应用层配置文件进行行为建模，生成第二私密库文件。
该种可能的实现方式中，获取到应用层配置文件后，可以使用Matlab或Simulink工具对应用层配置文件进行行为建模，生成第二私密库文件，提升了方案的可实现性。
在第二方面的一种可能的实现方式中，第一私密库文件包括软件层库文件和硬件抽象库文件，第二私密库文件包括设备抽象库文件和原子服务库文件。
该种可能的实现方式中，第一私密库文件具体可以是软件层库文件(BSW.a)和硬件抽象库文件(MCAL.a)，第二私密库文件具体可以是设备抽象库文件(SWC.a)和原子服务库文件(SWC.a)，提升了方案的可实现性。
在第二方面的一种可能的实现方式中，该方法还包括：配置代理接口，代理接口用于第二用户获取应用层配置文件、软件层配置文件、第一私密库文件和第二私密库文件。
该种可能的实现方式中，将BSW中的服务接口上移至AppL，第二用户就可以自行在AppL中调用这些接口，即第二用户可以通过各种代理接口获取第一用户生成的配置文件和私密库文件，减少了第一用户根据第二用户需要适配BSW的频率。
在第二方面的一种可能的实现方式中，该方法还包括：获取第一用户生成的更新配置文件；对更新配置文件进行拆分，得到第一配置文件和第二配置文件；对第二配置文件进行加密，以使第二用户基于第一配置文件和加密后的第二配置文件生成新的可执行文件。
该种可能的实现方式中，OEM还可以独立对通讯协议栈进行配置，或独立对诊断协议栈进行配置，提升了方案的可实现性。
本申请第三方面，提供了一种计算机设备，用于执行上述第一方面或第一方面的任意可能的实现方式中的方法。具体地，该计算机设备包括用于执行上述第一方面或第一方面的任意可能的实现方式中的方法的模块或单元，如：获取单元、第一生成单元、第二生成 单元和更新单元。
本申请第四方面，提供了一种计算机设备，用于执行上述第二方面或第二方面的任意可能的实现方式中的方法。具体地，该计算机设备包括用于执行上述第二方面或第二方面的任意可能的实现方式中的方法的模块或单元，如：获取单元、第一生成单元、第二生成单元、加密单元、配置单元和更新单元。
本申请第五方面提供一种计算机设备，该计算机设备包括处理器、内存和存储有计算机程序的计算机可读存储介质；处理器与计算机可读存储介质耦合，处理器上运行的计算机执行指令，当计算机执行指令被处理器执行时，处理器执行如上述第一方面或第一方面任意一种可能的实现方式的方法。可选地，该计算机设备还可以包括输入/输出(input/output，I/O)接口，该存储有计算机程序的计算机可读存储介质可以是存储器。
本申请第六方面提供一种计算机设备，该计算机设备包括处理器、内存和存储有计算机程序的计算机可读存储介质；处理器与计算机可读存储介质耦合，处理器上运行的计算机执行指令，当计算机执行指令被处理器执行时，处理器执行如上述第二方面或第二方面任意一种可能的实现方式的方法。可选地，该计算机设备还可以包括输入/输出(input/output，I/O)接口，该存储有计算机程序的计算机可读存储介质可以是存储器。
本申请第七方面提供一种存储一个或多个计算机执行指令的计算机可读存储介质，当计算机执行指令被处理器执行时，处理器执行如上述第一方面或第一方面任意一种可能的实现方式的方法。
本申请第八方面提供一种存储一个或多个计算机执行指令的计算机可读存储介质，当计算机执行指令被处理器执行时，处理器执行如上述第二方面或第二方面任意一种可能的实现方式的方法。
本申请第九方面提供一种存储一个或多个计算机执行指令的计算机程序产品，当计算机执行指令被处理器执行时，处理器执行如上述第一方面或第一方面任意一种可能的实现方式的方法。
本申请第十方面提供一种存储一个或多个计算机执行指令的计算机程序产品，当计算机执行指令被处理器执行时，处理器执行如上述第二方面或第二方面任意一种可能的实现方式的方法。
本申请第十一方面提供了一种芯片系统，该芯片系统包括至少一个处理器和接口，该接口用于接收数据和/或信号，至少一个处理器用于支持计算机设备实现上述第一方面或第一方面任意一种可能的实现方式中所涉及的功能。在一种可能的设计中，芯片系统还可以包括存储器，存储器，用于保存计算机设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
本申请第十二方面提供了一种芯片系统，该芯片系统包括至少一个处理器和接口，该接口用于接收数据和/或信号，至少一个处理器用于支持计算机设备实现上述第二方面或第二方面任意一种可能的实现方式中所涉及的功能。在一种可能的设计中，芯片系统还可以包括存储器，存储器，用于保存计算机设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
本申请实施例中，当原始设备制造商的应用软件模块更新时，零部件供应商只需要对基础软件层中不可开放的私密库文件进行相应的更新，原始设备制造商通过零部件供应商提供的配置文件和私密库文件就可以自行完成运行环境的生成和集成，提升了应用更新的效率。
附图说明
图1为汽车开放系统架构的架构示意图；
图2A为本申请实施例提供的数据处理方法的一实施例示意图；
图2B为本申请实施例提供的数据处理方法的另一实施例示意图；
图3为本申请实施例提供的配置代理接口的架构示意图；
图4为本申请实施例提供的配置通信协议栈的架构示意图；
图5为本申请实施例提供的数据处理方法的另一实施例示意图；
图6为本申请实施例提供的更新库文件的生成流程示意图；
图7为本申请实施例提供的配置诊断协议栈的架构示意图；
图8为本申请实施例提供的计算机设备的一实施例示意图；
图9为本申请实施例提供的计算机设备的另一实施例示意图；
图10为本申请实施例提供的计算机设备的另一实施例示意图。
具体实施方式
下面结合附图，对本申请的实施例进行描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。本领域普通技术人员可知，随着技术的发展和新场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
本申请实施例提供数据处理方法及相关设备，用于提升了应用更新的效率。本申请实施例还提供了相应的计算机设备、计算机可读存储介质、芯片系统及计算机程序产品等。以下分别进行详细说明。
下面对本申请实施例涉及的应用场景进行举例说明。
在汽车开放系统架构(automotive open system architecture，AUTOSAR)中，例如AUTOSAR经典平台(AUTOSAR classic platform，AUTOSAR CP)，为了实现应用程序和硬件模块之间的分离，汽车电子软件架构被抽象成四层，如图1所示，由上至下依次为：应用层(application layer，AppL)、运行环境(runtime environment，RTE)、基础软件层(basic  software,BSW)以及微控制器(micro controller)，其中，BSW为与功能无关的底层软件层，RTE为AUTOSAR中应用软件的运行环境。而BSW中也包括多个软件模块(下文简称模块)：系统服务模块、板载设备抽象模块、微控制器驱动模块、内存服务模块、内存硬件抽象模块、内存驱动模块、通信服务模块、通信硬件抽象模块、通信驱动模块、输入输出硬件抽象模块、输入输出驱动模块和复杂驱动模块等。这些不同的软件模块可以独立配置，但是同一个软件模块无法按照业务进行拆分。
AUTOSAR设计和开发流程分为三个阶段：系统配置阶段、电子控制单元(electronic control unit，ECU)设计与配置阶段和代码生成阶段。第一阶段定义系统配置文件，包括选择硬件和软件组件，定义整个系统的约束条件。AUTOSAR通过使用信息交换格式和模块描述文件来减少初始系统设计时的工作量。系统配置的输入为可扩展标记语言(extensible markup language,XML)类型的文件，输出为系统配置描述文件，系统配置的主要作用是把软件组件的需求映射到ECU上。第二阶段是根据系统配置描述文件提取单个ECU资源相关的信息，提取出来的信息生成ECU提取文件。根据这个提取文件对ECU进行配置，从而生成ECU配置描述文件。该描述文件包含了特定ECU的所有信息。最后一个阶段，即代码生成，是基于ECU配置描述文件指定的配置来产生代码、编译代码，并把相关的代码连接起来形成可执行文件。
在实际应用时，零部件供应商(例如ECU供应商)负责提供BSW和RTE，原始设备制造商(original equipment manufacturer，OEM)例如汽车整车制造商，负责提供AppL，例如提供应用软件模块(software component，SWC)，SWC为AUTOSAR CP中的应用软件，此外，零部件供应商还负责集成，完成AUTOSAR设计和开发流程。但是OEM在产品研发阶段，可能对SWC、通讯协议栈或诊断协议栈提出多次变更和更新的需求，相应的，零部件供应商就需要按照每次的需求进行BSW和RTE的配置、框架建模和最后的集成编译。
下面结合上述应用场景的描述对本申请实施例提供的数据处理方法进行详细说明。
本申请实施例提供的数据处理方法包括三个应用场景：OEM独立更新SWC；OEM独立对通讯协议栈进行配置；OEM独立对诊断协议栈进行配置。
场景一：
在OEM更新SWC时，OEM会对SWC进行增删改，包括可运行实体(runnable)的个数变更和调度周期的变更等，runnable为AUTOSAR CP中对运行实体的定义。在AUTOSAR CP架构下，RTE和操作系统(operating system，OS)中的任务映射(将runnable映射到定义好的任务中，TaskMapping)需要重新配置生成。在上述场景中，如图2A和图2B所示，本申请实施例提供的数据处理方法的一实施例包括：
201、获取第一用户生成的私密文件和应用层配置文件。
以计算机设备执行本申请实施例提供的数据处理方法为例，首先获取到第一用户生成的私密文件和应用层配置文件，其中第一用户为零部件供应商，例如ECU供应商，第一用户负责提供BSW，那么第一用户会预先生成BSW的私密文件和应用层配置文件，私密文件具体可以为控制器域网(controller area network，CAN)通讯矩阵(data base CAN，DBC)文件和以太通信AUTOSAR配置文件(AUTOSAR extensible markup language，ARXML)文件， 其中DBC文件为描述CAN报文的文件，ARXML文件是AUTOSAR中用来传递信息的工程配置文件，DBC文件具体可以包括CAN总线文件和局域互联网络(local interconnect network，LIN)总线文件等，应用层配置文件为ARXML文件，具体可以为原子服务SWC配置文件和设备抽象SWC配置文件。
202、基于私密文件生成第一私密库文件和软件层配置文件。
计算机设备获取到DBC文件后，使用配置工具进行配置，并生成动态代码，然后使用编译器和/或链接器编译出第一私密库文件，第一私密库文件具体可以是软件层库文件(例如BSW.a)和硬件抽象库文件(例如MCAL.a)。
此外，计算机设备还可以从配置工具中导出软件层配置文件，软件层配置文件可以为与RTE/OS相关的ARXML配置文件。
可选的，软件层配置文件还包括加密后的隐藏配置文件，计算机设备获取到软件层配置文件后，还会对软件层配置文件中的部分配置文件进行加密，得到加密后的隐藏配置文件。
示例性的，基于BSW的各个软件模块，软件层配置文件包括通讯模块(communication，COM)配置文件、大数据通讯模块(large data communication、LdCOM)配置文件、RTE配置文件、ECU配置模块(ECU configuration，ECUC)配置文件、OS配置文件和平台(platform)配置文件。
其中，RTE配置文件指的是RTE之上的SWC配置文件，COM配置文件、LdCOM配置文件和RTE配置文件全部开放给第二用户，整个ARXML文件不需要被加密或隐藏。ECUC配置文件、OS配置文件和platform配置文件为隐藏配置文件，第一用户不允许第二用户访问或操作，以实现第一用户的技术保密。
具体的，EcuC配置文件只开放ECUC配置设置(ECUC ConfigSet)与ECUC分区集合(ECUC Patition Collection)两个配置项，用于第二用户增加协议数据单元(protocol data Unit，Pdu)报文与SWC的配置，而EcuC配置文件中的ECUC硬件(ECUC Hardware)配置项需要隐藏和加密。
整个OS配置文件和platform配置文件进行隐藏和加密。对于OS配置文件，第二用户可以添加runnable到由第一用户定义好的任务(Task)中去，在“RTE TaskMapping”编辑器(editor)中开放映射(Mappings)页，而分区(Partitions)页隐藏。
203、基于应用层配置文件生成第二私密库文件。
计算机设备获取到应用层配置文件后，可以使用Matlab或Simulink工具对应用层配置文件进行行为建模，生成第二私密库文件，其中第二私密库文件具体可以是设备抽象库文件(例如SWC.a)和原子服务库文件(例如SWC.a)。
可选的，计算机设备还可以在AUTOSAR中配置代理接口，将BSW中的服务接口上移至AppL，第二用户就可以自行在AppL中调用这些接口，即第二用户可以通过各种代理接口获取第一用户生成的应用层配置文件、软件层配置文件、第一私密库文件和第二私密库文件。
具体的，如图3所示，应用层存在OEM SWC1、OEM SWC2和OEM SWC3三个SWC应用，通过配置基于IP的可扩展面向服务中间件(scalable service-oriented middleware over  IP，someip)服务代理SWC、持久化存储(non-volatile memory，NvM)代理SWC、诊断服务诊断通信管理(diagnostic communication manager，DCM)代理SWC和整车监控管理(vehicle health management，VHM)代理SWC(框架服务)等代理接口，SWC应用可以直接通过上述代理接口和RTE访问BSW中的LdCOM、NvM和DCM等模块，变更的影响限制在了RTE之上，而不需要对BSW做配置变更。
其中，someip为车载以太网的一种协议，DCM、NvM为AUTOSAR CP中的标准模块，本领域技术人员可以理解其功能和实现方式，本申请实施例不再赘述。
上述步骤为第一用户对计算机设备进行的操作步骤，下面说明第二用户对计算机设备进行操作的步骤。
204、获取第一用户生成的配置文件和私密库文件。
计算机设备通过代理接口从BSW获取第一用户生成的配置文件和私密库文件到AppL中，其中，配置文件包括上述的软件层配置文件和应用层配置文件，即软件层配置文件为与RTE/OS相关的ARXML配置文件，应用层配置文件为原子服务SWC配置文件和设备抽象SWC配置文件，可选的，软件层配置文件还包括加密后的隐藏配置文件。私密库文件包括上述的第一私密库文件和第二私密库文件，即软件层库文件、硬件抽象库文件、设备抽象库文件和原子服务库文件。
其中对第一用户生成的配置文件和私密库文件的具体描述可以参考上述实施例，本申请实施例在此不再赘述。
205、基于第二用户生成的应用软件模块和配置文件生成开放库文件。
在上述场景中，OEM会对SWC进行增删改，即第二用户会对AppL中的应用软件模块进行更新，计算机设备基于更新后的SWC和第一用户生成的配置文件，使用建模工具、配置工具、Matlab或Simulink工具生成开放库文件。
具体的，开放库文件包括应用层库文件(例如SWC.a)、运行环境库文件(例如RTE.a)和操作系统库文件(例如OS.a)，计算机设备以应用层配置文件(原子服务SWC配置文件和设备抽象SWC配置文件)作为部分输入，结合更新后的SWC，使用建模工具进行应用层的整体框架建模，并导出框架配置文件，框架配置文件具体可以为单个SWC的ARXML文件，计算机设备继续使用框架配置文件，通过Matlab或Simulink工具进行行为建模，生成相关代码，最后编译出应用层库文件(例如SWC.a)，并基于框架配置文件和软件层配置文件进行使用配置工具生成代码，编译出运行环境库文件(例如RTE.a)和操作系统库文件(例如OS.a)。
206、对私密库文件和开放库文件进行编译，得到可执行文件。
经过上述步骤，计算机设备获取到了应用层库文件(例如SWC.a)、运行环境库文件(例如RTE.a)、操作系统库文件(例如OS.a)、软件层库文件(例如BSW.a)、硬件抽象库文件(例如MCAL.a)、设备抽象库文件(例如SWC.a)和原子服务库文件(例如SWC.a)，计算机设备通过编译器/链接器进行编译，得到整个可执行文件(例如ECU.hex)，可执行文件可以在ECU上运行，由此第二用户OEM完成了独立更新SWC和集成。
本申请实施例中，当原始设备制造商的应用软件模块更新时，零部件供应商只需要对 基础软件层中不可开放的私密库文件进行相应的更新，原始设备制造商通过零部件供应商提供的配置文件和私密库文件就可以自行完成运行环境的生成和集成，提升了应用更新的效率，还减少了零部件供应商根据OEM需要适配BSW的频率。
场景二：
如图4所示，在OEM独立对通讯协议栈进行配置时，OEM会更换通过总线(CAN/LIN协议栈)接入的传统ECU(Legacy ECU)，这意味着局部通讯矩阵的变更，零部件供应商需要重新配置BSW的通讯协议栈，一般情况下，应用层的Legacy ECU服务中的SWC也会跟着变更，需要重新生成RTE和/或OS。OEM更换Legacy ECU时，应用层中的Legacy ECU原子服务，OS、BSW和MCAL中的通讯协议栈相关模块，例如COM、CAN传输协议(CAN transport protocol，CanTp)、CAN网络管理(CAN network management，CanNm)、CAN驱动(CAN driver，CanDrv)、CAN收发器(CAN transceiver，CanTrev)，以及通过整车控制器硬件(vehicle domain controller hardware，VDC HW)接入的Legacy ECU都需要跟着适配，这种情况下无法把所有的协议栈相关模块都通过代理接口上移到应用层。
其中，SDV原子服务为软件定义汽车(software defined vehicle，SDV)规范中定义的原子服务，COM、CanTp、CanNm、CanDrv、CanTrev为AUTOSAR CP中的标准模块，本领域技术人员可以理解其功能和实现方式，本申请实施例不再赘述。
在上述场景中，如图5所示，本申请实施例提供的数据处理方法的一实施例还包括：
501、获取第一用户生成的更新配置文件。
计算机设备获取到更新配置文件，该更新配置文件为第一用户基于第二用户更换Legacy ECU时适配更新得到的配置文件。
502、对更新配置文件进行拆分，得到第一配置文件和第二配置文件。
503、对第二配置文件进行加密。
计算机设备获取到更新配置文件后，还会对更新配置文件，例如Can接口(CanIf)、Lin接口(LinIf)和协议数据单元路由(PduR)等模块的配置文件进行拆分，得到第一配置文件和第二配置文件。
表1
CAN/LIN支持场景 需要开放的模块配置
支持报文与信号改变  
支持改变Can/Lin报文中的一个信号 SWC/RTE/Com
支持修改Can/Lin报文ID(接收/发送) CanIf/LinIf
支持修改Can报文发送模式 Com
支持修改Can/Lin报文发送周期 Com
支持报文与信号增加  
支持在发送/接收节点增加Can/Lin报文 SWC/RTE/LinIf/CanIf/PduR/Com
支持增加Can/Lin报文中的一个信号 SWC/RTE/LinIf/CanIf/PduR/Com
支持报文与信号删减  
支持减少Can/Lin报文中的一个信号 SWC/RTE/LinIf/CanIf/PduR/Com
支持在发送/接收节点删除Can/Lin报文 SWC/RTE/LinIf/CanIf/PduR/Com
其中，第一配置文件可以开放给第二用户配置，具体可以为CanIf、LinIf和PduR等模块的部分配置文件，第二配置文件为第一用户希望保密的配置文件，例如CanIf、LinIf和PduR等模块的另一部分配置文件，计算机设备可以通过配置工具在整个更新配置文件的界面上对其进行隐藏，并对第二配置文件的ARXML进行加密处理，而第一配置文件是可以开放给第二用户的，不做额外处理。
如表1所示，在不同的场景中，CanIf、LinIf和PduR的更新配置文件经过加密，都可以开放给第二用户，使得第二用户可以自行生成单个模块的库文件，完成对开放模块的未加密部分的配置和整体的集成。
其中，CanIf、LinIf、PduR为AUTOSAR CP中的标准模块，本领域技术人员可以理解其功能和实现方式，本申请实施例不再赘述。
上述步骤为第一用户对计算机设备进行的操作步骤，下面说明第二用户对计算机设备进行操作的步骤。
504、获取第一用户生成的第一配置文件和加密后的第二配置文件。
505、对第一配置文件进行更新，并基于第二配置文件和更新后的第一配置文件生成更新库文件。
计算机设备获取到第一配置文件和第二配置文件后，因第二配置文件已被隐藏和加密，第二用户只能对第一配置文件进行增删改，不能对第二配置文件修改，且更新的第一配置文件不能和第二配置文件产生冲突，即计算机设备通过配置工具对第一配置文件的信息进行处理，例如对信号收发和映射关系等配置信息进行处理，得到更新后的第一配置文件。
进一步的，计算机设备还需要基于第二配置文件和更新后的第一配置文件生成更新库文件，即基于第二配置文件和更新后的第一配置文件生成动态代码，并编译成单个模块的更新库文件(例如.a/.o文件)，具体可以为CanIf.o、LinIf.o或PduR.o文件。
示例性的，一并参照图6，第一用户完成对第一配置文件(BSW-A)的配置，第二用户完成对第二配置文件(BSW-B)的配置，第一配置文件加密后，第二用户通过配置工具导出更新库文件(例如Pb_cfg.o)。
506、基于更新库文件进行编译，得到新的可执行文件。
在计算机设备得到更新库文件后，可以重新执行上述步骤204-206，计算机设备获取第一用户交付的BSW.a(不包含需要第二用户更改的模块，例如CanIf、LinIf或PduR)、mcal.a等库文件，以及第一用户交付的SWC.a和ARXML文件等。第二用户通过计算机设备使用配置工具进行框架建模，并导入RTE和OS，最后将更新库文件一起编译，得到新的可执行文件(例如.hex/.elf文件)。
场景三：
如图7所示，在OEM对诊断协议栈进行配置时，OEM会把应用SWC的ARXML配置文件和库文件(例如.a文件)提供给零部件供应商，零部件供应商根据OEM的需求开发诊断模块(DIAG)中的静态代码并对BSW的DCM、诊断事件管理(diagnostic event manager，DEM)等进行配置编译，最终由零部件供应商完成集成编译。因此即使把DIAG模块开放给OEM，并假设OEM可以自己开发其中的代码，仍然需要在某些场景下对零部件供应商侧的BSW进行重新配置和 编译。
在上述场景中，依然可以执行上述图5所示的数据处理方法中的步骤501-506。
501、获取第一用户生成的更新配置文件。
502、对更新配置文件进行拆分，得到第一配置文件和第二配置文件。
503、对第二配置文件进行加密。
504、获取第一配置文件和加密后的第二配置文件。
505、对第一配置文件进行更新，并基于第二配置文件和更新后的第一配置文件生成更新库文件。
506、基于更新库文件进行编译，得到新的可执行文件。
其中，更新配置文件为第一用户基于第二用户配置诊断协议栈时适配更新得到的配置文件，第二配置文件为第一用户希望保密的配置文件，例如DCM、DEM、功能抑制管理(function of inhibition manager，FiM)和NvM等模块的部分配置文件。计算机设备获取到第一配置文件和第二配置文件后，还需要通过配置工具对第一配置文件的信息进行处理，例如对故障码、冻结帧和功能抑制等配置信息进行处理，得到更新后的第一配置文件。
进一步的，计算机设备还需要基于第二配置文件和更新后的第一配置文件生成更新库文件，即基于第二配置文件和更新后的第一配置文件生成动态代码，并编译成单个模块的更新库文件(例如.a/.o文件)，具体可以为DEM.o文件。计算机设备获取第一用户交付的BSW.a(不包含需要第二用户更改的模块，例如DEM)、mcal.a等库文件，以及第一用户交付的应用层诊断通讯模块(SWC_APP_DCM)的库文件和ARXML文件等。第二用户通过计算机设备使用配置工具进行框架建模，并导入RTE和OS，最后将更新库文件一起编译，得到新的可执行文件(例如.hex/.elf文件)。
如表2所示，在不同的场景中，例如对DCM服务(DCM Service)、诊断数据标识符(data identifier，DID)、例程ID(routine identifier，RID)、故障码(diagnostic trouble code，DTC)、冻结帧(FreezeFrame)、扩展数据(Extended Data)、NvM模块(NvM Block)和功能ID(function identifier，FID)进行变更时，需要对“x”标记的模块进行变更，其中SWC_APP_DCM仍然由第一用户提供，DCM、DEM、FiM和NvM的部分内容经过加密后可以开放给第二用户，使得第二用户可以自行生成单个模块的库文件，完成对开放模块的未加密部分的配置和整体的集成。
其中，DEM、FiM、NvM Block为AUTOSAR CP中的标准模块，DID为AUTOSAR CP中的诊断相关数据，RID为AUTOSAR CP中的诊断相关例程，DTC为AUTOSAR CP中的诊断故障码，FreezeFrame为AUTOSAR CP中的诊断冻结帧，FID为FiM模块中的功能ID，SWC_APP_DCM为自定义的DCM在应用层的代理，本领域技术人员可以理解其功能和实现方式，本申请实施例不再赘述。
具体实现方式可以参考如图5所示的实施例描述，本申请实施例不再赘述。
本申请实施例使用配置工具实现后编译(PB)功能，并结合配置工具的配置隐藏功能，纵向将模块的配置文件拆分成第一配置文件和第二配置文件两个ARXML文件，其中第二配置文件由零部件供应商配置，第一配置文件由OEM配置，不允许OEM对第二配置文件进行 任何改动，支持客户在第一配置文件进行增删改的操作，给OEM提供配置BSW相关模块的自由度，同时保护了零部件供应商的技术。
表2
变更场景 SWC_APP_DCM DCM DEM FiM NvM
增加DCM Service x x      
删除DCM Service x x      
修改DCM Service x x      
使能/禁用DCM service内部属性 x x      
增加DID x x      
删除DID x x      
修改DID x x      
使能/禁用DID内部属性 x x      
增加RID x x      
删除RID x x      
修改RID x x      
使能/禁用RID内部属性 x x      
增加DTC x   x    
删除DTC x   x    
修改DTC x   x    
增加FreezeFrame x   x   x
删除FreezeFrame x   x   x
修改FreezeFrame x   x   x
增加Extended Data x   x   x
删除Extended Data x   x   x
修改Extended Data x   x   x
增加NvM Block x   x   x
删除NvM Block x   x   x
修改NvM Block x   x   x
增加FID x     x  
删除FID x     x  
修改FID x     x  
应理解，本申请实施例中所描述的“.x文件”，含义为后缀名(也称文件扩展名，filename extension)为“x”的文件，例如“.hex文件”表示后缀名为“hex”的文件，具体为可执行文件，“.a文件”表示后缀名为“a”的文件，具体为库文件，本领域技术人员可以理解相似描述的具体含义。
以上介绍了本申请实施例提供的数据处理方法，下面结合附图介绍本申请实施例提供的相关设备。
如图8所示，本申请实施例提供的计算机设备800的一实施例包括：
获取单元801，用于获取第一用户生成的配置文件和私密库文件；该获取单元801可以执行上述方法实施例中的步骤201。
第一生成单元802，用于基于第二用户生成的应用软件模块和配置文件生成开放库文件；该第一生成单元802可以执行上述方法实施例中的步骤202。
第二生成单元803，用于对私密库文件和开放库文件进行编译，得到可执行文件。该第二生成单元803可以执行上述方法实施例中的步骤203。
可选的，配置文件包括软件层配置文件和应用层配置文件，软件层配置文件包括加密后的隐藏配置文件。
可选的，开放库文件包括应用层库文件、运行环境库文件和操作系统库文件；第一生成单元802具体用于基于应用软件模块和应用层配置文件进行框架建模，生成框架配置文件；基于框架配置文件进行行为建模，生成应用层库文件；对框架配置文件和软件层配置文件进行编译，生成运行环境库文件和操作系统库文件。
可选的，私密库文件包括软件层库文件、硬件抽象库文件、设备抽象库文件和原子服务库文件。
可选的，获取单元801具体用于通过代理接口获取第一用户生成的配置文件和私密库文件。
可选的，该计算机设备800还包括更新单元804：获取单元801还用于获取第一用户生成的第一配置文件和加密后的第二配置文件；更新单元804用于对第一配置文件进行更新，并基于第二配置文件和更新后的第一配置文件生成更新库文件；基于更新库文件进行编译，得到新的可执行文件。
如图9所示，本申请实施例提供的计算机设备900的一实施例包括：
获取单元901，用于获取第一用户生成的私密文件和应用层配置文件；该获取单元901可以执行上述方法实施例中的步骤204。
第一生成单元902，用于基于私密文件生成第一私密库文件和软件层配置文件；该第一生成单元902可以执行上述方法实施例中的步骤205。
第二生成单元903，用于基于应用层配置文件生成第二私密库文件，以使第二用户基于应用层配置文件、软件层配置文件、第一私密库文件和第二私密库文件生成可执行文件。该第二生成单元903可以执行上述方法实施例中的步骤206。
可选的，软件层配置文件包括加密后的隐藏配置文件，该计算机设备900还包括加密单元904：加密单元904用于对软件层配置文件中的部分配置文件进行加密，得到加密后的隐藏配置文件。
可选的，第二生成单元903具体用于基于应用层配置文件进行行为建模，生成第二私密库文件。
可选的，第一私密库文件包括软件层库文件和硬件抽象库文件，第二私密库文件包括设备抽象库文件和原子服务库文件。
可选的，该计算机设备900还包括配置单元905；配置单元905用于配置代理接口，代理接口用于第二用户获取应用层配置文件、软件层配置文件、第一私密库文件和第二私密库文件。
可选的，该计算机设备还包括更新单元906；获取单元901还用于获取第一用户生成 的更新配置文件；更新单元906用于对更新配置文件进行拆分，得到第一配置文件和第二配置文件；对第二配置文件进行加密，以使第二用户基于第一配置文件和加密后的第二配置文件生成新的可执行文件。
本申请实施例提供的计算机设备800和计算机设备900可以参阅前述数据处理方法实施例部分的相应内容进行理解，此处不再重复赘述。
图10所示，为本申请的实施例提供的计算机设备1000的一种可能的逻辑结构示意图。计算机设备1000包括：处理器1001、通信接口1002、存储器1003以及总线1004，该处理器1001可以包括中央处理器(central processing unit，CPU)，或者，CPU与图形处理器(graphics processing unit，GPU)和嵌入式神经网络处理器(neural-network processing unit，NPU)和其他类型的处理器中的至少一个。处理器1001、通信接口1002以及存储器1003通过总线1004相互连接。在本申请的实施例中，处理器1001用于对计算机设备1000的动作进行控制管理，例如，处理器1001用于执行图2A中的步骤201至206，以及图5中的步骤501至506和/或用于本文所描述的技术的其他过程。通信接口1002用于支持计算机设备1000进行通信。存储器1003，用于存储计算机设备1000的程序代码和数据。
其中，处理器1001可以是中央处理器单元，通用处理器，数字信号处理器，专用集成电路，现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理器和微处理器的组合等等。总线1004可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
在本申请的另一实施例中，还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当设备的至少一个处理器执行该计算机执行指令时，设备执行上述实施例所描述的数据处理方法。
在本申请的另一实施例中，还提供一种计算机程序产品，该计算机程序产品包括计算机执行指令，该计算机执行指令存储在计算机可读存储介质中；设备的至少一个处理器可以从计算机可读存储介质读取该计算机执行指令，至少一个处理器执行该计算机执行指令使得设备执行述实施例所描述的数据处理方法。
在本申请的另一实施例中，还提供一种芯片系统，该芯片系统包括至少一个处理器和接口，该接口用于接收数据和/或信号，至少一个处理器用于支持实现述实施例所描述的数据处理方法。在一种可能的设计中，芯片系统还可以包括存储器，存储器，用于保存计算机设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可 以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，read-only memory)、随机存取存储器(RAM，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (26)

  1. 一种数据处理方法，其特征在于，包括：
    获取第一用户生成的配置文件和私密库文件；
    基于第二用户生成的应用软件模块和所述配置文件生成开放库文件；
    对所述私密库文件和所述开放库文件进行编译，得到可执行文件。
  2. 根据权利要求1所述的方法，其特征在于，所述配置文件包括软件层配置文件和应用层配置文件，所述软件层配置文件包括加密后的隐藏配置文件。
  3. 根据权利要求2所述的方法，其特征在于，所述开放库文件包括应用层库文件、运行环境库文件和操作系统库文件；
    所述基于第二用户生成的应用软件模块和所述配置文件生成开放库文件包括：
    基于所述应用软件模块和所述应用层配置文件进行框架建模，生成框架配置文件；
    基于所述框架配置文件进行行为建模，生成所述应用层库文件；
    对所述框架配置文件和所述软件层配置文件进行编译，生成所述运行环境库文件和所述操作系统库文件。
  4. 根据权利要求1-3中任一项所述的方法，其特征在于，所述私密库文件包括软件层库文件、硬件抽象库文件、设备抽象库文件和原子服务库文件。
  5. 根据权利要求1-4中任一项所述的方法，其特征在于，获取第一用户生成的配置文件和私密库文件包括：
    通过代理接口获取第一用户生成的配置文件和私密库文件。
  6. 根据权利要求1-5中任一项所述的方法，其特征在于，所述方法还包括：
    获取所述第一用户生成的第一配置文件和加密后的第二配置文件；
    对所述第一配置文件进行更新，并基于所述第二配置文件和更新后的第一配置文件生成更新库文件；
    基于所述更新库文件进行编译，得到新的可执行文件。
  7. 一种数据处理方法，其特征在于，包括：
    获取第一用户生成的私密文件和应用层配置文件；
    基于所述私密文件生成第一私密库文件和软件层配置文件；
    基于所述应用层配置文件生成第二私密库文件，以使第二用户基于所述应用层配置文件、所述软件层配置文件、所述第一私密库文件和所述第二私密库文件生成可执行文件。
  8. 根据权利要求7所述的方法，其特征在于，所述软件层配置文件包括加密后的隐藏配置文件，所述方法还包括：
    对所述软件层配置文件中的部分配置文件进行加密，得到加密后的隐藏配置文件。
  9. 根据权利要求7或8所述的方法，其特征在于，所述基于所述应用层配置文件生成第二私密库文件包括：
    基于所述应用层配置文件进行行为建模，生成所述第二私密库文件。
  10. 根据权利要求7-9中任一项所述的方法，其特征在于，所述第一私密库文件包括软件层库文件和硬件抽象库文件，所述第二私密库文件包括设备抽象库文件和原子服务库文 件。
  11. 根据权利要求7-10中任一项所述的方法，其特征在于，所述方法还包括：
    配置代理接口，所述代理接口用于所述第二用户获取所述应用层配置文件、所述软件层配置文件、所述第一私密库文件和所述第二私密库文件。
  12. 根据权利要求7-11中任一项所述的方法，其特征在于，所述方法还包括：
    获取第一用户生成的更新配置文件；
    对所述更新配置文件进行拆分，得到第一配置文件和第二配置文件；
    对所述第二配置文件进行加密，以使所述第二用户基于所述第一配置文件和加密后的第二配置文件生成新的可执行文件。
  13. 一种计算机设备，其特征在于，包括：
    获取单元，用于获取第一用户生成的配置文件和私密库文件；
    第一生成单元，用于基于第二用户生成的应用软件模块和所述配置文件生成开放库文件；
    第二生成单元，用于对所述私密库文件和所述开放库文件进行编译，得到可执行文件。
  14. 根据权利要求13所述的设备，其特征在于，所述配置文件包括软件层配置文件和应用层配置文件，所述软件层配置文件包括加密后的隐藏配置文件。
  15. 根据权利要求14所述的设备，其特征在于，所述开放库文件包括应用层库文件、运行环境库文件和操作系统库文件；
    所述第一生成单元具体用于基于所述应用软件模块和所述应用层配置文件进行框架建模，生成框架配置文件；基于所述框架配置文件进行行为建模，生成所述应用层库文件；对所述框架配置文件和所述软件层配置文件进行编译，生成所述运行环境库文件和所述操作系统库文件。
  16. 根据权利要求13-15中任一项所述的设备，其特征在于，所述私密库文件包括软件层库文件、硬件抽象库文件、设备抽象库文件和原子服务库文件。
  17. 根据权利要求13-16中任一项所述的设备，其特征在于，所述获取单元具体用于通过代理接口获取第一用户生成的配置文件和私密库文件。
  18. 根据权利要求13-17中任一项所述的设备，其特征在于，所述计算机设备还包括更新单元：
    所述获取单元还用于获取所述第一用户生成的第一配置文件和加密后的第二配置文件；
    所述更新单元用于对所述第一配置文件进行更新，并基于所述第二配置文件和更新后的第一配置文件生成更新库文件；基于所述更新库文件进行编译，得到新的可执行文件。
  19. 一种计算机设备，其特征在于，包括：
    获取单元，用于获取第一用户生成的私密文件和应用层配置文件；
    第一生成单元，用于基于所述私密文件生成第一私密库文件和软件层配置文件；
    第二生成单元，用于基于所述应用层配置文件生成第二私密库文件，以使第二用户基于所述应用层配置文件、所述软件层配置文件、所述第一私密库文件和所述第二私密库文件生成可执行文件。
  20. 根据权利要求19所述的设备，其特征在于，所述软件层配置文件包括加密后的隐藏配置文件，所述计算机设备还包括加密单元：
    所述加密单元用于对所述软件层配置文件中的部分配置文件进行加密，得到加密后的隐藏配置文件。
  21. 根据权利要求19或20所述的设备，其特征在于，所述第二生成单元具体用于基于所述应用层配置文件进行行为建模，生成所述第二私密库文件。
  22. 根据权利要求19-21中任一项所述的设备，其特征在于，所述第一私密库文件包括软件层库文件和硬件抽象库文件，所述第二私密库文件包括设备抽象库文件和原子服务库文件。
  23. 根据权利要求19-22中任一项所述的设备，其特征在于，所述计算机设备还包括配置单元；
    所述配置单元用于配置代理接口，所述代理接口用于所述第二用户获取所述应用层配置文件、所述软件层配置文件、所述第一私密库文件和所述第二私密库文件。
  24. 根据权利要求19-23中任一项所述的设备，其特征在于，所述计算机设备还包括更新单元；
    所述获取单元还用于获取第一用户生成的更新配置文件；
    所述更新单元用于对所述更新配置文件进行拆分，得到第一配置文件和第二配置文件；对所述第二配置文件进行加密，以使所述第二用户基于所述第一配置文件和加密后的第二配置文件生成新的可执行文件。
  25. 一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-6或7-12中任一项所述的方法。
  26. 一种芯片系统，其特征在于，包括至少一个处理器和接口，所述接口用于接收数据和/或信号，所述至少一个处理器被配置为用于执行如权利要求1-6或7-12中任一项所述的方法。
PCT/CN2022/122389 2022-09-29 2022-09-29 一种数据处理方法及相关设备 Ceased WO2024065347A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2022/122389 WO2024065347A1 (zh) 2022-09-29 2022-09-29 一种数据处理方法及相关设备
CN202280100008.8A CN119856492A (zh) 2022-09-29 2022-09-29 一种数据处理方法及相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/122389 WO2024065347A1 (zh) 2022-09-29 2022-09-29 一种数据处理方法及相关设备

Publications (1)

Publication Number Publication Date
WO2024065347A1 true WO2024065347A1 (zh) 2024-04-04

Family

ID=90475263

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/122389 Ceased WO2024065347A1 (zh) 2022-09-29 2022-09-29 一种数据处理方法及相关设备

Country Status (2)

Country Link
CN (1) CN119856492A (zh)
WO (1) WO2024065347A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200218531A1 (en) * 2019-01-07 2020-07-09 Nokia Solutions And Networks Oy OVER-THE-AIR (OTA) UPDATES OF ELECTRONIC CONTROL UNITS (ECUs) IN VEHICLES
CN114172938A (zh) * 2022-02-10 2022-03-11 诚迈科技（南京）股份有限公司 智能座舱soa化的实现方法、系统和智能汽车
CN114895935A (zh) * 2022-04-25 2022-08-12 深圳市元征科技股份有限公司 刷写车辆ecu的方法、装置、电子设备及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200218531A1 (en) * 2019-01-07 2020-07-09 Nokia Solutions And Networks Oy OVER-THE-AIR (OTA) UPDATES OF ELECTRONIC CONTROL UNITS (ECUs) IN VEHICLES
CN114172938A (zh) * 2022-02-10 2022-03-11 诚迈科技（南京）股份有限公司 智能座舱soa化的实现方法、系统和智能汽车
CN114895935A (zh) * 2022-04-25 2022-08-12 深圳市元征科技股份有限公司 刷写车辆ecu的方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN119856492A (zh) 2025-04-18

Similar Documents

Publication Publication Date Title
US8521359B1 (en) Application-independent and component-isolated system and system of systems framework
US8024564B2 (en) Automating configuration of software applications
JP5021475B2 (ja) コンテキストポリシー制御によるアプリケーション間の関連付けの制御のためのシステムおよび方法
US10594800B2 (en) Platform runtime abstraction
CN112149169B (zh) 一种应用访问方法、装置及计算机可读存储介质
KR20070049166A (ko) 목표 기기 상에서의 종속 소프트웨어 패키지의 검출 및이용을 자동화하기 위한 방법 및 소프트웨어 리포지터리를생성하기 위한 시스템
WO2020096867A1 (en) Generating and implementing a platform-neutral cloud-native application model
US20080282242A1 (en) Simulation management within a grid infrastructure
WO2024093731A1 (zh) 汽车开放系统架构、数据处理方法及车载设备
US20220038367A1 (en) System and method of suppressing inbound payload to an integration flow of an orchestration based application integration
CN115794093A (zh) 一种基于多应用融合的微前端实现方法
CN114581241A (zh) 智能合约的处理方法和装置、处理器及电子设备
Tarafdar et al. Building the infrastructure for deploying FPGAs in the cloud
Cebotari et al. On the Nature of Automotive Service Architectures.
WO2024065347A1 (zh) 一种数据处理方法及相关设备
CN110955412B (zh) 面向服务的智能座舱系统及其设计方法和设计系统
CN119512534A (zh) 代码的生成方法、装置、计算机程序产品以及电子设备
WO2026056875A1 (zh) 一种代码开发方法及相关装置
Zaremba et al. Towards dynamic execution semantics in semantic web services
JP2001318903A (ja) コンピュータ演算処理システム及び同システムにより実行されるコンピュータ演算処理方法
Ni et al. Design and implementation of a dynamic component model for federated AUTOSAR systems
CN110083469B (zh) 一种异构硬件组织运行统一内核方法及系统
Dolstra et al. Charon: Declarative provisioning and deployment
CN118656086B (zh) 一种低代码应用基于SaaS多租户间的复制方法
US20250330377A1 (en) Configuration Method and Apparatus

Legal Events

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

Ref document number: 22959990

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202280100008.8

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 202280100008.8

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22959990

Country of ref document: EP

Kind code of ref document: A1