处理单元、软件模块、方法和程序代码

背景技术

应用软件开发人员在不编写他们自己的或自定义的硬件抽象层或垫层的情况下，在到了供应和随后消费特定的硬件微服务之时总是苦苦挣扎。例如，为专用操作而构建的硬件微服务通常需要粘合固件和/或相应的驱动器来揭示硬件微服务，该硬件微服务随后必须被暴露并抽象为API(应用编程接口)。然后可能需要称为API(也称为软件微服务)的中间层，以允许更高级别的软件应用接入/访问硬件微服务。

通过仿真技术和平台，在硬件工程实践中经常存在对硬件微服务建模的概念。例如，来自其他系统的是已知的仿真平台，这些仿真平台能够对复杂硬件操作执行系统仿真。这些平台是模拟电子硬件操作的全系统仿真器框架表示。然而，最好部署这些平台来支持硬件仿真。存在可以提供硬件编程特征可视化的其他零星示例工具，但不是硬件微服务抽象的良好解决方案。例如，可以利用编程语言本身，它不是工具的并且可以为软件库抽象仿真提供可视化。

这两种方法都缺乏硬件抽象的可视化能力。此外，它们缺乏即时反馈，并且缺乏即时模仿，并且容易遭受人为影响的编程错误，因为它不是硬件抽象或建模工具。因此，用户(例如，应用开发人员)需要被给予他可以立即仿真或快速配置软件的不同概念表示的机会或抽象解决方案。

例如，如果软件开发人员想要开发安全敏感的应用，并且可能会希望将硬件微服务用作硬件信任根，并且因此将必须在许多固件与软件库之间仔细导航，以便接入硬件微服务。因此，可能会需要增加硬件微服务的可访问性/资格。

附图说明

装置和/或方法的一些示例将在下文仅作为示例并参考所附附图来进行描述，在附图中

图1示出处理单元的示例的框图；

图2示出软件模块的示例的框图；

图3a和图3b示出通用IDE的示例；

图4a-图4c更详细地示出图3的IDE；以及

图5示出概念IDE元建模的示例；

图6a-图6c更详细地示出图5的概念IDE元建模；

图7示出用于软件模块的方法的示例；

图8示出用于处理单元的方法的示例；以及

图9示出计算设备。

具体实施方式

现在将参考所附附图更全面地描述各示例，在这些附图中图示出一些示例。在附图中，出于清楚性，线、层和/或区域的厚度可被夸大。

相应地，尽管进一步的示例能够具有各种修改和替代形式，但其一些特定示例在附图中示出并随后将详细描述。然而，此种详细描述并非将进一步的示例限于所描述的特定形式。进一步的示例可涵盖落入本公开范围内的所有修改、等效方案和替代方案。贯穿附图的描述，同样的数字指代同样或类似的要素，这可相较于彼此相同地或以修改形式被实现同时提供相同或类似的功能。

一些实施例可具有针对其他实施例所描述的特征中的一些或全部，或完全不具有这些特征。“第一”、“第二”、“第三”等等描述常见的对象，并且指示被引用的类似对象的不同实例。此类形容词并不暗示如此描述的元素项必须在时间上或空间上、在排名方面或以任何其他方式按照给定顺序。“连接的”可指示元件彼此处于直接的物理或电接触，并且耦合的摂可指示元件彼此协作或交互，但这些元件可以或可以不处于直接的物理或电接触。

如本文中所使用，术语“操作”、“执行”或“运行”在其涉及与系统、设备、平台或资源有关的软件或固件时可互换地使用，并且可以指代存储在可由系统、设备、平台或资源访问的一种或多种计算机可读存储介质中的软件或固件，即使该软件或固件中所包含的指令并非正在被系统、设备、平台或资源活跃地执行。

说明书可使用短语“在一实施例中”、“在实施例中”、“在一些实施例中”和/或“在各实施例中”，这些短语中的每一个都可指代相同或不同实施例中的一个或多个。此外，如相对于本公开的实施例所使用的术语“包含”、“包括”、“具有”等是同义的。

将理解，当要素被称为“连接到”或“耦合到”另一要素时，这些要素可直接连接或耦合或经由一个或多个中介要素。如果两个要素A和B使用“或”来组合，则要理解这公开了所有可能的组合，即，仅A、仅B、以及A和B。针对同一组合的替代措辞为“组A和B中的至少一者”。这同样适用于多于2个要素的组合。

本文中出于描述特定示例的目的所使用的属于并非旨在限制进一步的示例。不论何时单数形式“一(a/an)”和“该(the)”被使用并且使用仅单个元素既不显式也不隐式地被限定为强制性的，进一步的示例也可使用复数要素来实现相同的功能。同样，当功能随后被描述为使用多个要素实现时，进一步的示例可使用单个要素或处理实体来实现相同的功能。还将理解，当使用术语“包括(comprise和/或comprising)”、“包含(include和/或including)”时，其指定所陈述的特征、整数、步骤、操作、过程、动作、元件和/或组件的存在，但不排除除此之外的一个或多个其他特征、整数、步骤、操作、过程、动作、元件、组件和/或它们的组的存在。

除非以其他方式限定，否则所有术语(包括技术和科学术语)在本文中以示例所属领域的普通含义来使用。

图1示出处理单元30的示例的框图。第一处理单元30包括被配置成用于与至少一个硬件组件进行通信的一个或多个接口32以及被配置成用于控制该一个或多个接口32的处理电路系统34。此外，处理电路系统34被配置成用于确定至少一个硬件组件的多个硬件微服务的超集。因此，至少一个硬件设备的多个硬件微服务可以被概括在超集中。

例如，超集可以包括至少一个硬件组件的多个硬件微服务的集合(或目录)。以此种方式，超集可以用于提供关于多个硬件微服务的信息，例如，用于浏览多个硬件微服务。例如，多个硬件微服务可以包括不同的硬件微服务(例如，可由不同的集成开发环境(integrated development environment，IDE)访问)。不同的硬件微服务可以包括不同的配置层或不同的组合库集合，使得不同的硬件微型服务可以由从其他系统已知的不同IDE访问。因此，可以通过利用超集(例如，通过将超集合并到软件微服务(参见图2)的抽象(这里称为硬件API)中)来提供用于使用多个硬件微服务的唯一接口。例如，多个硬件微服务可以由硬件API访问，以例如探索多个硬件微服务来选择期望的硬件微服务。

此外，例如，通过使用硬件API，可以向用户提供即时反馈。超集可用于生成软件微服务的抽象(硬件API)，从而提供低等待时间和易用性，这可以使得用户能够对多个硬件微服务，特别是具有容易的访问和/或低进入成本的硬件微服务进行探索(例如，通过探索过程，参见例如图4a、图6a)、建模(例如，通过建模过程，参见例如图4b、图6b)和部署(例如，通过部署过程，参见例如图4c、图6c)。因此，可以提供概念软件微服务设计仿真方法，而不需要构建到从其他系统已知的平台中。硬件API可以包括新的软件到硬件抽象建模平台，该平台可以用于/执行目录软件微服务(探索)、视觉原型表示(建模)和概念供应(部署)。

例如，硬件API可以向用户(例如，应用软件开发人员(社区))提供通用IDE建模表达，从而增强用户体验，该用户体验超越编码，并包含探索、建模和部署的主要混合。以此种方式，硬件API可以提供除编码之外的软件微服务的可视化建模装置。

为了生成硬件API，处理单元30被配置成用于确定超集。可以通过确定至少一个硬件组件的多个硬件微服务(例如，所有硬件微服务)来执行对超集的确定。可以在超集中总结所确定的多个硬件微服务，使得超集包括至少一个硬件组件的多个硬件微服务(例如，所有硬件微服务)。例如，可以使用本地持久存储装置，该本地持久存储装置被附接至同步引擎来维护硬件特征抽象目录的最新副本，以及与云中的联合注册表同步后的相应硬件API执行配方。同步引擎可以是后台进程，用于周期性地检查抽象目录和执行配方中的更新，并随后在自上次更新以来发生变化的情况下更新本地持久存储装置。本地持久存储装置还可以捕获最终的硬件微服务选择。图4中更详细地描述了本地持久存储装置和同步引擎。

在示例中，处理电路系统34可以进一步被配置成用于生成包括多个硬件微服务的列表。例如，该列表可以是多个硬件微服务的目录。可以在列表中对多个硬件微服务进行排序，以提供对期望的硬件微服务的轻松访问。例如，可以根据名称、所属硬件组件、功能/特征等对多个硬件微服务进行排序。可选地，列表可以包括多个子列表，使得每个子列表可以包括属于特定功能/特征(例如，用于随机数生成)的硬件微服务。通过生成列表/子列表，可以简化多个硬件微服务的后处理，例如，用户可以接收期望的子列表。

在示例中，处理电路系统34可以进一步被配置成用于观察至少一个硬件组件的状态(例如，特性、属性等)，并且如果该至少一个硬件组件的状态已经改变，则重新确定该至少一个硬件组件的硬件微服务。例如，硬件微服务可能已经被更新、禁用、启用等，因此多个硬件微服务可能已经改变，例如，多个硬件微服务中的硬件微服务的特征/功能可能已经改变。因此，通过观察至少一个硬件组件的状态，可以使多个硬件微服务保持真实。

处理单元可以是计算机、处理器、控制单元、(现场)可编程逻辑阵列((field)programmable logic array，(F)PLA)、(现场)可编程门阵列((field)programmable gatearray，(F)PGA)、图形处理器单元(graphics processor unit，GPU)、专用集成电路(application-specific integrated circuit，ASIC)、集成电路(integrated circuit，IC)或片上系统(system-on-a-chip，SoC)系统。硬件组件可以是计算机、处理器、控制单元、(现场)可编程逻辑阵列((F)PLA)、(现场)可编程门阵列((F)PGA)、图形处理器单元(GPU)、专用集成电路(ASIC)、集成电路(IC)或片上系统(SoC)系统。

如图1中所示，在处理单元30处，相应的一个或多个接口32耦合至相应的处理电路系统34。在示例中，处理电路系统34可使用一个或多个处理单元、一个或多个处理设备、用于处理的任何装置(诸如，处理器、计算机、或者可与相应适配的软件一起操作的可编程硬件组件)来实现。类似地，处理电路系统34的所描述的功能还可采用软件来实现，该软件随后在一个或多个可编程硬件组件上执行。此类硬件组件可包括通用处理器、数字信号处理器(Digital Signal Processor，DSP)、微控制器等。处理电路系统34能够控制一个或多个接口32，使得在该一个或多个接口32上发生的任何数据传输和/或其中可能涉及该一个或多个接口32的任何交互可由处理电路系统34控制。

在实施例中，处理单元30可包括存储器和至少一个处理电路系统34，该至少一个处理电路系统34可操作地耦合至存储器并被配置成用于执行下文提及的方法。

在示例中，一个或多个接口32可对应于用于获取、接收、发射或提供模拟或数字信号或信息的任何装置，例如，允许提供或者获取信号或信息的任何连接器、接触件、引脚、寄存器、输入端口、输出端口、导体、通道等。该一个或多个接口32可以是无线的或有线的，并且其可被配置成用于与其他内部或外部组件对信息进行通信(例如，发射或接收信号)。一个或多个接口32可包括用于启用交通工具之间的通信的其他组件。此类组件可包括收发器(发射器和/或接收器)组件，诸如一个或多个低噪声放大器(Low-Noise Amplifier，LNA)、一个或多个功率放大器(Power-Amplifier，PA)、一个或多个收发双工器、一个或多个同向双工器、一个或多个滤波器或滤波器电路、一个或多个转换器、一个或多个混频器、相应适配的射频组件等。

与下文描述的细节相结合提及更多的细节和方面。图1中示出的示例可包括与结合所提出的概念或者下文(例如，图2-图9)描述的一个或多个示例提及的一个或多个方面相对应的一个或多个任选的附加特征。

图2示出软件模块50的示例的框图。软件模块50包括一个或多个接口52和处理电路系统54，该一个或多个接口52被配置成用于与处理单元(例如，参考图1所述的处理单元)进行通信，该处理电路系统54被配置成用于控制一个或多个接口72。此外，处理电路系统54被配置成用于接收关于至少一个硬件组件的多个硬件微服务的超集(例如，由参考图1所述的处理单元生成的超集)的信息。此外，处理电路系统54被配置成用于提供关于超集的信息以及基于用户输入生成子集。因此，可使得用户能够通过使用硬件API来选择期望的硬件微服务。

通过提供信息，用户可以被赋予预览他可能需要/可以访问哪个硬件微服务来构建/包括到模型中的能力。因此，可以向用户提供对底层多个硬件微服务的完全和完整理解，从而自己构建相关抽象层。此外，可以省略对重新编译源代码层和拼合所有层的需要，可以提供对软件层或库的容易的访问，可以省略对解决软件编译依赖性和应对编译错误的需要，或者可以执行硬件微服务的选择，而不需要对(多个)编码语言(特别是低级语言)的了解。

通过提供关于超集的信息，可以提供建模、设计和/或供应多个硬件微服务的概念。例如，可以通过用户输入(例如，(动作)用户姿势)来执行建模。(例如，在膝上型电脑、平板电脑、监测器等的显示器上)对超集的描绘可以使得用户能够选择多个硬件微服务中的所期望的硬件微服务。因此，用户输入可以是对期望的硬件微服务的选择(例如，通过键盘、触摸板、触摸屏等接收)，该选择可以例如在探索过程中被接收。

例如，可以经由移动的动作姿势(诸如拖放、翻转、挥刷、摆动、滑动、抓取等)来提供用户输入。通过使用/解释用户输入，软件模块50可以实例化软件对象，特别是在IDE或编程工具的不同软件工作空间之间。此外，软件模块50可以能够将用户输入(例如，动作姿势(例如，拖放))转换/变换为可编译为可执行二进制件的代码库。

在示例中，提供关于超集的信息并生成子集可以被探索过程所包括(或可由探索过程执行)。探索过程可以是可以由软件模块50执行的多个过程中的一个过程。多个过程可以定义(例如，通过使用硬件API)将多个硬件微服务抽象为软件微服务的基础或基本。硬件API可以基于低代码平台原则的原则，这可以强调丰富的用户体验。此外，可以减少设计、供应和/或消费多个硬件微服务的编码努力。

多个过程(及其底层硬件API设计和属性)可以定义用于设计多个硬件微服务的抽象和/或用于供应软件微服务的改进的方式。例如，用户可以使用探索过程来浏览、研读和/或探索多个硬件微服务的超集(例如，(主)目录(例如，主目录可以包括如参考图1所述的由处理单元生成的列表/子列表))和/或其超集的(一个或多个)底层硬件API执行配方。

在示例中，处理电路系统54可以进一步被配置成用于检查所接收的信息的更新是否可用，并且如果所接收到的信息已经更新，则接收关于多个硬件微服务的经更新的信息。以此种方式，软件模块50可以确保例如用于探索过程的所使用的超集是真实的。例如，可以保持多个硬件微服务的当前性。

在示例中，处理电路系统54可以进一步被配置成用于同步多个硬件微服务以将它们提供给外部处理单元。以此种方式，超集可以在处理单元之间共享。例如，外部处理单元可以是远程终端，该远程终端访问主机终端(例如，处理单元)的多个硬件微服务。

在示例中，如果选择了多个硬件微服务中的多个硬件微服务，则处理电路系统54可以进一步被配置成用于生成多个硬件微服务的查询计划。以此种方式，可以生成处理多个所期望的硬件微服务的顺序。例如，用户可能已经在探索过程中选择了多个期望的硬件微服务，并且可以按照必要的顺序来对所选择的多个硬件微服务进行排序。例如，第一选择的硬件微服务可以生成输出参数，该输出参数可能需要作为用于第二选择的硬件微服务的输入参数。因此，在查询计划中，第一选择的硬件微服务会被定位，使得它在第二选择的硬件微服务之前被执行/处理。

例如，在探索过程中，对硬件微服务的选择可能取决于硬件微服务所需的输入参数。例如，仅当第一硬件微服务由用户输入选择时，才可以启用对第二硬件微服务的选择，该选择需要第一硬件微服务的输出作为输入参数。以此种方式，探索过程/查询计划确保可以处理/执行多个硬件微服务中的所有选择的硬件微服务，这可以增加用户体验。

例如，对超集的描绘可以是基于低代码平台原则的最终设计实现的视觉原型或建模，其中用户(例如，应用开发人员)可以使用用户输入(例如，动作姿势(例如，拖放))从一开始就构建最终用户体验。

在示例中，处理电路系统54可以进一步被配置成用于将多个硬件微服务的查询计划呈递为层级树，例如，查询结果。例如，层级树可以包括处理所选择的硬件微服务的顺序。例如，层级树可以反映多个硬件微服务的执行顺序，例如，必须首先执行为第二硬件微服务提供输入的第一硬件微服务。以此种方式，可以向用户通知所需的硬件微服务，用户可能必须选择该硬件微服务来实现所期望的硬件微服务的执行，例如，用户可能必须在他可选择第二硬件微服务之前选择第一硬件微服务。

在示例中，处理电路系统54可以进一步被配置成用于生成多个硬件微服务的序列流。例如，序列流可以包括通过层级树获得的顺序。例如，序列流可以包括代码库，该代码库可以被编译成可执行二进制件和/或底层硬件API执行配方，用于执行多个硬件微服务中的所选择的多个硬件微服务。以此种方式，序列流可以提供访问/执行多个硬件微服务的特征/功能所需的信息。

在示例中，生成序列流可以被建模过程所包括(或由建模过程执行)。例如，建模过程可以属于多个过程，这多个过程可以定义用于(例如，通过使用硬件API)将多个硬件微服务抽象为软件微服务的基础或基本。

在示例中，处理电路系统54可以进一步被配置成用于检查序列流中的多个硬件微服务中的第一硬件微服务的输出参数与序列流中的多个硬件微服务中的第二硬件微服务的输入参数是否匹配。以此种方式，可以确保第二硬件微服务可以被执行，例如，如果需要由第一硬件微服务提供的输出参数作为第二硬件微服务的输入参数。例如，在建模过程(和探索过程)期间，用户输入可以导致对第二硬件微服务的选择，而无需选择第一硬件微服务。因此，软件模块50可以自动地选择第一硬件微服务，以确保用于第二硬件微服务的所有所需输入参数是可访问的。可选地或替代地，如果软件模块50识别出第一硬件微服务的输出参数与第二硬件微服务的输入参数不匹配(或缺失)，则软件模块可以再次提供关于超集的信息，例如，以在进行新的探索过程的同时接收新的用户输入，以(例如，基于新的用户输入)生成新的子集。以此种方式，可以确保用户已经选择了生成/执行序列流所需的所有硬件微服务。

在示例中，处理电路系统54可以进一步被配置成用于从序列流生成不可知代码。以此种方式，从其他系统已知的不同IDE可以通过使用不可知代码来处理/执行序列流。因此，可以向不同的IDE提供对多个硬件微服务的通用、唯一的访问。例如，不可知代码可以包括用于执行所选择的多个硬件微服务的特定执行配方，这多个硬件微服务可以在探索过程中由用户输入选择和/或可以在建模过程中被证明一致。

在示例中，处理电路系统54可以进一步被配置成用于将不可知代码传送至外部处理单元，以使得外部处理能够使用多个硬件微服务。以此种方式，不可知代码可以在处理单元之间共享。例如，用户可以(使用探索过程和/或建模过程)生成不可知代码，并且可能希望与(例如，在不同的位置处的)其他用户共享该不可知代码。因此，不可知代码可用于存储/共享模型，例如，该模型包括对多个硬件微服务中的硬件微服务的选择和底层硬件API执行配方。以此种方式，可以改善不同用户之间的协作，因为不可知代码可以为数据交换建立基础，特别是独立于所使用的软件(例如，IDE)的数据交换。因此，从其他系统已知的每个IDE都可以能够接受不可知代码产生的输入。

在示例中，处理电路系统54可以进一步被配置成用于将不可知代码解码为应用代码。应用代码(类型)可以是用于从其他系统已知的IDE的代码(类型)，例如，Java、.Net等。因此，存储在不可知代码中的信息可以由每个IDE访问，例如，可能不需要通用IDE。例如，用户可以定义用于解码不可知代码的期望的应用代码类型。

在示例中，对不可知代码进行解码可以被部署过程所包括(或由部署过程执行)。例如，部署过程可以属于多个过程，这多个过程可以定义用于(例如，通过使用硬件API)将多个硬件微服务抽象为软件微服务的基础或基本。例如，部署过程可以将序列流(例如，最终模型(例如，视觉模型))转换为应用代码，该应用代码可以用作最终部署格式的基础。此外，部署过程可以包括保持模型的开发环境不可知表示。

例如，多个过程(探索过程、建模过程、部署过程)可以使用户能够浏览超集(例如，多个硬件微服务的目录)，以选择所期望的硬件微服务，可以提供软件结构建模能力，或者可以提供源代码(例如，不可知代码)的自动制定。

可以将多个过程视为通用IDE，该通用IDE被配置成用于访问硬件组件的多个硬件微服务，并向用户提供本领域已知的IDE的所有特征。通过使用通用IDE，可以使得用户能够产生易于制作的软件源代码(不可知代码)，而无需写入源代码，这可以增加用户体验。例如，用户可以在探索过程中使用拖动对象集合(诸如软件库)作为可视化艺术。此外，用户可以基于软件微服务池(通过使用硬件API)执行建模，这可以通过通用IDE轻松完成。通用IDE可以能够产生如关于部署过程所述的可执行二进制件和/或底层硬件API执行配方。下文将(例如，参考图3和图4)更详细地描述通用IDE。

如图2中所示，在软件模块50处，相应的一个或多个接口52耦合至相应的处理电路系统54。在示例中，处理电路系统54可使用一个或多个处理单元、一个或多个处理设备、用于处理的任何装置(诸如，处理器、计算机、或者可与相应适配的软件一起操作的可编程硬件组件)来实现。类似地，所描述的处理电路系统54的功能也可采用软件来实现，该软件随后在一个或多个可编程硬件组件上执行。此类硬件组件可包括通用处理器、数字信号处理器(DSP)、微控制器等。处理电路系统54能够控制一个或多个接口52，使得在该一个或多个接口52上发生的任何数据传输和/或其中可能涉及该一个或多个接口52的任何交互可由处理电路系统54控制。

在实施例中，软件模块50可包括存储器和至少一个处理电路系统54，该至少一个处理电路系统54可操作地耦合至存储器并被配置成用于执行下文提及的方法。

在示例中，一个或多个接口52可对应于任何用于获取、接收、发射或提供模拟或数字信号或信息的装置，例如，允许提供或者获取信号或信息的任何连接器、接触件、引脚、寄存器、输入端口、输出端口、导体、通道等。该一个或多个接口52可以是无线的或有线的，并且其可被配置成用于与其他内部或外部组件对信息进行通信(例如，发射或接收信号)。一个或多个接口52可包括用于启用交通工具之间的通信的其他组件。此类组件可包括收发器(发射器和/或接收器)组件，诸如一个或多个低噪声放大器(LNA)、一个或多个功率放大器(PA)、一个或多个收发双工器、一个或多个同向双工器、一个或多个滤波器或滤波器电路、一个或多个转换器、一个或多个混频器、相应适配的射频组件等。

与上文和/或下文描述的示例相结合提及更多的细节和方面。图2中示出的示例可包括与结合提出的概念或者上文(例如，图1)和/或下文(例如，图3-图9)描述的一个或多个示例提及的一个或多个方面相对应的一个或多个任选的附加特征。

图3a和图3b示出通用IDE 300的示例。如图3a中可见，通用IDE 300包括多个过程310、320、330。IDE 300包括用于对硬件组件的多个硬件微服务进行抽象的普遍存在的概念，例如，通过使用参考图1所述的超集，该超集可以由参考图2所述的软件模块使用。如图3a中可见，通用IDE 300可以包括三个过程，这三个过程可以从左到右执行：探索过程310(也称为探索)、建模过程320(也称为建模)和部署过程330(也称为部署)。因此，通用IDE300可以区别地识别用于以可扩展方式(例如，基于硬件API)来制造(探索)、组合、设计实现(建模)和/或广泛供应(部署)硬件/软件微服务的过程或方法。

如图3b中可见，通用IDE 300可以是从其他系统已知的IDE的替代，这些IDE可能无法访问硬件组件的多个硬件微服务中的每个硬件微服务。因此，通用IDE 300可以改善用户体验。例如，通用IDE 300可以为用户(例如，应用开发人员)引入创新的、独特的和开创性的方式，以便以无缝和/或可扩展的方式为终端用户应用开发空间设计、开发和/或供应硬件组件的多个硬件微服务。可以使用如美国专利申请第17/485,351([1])号中所述的用于将微服务暴露于软件层374的方法和/或装置的底层概念。美国专利申请第17/485,351号的主题在此处通过引用明确并入本申请。

与上文和/或下文描述的示例相结合提及更多的细节和方面。图3中示出的示例可包括与结合提出的概念或者上文(例如，图1-图2)和/或下文(例如，图4-图9)描述的一个或多个示例提及的一个或多个方面相对应的一个或多个任选的附加特征。

图4a-图4c更详细地示出图3的IDE。图4a示出探索310的体系结构的示例，该探索310可以包括三个子组件312、314、316，即调色板渲染引擎312(palette renderingengine，PRE)、微服务目录构建器314(microservices catalog builder，μSCB)和本地化持久存储装置316(localized persistent storage，LPS(n))。

每个子组件312、314、316的功能可以如下所述：

·PRE 312可以处理来自μSCB 314的原始机器可读输出并将其转换/呈递为层级树表示，以简化用户的选择。这可以允许用户(例如，应用开发人员)浏览、选择或最终决定(最终)硬件微服务。

·μSCB 314可以作为查询引擎(例如，后台过程)触发，该查询引擎可以从PRE 312接收查询请求，并随后构建硬件微服务目录查询计划，并将结果(例如，查询计划的输出)从LPS1 316返回至PRE 312作为输入。

·LPS1 316可以附接至同步引擎(synchronization engine，SE)，以保持硬件微服务抽象目录(例如，硬件API)的最新副本及其相应的硬件API执行配方，例如，与云中的联合注册表进行后同步。SE(例如，基于本地存储云的联合(毫微微蜂窝(femtocell)应用编程接口)注册表)可以是后台进程，用于周期性地检查硬件微服务抽象目录中的更新(例如，如参考图2所述，用于所接收的信息的更新)和执行配方，并随后在自上次更新以来发生变化的情况下更新LPS1 316。LPS1 316还可以捕获最终的硬件微服务选择。

示例性工作流可以如下所示。当触发探索310时，可以例如通过使用探索调色板将关于超集的信息提供给用户，例如，应用开发人员。PRE 312可以实例化并触发μSCB 314，以验证硬件微服务抽象目录的最新版本是否存在。如果MSCB 314可以检测到硬件微服务抽象目录的最新版本不存在(例如，不存在硬件微服务的版本)，则可以执行进一步的措施，例如，可以通过连接到LSP1 316来加载最新的硬件微服务目录。在硬件微服务抽象目录过期或被否决的情况下，μSCB 314可以与LPS1 316连接以发起新的下载来同步最新的硬件微服务抽象目录(注册表)PRE 312然后可以以可扩展或折叠的层级树的格式呈递硬件微服务抽象目录，使得用户(例如，开发人员)可具有选择(和构建)超集的硬件微服务集合的选项，以在画布(例如，显示器上的用户友好表示)中生成表示为类别类型对象的子集。

图4b示出建模320的体系结构的示例，该建模320可以包括两个子组件322、324，即建模画布引擎322(modelling canvas engine，MCE)和元模型构造器324(meta modelconstructor，MMC)。

每个子组件322、324的功能可被描述为如下：

·MCE 322可以从LPS1 316取回最终的硬件微服务集合，并且可以在建模画布(例如，显示器上的用户友好表示)上呈递或绘制子集。因此，它可以捕获并记录用户在设置关系、所选择的库的编排或执行流程以及具有可选的嵌入式脚本和/或代码的最终执行配方方面的(一个或多个)决定。

·MMC 324可以是解释引擎的形式，解释引擎将来自存储在LPS2 326中的MCE 322的建模转换为不可知的机器可读表示。MMC 324可以组装MCE 322的软件表示的不可知模型。

·LPS2 326可以是用于永久地(并且安全地)存储可再生和/或非否决的机器可读表示的永久存储介质。

·LPS3 328(另比较图4c)可以是用于最终不可否决(non-repudiable)机器可读平台不可知硬件微服务设计表示(例如，由软件模块生成的不可知代码(例如，参见图2))的永久存储介质。

示例性工作流可以如下所示。当建模320被用户动作激活时，MCE 322可以首先取回从探索310中选择的微服务集合，例如，基于用户输入生成的子集，该子集可以保存在LPS1 316中。此外，MCE 322可以在设计画布上构造或绘制该子集。可以将每个用户输入(例如，要在硬件微服务之间关联或用自定义代码或脚本提取每个硬件微服务的姿势动作)实时转换成机器可读格式并存储在LPS2 326上。当基于用户输入而生成的子集(例如，包括所选择的硬件微服务、所期望的顺序等)可以传递至MMC 324时，可以生成最终模型的永久和不可否决的平台不可知机器可读表示(例如，不可知代码)，并将其存储在LPS3 328中。

图4c示出部署330的体系结构的示例，该部署330可以包括两个子组件332、334，即代码供应引擎332(code provisioning engine，CPE)和应用代码构件器334(applicationcode builder，ACB)。

每个子组件332、334的功能可以如下所述：

·CPE 332可以是该组件的核心功能，并且可以用于读取和/或解码LPS3 328中的最终模型的机器可读表示，并准备缓存，用于(例如，基于用户对应用代码类型(例如，Java、.Net等)的选择)以应用代码的格式创建最终实现。

·ACB 334可以接收用于(例如，基于用户(例如，应用开发人员)选择的代码类型)以应用代码格式生成最终实现的句柄或指令。

示例性工作流可以如下所示。当部署330由用户输入(例如，姿势动作)触发时，CPE332可以摄取并解码最终模型的机器可读表示，并向ACB 334发送组装应用软件应用代码的指令或句柄。然后可以将软件应用代码供应到用户专用IDE编码空间上，以供用户消费该代码。

与上文和/或下文描述的示例相结合提及更多的细节和方面。图4中示出的示例可包括与结合提出的概念或者上文(例如，图1-图3)和/或下文(例如，图5-图9)描述的一个或多个示例提及的一个或多个方面相对应的一个或多个任选的附加特征。

图5示出概念IDE元建模500的示例。概念IDE元建模500以元模型图的形式概述了逻辑设计以及多个过程(探索310、建模320和部署330)的相应序列。此外，图5还描述了每个过程310、320、330的高级属性。

例如，在高级结构图示中，概念化平台(例如，IDE)可以作为根(IDE DX)开始，该根可以包括：探索调色板(探索310)，例如，用于基于由探索调色板提供的用户输入来生成子集，该探索调色板可以提供关于超集的视觉信息；项目画布(建模320)，例如，用于(基于序列流)生成可编译为可执行二进制件和/或底层硬件API执行配方的代码库；以及元代码生成器(部署330)，用于将代码库解码为应用代码，使得特定IDE可以访问/使用所选择的硬件微服务。

与上文和/或下文描述的示例相结合提及更多的细节和方面。图5中示出的示例可包括与结合提出的概念或者上文(例如，图1-图4)和/或下文(例如，图6-图9)描述的一个或多个示例提及的一个或多个方面相对应的一个或多个任选的附加特征。

图6a-图6c更详细地示出图5的概念IDE元建模。图6a示出探索过程310(探索)的示例。探索310可以提供发现、浏览和/或应用对超集所包括的多个硬件微服务中的硬件微服务的选择的能力。探索310可以允许用户(例如，开发人员)例如使用相关联的组件/硬件微服务和/或相应的用户定义的库(例如，通过所提供的关于超集的信息)调查和/或浏览可用的硬件微服务(例如，硬件组件的每个硬件微服务)。可用硬件微服务特征的列表(例如，如参考图1所述的由处理单元生成的列表)可以通过容器352(例如，调色板(Palette)352)提供。调色板352可以是探索能力的强制性概念，并且可以充当用于对可用硬件微服务编目录以供用户选择和/或消费的容器。

例如，用户从调色板352拾取和选择硬件微服务对象(硬件微服务)的动作可以包括(但不限于)两个可执行性质：查看服务和选择服务。硬件微服务对象354可以包括超集的列表、子列表等。关于多个硬件微服务的知识本质上可以是在软件微服务预对准的情况下浏览硬件组件的所有硬件微服务的目录的能力。

图6a进一步将调色板352的关系示出为目录，该目录用于提供可用的硬件微服务，该可用的硬件微服务具有相关联的硬件微服务抽象定义、底层实现和标记为硬件微服务对象354的对象。

图6b示出建模过程320(建模)的示例，尤其是经由概念项目画布或视觉设计者能力进行的可视化建模。该视觉可以供用户(例如，开发人员)用所期望的硬件微服务对应用/模型进行建模，以及将这些组件与外部组件和/或用户定义的库进行互操作，用户定义的库是以从其他系统已知的各种编程语言开发的。以此种方式，开发应用就像将现有组件与硬件组件的硬件微服务编排在一起。

图6b示出概念项目画布(ProjectCanvas)362所需的设计性质。使用项目画布362开发应用的概念通常被称为视觉编程，其中用户使用姿势，诸如来自列表或图6a中所示的调色板352的拖放编程构建块。

项目画布362可以用于基于用户在探索310中发现或选择的内容来呈现软件微服务的模板的目的。项目模型设计(ProjectModelDesign)364可以包含模型的能力，该能力包括(但不限于)创建、更新和/或保存到存储装置(例如，LPS2、LPS3)中。建模320还可以包括允许用户导航和/或更新设计的能力。项目画布362可以是每个用户(诸如开发人员或设计者)的单独实现的抽象，并且不是建模320的强制性定义。例如，项目画布362可以是每个项目实现的唯一的单独工作空间。

项目模型设计364可以是用户(诸如开发人员或设计者)的最终设计版本或输出，来自在项目画布362上应用的工作的工作产品。它可以是开发人员或设计者要在其后续实现中消费的设计的最终副本，例如，它可以是存储在LPS3中的不可知代码。

元模型生成器(MetaModelGenerator)366可以是由用户用于创建设计的不可知元模型定义的强制性组件。这是在建模320期间构建的设计的定义，并准备好进行应用代码生成和实现。源代码可以经由元模型生成器366形成，例如，由元模型生成器366组装。源代码可以是对包含被调用的组件和功能的应用代码的描述。可以经由项目画布362从用户准备的模型自动生成源代码。可以保存源代码，并且可以对在硬件微服务的新探索开始(例如，超集被更新)时刷新源代码。

图6c示出部署过程330(部署)的示例，尤其是源代码供应。例如，可以提供将(软件)源代码(例如，不可知代码)供应至IDE应用编码空间中的能力。源代码可由通用IDE用于构建应用代码。取决于用户的目的，应用代码可以是各种语言的形式的。此外，应用代码可以移植到不同的环境中。例如，应用代码可以是Java、C++、Android、Swift等。

应用代码的构建可以由应用代码构建器(ApplicationCodeBuilder)372来完成，应用代码构建器372可以是通过将源代码的行解释为应用代码中的一系列顺序和并行过程来作为模型的强制性组件。应用代码构建器372可以使用由方法和/或装置提供的信息来将微服务暴露于软件层374，如[1]中所述。

顺序和并行过程可包含对外部组件、硬件微服务和用户定义的库中的功能的调用。例如，可以取回源代码的一部分，因为在建模320期间可以生成元代码的该部分。

与上文和/或下文描述的示例相结合提及更多的细节和方面。图6中示出的示例可包括与结合提出的概念或者上文(例如，图1-图5)和/或下文(例如，图7-图9)描述的一个或多个示例提及的一个或多个方面相对应的一个或多个任选的附加特征。

图7示出用于软件模块的方法700的示例。该方法包括：基于多个硬件组件接收710关于多个硬件微服务的超集的信息，以及选择720多个硬件微服务中的至少一个硬件微服务。例如，该方法可以由参考图2所述的软件模块执行。

在示例中，方法700可以进一步包括生成包括该至少一个硬件微服务的子集。

与上文和/或下文描述的示例相结合提及更多的细节和方面。图7中示出的示例可包括与结合提出的概念或者上文(例如，图1-图6)和/或下文(例如，图8-图9)描述的一个或多个示例提及的一个或多个方面相对应的一个或多个任选的附加特征。

图8示出用于处理单元的方法800的示例。方法800可以包括确定至少一个硬件组件的多个硬件微服务的超集。例如，方法800可以由参考图1所述的处理单元执行。

在示例中，方法800可以进一步包括生成包括多个硬件微服务的列表。

与上文和/或下文描述的示例相结合提及更多的细节和方面。图8中示出的示例可包括与结合提出的概念或者上文(例如，图1-图7)和/或下文(例如，图9)描述的一个或多个示例提及的一个或多个方面相对应的一个或多个任选的附加特征。

图9示出计算设备900。计算设备900容纳板902。板902可包括多个组件，包括但不限于处理器904和至少一个通信芯片906。如图9中所示，处理器904可以包括如上所述(例如，参考图1)的处理单元或如上所述(例如，参照图2)的软件模块。

处理器904物理地以及电气地耦合至板902。在一些示例中，至少一个通信芯片906也物理地以及电气地耦合至板902。在进一步示例中，通信芯片906是处理器904的部分。

取决于其应用，计算设备900可包括可物理地以及电气地耦合至板902或者可以不物理地以及电气地耦合至板902的其他组件。这些其它组件包括但不限于易失性存储器(例如，DRAM)、非易失性存储器(例如，ROM)、闪存存储器、图形处理器、数字信号处理器、密码处理器、芯片组、天线、显示器、触摸屏显示器、触摸屏控制器、电池、音频编解码器、视频编解码器、功率放大器、全球定位系统(global positioning system，GPS)设备、罗盘、加速度计、陀螺仪、扬声器、相机以及大容量存储设备(诸如硬盘驱动器、致密盘(compact disk，CD)、数字多功能盘(digital versatile disk，DVD)等等)。通信芯片906实现无线通信以用于去往计算设备900和来自计算设备900的数据传输。术语“无线”和其衍生词可用于描述可通过使用经调制的电磁辐射来使数据传递通过非固态介质的电路、设备、系统、方法、技术、通信信道等。该术语不暗示相关联的设备不包含任何线，但是在一些示例中，相关联的设备可能不包含任何线。通信芯片906可实现多种无线标准或协议中的任一种，这些无线标准或协议包括但不限于Wi-Fi(IEEE 802.11系列)、WiMAX(IEEE 802.16系列)、IEEE 802.20、长期演进(long term evolution，LTE)、Ev-DO、HSPA+、HSDPA+、HSUPA+、EDGE、GSM、GPRS、CDMA、TDMA、DECT、蓝牙及其衍生物以及称为3G、4G、5G以及更高世代的任何其他无线协议。计算设备900可包括多个通信芯片906。例如，第一通信芯片906可专用于较短程的无线通信，诸如Wi-Fi和蓝牙；而第二通信芯片906可专用于较长程的无线通信，诸如GPS、EDGE、GPRS、CDMA、WiMAX、LTE、Ev-DO等。

计算设备900的处理器904包括封装在处理器904内的集成电路。在一些示例中，处理器的集成电路管芯包括组装在基于ePLB或eWLB的P0P封装中的一个或多个设备，根据示例，该封装包括直接接触衬底的模具层。术语“处理器”可以指处理来自寄存器和/或存储器的电子数据以将该电子数据转换成可存储于寄存器和/或存储器中的其他电子数据的任何设备或设备的部分。

通信芯片906还包括封装在通信芯片906内的集成电路管芯。根据另一示例，通信芯片的集成电路管芯包括组装在基于ePLB或eWLB的P0P封装中的一个或多个设备，根据示例，该封装包括直接接触衬底的模具层。

与上文描述的示例相结合提及更多的细节和方面。图9中示出的示例可包括与结合提出的概念或者上文(例如，图1-图8)描述的一个或多个示例提及的一个或多个方面相对应的一个或多个任选的附加特征。

与前述示例中的一个特定示例相关地描述的方面和特征可与其他示例中的一个或多个相组合，以代替该其他示例的相同或类似特征或者将这些特征附加地引入到其他示例中。

示例可进一步是或涉及(计算机)程序，包括用于在该程序在计算机、处理器或其他可编程硬件组件上执行时执行以上方法中的一个或多个方法的程序代码。由此，上文所描述的方法中的不同方法的步骤、操作或过程也可以由经编程的计算机、处理器或其他可编程硬件组件执行。示例还可涵盖程序存储设备，诸如数字数据存储介质，其为机器可读、处理器可读或计算机可读的并且编码和/或包含机器可执行、处理器可执行或计算机可执行的程序和指令。例如，程序存储设备可包括或可以是数字存储设备、磁存储介质(诸如磁盘和磁带)、硬盘驱动器或光学可读数字数据存储介质。其他示例还可包括被编程为用于执行上文所描述的方法的步骤的计算机、处理器、控制单元、(现场)可编程逻辑阵列((field)programmable logic array，(F)PLA)、(现场)可编程门阵列((field)programmable gatearray，(F)PGA)、图形处理器单元(graphics processor unit，GPU)、专用集成电路(application-specific integrated circuit，ASIC)、集成电路(integrated circuit，IC)、或片上系统(system-on-a-chip，SoC)系统。

还将理解，在说明书或权利要求书中公开的若干步骤、过程、操作或功能的公开不应被解释为暗指这些操作必须根据所描述的次序，除非在单独的用例中明确陈述或出于技术原因而必要。因此，先前的描述并非将若干步骤或功能的执行限于某个次序。此外，在其他示例中，单个步骤、功能、过程或操作可包括和/或被分解为子步骤、子功能、子过程或子操作。

计算机可执行指令可以是例如计算系统的操作系统、存储在计算系统本地的应用、或对于计算系统可访问的远程应用(例如，经由网页浏览器)的部分。本文所述的方法中的任何方法均可以通过计算机可执行指令来执行，这些指令由单个计算系统或由在网络环境中操作的一个或多个联网的计算系统执行。计算机可执行指令和对计算机可执行指令的更新可以从远程服务器下载到计算系统。

此外，应理解，所公开的技术的实现不限于任何特定的计算机语言或程序。例如，所公开的技术可以由以C++、C#、Java、Perl、Python、JavaScript、Adobe Flash、C#、汇编语言、或任何其他编程语言编写的软件来实现。同样，所公开的技术不限于任何特定的计算机系统或任何特定类型的硬件。

此外，任何基于软件的实施例(包括例如用于使计算机执行所公开的方法中的任一者的计算机可执行指令)可以通过合适的通信手段被上传、下载或远程访问。此类合适的通信手段包括例如，因特网、万维网、内联网、电缆(包括光纤电缆)、磁通信、电磁通信(包括RF、微波、超声波和红外通信)、电子通信或其他此类通信手段。

如在本申请和权利要求书中所使用，由术语“和/或”连接的项列表可意指列出的项的任何组合。例如，短语“A、B和/或C”可意指A；B；C；A和B；A和C；B和C；或A、B和C。如在本申请和权利要求书中所使用，由术语“……中的至少一个”连接的项列表可意指列出的项的任何组合。例如，短语“A、B或C中的至少一个”可意指A；B；C；A和B；A和C；B和C；或A、B和C。而且，如在本申请和权利要求书中所使用的，由术语“……中的一个或多个”连接的项列表可意指所列项的任何组合。例如，短语“A、B和C中的一个或多个”可意指A；B；C；A和B；A和C；B和C；或A、B和C。

不应将所公开的方法、设备和系统解释为以任何方式进行限制。替代地，本公开内容单独地以及以与彼此的各种组合和子组合针对各个公开的实施例的所有新颖的且非显而易见的特征和方面。所公开的方法、设备和系统既不限于任何特定方面或特征或其组合，所公开的实施例也不要求存在任何一个或多个特定优点或解决任何一个或多个特定的问题。

参考本公开的设备或方法在此提出的操作理论、科学原理或其他理论描述是出于更好地理解的目的而提供的，并且不旨在限制范围。所附权利要求中的设备和方法不限于以由此类操作理论描述的方式起作用的那些设备和方法。

虽然出于方便呈现起见而以特定的、连续的顺序描述了所公开的方法中的一些方法的操作，但是应理解，这种描述方式涵盖重新安排，除非本文中阐述的特定语言需要特定的排序。例如，在某些情况下，顺序地描述的操作可以被重新安排或同时执行。而且，出于简单起见，附图可能未示出所公开的方法可以与其他方法结合使用的各种方式。

如果一些方面已结合设备或系统进行了描述，但这些方面也应当被理解为对相对应方法的描述。例如，块、设备、或者设备或系统的功能性方面可与相对应方法的特征(诸如方法步骤)相对应。相应地，结合方法描述的方面也应当被理解为对相对应块、相对应元件、相对应设备或相对应系统的属性或功能性特征的描述。

如本文所使用，术语“模块”是指可采用硬件组件或设备、在处理单元上运行的软件或固件、或其组合来实现的用于执行符合本公开的一个或多个操作的逻辑。软件和固件可以被具体化为存储在非瞬态计算机可读存储介质上的指令和/或数据。如本文所使用，术语“电路系统”可以单独地或以任何组合包括非可编程(硬连线)电路系统、可编程电路系统(诸如处理单元)、状态机电路系统和/或存储可由可编程电路系统执行的指令的固件。本文中所描述的模块可共同地或单独地被具体化为形成计算系统的部分的电路。由此，模块中的任一者可以被实现为电路系统。被称为被编程为用于执行方法的计算系统可以被编程为经由软件、硬件、固件或其组合来执行该方法。

示例(例如，示例1)涉及一种处理单元，该处理单元包括：一个或多个接口，该一个或多个接口被配置成用于与至少一个硬件组件进行通信；以及处理电路系统，该处理电路系统被配置成用于控制该一个或多个接口，以及用于确定该至少一个硬件组件的多个硬件微服务的超集。

另一示例(例如，示例2)涉及先前描述的示例(例如，示例1)，其中处理电路系统进一步被配置成用于生成包括多个硬件微服务的列表。

另一示例(例如，示例3)涉及先前描述的示例(例如，示例1-示例2中的一个示例)，其中处理电路系统进一步被配置成用于观察至少一个硬件组件的状态，并且如果该至少一个硬件组件的状态已改变，则重新确定该至少一个硬件组件的硬件微服务。

示例(例如，示例4)涉及一种软件模块，该软件模块包括：一个或多个接口，该一个或多个接口被配置成用于与处理单元进行通信；以及处理电路系统，该处理电路系统被配置成用于控制该一个或多个接口，以及用于接收关于至少一个硬件组件的多个硬件微服务的超集的信息，提供关于该超集的信息并基于用户输入生成子集。

另一示例(例如，示例5)涉及先前描述的示例(例如，示例4)，其中提供关于超集的信息和生成子集被探索过程所包括。

另一示例(例如，示例6)涉及先前描述的示例(例如，示例4-示例5中的一个示例)，其中处理电路系统进一步被配置成用于检查所接收的信息的更新是否可用，并且如果所接收的信息已经更新，则接收关于多个硬件微服务的经更新的信息。

另一示例(例如，示例7)涉及先前描述的示例(例如，示例4-示例6中的一个示例)，其中处理电路系统进一步被配置成用于同步多个硬件微服务，以将它们提供给外部处理单元。

另一示例(例如，示例8)涉及先前描述的示例(例如，示例4-示例7中的一个示例)，其中如果多个硬件微服务中的多个硬件微服务被选择，则处理电路系统进一步被配置成用于生成用于多个硬件微服务的查询计划。

另一示例(例如，示例9)涉及先前描述的示例(例如，示例8)，其中处理电路系统进一步被配置成用于将多个硬件微服务的查询计划呈递至层级树中。

另一示例(例如，示例10)涉及先前描述的示例(例如，示例4-示例9中的一个示例)，其中处理电路系统进一步被配置成用于生成子集的序列流。

另一示例(例如，示例11)涉及先前描述的示例(例如，示例10)，其中生成序列流被建模过程所包括。

另一示例(例如，示例12)涉及先前描述的示例(例如，示例10-示例11中的一个示例)，其中处理电路系统进一步被配置成用于检查序列流中的多个硬件微服务中的第一硬件微服务的输出参数与序列流中的多个硬件微服务中的第二硬件微服务的输入参数是否匹配。

另一示例(例如，示例13)涉及先前描述的示例(例如，示例10-示例12中的一个示例)，其中处理电路系统进一步被配置成用于从序列流生成不可知代码。

另一示例(例如，示例14涉及先前描述的示例(例如，示例13)，其中处理电路系统进一步被配置成用于将不可知代码传送至外部处理单元，以使得外部处理能够使用多个硬件微服务。

另一示例(例如，示例15)涉及先前描述的示例(例如，示例10-示例14中的一个示例)，其中处理电路系统进一步被配置成用于将不可知代码解码为原生代码类型。

另一示例(例如，示例16)涉及先前描述的示例(例如，示例15)，其中解码不可知代码被部署过程所包括。

示例(例如，示例17)涉及一种方法，接收关于至少一个硬件组件的多个硬件微服务的超集的信息，并选择多个硬件微服务中的至少一个硬件微服务。

另一示例(例如，示例18)涉及先前描述的示例(例如，示例17)，进一步包括生成包括至少一个硬件微服务的子集。

另一示例(例如，示例19)涉及先前描述的示例(例如，示例17-示例18中的一个示例)，进一步包括检查所接收的信息的更新是否可用，并且如果所接收的信息已经更新，则接收关于多个硬件微服务的经更新的信息。

另一示例(例如，示例20)涉及先前描述的示例(例如，示例17-示例19中的一个示例)，进一步包括：如果多个硬件微服务中的多个硬件微服务被选择，则生成用于多个硬件微服务的查询计划。

另一示例(例如，示例21)涉及先前描述的示例(例如，示例20)，进一步包括将多个硬件微服务的查询计划呈递至层级树中。

示例(例如，示例22)涉及一种非瞬态计算机可读介质，该非瞬态计算机可读介质包括程序代码，该程序代码当在计算机、处理器或可编程硬件组件上执行时，执行上述示例(例如，示例17-示例21)中的一个示例。

另一示例(例如，示例22a)涉及一种计算机程序，该计算机程序具有程序代码，该程序代码用于当计算机程序在计算机、处理器或可编程硬件组件上执行时，执行上述示例(例如，示例17-示例21中的一个示例)的方法。

示例(例如，示例23)涉及一种方法，该方法包括确定至少一个硬件组件的多个硬件微服务的超集。

另一示例(例如，示例24)涉及先前描述的示例(例如，示例23)，进一步包括生成包括多个硬件微服务的列表。

示例(例如，示例25)涉及一种非瞬态计算机可读介质，该非瞬态计算机可读介质包括程序代码，该程序代码当在计算机、处理器或可编程硬件组件上执行时，执行上述示例中的一个示例(例如，根据示例23至示例24中的一个示例)。

示例(例如，示例25a)涉及一种计算机程序，该计算机程序具有程序代码，该程序代码用于当计算机程序在计算机、处理器或可编程硬件组件上执行时，执行上述示例(例如，示例23-示例24中的一个示例)的方法。

示例(例如，示例26)涉及处理单元，该处理单元包括用于处理的装置和用于存储信息的装置，其中处理单元被配置成用于确定至少一个硬件组件的多个硬件微服务的超集。

示例(例如，示例27)涉及软件模块，该软件模块包括用于处理的装置和用于存储信息的装置，其中该软件模块被配置成用于接收关于至少一个硬件组件的多个硬件微服务的超集的信息，提供关于该超集的信息以及基于用户输入生成子集。

所附的权利要求由此被包括在具体实施方式中，其中，每一项权利要求本身可作为单独的示例。应当注意，虽然在权利要求书中从属权利要求指代与一项或多项其他权利要求的特定组合，但是其他示例也可包括该从属权利要求与任何其他从属或独立权利要求的主题的组合。在此明确提出此类组合，除非在个别情况下声明特定组合并非预期的。此外，即使权利要求并未直接被限定为引用任何另一独立权利要求，但该权利要求的特征也应针对该任何另一独立权利要求而被包括。