CN113641413A - 目标模型加载更新方法及装置、可读介质和电子设备 - Google Patents

Abstract

本公开提供一种目标模型加载更新方法及装置、计算机可读介质和电子设备，涉及计算机技术领域。该方法包括：获取目标模型对应的可执行文件；若检测到嵌入式实时操作系统请求运行目标模型，则将可执行文件解析生成待加载结构体，并以共享内存的方式传递给嵌入式实时操作系统的第二内存，以使嵌入式实时操作系统将待加载结构体作为待运行任务进行启动运行，实现目标模型的加载更新。本公开能够在SensorHub环境下实现人工智能模型的动态加载或者更新，不需要每次将人工智能模型与OS内核一起编译成完整镜像到SensorHub运行，有效提高SensorHub环境中人工智能模型的更新效率，节省内存空间。

Description

目标模型加载更新方法及装置、可读介质和电子设备

技术领域

本公开涉及计算机技术领域，具体涉及一种目标模型加载更新方法、目标模型加载更新装置、计算机可读介质和电子设备。

背景技术

随着人工智能技术(Artificial Intelligence，AI)的研究和进步，人工智能技术在多个领域展开研究和应用，例如常见的智能家居、智能穿戴设备、虚拟助理、智能音箱、智能营销、无人驾驶、自动驾驶、无人机、机器人、智能医疗、智能客服等。

AI算法在相关移动终端的低功耗平台SensorHub上有着越来越多的应用，如一些在智能手机上需要常开的AI算法，实现步行者位置感知，情景感知等等，基于此，AI模型如何在SensorHub上部署成为一个需要考虑的热点。

目前，在SensorHub上加载或者更新训练好的AI模型时，需要将AI模型对应的代码和OS内核一起编译，生成一个完整的镜像，然后传递到SensorHub的嵌入式实时操作系统运行。这样，一旦AI模型需要更新，就必须重新编译所有代码并重新烧写镜像，降低了SensorHub中AI模型的加载更新效率，同时，镜像文件占用的内存空间较多，对SensorHub造成较大的内存压力。

发明内容

本公开的目的在于提供一种目标模型加载更新方法、目标模型加载更新装置、计算机可读介质和电子设备，进而至少在一定程度上提高在SensorHub平台中AI模型的加载更新效率，节省内存空间。

根据本公开的第一方面，提供一种目标模型加载更新方法，包括：

获取目标模型对应的可执行文件；

若检测到所述嵌入式实时操作系统请求运行所述目标模型，则将所述可执行文件解析到第一内存中生成待加载结构体；

将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存，以使所述嵌入式实时操作系统将所述第二内存中的所述待加载结构体作为待运行任务进行启动运行，实现所述目标模型的动态加载更新。

根据本公开的第二方面，提供一种目标模型加载更新装置，包括：

可执行文件获取模块，用于获取目标模型对应的可执行文件；

结构体生成模块，用于若检测到所述嵌入式实时操作系统请求运行所述目标模型，则将所述可执行文件解析到第一内存中生成待加载结构体；

模型加载更新模块，用于将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存，以使所述嵌入式实时操作系统将所述第二内存中的所述待加载结构体作为待运行任务进行启动运行，实现所述目标模型的动态加载更新。

根据本公开的第三方面，提供一种计算机可读介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述的方法。

根据本公开的第四方面，提供一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现上述的方法。

本公开的一种实施例所提供的目标模型加载更新方法，获取目标模型对应的可执行文件并存储到应用处理器侧的文件系统，在检测到SensorHub请求运行目标模型时，将可执行文件解析到第一内存中生成待加载结构体，并将待加载结构体以共享内存的方式传递给SensorHub的第二内存，以使嵌入式实时操作系统将第二内存中的待加载结构体作为待运行任务进行启动运行，实现目标模型的动态加载更新。一方面，先将目标模型对应的可执行文件存储到文件系统，并以共享内存的方式传递给SensorHub的嵌入式实时操作系统，使嵌入式实时操作系统将可执行文件对应的待加载结构体作为待运行任务进行启动运行，实现了目标模型在SensorHub上的动态加载更新，并不需要将目标模型对应的代码与内核烧录成镜像文件发给SensorHub运行，有效提升目标模型的加载更新效率；另一方面，将目标模型对应可执行文件存储到第一内存中，在嵌入式实时操作系统请求运行时，将可执行文件传递给嵌入式实时操作系统中的第二内存，通过这样的动态加载特性降低嵌入式实时操作系统的内存占用，减少嵌入式实时操作系统的内存压力，进一步保证目标模型的加载更新效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了可以应用本公开实施例的一种示例性系统架构的示意图；

图2示出了可以应用本公开实施例的一种电子设备的示意图；

图3示意性示出本公开示例性实施例中一种目标模型加载更新方法的流程示意图；

图4示意性示出本公开示例性实施例中一种实现将待加载结构体作为待运行任务启动运行的流程示意图；

图5示意性示出本公开示例性实施例中一种实现待加载结构体的代码迁移的流程示意图；

图6示意性示出本公开示例性实施例中一种符号重定位的流程示意图；

图7示意性示出本公开示例性实施例中一种卸载目标模型的流程示意图；

图8示意性示出本公开示例性实施例中一种分层加载目标模型的流程示意图；

图9示意性示出本公开示例性实施例中一种实现目标模型分层加载的结构示意图；

图10示意性示出本公开示例性实施例中一种实现目标模型加载更新的系统示意图；

图11示意性示出本公开示例性实施例中目标模型加载更新装置的组成示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1示出了可以应用本公开实施例的一种目标模型加载更新方法及装置的示例性应用环境的系统架构的示意图。

如图1所示，系统架构100可以包括终端设备101、102、103中的一个或多个，网络104和云端服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。终端设备101、102、103可以是各种集成有低功耗计算平台的电子设备，包括但不限于智能手机和平板电脑等等。应该理解，图1中的终端设备、网络和云端服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和云端服务器。比如云端服务器105可以是多个服务器组成的服务器集群等。

本公开的示例性实施方式提供一种用于实现目标模型加载更新方法的电子设备，其可以是图1中的终端设备101、102、103。该电子设备至少包括处理器和存储器，存储器用于存储处理器的可执行指令，处理器配置为经由执行可执行指令来执行目标模型加载更新方法。

下面以图2中的移动终端200为例，对电子设备的构造进行示例性说明。本领域技术人员应当理解，除了特别用于移动目的的部件之外，图2中的构造也能够应用于固定类型的设备。

如图2所示，移动终端200可以至少包括应用处理器(Application Processor，AP)210和低功耗计算平台(SensorHub，又称智能传感集线器)220。

应用处理器210是指在低功耗CPU的基础上扩展音视频功能和专用接口的超大规模集成电路，目前是以协处理器的地位出现在智能手机中。

低功耗计算平台220是一种基于低功耗MCU(Microcontroller Unit，MCU)和轻量级的嵌入式实时操作系统(Real Time Operating System，RTOS)之上的软硬件结合的解决方案，其主要功能是连接并处理来自各种传感器设备的数据。诞生之初的目的主要是为了解决在移动设备端的功耗问题，现在随着业务的不断增加，其功能和性能都在不断迭代更新，例如用于常开的步行者位置感知，情景感知等应用场景。

在另一些实施方式中，移动终端200可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件或软件和硬件的组合实现。各部件间的接口连接关系只是示意性示出，并不构成对移动终端200的结构限定。

下面以移动终端200执行该方法为例，对本公开示例性实施方式的目标模型加载更新方法和目标模型加载更新装置进行具体说明。

图3示出了本示例性实施方式中一种目标模型加载更新方法的流程示意图，可以包括步骤S310至步骤S330：

在步骤S310中，获取目标模型对应的可执行文件。

在一示例性实施例中，目标模型是指需要动态加载或者更新到终端设备的SensorHub中的算法模型，例如，目标模型可以是在远端服务器训练完成的人工智能模型，如人工智能模型可以是结合SensorHub采集的传感器数据实现步行者感知或者情景感知的神经网络模型，当然，目标模型也可以是机器学习模型，本示例实施例对此不做特殊限定。

目标模型也可以是需要加载或者更新到终端设备的SensorHub中的软件模块(软件代码)，用于实现SensorHub不同功能，例如目标模型可以是用于优化SensorHub的实时控制以降低功耗的软件代码，也可以是实现对不同的传感器数据进行融合的软件模块，本示例实施例对此不做特殊限定。

可执行文件是指云端服务器将训练完成的目标模型进行编译处理生成的可执行类型的文件，例如，可执行文件可以是可执行可链接文件(Executable and LinkableFormat，ELF)，目前常见的Linux可执行文件、Android可执行文件、共享库(.so)、目标文件(.o)均为此格式，具体可以使用SensorHub平台的交叉编译工具链将目标模型转换生成ELF文件；可执行文件也可以是二进制文件(Binary，Bin)，Bin一般来讲是机器代码，汇编语言编译后的结果；当然，可执行文件还可以是其他文件格式类型的可执行文件，本示例实施例对此不做特殊限定。

具体的，可以向云端服务器发送目标模型的加载更新请求，以获取云端服务器响应加载更新请求并返回的可执行文件；以及将可执行文件存储到目标文件系统中。

其中，加载更新请求是指终端设备在检测到需要加载或者更新目标模型或者相关软件模块时向云端服务器发送的请求指令，该请求指令可以包括目标模型的标识信息，如该标识信息可以是目标模型的唯一编码。目标文件系统是指应用处理器AP侧对应的文件系统。

在步骤S320中，若检测到所述嵌入式实时操作系统请求运行所述目标模型，则将所述可执行文件解析到第一内存中生成待加载结构体。

在一示例性实施例中，嵌入式实时操作系统RTOS是指当外界事件或数据产生时，能够接受并以足够快的速度予以处理，其处理的结果又能在规定的时间之内来控制生产过程或对处理系统做出快速响应，调度一切可利用的资源完成实时任务，并控制所有实时任务协调一致运行的操作系统，提供及时响应和高可靠性是其主要特点。

第一内存是指应用处理器AP侧对应的内存空间，由于SensorHub平台并不支持文件系统，因此，在从云端服务器获取到目标模型对应的可执行文件之后，可以将可执行文件存储的到应用处理器AP侧对应的文件系统中，并在SensorHub平台的嵌入式实时操作系统请求运行目标模型时，将文件系统中存储的可执行文件解析到应用处理器AP侧对应内存空间即第一内存中，进而可以通过共享内存的方式将其传递到嵌入式实时操作系统的内存空间。

结构体(struct)是一种数据结构，是C语言中聚合数据类型(aggregate datatype)的一类。结构体可以被声明为变量、指针或数组等，用以实现较复杂的数据结构。结构体同时也是一些元素的集合，这些元素称为结构体的成员(member)，且这些成员可以为不同的类型，成员一般用名字访问。

待加载结构体是指可执行文件解析到第一内存中生成的load_info结构体，举例而言，load_info结构体的定义可以如以下伪代码所示：

当然，此处的load_info结构体的伪代码仅是示意性举例说明，并不应对本示例实施例造成任何特殊限定。

在步骤S330中，将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存，以使所述嵌入式实时操作系统将所述第二内存中的所述待加载结构体作为待运行任务进行启动运行，实现所述目标模型的动态加载更新。

在一示例性实施例中，共享内存的方式是指是多进程或者多处理器之间的通信方法，这种方法通常用于一个程序的多进程间通信，实际上多个程序间也可以通过共享内存来传递信息。第二内存是指嵌入式实时操作系统对应的实际运行内存。

SensorHub平台一般使用的时轻量级的嵌入式实时操作系统，而嵌入式实时操作系统不支持动态加载的功能，本公开是借鉴Linux系统的动态加载特性，并将其应用到SensorHub平台中的嵌入式实时操作系统，较好地实现了在嵌入式实时操作系统上实现目标模型的动态加载或者动态更新的目的，有效提升了在SensorHub平台的嵌入式实时操作系统上加载更新人工智能模型或者软件模块的效率，便于后续的升级。

下面，对步骤S310至步骤S330进行详细说明。

在一示例性实施例中，可以通过图4中的步骤实现使嵌入式实时操作系统将第二内存中的待加载结构体作为待运行任务进行启动运行，参考图4所示，具体可以包括：

步骤S410，从所述待加载结构体中获取所述可执行文件的文件头，并根据所述文件头确定所述待加载结构体的入口函数相对于代码段的偏移量；

步骤S420，基于所述代码段的加载地址以及所述偏移量确定所述待加载结构体的绝对入口地址；

步骤S430，在创建待运行任务时，将所述待运行任务的入口地址设置为所述待加载结构体的绝对入口地址，实现将所述待加载结构体作为所述待运行任务进行启动运行。

其中，以可执行文件是ELF文件为例，ELF文件的文件头是指待加载结构体中的ELFHeader，可以从ELF Header中得到节区头部表(section header table)在ELF文件中的偏移位置(sh_offset)和大小(sh_size)，节区头部表描述了各节区(section)在进程内存中的起始位置和偏移，起始位置初始为0，在SensorHub中真正启动加载目标模型时，可以将起始位置修改为SensorHub可用内存的起始位置，而节区的内容在ELF文件的节区(section)中。

加载地址是指代码段存储在第二内存中的物理地址，可以在ELF文件的文件头ELFHeader中获取待加载结构体的入口函数相对于代码段(.text)的偏移量，具体可以根据关系式(1)计算待加载结构体的绝对入口地址：

A1＝A2+a (1)

其中，A1是指待加载结构体的绝对入口地址，A2是指代码段的加载地址，a是指入口函数相对于代码段的偏移量。

在一示例性实施例中，可以通过图5中的步骤实现将待加载结构体以共享内存的方式传递给嵌入式实时操作系统的第二内存，参考图5所示，具体可以包括：

步骤S510，从所述待加载结构体中获取所述可执行文件的文件头，并根据所述文件头确定代码段、只读数据段、数据段以及未初始数据段的占用空间和偏移位置；

步骤S520，基于所述占用空间计算加载所述待加载结构体所需的总占用空间；

步骤S530，根据所述总占用空间分配所述待加载结构体在所述第二内存中的首地址，并按照所述首地址以及所述偏移位置计算实际内存地址；

步骤S540，按照所述实际内存地址将所述代码段、所述只读数据段、所述数据段以及所述未初始数据段复制到所述第二内存中，实现将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存。

其中，以可执行文件是ELF文件为例，可以获取ELF文件的文件头ELF Header，并从ELF Header中获取到节区头部字符串表的索引，进而根据该索引确定代码段(.text)、只读数据段(.rodata)、数据段(.data)以及未初始数据段(.bss)的占用空间和偏移位置。

在计算总占用空间时，除了代码段(.text)、只读数据段(.rodata)、数据段(.data)以及未初始数据段(.bss)的占用空间，由于需要创建待运行任务，而待运行任务中需要包含任务控制块(Task Control Block，TCB)和任务栈(Task Stack)，因此，需要将各段的占用空间加上任务控制块和任务栈的占用空间，才是加载运行待加载结构体所需的总占用空间。

实际内存地址是指待加载结构体中各节区section(即代码段(.text)、只读数据段(.rodata)、数据段(.data)以及未初始数据段(.bss))在嵌入式实时操作系统对应的运行内存即第二内存中的地址。

具体的，在通过图5的步骤将待加载结构体迁移到嵌入式实时操作系统对应的运行内存时，可以根据在DRAM(Dynamic Random Access Memory，动态随机存取存储器)或者SRAM(Static Random-Access Memory，静态随机存取存储器)加载运行待加载结构体的需求，选择通过动态任务创建的方式或者选择静态任务创建的方式将待加载结构体作为待运行任务进行加载。在选择通过动态任务创建的方式加载待加载结构体时，待加载结构体的总占用空间对应的内存可以从堆区(heap，用于动态分配内存，位于BSS和栈中间的地址区域，由程序员申请分配和释放)中进行分配；或在选择通过静态任务创建的方式加载待加载结构体时，待加载结构体的总占用空间对应的内存可以从静态区(static)中进行分配。

在一示例性实施例中，由于待加载结构体的代码搬移完成之后，需要将代码里面的各函数和变量的地址进行重定位，也就是说必须先解决静态链接时的符号引用与动态加载时实际符号地址不一致的问题，搬移后的待加载结构体对应的模块才能运行起来。

具体的，可以根据文件头确定代码段、只读数据段、数据段以及未初始数据段对应的重定位表，进而可以通过重定位表对代码段、只读数据段、数据段以及未初始数据段中的符号进行重定位。

图6示意性示出本公开示例性实施例中一种符号重定位的流程示意图。

参考图6所示，步骤S610，遍历符号表；

步骤S620，判断符号是否属于代码段、只读数据段、数据段以及未初始数据段其中之一，若是则执行步骤S630，否则结束当前流程；

步骤S630，判断符号是否是SHN_UNDEF类型，若是则执行步骤S640，否则执行步骤S650；

步骤S640，判断符号在内核符号中是否能找到，若能找到则执行步骤S660，否则执行步骤S670；

步骤S650，修改符号表中符号的地址为实际内存地址，实际内存地址可以根据待运行任务的总占用空间以及符号在节区section中的偏移相加得到；

步骤S660，修改符号表中符号的地址为内核符号表中的地址；

步骤S670，终止加载并报错；

步骤S680，将修改后的符号地址应用到各个段。

在一示例性实施例中，可以通过图7中的步骤实现将目标模型从SensorHub平台的嵌入式实时操作系统中进行卸载，参考图7所示，具体可以包括：

步骤S710，将所述待运行任务从所述嵌入式实时操作系统对应的待运行任务队列和事件队列中进行删除，以实现将所述待运行任务插入到待删除任务队列中；以及

步骤S720，通过目标进程任务对所述待删除任务队列中的所述待运行任务进行地址空间释放，实现所述目标模型的卸载。

其中，目标进程任务是指Idle任务，Idle任务如果发现待删除任务队列中有待删除的任务存在，则会自动释放该任务的地址空间。

在待运行任务运行结束时，可以将待运行任务从嵌入式实时操作系统对应的待运行任务队列和事件队列中进行删除，此时待运行任务被放入到待删除任务队列，在Idle任务中，会对待删除任务队列中的待运行任务占用的地址空间进行释放，实现目标模型的卸载。

在一示例实施例中，在目标模型为人工智能模型时，目标模型可以包括多个结构层，一些情况下，目标模型所占用的内存空间可能大于或者等于SensorHub的内存空间，此时，如果将整个目标模型直接加载到SensorHub中，可能导致SensorHub的内存空间压力大，甚至有可能导致SensorHub的运行崩溃。鉴于此，可以通过图8中的步骤实现目标模型分层加载，降低SensorHub的内存压力，参考图8所示，具体可以包括：

步骤S810，从云端服务器获取所述目标模型中第一结构层对应的第一可执行文件，并将所述第一可执行文件的待加载结构体作为所述嵌入式实时操作系统的第一任务进行加载运行；

步骤S820，在所述第一任务运行完成后，卸载所述第一结构层；以及

步骤S830，从云端服务器获取所述目标模型中第二结构层对应的第二可执行文件，并将所述第二可执行文件的待加载结构体作为所述嵌入式实时操作系统的第二任务进行加载运行，实现所述目标模型的分层加载更新。

其中，第一结构层是指目标模型中对应的一部分结构层，第二结构层是指目标模型中对应的另一部分结构层，例如，目标模型可以包括1-10个结构层，第一结构层可以是1-5的结构层，第二结构层可以是6-10的结构层，当然，此处仅提到第一结构层、第二结构层仅是一种示例性说明，本领域技术人员可以容易想到的将目标模型分为第一结构层、第二结构层、第三结构层……本示例实施例对此不做特殊限定。

需要说明的是，“第一结构层”、“第二结构层”中的“第一”“第二”仅适用于区别目标模型中划分得到的不同部分的结构层，并没有任何特殊意义上的意义，不应对本示例实施例造成任何特殊限定。

第一任务是指基于第一结构层对应的第一可执行文件构建的待运行任务，第二任务是指基于第二结构层对应的第二可执行文件构建的待运行任务，分别将第一任务和第二任务作为一个完整的加载任务在嵌入式实时操作系统中进行加载运行，在第一任务加载运行完成时，进行卸载，并加载运行第二任务，实现占用较大内存空间的目标模型在内存空间较小的SensorHub的加载运行。

本领域技术人员容易理解的是，可以在云端服务器将训练完成的目标模型划分为多个部分的结构层，并分别编译为可执行文件下发到SensorHub上进行加载更新，当然，也可以将训练完成的完整目标模型下达到应用处理器AP侧的文件系统，每次可以按照结构层的顺序将完整目标模型的部分结构层传递到SensorHub上运行，直到目标模型的所有结构层均在SensorHub上加载运行完成。

图9示意性示出本公开示例性实施例中一种实现目标模型分层加载的结构示意图。

参考图9所示，存储在应用处理器910的目标文件系统中的目标模型930可以至少包括结构层1、结构层2、结构层3······目标模型920此时以可执行文件的形式存储。在加载至SensorHub运行时，可以将目标模型920中的每个结构层作为一个待运行任务分别进行加载计算，例如，可以将结构层1作为第一任务940，在加载计算完毕后，卸载第一任务940，然后继续将结构层2作为第二任务950，并在加载计算完毕后，卸载第二任务950，同样的，继续将结构层3作为第三任务960，并在加载计算完毕后，卸载第三任务960······以此类推，直到将目标模型的所有结构层均在SensorHub上加载运行完成，实现目标模型在SensorHub上的加载更新。

图10示意性示出本公开示例性实施例中一种实现目标模型加载更新的系统示意图。

参考图10所示，目标模型加载更新系统可以至少包括云端服务器1010和终端设备1020，首先在云端服务器1010上训练AI模型1030，并将训练完成的AI模型1030通过编译工具转换为可执行文件(Module.ELF)1040，并通过云端服务器1010将可执行文件1040下发存储到终端设备1020的应用处理器1021侧的文件系统中。在SensorHub平台1022需要运行该AI模型1030时，通过微控制单元10221确定将AI模型1030加载到DRAM存储器10222上以动态任务的方式加载，或者将AI模型1030加载到SRAM存储器10222上以静态任务的方式加载，SensorHub平台1022使用嵌入式实时操作系统内核10224实现，并且由于嵌入式实时操作系统内核10224不支持动态加载的特性，因此本示例实施例通过目标模型加载更新方法实现在嵌入式实时操作系统内核10224上进行AI模型1030的动态加载更新。

综上所述，本示例性实施方式中，获取目标模型对应的可执行文件并存储到应用处理器侧的文件系统，在检测到SensorHub请求运行目标模型时，将可执行文件解析到第一内存中生成待加载结构体，并将待加载结构体以共享内存的方式传递给SensorHub的第二内存，以使嵌入式实时操作系统将第二内存中的待加载结构体作为待运行任务进行启动运行，实现目标模型的动态加载更新。一方面，先将目标模型对应的可执行文件存储到文件系统，并以共享内存的方式传递给SensorHub的嵌入式实时操作系统，使嵌入式实时操作系统将可执行文件对应的待加载结构体作为待运行任务进行启动运行，实现了目标模型在SensorHub上的动态加载更新，并不需要将目标模型对应的代码与内核烧录成镜像文件发给SensorHub运行，有效提升目标模型的加载更新效率；另一方面，将目标模型对应可执行文件存储到第一内存中，在嵌入式实时操作系统请求运行时，将可执行文件传递给嵌入式实时操作系统中的第二内存，通过这样的动态加载特性降低嵌入式实时操作系统的内存占用，减少嵌入式实时操作系统的内存压力，进一步保证目标模型的加载更新效率。

需要注意的是，上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

进一步的，参考图11所示，本示例的实施方式中还提供一种目标模型加载更新装置1100，可以包括可执行文件获取模块1110、结构体生成模块1120和模型加载更新模块1130。其中：

可执行文件获取模块1110用于获取目标模型对应的可执行文件；

结构体生成模块1120用于若检测到所述嵌入式实时操作系统请求运行所述目标模型，则将所述可执行文件解析到第一内存中生成待加载结构体；

模型加载更新模块1130用于将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存，以使所述嵌入式实时操作系统将所述第二内存中的所述待加载结构体作为待运行任务进行启动运行，实现所述目标模型的动态加载更新。

在一示例性实施例中，模型加载更新模块1130可以用于：

从所述待加载结构体中获取所述可执行文件的文件头，并根据所述文件头确定所述待加载结构体的入口函数相对于代码段的偏移量；

基于所述代码段的加载地址以及所述偏移量确定所述待加载结构体的绝对入口地址；

在创建待运行任务时，将所述待运行任务的入口地址设置为所述待加载结构体的绝对入口地址，实现将所述待加载结构体作为所述待运行任务进行启动运行。

在一示例性实施例中，模型加载更新模块1130还可以用于：

从所述待加载结构体中获取所述可执行文件的文件头，并根据所述文件头确定代码段、只读数据段、数据段以及未初始数据段的占用空间和偏移位置；

基于所述占用空间计算加载所述待加载结构体所需的总占用空间；

根据所述总占用空间分配所述待加载结构体在所述第二内存中的首地址，并按照所述首地址以及所述偏移位置计算实际内存地址；

按照所述实际内存地址将所述代码段、所述只读数据段、所述数据段以及所述未初始数据段复制到所述第二内存中，实现将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存

在一示例性实施例中，目标模型加载更新装置1100还包括动静态加载模块，该动静态加载模块可以用于：

通过动态任务创建的方式加载所述待加载结构体，所述动态任务创建的方式是指所述总占用空间的内存从堆中进行分配；或者

通过静态任务创建的方式加载所述待加载结构体，所述静态任务创建的方式是指所述总占用空间的内存从静态区中进行分配。

在一示例性实施例中，目标模型加载更新装置1100还包括符号重定位模块，该符号重定位模块可以用于：

根据所述文件头确定所述代码段、所述只读数据段、所述数据段以及所述未初始数据段对应的重定位表；

通过所述重定位表对所述代码段、所述只读数据段、所述数据段以及所述未初始数据段中的符号进行重定位。

在一示例性实施例中，目标模型加载更新装置1100还包括目标模型卸载单元，该目标模型卸载单元可以用于：

将所述待运行任务从所述嵌入式实时操作系统对应的待运行任务队列和事件队列中进行删除，以实现将所述待运行任务插入到待删除任务队列中；以及

通过目标进程对所述待删除任务队列中的所述待运行任务进行地址空间释放，实现所述目标模型的卸载。

在一示例性实施例中，目标模型加载更新装置1100还可以包括目标模型分层加载模块，该目标模型分层加载模块可以用于：

从云端服务器获取所述目标模型中第一结构层对应的第一可执行文件，并将所述第一可执行文件的待加载结构体作为所述嵌入式实时操作系统的第一任务进行加载运行；

在所述第一任务运行完成后，卸载所述第一结构层；以及

从云端服务器获取所述目标模型中第二结构层对应的第二可执行文件，并将所述第二可执行文件的待加载结构体作为所述嵌入式实时操作系统的第二任务进行加载运行，实现所述目标模型的分层加载更新。

在一示例性实施例中，可执行文件是通过云端服务器对训练完成的目标模型进行编译处理得到的，可执行文件获取模块1110可以用于：

向所述云端服务器发送目标模型的加载更新请求，以获取所述云端服务器响应所述加载更新请求并返回的可执行文件；以及

将所述可执行文件存储到目标文件系统中。

上述装置中各模块的具体细节在方法部分实施方式中已经详细说明，未披露的细节内容可以参见方法部分的实施方式内容，因而不再赘述。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

本公开的示例性实施方式还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤，例如可以执行图3至图10中任意一个或多个步骤。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

此外，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限。

Claims (10)

1.一种目标模型加载更新方法，其特征在于，应用于集成有低功耗计算平台SensorHub的终端设备，所述低功耗计算平台SensorHub包括轻量级的嵌入式实时操作系统，所述方法包括：

获取目标模型对应的可执行文件；

若检测到所述嵌入式实时操作系统请求运行所述目标模型，则将所述可执行文件解析到第一内存中生成待加载结构体；

将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存，以使所述嵌入式实时操作系统将所述第二内存中的所述待加载结构体作为待运行任务进行启动运行，实现所述目标模型的动态加载更新。

2.根据权利要求1所述的方法，其特征在于，所述使所述嵌入式实时操作系统将所述第二内存中的所述待加载结构体作为待运行任务进行启动运行，包括：

从所述待加载结构体中获取所述可执行文件的文件头，并根据所述文件头确定所述待加载结构体的入口函数相对于代码段的偏移量；

基于所述代码段的加载地址以及所述偏移量确定所述待加载结构体的绝对入口地址；

在创建待运行任务时，将所述待运行任务的入口地址设置为所述待加载结构体的绝对入口地址，实现将所述待加载结构体作为所述待运行任务进行启动运行。

3.根据权利要求1所述的方法，其特征在于，所述将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存，包括：

从所述待加载结构体中获取所述可执行文件的文件头，并根据所述文件头确定代码段、只读数据段、数据段以及未初始数据段的占用空间和偏移位置；

基于所述占用空间计算加载所述待加载结构体所需的总占用空间；

根据所述总占用空间分配所述待加载结构体在所述第二内存中的首地址，并按照所述首地址以及所述偏移位置计算实际内存地址；

按照所述实际内存地址将所述代码段、所述只读数据段、所述数据段以及所述未初始数据段复制到所述第二内存中，实现将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

通过动态任务创建的方式加载所述待加载结构体，所述动态任务创建的方式是指所述总占用空间的内存从堆中进行分配；或者

通过静态任务创建的方式加载所述待加载结构体，所述静态任务创建的方式是指所述总占用空间的内存从静态区中进行分配。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

将所述待运行任务从所述嵌入式实时操作系统对应的待运行任务队列和事件队列中进行删除，以实现将所述待运行任务插入到待删除任务队列中；以及

通过目标进程对所述待删除任务队列中的所述待运行任务进行地址空间释放，实现所述目标模型的卸载。

6.根据权利要求1至5任意一项所述的方法，其特征在于，所述目标模型包括多个结构层，所述方法还包括：

从云端服务器获取所述目标模型中第一结构层对应的第一可执行文件，并将所述第一可执行文件的待加载结构体作为所述嵌入式实时操作系统的第一任务进行加载运行；

在所述第一任务运行完成后，卸载所述第一结构层；以及

从云端服务器获取所述目标模型中第二结构层对应的第二可执行文件，并将所述第二可执行文件的待加载结构体作为所述嵌入式实时操作系统的第二任务进行加载运行，实现所述目标模型的分层加载更新。

7.根据权利要求1所述的方法，其特征在于，所述可执行文件是通过云端服务器对训练完成的目标模型进行编译处理得到的；

所述获取目标模型对应的可执行文件，包括：

向所述云端服务器发送目标模型的加载更新请求，以获取所述云端服务器响应所述加载更新请求并返回的可执行文件；以及

将所述可执行文件存储到目标文件系统中。

8.一种目标模型加载更新装置，其特征在于，包括：

可执行文件获取模块，用于获取目标模型对应的可执行文件；

结构体生成模块，用于若检测到所述嵌入式实时操作系统请求运行所述目标模型，则将所述可执行文件解析到第一内存中生成待加载结构体；

模型加载更新模块，用于将所述待加载结构体以共享内存的方式传递给所述嵌入式实时操作系统的第二内存，以使所述嵌入式实时操作系统将所述第二内存中的所述待加载结构体作为待运行任务进行启动运行，实现所述目标模型的动态加载更新。

9.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的方法。

10.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至7任一项所述的方法。

Images