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

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

Info

Publication number
CN119856492A
CN119856492A CN202280100008.8A CN202280100008A CN119856492A CN 119856492 A CN119856492 A CN 119856492A CN 202280100008 A CN202280100008 A CN 202280100008A CN 119856492 A CN119856492 A CN 119856492A
Authority
CN
China
Prior art keywords
file
configuration file
library
library file
configuration
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.)
Pending
Application number
CN202280100008.8A
Other languages
English (en)
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.)
Shenzhen Yinwang Intelligent Technology Co Ltd
Original Assignee
Shenzhen Yinwang Intelligent Technology 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 Shenzhen Yinwang Intelligent Technology Co Ltd filed Critical Shenzhen Yinwang Intelligent Technology Co Ltd
Publication of CN119856492A publication Critical patent/CN119856492A/zh
Pending legal-status Critical Current

Links

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

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中任一项所述的方法。
CN202280100008.8A 2022-09-29 2022-09-29 一种数据处理方法及相关设备 Pending CN119856492A (zh)

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
CN119856492A true CN119856492A (zh) 2025-04-18

Family

ID=90475263

Family Applications (1)

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

Country Status (2)

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

Family Cites Families (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
CN114172938B (zh) * 2022-02-10 2022-05-20 诚迈科技（南京）股份有限公司 智能座舱soa化的实现方法、系统和智能汽车
CN114895935A (zh) * 2022-04-25 2022-08-12 深圳市元征科技股份有限公司 刷写车辆ecu的方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
WO2024065347A1 (zh) 2024-04-04

Similar Documents

Publication Publication Date Title
CN111385191B (zh) 车载互联网关、车辆ota升级系统和方法、计算机存储介质
Fürst Challenges in the design of automotive software
US11838375B2 (en) Universal software communication bus
Thiel et al. Systematic integration of variability into product line architecture design
US7146307B2 (en) System and method for testing telematics software
JP3851042B2 (ja) 自動車用コンピュータ・システム
Vetter et al. Development processes in automotive service-oriented architectures
US20170048331A1 (en) Platform runtime abstraction
EP4689906A1 (en) Vehicle test environment management service
Axelsson et al. On the conceptual design of a dynamic component model for reconfigurable AUTOSAR systems
Keßler et al. The software defined vehicle–technical and organizational challenges and opportunities
Briciu et al. A new trend in automotive software: AUTOSAR concept
Cebotari et al. On the Nature of Automotive Service Architectures.
Madhuri et al. Software-defined vehicles: The future of automobile industry
CN109740304A (zh) 一种车型诊断权限管理方法及相关设备
Becker Operating system for software-defined vehicles
US12411757B1 (en) Vehicle software change control system
Li et al. OSGi-based service gateway architecture for intelligent automobiles
CN119856492A (zh) 一种数据处理方法及相关设备
CN119512534A (zh) 代码的生成方法、装置、计算机程序产品以及电子设备
CN110955412B (zh) 面向服务的智能座舱系统及其设计方法和设计系统
Mattausch et al. E/E architectures and the automotive OS
CN120615189A (zh) 一种用于调整用于安全性检查的测试用例的方法
US12255894B2 (en) Method and system for running an identity and access management system
CN121029137A (zh) 一种代码开发方法及相关装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information

Country or region after: China

Address after: 518110 Guangdong Province Shenzhen City Longhua District Fucheng Street Jiulianshan Community Jingyue Road No. 1 Building A1 101

Applicant after: Yinwang Intelligent Technology Co., Ltd.

Address before: 518129 Huawei Headquarters Office Building 101, Wankecheng Community, Bantian Street, Longgang District, Shenzhen, Guangdong

Applicant before: Shenzhen Yinwang Intelligent Technology Co.,Ltd.

Country or region before: China