本申请要求2016年9月9日提交的美国临时专利申请no.62/385,516和2016年10月31日提交的美国临时专利申请no.62/415,297的权益。通过引用合并2016年9月9日提交的美国临时专利申请no.62/385,516和2016年10月31日提交的美国临时专利申请no.62/415,297的公开内容通过引用合并于此，就如同在此以它们的整体呈现一样。本公开总体上涉及诸如针对在仓库、分发、制造和其他设施中的拣选、分类和包装、运送和其他操作的工作流(workflow)的控制。特别地，本公开涉及用于操作和管理此类设施内的业务/设施工作流的通信系统，该通信系统能够实现针对利用各种不同的自动化系统和/或设备的设施的(一个或多个)期望的业务/设施工作流的通信和执行，所述各种不同的自动化系统和/或设备可以利用不同的操作平台和/或编程语言来执行业务/设施工作流所需的操作、任务和/或功能。
背景技术：
：：仓库、制造工厂、分发中心和其他类似设施正变得越来越自动化以满足对更高效率的需求和对货物的生产、移动的控制以及库存的控制，以降低运营成本。对于公司而言，能够非常密切地跟踪和监视其设施内的产品、设备和其他资产，以提高在制造、库存和货物/产品进出它们的设施的移动这些方面的生产率和效率，已经变得越来越重要。例如，虽然许多大型制造公司和零售商一段时间以来一直强调需要监视并积极控制产品的库存，以便将需求与它们供应此类产品的能力平衡，但是其他类型的公司，诸如fedex、以及ups和其他递送服务公司，连同诸如amazon和cdw之类的大型在线零售商，正进一步寻求方法以用来管理它们对进入设施的包裹/小包裹(parcel)和/或产品(诸如在amazon或cdw的情况下)的接纳(intake)，然后分类、库存(如果需要的话)、拣选、放置/包装，并进一步跟踪此类包裹和/或产品经过仓库或分发/分类设施的路线，以便运送到全国各地的收件人或客户，这包括确保将此类包裹或产品递送到所要求的位置并且是在规定的时间内。为了帮助在诸如制造、分发、仓库等设施中实现更有效的工作流管理，已经开发了自动化设备和技术来帮助管理、监视和执行公司在它们的设施处的(一个或多个)业务工作流所需的功能和/或任务。例如，现在通常使用诸如膝上型电脑、平板电脑以及甚至手机之类的移动设备，以使得工作人员能够快速且容易地与设施或公司服务器通信以输入数据和接收指令。另外，条形码扫描仪和qr扫描仪、光学字符读取器或相机、和/或其他小型手持设备可以提供进一步的便携性、提高的效率、和/或易于设施人员使用以根据需要对产品或设备进行跟踪、分类、储存、拣选或包装、以及/或者重定向。然而，在此类技术和/或设备的增加使用和开发的过程中已经出现的一个问题是，这些设备倾向于利用各种不同的操作平台。例如，一些膝上型电脑和平板电脑可以利用windows(和/或其各种版本)操作系统/平台，而其他设备利用apple或操作系统，这些操作系统通常彼此不是很兼容。此外，各种不同的公司已经开发了诸如各种扫描仪或光学读取器之类的其他设备，它们不仅是之前已经利用了不同操作系统和/或编程语言，而且进一步地，随着更加新的和/或不同的版本或改进的/新的型号和/或设备被开发和引入，此类新的型号或设备通常与其旧版本或旧代产品不兼容。因此，公司经常面临困难选择，即关于如何将更加新的技术或设备集成到它们的业务或设施工作流管理中，因为公司或设施通常已经对其较旧的设备进行了非常大的投资。此外，由于不同的用户/工作人员具有不同的偏好(即，有些人可能更喜欢可操作设备，而其他人更喜欢apple或可操作设备)，并且还因为一些设备诸如扫描仪、平板电脑或所需要或使用的其他系统/设备可能是由不会简单地使用相同或兼容的操作平台的不同公司制造的，所以公司通常难以尝试将它们所使用的设备或操作平台标准化。因此，公司通常别无选择，只能创建和/或购买专用于其所利用的不同设备和/或自动化系统中的每一个的、定制或设备专用的工作流逻辑、编程和/或指令，并且当更新此类自动化系统或设备或购买新设备时，还必须创建或更新用于每个此类设备或自动化系统的新的业务逻辑和设备专用的编程/指令的集合。这可能是非常时间密集的且成本高，不仅是在为每个新的/升级的设备创建新的编程、逻辑和/或指令的集合所需的成本和时间方面，而且还在测试和修复可能出现的错误或故障方面。对于需要使用多个不同设备或自动化系统和/或操作平台的客户而言，这种时间和费用的投入会进一步显著地成倍增加。因此，可以看出，存在对解决本领域中的前述和其他不相关问题的一种系统或工作流控制和管理的需要。技术实现要素：简而言之，在一个方面，本公开涉及一种通信和控制系统，其用于集成和实现一系列外围设备与用于控制所选设施(例如仓库或其他合适的设施)的操作的、设施的设备中立的(deviceneutral)工作流之间的通信。该工作流通信系统可以包括/并入可以在所选设施处执行一个或多个功能或操作的各种设备。这些设备还可以操作或运行各种不同的平台或操作系统，例如apple等。自动化系统还可以包括可以通过各种设备来接入的一个或多个工作流，所述(一个或多个)工作流可以包括用于一系列任务的设备中立或设备不可知的业务逻辑或指令的集合，其与要由各种设备来执行的、或要在所选位置处执行的规定工作流操作或功能相对应。此外，各种设备将包括引擎，其被配置、可操作和/或设计用来接入、运行(一个或多个)总体工作流或与(一个或多个)总体工作流通信，并允许(一个或多个)工作流的逻辑或指令在具有不同操作系统的设备上(例如在运行apple等的设备上)执行。因此，(一个或多个)工作流的业务逻辑或指令将是设备中立的，具有按照需要提供的特定子工作流，例如以便由所选设备或在所选位置处、使用可以操作或运行各种不同的平台或操作系统的一个或多个外围设备来执行特定操作或功能。因此，如果一个或多个设备被更改或更新、或者(一个或多个)工作流的操作/功能被修改或更新，则可以仅必须修改用于(一个或多个)特定被改变或受影响的设备的一个或多个引擎，而不用必须为通过工作流通信系统而链接的、并且运行或操作不同的操作系统或平台的设备中的每一个创建设备专用的工作流程序和指令。这还可以提供运行各种平台或操作系统的设备的改进的集成性。在另一方面，本公开可以涉及一种用于通信和控制系统在所选设施处的操作的方法。该方法可以包括：通过提供用于在设施处执行部件/系统的任务、操作或控制的设备，来集成和实现一系列外围设备与用于控制在所选设施(例如仓库或其他合适设施)处的操作的、设施的设备中立的工作流之间的通信系统，该设备可以操作或运行不同的平台或操作系统。该方法还可以包括将一个或多个引擎加载到设备的每一个上，并且该方法可以包括接入至少一个工作流(其可以具有设备中立的业务逻辑)，利用这些引擎来在该设施处执行特定任务、功能或操作。这些引擎可以被配置或可操作成允许(一个或多个)设备中立的工作流在各种外围设备的不同操作系统/平台上运行或与其通信，以便利用其硬件部件。附图说明图1示出根据本公开的原理的，用于集成和实现一系列优选设备之间的通信的通信系统，和用于控制设施的操作的、设施的设备中立的工作流的示意图。图2示出根据本公开的原理的通信系统的操作的流程图。图3a-3b示出了根据本公开的原理的用于与通信系统进行消息传递的示图。图4a是示出根据本公开的原理的工作流通信系统的示例的流程图。图4b是示出根据本公开的原理的用于通信系统的控制的流程的示图。图5示出采用根据本公开的原理的通信系统的示例设施。图6示出用于图5的设施的示例拣选站。图7示出用于图5的设施的示例放置/拣选壁组件或系统。具体实施方式如图1-7所示，本公开涉及具有一个或多个通信系统10的设施1，该一个或多个通信系统10控制在设施1处的特定操作或功能。设施1可以包括用于执行在设施1处的特定功能或操作的各种设备12，并且通信系统10可以包括：至少一个工作流14，其包括用于使设备执行其对应功能/操作的指令；以及通过设备12来接入、在设备12上运行、或以其他方式与设备12通信的一个或多个引擎16，所述引擎16可以被配置或可操作用来与工作流14通信，并在设备12上启动和运行工作流14。工作流14可以是设备中立的(deviceneutral)或设备独立的，并且可以包括用于使用各种设备12来执行设施1的特定功能或操作的业务逻辑或指令，而引擎16可以是设备专用的并且可操作的，因此具有不同操作系统或平台的设备12可以与至少一个工作流14通信并运行该至少一个工作流14。链接到通信系统2/集成在通信系统2内的设备12可以单独地/独立地接入工作流14。工作流14通常将包含用于执行设施1的特定功能/操作的业务逻辑或指令。例如，工作流14可以是一组指令，其行至运营商或通过特定进程来控制设施1处的一个或多个自动化系统或设备。工作流14进一步地通常将是设备中立的或设备独立的，并且可以是用所选的编程语言创建和/或编写的，而不必为特定的操作平台或软件或针对特定的操作平台或软件编写语言；并且可以主要包含用于执行设施的特定功能或操作的业务逻辑或指令。例如，(一个或多个)工作流14可以在如下情况下被编写，即它们不需要包含特定的指令或代码以用于与通信系统的外围设备12的一系列特定和/或不同操作系统中的每一个进行交互，以便接入或操作所述设备的功能或硬件(例如，用来接入和操作移动设备的显示器18、输入端20或硬件部件26的特定指令或逻辑)。在一个示例中，(一个或多个)工作流14可以被存储在自动化系统12的服务器的存储装置或存储器中。服务器可以包括可操作用来接入存储器并执行存储在其中的程序或指令的处理器。服务器可以与网络通信，并且移动设备也可以与网络通信，从而允许移动设备12接入(一个或多个)工作流14。如图1中所指示的，设备中立的或设备独立的总体设施工作流14可以由设施管理者来创建、或以操作的设施控制层级来创建，并且因为它不必是设备专用的，所以反而可以关注于提供在特定设施(无论它是制造工厂、仓库或分发中心还是其他类似类型的设施)处所需的必要/期望任务、功能或其他操作。可以将这些指令或工作流任务列表创建为子工作流，其也可以根据需要而容易地更新或修改，基本上不用考虑执行每个工作流任务或功能所需的一个或多个特定设备。例如，可以为不同的设施、操作、站点、或者为工厂或设施的不同地区或区域创建工作流和/或一系列工作流，诸如为产品的制造、库存、分类、处理订单、拣选和包装、和/或运送提供(一个或多个)工作流。如上所指出的，设施工作流14可以被存储或驻留在服务器上或一系列服务器上(包括被提供在远程位置处或云存储中的)，并且在一些实施例中可以包括针对设备的特定动作、位置和/或类型或组的各种子工作流。举例来说，工作流14可以被设计有任务列表或子工作流，其提供特定设施或客户的过程/指令以用于对进入设施的产品或货物的接纳；用于对进来的产品进行分类；根据需要对已分类的产品进行库存，其包括用于将每个产品或一系列产品发送到已知库存位置的指令；提供用于根据诸如运送日期、产品的类型等的参数进行接纳、处理、安排和订单履行的过程/指令；提供用于根据进行包装的每个订单来检索、拣选和/或放置货物或产品的指令；提供用于每个订单就完整性的质量控制或检查、并用来确保质量的指令；以及提供用于在订单或一系列订单从设施释放时创建和提供跟踪信息的指令。可以由各种不同的设备来检索和执行子工作流或任务列表中的每一个，如例如在图4a中所指示的，诸如由不同类型的扫描仪或光学字符读取器和相机来执行的接纳和分类。作为工作流通信系统2的一部分而链接的设备中的每一个设备的引擎将与工作流通信并接入工作流，并且可以从工作流检索用于执行所需任务指令或步骤中的每一个的指令，将根据用于其的操作平台/语言来解释这些指令，并且因此能够实现控制其的相关设备以执行这些功能。此后，引擎可以进一步传送回工作流或直接传送到设施服务器，以指示已经执行了所选或所检索的任务或一系列功能。作为设备中立的，工作流因此不必关心由单个设备承担的步骤或动作中的每一个，或者特别地需要哪些设备来执行这样的任务或工作流功能，而只要关心任务被分配或检索给设备，以及针对特定产品、产品组或订单的任务已完成。因此，除了不必对每个单独的设备用其自己的工作流指令来重新创建和编程之外，可以根据需要而容易地和/或无困难地创建、更新和/或以其他方式修改工作流，并且其任务可以被检索或分配给各种不同设备，而基本上不考虑通过本通信系统2连接到工作流的不同外围设备的编程语言或操作平台的差异。作为用于设施或其区域的通信系统2的一部分而链接到工作流14的外围设备12可以被配置或可操作用来执行在设施1处的操作或功能，并且可以包括台式机、膝上型电脑、移动电话、平板电脑、扫描仪、相机、光学字符识别读取器或其他合适的移动或手持设备。设备12可以操作或运行不同的平台或操作系统，其可以包括例如平台、平台(例如windows或ce)、或任何其他合适的平台或操作系统。在一个示例中，该设备可以包括具有显示器18、一个或多个输入端20、处理器22、存储装置或存储器24、以及一个或多个硬件部件26(诸如扫描仪)的处理设备12，诸如膝上型电脑、台式机、或者移动或手持设备(例如平板电脑或智能电话)。该设备可以包括一个或多个引擎16，接入一个或多个引擎16、或以其他方式与一个或多个引擎16通信，以用于与工作流14通信、解释和运行工作流14。引擎16可以是设备专用的并且包含对应于设备12的独特或不同平台或操作系统的逻辑或指令。引擎16可以被存储在其对应设备12的存储器24中，并且可以被设备12的处理器22接入以运行其上的(一个或多个)工作流14。引擎16可以在设备14上启动和运行(一个或多个)工作流14，以使得设备执行工作流的业务逻辑并执行在设施1处的特定操作和功能。在一个示例中，每个引擎16可以包括一系列部件，该一系列部件包括：第一部件，该第一部件可以包括依赖于设备的(或设备专用的)接口代码或指令，其可操作用来管理对应设备12资源以及可以是设备专用的其他部件，例如用来接入移动设备的输入端20或硬件部件26的指令。引擎16还可以包括第二部件，该第二部件包括设备专用的可执行逻辑或指令，其可操作用来起动或启动在特定设备上加载和运行工作流14的第三部件并与其通信。该部件可以被称为“工作流设备引擎”并且可以包括特定代码，例如代码，并且第二部件可以包括用于该特定代码的可执行代码(executable)，例如可执行代码，其可操作用来起动和与通信，尽管在不脱离本公开的情况下可以使用任何合适类型的代码或指令。工作流引擎可以包含对连接(例如md或http连接)、工作流状态引擎、翻译和对话进行管理的所有通用代码。工作流引擎和工作流14可以经由功能接口彼此通信。工作流引擎和第二部件可以在端口(诸如tcp端口或其他合适的端口)上经由md或http消息进行通信，并且第一部件和第二部件可以经由md/http或其他程序接口进行通信。根据本公开的一个方面，一个或多个引擎16可以被配置为在通用平台(“uwp”)上运行/操作，并且因此(一个或多个)工作流14可以通过可运行/操作uwp且具有uwp的设备12来解释和接入。例如，用于uwp的该(一个或多个)引擎16可以允许(一个或多个)工作流14扩展到设备12并且被设备12接入，该设备12包括利用平台的uwp家族或10来操作的电话、平板电脑、台式机、服务器以及其他合适的设备或信息处理系统。例如，(一个或多个)工作流14可以便利于在设施1处与人员或用户的交互，并且可以使用设备12的文本到语音(text-to-speech)(“tts”)或自动语音识别(“asr”)操作/功能来执行在设施1处的各种功能或操作、或者使得工作人员能够执行在设施1处的各种功能或操作。(一个或多个)工作流14还可以包括设备中立的逻辑或指令，其允许设施人员与设备12的显示器13上提供的引导式用户接口交互，以便指示人员执行在设施1处的规定功能/操作，或允许人员执行在设施1处的特定自动化功能或其他操作。在一个示例中，如图2中所示的，工作流系统10可以首先例如在移动设备12的显示器16上请求来自用户、操作员或工作人员的识别信息(id)(框102)。然后，操作员/工作人员可以使用输入端20来输入识别信息(id)，该识别信息(id)可以由移动设备16的处理器22接收到(框104)。处理器22可以检索与操作员输入的识别信息(id)相关联的一个或多个工作流14(框106)。然后，处理器22可以启动或运行引擎16(框108)，该引擎16能够加载和启动所检索到的工作流14(框110)。引擎16可以与所检索到的工作流14通信，并且接入和翻译工作流14业务逻辑中的每一个以用于使用移动设备16在设施处的特定功能或操作的执行(框112)。在读取业务逻辑时，引擎可以例如使用其操作系统或平台来接入移动设备的部件或资源，以指示/控制移动设备来执行/实行业务逻辑(框114)。然后，移动设备16可以至少部分地基于工作流的业务逻辑来执行在设施处的特定功能或操作(框116)。例如，(一个或多个)工作流14可以使用tts、asr或在一个或多个设备12的显示器16上提供的引导式用户界面来指示用户执行或允许用户执行在设施1处的所选择的功能或操作。因此，利用本公开的实施例，用于执行在设施处的所有的特定操作或功能、控制或以其他方式便利于在设施处的特定操作或功能的(一个或多个)特定工作流14，可以被每个设备12的引擎接入和运行，即使设备12使用不同的平台或操作系统，例如一个设备在平台上运行，一个设备在平台上运行，并且一个设备在平台上运行，等等。工作流14也可以由利用uwp操作的各种设备接入。因此，如果(一个或多个)工作流14被更新或定制/当(一个或多个)工作流14被更新或定制时，仅需要修改工作流14本身，而不是修改针对使用不同操作平台的每个设备12的单个程序或指令。另外，使用不同平台或操作系统的设备12可以被互换地使用，以实行或执行在设施处的功能和操作。例如，设施1可以使用特定数量的(例如五个)台式机来运行规定的工作流14以执行(一个或多个)特定的功能或操作，而该数量的台式机有时可能不足以适应设施的需要，例如，归因于对台式机所执行的特定功能的高需求或容量。利用本公开的实施例，设施的运营商可以能够引入和使用其他可用的设备(例如平板电脑或其他移动设备或信息处理系统)来操作规定的工作流并满足需求，而不需要购买新的台式机来适应高需求/容量的时段。这些设备12中的每个都可以包括用来运行(一个或多个)工作流14的引擎16，因此基本上被无缝地引入以执行特定功能/操作，因为将不必开发专用于在不同平台上操作的每个设备的工作流。在一个方面，例如，(一个或多个)工作流14可以包括(一个或多个)质量控制工作流，其可以便利于分析在设施1处执行的功能或操作的质量，或者允许用户或设施人员评估设施1的操作/功能的质量，并且尽管通常可以使用根据本公开的引擎16在繁忙时段或高需求时间期间、使用诸如台式机或膝上型电脑之类的设备(例如使用10平台/操作系统或其他操作系统进行操作的设备)来执行这些质量控制工作流，但是设施1的操作员可以能够利用平板电脑或电话(诸如运行windows10移动版、android或ios的那些)以增加额外的设备(诸如用户的移动设备或平板电脑)，其没有台式机设备或可用设备那么昂贵，以便在不需要购买昂贵的台式机设备的情况下满足运营需求。图4a示出了根据一个示例实施例或资产的工作流通信系统2的设计或架构的总体概述。例如，工作流/通信系统可以包括一系列层级，例如，四个层级。层级1(在图4a中的l1处指示的)可以是完全依赖于设备的，并且可以包括用来管理设备的资源和设备专用的其他项目(例如运行/操作诸如windowswindows或对话器(talkman)的平台的层级1平板电脑或手持设备(或其他硬件))的接口代码(诸如用来接口的代码)。层级2(在图4a中的l2处指示的)可以包括可执行的或操作系统软件(其也可以是依赖于设备的)，和/或包括起动该可执行的软件并与其通信所需的代码。层级3(在图4a-4b中的l3处指示的)可以包括主代码应用程序或(一个或多个)工作流引擎，加载、解释和运行实际的设备中立的工作流代码(其是层级4)的代码。层级4(在图4a-4b中的l4处指示的)通常将处理例如配置、对话、翻译、消息、全局和工作流字(word)、工作流状态、以及比如全局高速缓存之类的一些杂项接口。层级3代码或“工作流引擎”可以包含对连接、引擎(例如工作流状态引擎)、翻译和对话进行管理的所有通用代码。层级3和层级4可以经由功能接口彼此通信，而层级3和层级2可以在一个或多个端口(例如tcp端口)上经由消息进行通信，并且层级2和层级1可以经由程序化接口进行通信。主代码(例如代码或其他合适的代码或编程语言)可以在特定目录下。层级3代码也可以在一目录下，而用于示例的引擎测试器(enginetester)层级4工作流的代码可以附加地在一目录(例如引擎测试器目录)下。在这些目录下，还可以是src目录，并且在该src目录下可以是包含主代码(例如代码)的目录。与src处于同一层级的dev和resources目录可以分别被用于测试代码和资源文件(例如数据文件)。设施工作流或其子工作流(例如，用于订单履行的指令)可以是主代码，例如代码，或指导客户经过工作进程的其他合适的代码或编程语言。引擎可以在设备上执行该主代码，以使得在设备和工作流之间的客户的交互基本上是无缝的。此外，层级3代码可以提供能够处理通常所需要的功能的api或基本功能，例如用户交互、设备外部的通信、和进程流控制。在一个示例实施例中，层级4或工作流可能需要：·包(通常是在“工作流(workflows)”下具有工作流的名称的目录)·包目录下的dev、resources和src目录·没有代码的default__init__.py文件·具有以下代码的main.py文件：defmain():workflowapp(clmaintask)·具有从clworkflowbase导出的被称为clmaintask的类别class(clworkflowbase)的maintask.py文件，该类别应该包含作为工作流的起点的stwelcome方法·languageparsingdirectives.py文件，其可选地可以具有针对语法实用程序(grammarutility)的信息·被用于需要翻译的令牌的tokens.py文件·workflowglobalwords.py文件，其用于在所有提示(prompt)上使用的退出字(exitword)。层级4或工作流代码可以主要经由对话和陈述与层级3代码交互。对话方法可以允许层级4代码向层级3引擎发送提示，然后继续或等待响应。引擎测试器(enginetester)是示例的层级4工作流，它尝试练习所有的层级3工作流功能，因此它尝试不同的对话功能、设置标志等。根据一个实施例，配置可以允许在不改变代码的情况下适应环境，并且允许在(一个或多个)设备和(一个或多个)服务器之间建立通信。可以存在多个配置，例如每个工作流有两个文件。配置文件中的一个可以是全局工作流文件(例如workflow.ini)，它可以被用于所有的工作流，并且配置文件中的另一个可以是用于层级4工作流的ini文件，它应该具有与工作流相同的名称，例如<workflow>.ini。专用于层级4工作流的属性或外部连接可以被放置在该第二个配置文件中。至其他系统的连接(诸如md、http或其他连接)可以在ini文件中被描述为通用适配器(commadapter)，它可以是ini区段，其中该区段名称可以是comm.<someuniquename>。至少可以配置全局workflow.ini中的comm.default适配器。当在dit或diq中使用工作流配置文件创建器来创建配置文件时，这通常是在各种设备平台、例如和vpack(其可以包括windowswindows和可能的其他操作软件)平台上完成的。这可以将ip/主机名称放入针对该配置文件的全局workflow.ini文件中，其通常是可以下载到设备的。如果需要手动编辑默认的适配器的其他属性，则可以手动编辑workflow.ini。workflow.ini设置中的默认连接的示例可以包括：workflow.ini默认通用适配器主代码/程序(例如代码)可以具有一个或多个模块，例如configparser，其可以解析ini文件并且是其标准特征设置的一部分，使得所有的层级3和层级4配置文件都可以使用ini格式，在下面示出其示例：存在几个层级的ini文件，其包括用于由层级3工作流引擎所使用的配置参数的全局ini文件，以及用于每个层级4工作流的可选ini文件。层级3工作流ini文件可以保持关于至其他进程和工作流默认的连接的信息。单个工作流ini文件可以被用来存储专用于工作流的值，例如，用于不同变量的默认值、字符串常量、或至专用于该工作流的进程的连接。层级3文件可以在所有平台上被称为‘workflow.ini’，并且在开发环境中，它可以位于工作流资源文件中。当在安装中部署时，可以为所创建的每个工作流配置文件创建workflow.ini文件。该workflow.ini文件可以在特定地址(例如％dc_home％\apps\vpack\configuration\workflowprofiles\<nameofprofile>)处找到。如果手动改变配置文件，则可以将已修改的ini添加到resources.zip，以便将该变化加载到设备上。当工作流引擎起动时，它可以在其目录树中查找所有的ini文件并且加载所有的属性，包括将在下面更详细讨论的通用适配器属性。这些属性可以被存储在映射中，其中针对每个属性的密钥可以呈‘<workflowname>.<sectionname>.<keyname>’的形式。对于workflow.ini中的默认属性，工作流名称可以是‘workflow’。为了检索它们，可以使用getproperty(<key>,adefault＝<default|none>)方法，其中第一个参数可以是组合的区段+密钥，并且如果在该区段中没有找到密钥，则第二个参数可以是默认值。如果没有找到密钥并且不存在默认，则该方法可以返回‘none’。例如，基于上面的示例，可以利用规定调用、例如getproperty(‘workflow.sectionname1.param2’，‘mydefaultvalueifnotfound’)来完成/执行获得sectionname1中的param2的值，其中如果没有找到密钥，则可以返回具体值，例如‘mydefaultvalueifnotfound’。可以在能够被用于通用适配器的名称的前面指定通用适配器区段，例如附加‘comm.’。例如，为了具有被称为‘client1’的通用适配器，ini文件中的区段标题(sectionheader)可以是[comm.client1]。名称comm.default可以被用来指定默认的通用适配器，并且可以被保留以便在workflow.ini中使用，这可以使层级4工作流的创建器不必跟踪哪个通用适配器正被使用(如果它们仅需要一个的话)。可以在ini文件中为特定工作流指定额外的通用适配器。针对工作流具有多个通用适配器是可能的，如果它们具有独特的名称。如果分配了复制的名称，则可能无法保证将哪组通用适配器属性附加到该名称。如果在workflow.ini和层级4工作流中存在复制的通用适配器名称，则可以始终使用workflow.ini中的属性，并且可以忽略层级4配置。可以在启动时创建workflow.ini中的任何通用适配器，以便在选择工作流之前通信可以是可用的。当加载工作流时，可以创建其通用适配器，并且可以关闭任何其他层级4工作流的通用适配器。在任何给定的时间，仅有来自当前工作流和workflow.ini的适配器可以是活动的。还可以存在能够在ini文件中设置的各种类型的通用适配器，例如两种、三种或更多种类型的通用适配器，包括：md管理器、md客户端和网络服务和/或其他。在一个示例实施例中，对于md连接，仅管理器可以被使用，因为它可以指明它正在监听什么种类的消息，并且通常可以比客户端更容易使用。在什么样的特定md消息类型预期或遇到管理器实现的限制为未知的情况下，客户端连接可以是有用的。可用于各种通用适配器的参数可以包括通用(common)、管理器(manager)、客户端(client)和网络服务(webservice)参数。例如，可用于md管理器和客户端二者的通用参数可以例如包括：·port-要连接至的端口·filter-应用于该连接的md过滤器·pt-pt字符串·pl-pl字符串示例的管理器参数可以包括：·host-要连接的主机的名称或ip·sl-sl字符串·st-st字符串·mtinmb–应该将mt字符串包含在mb(消息正文)中(真/假)·isjson–预期json中的消息(真/假)·persistent-套接字(socket)连接应该是持久的(真/假)·jsonmtinmb-如果mtinmb为真，则mt应该是在json中(真/假)示例的客户端参数可以包括：·ip-要连接的主机的ip·sendingonly-仅使用连接来发送消息(真/假)·queuefilename-持久队列的名称·maxfilessize-队列文件的最大尺寸·nomanager–不使用管理器，值无关紧要，如果参数存在，则这将是客户端连接而示例的网络服务参数可以包括：·通用参数·host主机-要连接的主机的名称或ip·connectiontype＝webservice示例的md管理器连接利用本公开的实施例，消息可以是类别消息，其超类(superclass)是可以在工作流消息文件中找到的类别clmemorydefinitionbase。如下面更详细地讨论的，通常以不同方式来处理md请求。消息类别可以被用来定义md消息的mb部分的格式。在下面的示例中，type字段指定消息的mt类型，mtinmb＝true将mt类型添加到mb字段，并且其他字段可以描述md消息的内容。md消息还可以从clmemorydefinitionbase中得到在网络服务中使用的消息类别。消息类别可以被用来指定消息中的字段以及应该如何发送消息。在diq中，可以存在可用的标准restful网络服务和自定义的非标准网络服务，因此在创建消息时，应该适当地设置类别的初始值。下面示出标准restful网络服务消息定义的示例：restful消息该消息类别可以包含运行所需的最小信息量。type字段告知主代码(例如代码)，用于该网络服务的uri以及__init__中的参数可以是在消息正文中发送的字段。所使用的命令可以至少部分地基于是在sendmessage还是在sendrequest调用中使用该消息。如果是sendmessage，则可以假设这是put请求。如果是sendrequest，可以假设post。如果它是put或post，则可以将消息正文作为json字符串发送。如果消息的http_requesttype字段被设置为get，则参数可以以形式？param1＝value¶m2＝value附加到uri。type字段也可以被md消息使用以指定其md类型。可以使用http_messagetype字段，而不是使用用于uri的type字段。如果两者都被使用，则http_messagetype可以优先。在下面示出具有http_requesttype设置的消息的示例：具有请求类型设置的restful消息对于具有http_requesttype设置的消息类别，sendmessage请求和sendrequest请求二者都可以使用http_requesttype值作为网络服务请求类型，并且可以覆盖所有的默认值。来自directorit的一些pla应用程序可以使用非标准rest类型接口。下面示出使用非标准接口的消息的示例：非标准消息标准消息和该示例的非标准消息之间的区别可以是http字段。字段http_format可以向主代码(例如代码)通知应该根据自定义标准来将消息格式化，其可以将消息的内容例如作为json字符串添加到uri。它可以默认为‘rest’。字段http_requesttype可以指定在发送该消息时要使用什么http命令。在这种情况下，消息可以始终作为get来发送。对于等同于dematic的具有http_format的消息，默认sendmessage和sendrequest二者可以使用get。该字段可以被默认成‘auto’，这可以意味着层级3代码可以确定要使用什么请求协议。最后，http_messagetype字段可以保持用于消息的uri。通常，可以提供实现与资源通信的跨平台方法以根据需要进一步接入工作流和/或业务逻辑要求。这样的资源可以包括与设备(例如扫描仪、耳机或连接到工作流引擎设备的其他外围设备)分开的外部服务器或其他设备。可以使用clummanager类别的实例将消息发送到此类设备，其包含通用适配器对象。如下面讨论的，clummanager实际上可以调用通用适配器的发送方法。可以使用clmdclient对象来发送md消息，该clmdclient对象可以包含至md主机/端口的连接，而在具有管理器对象的情况下，可以利用sendmessage或sendrequest来发送消息。对于使用mdmanager的sendmessage，唯一的要求可能是消息的类型为clmemorydefinitionbase。对于sendrequest，同样也是这样，并且第二参数(其是类别类型(不是对象))也可以是clmemorydefinitionbase类型。如果使用了mdclient，则发送函数可以使用/请求clmdmessage对象。此外，可以使用clwebmanager对象来发送网络服务消息，该clwebmanager对象可以充当用于特定网络服务的通用适配器。关于md接口，这通常可以被包含在ummanager对象中，因此通常可以忽略clwebmanager的细节。在工作流中，如本文中所述的，可以在ini文件中设置通用适配器。还可以使用保证的消息/将保证的消息排队。为了使消息得到保证，通用适配器可以具有通过向queuefilename分配名称而指定的队列，如在上面的示例中示出的，并且消息可以具有id。当消息被发送时，可以将消息添加到磁盘队列，并且层级3代码(其可以是代码)可以继续尝试重新发送它直到成功为止。通常，成功可以被定义为在使用md消息时接收到确认。对于网络服务，成功通常可以被定义为从服务器接收到状态代码为200的http响应，尽管可能存在一些例外情况。对于网络服务通用适配器，间接性(indirection)也可以允许通用适配器属性立即被设置。在创建配置文件时，可以利用实际的主机和其他属性来设置全局worflow.ini中的通用适配器，但可以不设置单个<workflowname>.ini中的通用适配器。为了针对单个工作流设置通用适配器，间接性可以允许单个workflow.ini中的通用适配器指向全局workflow.ini中的通用适配器中的一个。针对该间接性的语法可以是％[workflowname,commadaptername,attributename]％。宏替换可以被用于任何ini属性，而不仅仅是通用适配器。用于替换的语法的一个示例可以是％[workflowname,sectionname,attributename]％。另外，宏可以被配置为指向系统环境变量。下面更多地讨论环境变量。用于环境变量替换的语法可以是％[env,<environmentvariablekey>]％。如果没有找到环境变量，则该值可以为none。下面示出一个示例：示例的网络服务间接性层级3工作流还可以支持环境变量，该环境变量可以是从外部源(例如来自外部系统的消息或直接来自专用于层级2平台的代码的消息)传递到层级3中的值。可以将值存储在使用规定的函数(例如，getenv和setenv)来检索和设置的特定映射和/或其他合适的集合中。可以将任何所需的密钥值对添加到环境变量集合中。在一个示例中，可以使用各种字符串作为密钥以将值存储在环境变量(environmentvariable)字典中。另外，根据本公开的原理，工作流提示或对话可以被用来在用户和工作流之间传递消息。该对话可以提示用户输入一些语音或rf，其被传递给工作流。工作流可以使用该输入来确定接下来要采取的步骤，并向用户发送下一个提示。工作流引擎可以处理用户和工作流之间的通信，所以用户使用特定设备(例如平板电脑、台式机、膝上型电脑等)与工作流无缝地通信。该输入通常可以包括非退出字(non-exitword)，其是用户输入的某种类型的数据(数字、字母等)，以及包括退出字(exitword)，其可以从传递到对话中的列表中获取并且被用来发信号通知需要进行对非退出字的某些处理。各种请求对话之间的区别可以是，每种类型的对话预期一组不同的非退出字，或者在requestwords的情况下没有非退出字。下面将进一步讨论当使用它们时可用的不同提示和选项。对话可以被定义为工作流和用户之间的接口。对话可以提示用户输入，该输入可以包括一组字、数字、字符或其某种组合。当用户输入他们的数据时，可以转到处理它的工作流，确定下一步骤并向用户给出下一个对话提示。还存在可以在对话中使用、影响其行为的各种标志。这些标志可以包括选项，比如零长度标志(如果为真则需要输入一些数据)、以及长度标志(其指定可以输入多少个字符或数位)等等。一个简单的对话示例可以包括：在使用提示之前，可以输入所需的模块，例如：除了requestyesno之外，所有的请求对话可以共享相同的参数。下面提供一组示例性的可用参数：·atokeninstruction–在翻译之后被用作提示的字符串或cltoken对象(优选)·atokentemp-在指示之前被翻译并显示/说出的字符串或cltoken对象(优选)·aexitwords-本地退出字的映射，映射使用退出字作为密钥并且值是被用于退出字的标志集。可用的标志为：用于验证的‘v’，这意指用户必须在退出字的处理能够发生之前对验证问题回答‘是(yes)’；用于零长度的‘z’，这意指非退出字必须是输入的一部分；以及用于包含的‘i’，这意指自始至终都包括非退出字。·anonexitwordsecho-true/false(真/假)，用于在对话返回非退出字时确定它们是否被回应的标志。默认为false。·ascannerenabled-true/false，用于确定扫描仪输入是否将被接受的标志。默认为none(等同于false)·alengthtocapture-可以被用于告知工作流期望多少数位或字符。当已输入数字时，对话返回。默认为none。如果设置了alengthtocapture和aacceptfirstword(见下文)，则忽略aacceptfirstword。·adisableglobalwords-true/false，如果为true，则忽略全局工作流字。默认为false。·adisableworkflowwords-true/false。如上所述，除了工作流字之外。·adisablesystemwords-true/false。如上所述，除了系统全局字之外。·aacceptfirstword-true/false。用于确定对话是否将接受说出的第一有效响应的标志。默认为false。如果退出字是可能的，则将“i”标志附在其上，以便在你说出退出字时正确地返回非退出字。·接受第一字示例可以包括：·adisablenonexitwords-true/false。这仅对requestwords提示有效。默认为true。这被用来丢弃保证的非退出字。参见下面的更多细节。为了使语法实用程序正确地解析提示，每个引数(argument)(例如，用于token的aparts、atts、agui；用于提示其本身的adisablenonexitwords等)可以在其自己的行上。常量令牌应该在工作流的tokens.py文件中。工作流可以提示用户是/否问题，诸如在希望让设备的用户回答简单的是或否问题的情况下，请求是/否提示可能不具有aexitwords参数，因为提示只说是或否。工作流还可以提示用户输入数字。在这里，与是/否提示不同，可以在requestdigits提示中使用退出字，并且数字通常应该被输入作为非退出字。更进一步地，工作流可以提示用户输入字符。除了可以输入字母字符(alphacharacter)之外，这可以与requestdigits提示相同。工作流可以额外地提示用户输入浮点数(float)。除了还可以输入小数之外，这可以与requestdigits示例相同。工作流可以提示用户输入字母数字输入(alphanumericinput)，除了可以输入字母字符之外，它可以与requestdigits相同。例如：工作流可以提示用户仅输入退出字，例如，仅退出字可以被处理。例如：利用该示例，默认可以丢弃非退出字，但是可以通过在requestwords调用中指定adisablenonexitwords＝false来接受非退出字。下面是示例。在该示例中，较高层级的系统发送具有结果的非退出字并且可以由层级4编程者(programmer)来处理它们是可能的。在99％的情况下，这可能不需要，这就是默认值可以被设置为true的原因。工作流可以在不请求更多信息的情况下通知用户以告知用户某事。在例如向用户给出更多信息但不需要响应的情况下，可以使用notifyuser。这可以将消息放入特殊的消息队列中。当发生下一个对话请求时，可以在提示新的对话请求之前从队列中获取所有的通知消息并显示/说出。一个代码示例是：工作流可以接受非退出字。例如，如果这种情况出现，则允许用户在不需要说出退出字的情况下输入非退出字，可以在任何请求功能上利用acceptfirstword功能。该功能在高吞吐量工作流中是有用的，在这里退出字可能不那么有用。或者，例如，可以使用pin输入提示。在具有这样的提示的情况下，用户在其每次登录时可以说同样的事情，因此他们的错误率可能是低的，并且需要退出字可能会导致重复使用的烦恼。在这种情况下，acceptfirstword可以被用于加速该特定提示。可以使用设置为true的aacceptfirstword标志来实现指定该功能。一个代码示例在这种情况下，可以提示用户说出数位。尽管“准备好(ready)”是一个退出字，但他们可能不需要说出它来继续。用户可以简单地说“1234”。在暂停之后不说出准备好的情况下，工作流将处理该数位。他们还可以说“1234准备好”，这是传统的交互方式。‘acceptfirstword’标志可以被设置用于：requestalpha、requestdigits、requestalphanumerics和requestfloats。该功能对于所有的请求类型可以是相同的，但是在长度检查(lengthcheck)的情况下该功能可以稍微不同地工作。由于一旦用户说出所需数量的数位，长度检查就可以自动前进，因此它们可能已经类似于acceptfirstword提示那样地工作。因此，在长度检查的情况下，可以有效地忽略acceptfirstword选项。另外，可以通过使alengthtocapture标志为大于零的整数来设置工作流长度检查。这可以告知对话，当非退出字的数量或非退出字的长度等于该标志时，应该返回值并处理结果，而不必说出非退出字。在语音系统中，当用户说出等于长度检查的字符的数量时，提示可以停止接受输入并处理已输入的那些。如果提示也具有一个或多个退出字，则用户可以说出退出字以便在预期数量的字符已经输入之前强迫进行处理。在层级4工作流中，可以指定在特定提示处期望或要求来自用户的数字字符(数位或字母)。此外，提示可能具有退出字。在rf系统中，可以处理提示具有长度检查的所有情况，例如，当提示仅具有长度检查时，或者当提示具有长度检查和退出字时。在仅存在长度检查的情况下，rf系统可以将在数据输入字段中允许的最大数量的非退出字设置为长度检查值。由于每个单个的字符可能不像在语音中完成的那样通过工作流来处理，所以用户可能需要一种用来告知系统来处理的方式。因此，即使不存在退出字，gui也可以将“准备好”按钮添加作为用户可以按下以提交数据的第一按钮。如果还没有输入预期数量的字符，则gui可以保持“准备好”按钮禁用，或者在继续之前显示用户必须输入<lengthcheck>字符的警告。一旦用户已输入了所需数量的字符并按下‘准备好’，就可以与作为非退出字而输入并且没有退出字的数据一起发送消息。工作流可以知道长度检查是预期的，所以它可以检查非退出字的长度，并且如果其与预期的长度匹配，则它可以处理该消息。在存在长度检查和退出字的情况下，rf系统仍可以将在数据输入字段中允许的最大数量的字符设置为长度检查值。它还可以为所有的退出字提供按钮。如果不存在‘准备好’按钮，则可以添加‘准备好’按钮。如果用户按下有效的退出字，则可以与该退出字以及到目前为止输入的数据一起提交消息，即使存在比预期长度更少的字符作为非退出字。如果按下‘准备好’并且在退出字的列表中可能不存在‘准备好’，则系统应该检查输入的数据的长度，并且如果还没有达到预期长度则警告用户，并且一旦达到正确的长度就允许用户继续。如果用户已选择了有效的退出字(‘准备好’或没有)，则工作流可以首先检查所输入的数据的长度是否与预期长度匹配或超过预期长度，并且如果是这种情况则就像不存在退出字那样来处理它。为了使rf系统知道存在长度检查，层级3工作流代码可以在vpdisplaytext消息中将信息传递给它。为此，lengthcheck＝<lengthexpected>；当存在长度检查时，可以将要素添加到vpdisplaytextmsgrule字段。当工作流接收到响应时，它会根据内容对其进行不同的处理。例如，如果响应是扫描，则可以按原样来处理非退出字，并且可以忽略长度检查。如果响应不具有退出字，则可以检查非退出字的正确长度并且如果它是正确的则对其进行处理。如果它太短，则可以拒绝响应并且将重新发送最后的提示。如果它太长，则可以将响应截取为正确长度。如果响应具有退出字，则可以不检查长度并且可以处理该消息。在rf侧上，工作流可以能够解析vpdisplaytext消息并处理上述不同的场景。为了设置最大字段长度，可以将新的输入过滤器添加到edittext字段。可以将用于添加“准备好”按钮的代码添加到现有的退出字代码。工作流还可以利用图像来提示用户。例如，在任何给定的提示上，可以包括要向用户显示的图像的位置。该位置可以由层级4工作流来确定，并且可以是产品图像，或者可以完全是别的东西。目前，系统可以支持使用url来用于显示图像的位置。当设备接收到图像位置时，设备可以下载并显示图像。以下是如何指定图像位置的一个示例。来自工作流的所有提示都可以引起vpdisplaytext消息，该消息可以被递送到层级2(vpack或其他合适的操作系统或平台)。为了显示图像，msgdata字段可以被用来发送位置载荷(payload)。该字段可以被格式化为jsonobject，并且消息中的其他字段可以被视为平字符串(flatstring)。下面示出诸如针对和vpack的示例消息。然而，各种设备和/或设备操作系统可能不使用这样的消息，并且可能具有用于显示图像的ui。为imagelocation发送空值可以引起在和vpack二者上的ui表现得好像没有指定图像那样。发送用于字段的无效值可以引起ui尝试检索并且以错误消息而失败。在工作流中，可以通过使用令牌来处理翻译。令牌可以是字符串，其被用作在各种语言中找到翻译的密钥。按照惯例，自然语言英语字符串可以被用作工作流中的令牌。如果不存在可用的翻译，则默认可以是英语令牌。一种典型的方法可以是在单独的文件中为其中出现令牌的工作流定义令牌。按照惯例，该文件可以被称为tokens.py并且包括令牌常量的列表，比如下面的示例表明：这是示出一些可用选项的典型示例。首先，令牌字符串本身可以具有替代引数‘{0}’，当翻译令牌时，可以用一些变量来替换该替代引数‘{0}’。其次，aispriority标志可以被设置为false。这意味着使用该令牌的提示在tts已完成说出它之前可能被后续提示中断。另一方面，如果标志为true，则整个提示必须在可以说出别的任何东西之前完成。最后，该提示可以具有附加的帮助消息，如果用户输入‘帮助(help)’，则该附加的帮助消息可以被显示/说出。下面是在具有aparts引数设置的情况下在提示中使用令牌的一个示例。该片段(part)可以被用来对替代引数进行替换。使用令牌实际的翻译可以从用于每个工作流的messages.txt文件中提取，其可以使用实际的工作流代码和文件来构建。该文件最初可以由语法实用程序产生，并且被放在用于层级4工作流的资源目录中。该实用程序可以找到所有的令牌，并将它们置于针对显示(gui)和语音(tts)二者的每个平台的适当格式。为了添加翻译，可以编辑和登记翻译文件。工作流可以被设计为使用被称为“令牌化”的那些来支持多种“口头”语言。令牌是字符串，其被用作用以找出可以被呈现给用户的字符串的密钥。在主工作流(例如工作流)中，默认可以使令牌为自然英语字符串，以便如果没有找到翻译则可以将其用作默认呈现。可以通过语法实用程序来从层级4工作流中提取令牌。令牌及其翻译可以在文件<workflow>_messages.txt中在用于它们所属的工作流的的资源目录中找到。最初可以通过在层级4工作流上运行语法实用程序来创建messages.txt，这可以确保可以选择创建messages.txt文件的选项。语法实用程序可以解析主代码，例如代码，并搜索由短语‘cltranslator.token’所创建的cltokens，该短语‘cltranslator.token’用来构建workflowgrammarutility_translations.txt和<workflow>_messages.txt文件。该文件可以在工作流之后被命名，例如enginetester_messages.txt。可以在所选的目录、例如$dc_home/apps/workflow/bin目录中找到语法实用程序。在下面的示例中，要求该实用程序创建消息文件并添加针对平台vocollect、vpack(包括windows以及可能地其他操作软件)和的行。在与工作流语法实用程序相同的目录中，可以提供workflowgrammarutility_translations.txt，其可以具有针对该实用程序已经在工作流中找到的每个唯一令牌的行。每行包含英语令牌，它可以被用作默认的英语翻译，然后是用‘|’字符分开的任何其他所需的令牌。该文件的第一行列出所支持的语言，按照它们可能在每行上出现的顺序，用‘|’字符分开。在下面的示例中，请注意可以不翻译<spell>和</spell>。这些可以是由工作流使用以指定特殊处理的特殊标签。括号可以是替代字符，可以在运行时用变量来替换它。在这种情况下，无论括号被替换成什么，都可以按字符地拼写出来，而不是将它视为一个或多个完整的字。下面更详细地讨论标签和替代。翻译可以被手动地添加到translations.txt文件，如在第一行中那样，用‘|’字符来使每个翻译与其他翻译分开。wf_messages.txt文件可以被用来解析令牌。对于每个令牌，该文件包含：·在语法实用程序中为所有可用语言选择的用于所有平台的语言专用tts翻译·在语法实用程序中为所有可用语言选择的用于所有平台的语言专用gui翻译。实际的messages.txt文件可以包含在语法实用程序中选择的用于每种平台类型的消息。选项可以包括vocollect、vpack、android、windows、apple等，它们中的每一个可以使用略有不同的语法来处理每个平台上的asr引擎之间的差异。如果平台支持rf(具有显示器)(对于除了vocollect之外的所有平台可能都是这种情况)，则还可以存在<platformname>gui行。如果workflowgrammarutility_translations.txt文件中指定了多于一种语言，则对于每种语言的每个平台可能都有一行。使用上面的第一行的、在messages.txt的每行中的以逗号分开的字段的示例列表可以包括：·counter-17-定义从1开始并继续经过文件的递增计数器。该计数器被用于调试。·token-enteranewvalue-定义令牌密钥。按照惯例，我们使用自然语言英语作为密钥。·translation-enteranewvalue-定义从文件中解析的令牌翻译，这是将要呈现给用户的内容。·unusedfield-7-这是从vpack的早期版本带来的常量。·platform-vpack-定义平台和对于每行的呈现方法。·language-enu-使用标准3位语言代码来表示语言。在directorit7中看到的更通用的代码中的一些是针对英语的enu、针对西班牙语的spm、针对德语的ger·priority–yes–指示tts是否为优先级提示。no意指提示可能被中断，yes意指提示将被说出到完成。·unusedfield·unusedfield·help-goodbyeprompt.–指示当用户请求帮助时将被说出并显示的帮助文本。在主代码(例如代码)中，令牌可以是在对话请求方法中使用的cltoken对象。对于cltoken对象，下面的字段可以是可用的：·atts-要被说出的文本，是必需的·aispriority-true/false，必须是在开始另一次说出之前说出的整个文本，是必需的。在和vocollect中，asr被禁用，直到已说出所有文本为止。·aparts-对于具有替代值({})的令牌，这些片段将在适当位置处被放置在令牌中，默认为none。·agui-要在设备的屏幕上显示的文本，默认为空，在这种情况下将使用atts·ahelp-当用户在此提示下请求帮助时要显示和说出的文本。在vocollect中，你必须说出‘对话器帮助(talkmanhelp)’，而不仅仅是‘帮助(help)’。语法实用程序可以在创建messages.txt文件时从cltoken字段中提取信息。下面的示例代码片段示出了令牌定义以及使用该令牌的requestwords函数的示例用法：使用令牌使用令牌的另一种方式可以是使用token方法在提示内创建cltoken对象：在提示中创建的令牌对象很多时候，可能存在希望被包括在翻译的令牌中的某些值或字符串，但是它可能仅在运行时已知。引数替代可以包括使用一些标准标记(通常为{})来指定需要将值插入在哪里。当翻译令牌时，可以传递任何引数以插入作为使用aparts参数的列表，如在上面的示例中示出的。标记可以是令牌的一部分。通常期望令牌使用标准主代码(例如代码)、引数替代语法。这可以使用{}字符来指定替代。对于多于一个的替代，可以在你想要替代发生的每个位置处放置一对括号。当替代发生时，可以将片段(part)的列表从头到尾代替括号而插入。为了使片段以某一其他顺序输入，可以通过在括号内放置数字(例如(0)或(1))来将数值位置分配给替代标记。所以，对于令牌–‘thisisthefirstargument{}.hereisthesecond{}’和片段–‘第一个’和‘第二个’-替换后的字符串可能是：‘thisisthefirstargumentfirst.hereisthesecondsecond.’。如果令牌变为：‘thisisthefirstargument{1}.hereisthesecond{0}’，在替换后你可能得到：‘thisisthefirstargumentsecond.hereisthesecondfirst.’。当语法实用程序创建messages.txt时，它可以为令牌提供翻译，从workflowgrammarutility_translations.txt中提取它(如果它是可用的)。在messages.txt文件中，当实用程序创建每一行时，它可以将替代标记翻译为该行所针对的平台所预期的格式。目前，大多数平台(包括所有gui值)可以使用与主代码相同的语法(例如语法)，如在令牌中所预期的。例外可以是vpack，它用％r％替换{}并且不是从0而是从1开始其编号。在某些情况下，可能希望tts以与显示器不同的方式来处理令牌的片段。对于这些情况，可以使用与html标签类似的标签来指定应以不同方式处理消息的哪些片段以及区别是什么。标签可以被用于messages.txt文件中的tts行，而不用于gui行。例如，可以在令牌中使用以下标签：·<spell>#</spell>-告诉tts引擎以用户所选的语言逐字母地拼写替换字符串·<phonetic>#</phonetic>-告诉tts引擎以用户所选语言按语音字母(phoneticletter)拼写替换字符串。例如，在英语中，a将被说成为阿尔法(alpha)，b将被说成为贝塔(beta)等·<pause_ms>300</pause_ms>-告诉tts引擎暂停指定的毫秒数在创建翻译时，诸如vpack的一些平台可以针对标签使用不同格式，如下所示：tts标签图3a示出了从用户的角度出发会话可以如何，而图3b示出了会话可以从vpack平台上的计算机消息发送角度出发。其他平台或操作系统可以具有类似的流程。可以通过使用令牌来找到翻译，该令牌可以是至包含实际翻译的映射的密钥的一部分。可以在层级4代码中找到令牌，以作为通过使用cltranslator.token方法创建的cltoken对象。当语法实用程序运行时，它可以将英语翻译默认给令牌，但它可能会向翻译添加需要作出的任何变化，以适应对于替代和标签来说特定平台期望什么。为了改变令牌的英文版本，可以改变主代码(例如代码)内部的令牌，然后还可以改变语法实用程序。要将使令牌成为其他语言的任何翻译添加到workflowgrammarutility_translations.txt文件。在添加它们之后，可以重新运行语法实用程序以创建包括新翻译的新消息文件。当工作流实际运行并且在对话中遇到令牌时，对话可以首先通过使用下面三个密钥在消息文件中查找令牌来翻译令牌：实际令牌、工作流运行所在的平台(vpack或或其他合适的平台或操作系统)和当前语言(enu、spm等)。在找到翻译后的文本之后，可以用实际值或空字符串(如果没有值被传入)来对替代标签进行替换。然后可以将已翻译并完成替代的最终字符串传递至要被显示或说出的设备。如果在tts和显示器二者都可用的平台(和vpack)上，则tts和gui令牌二者可以被翻译并传递给设备。在层级4代码中，语法实用程序通常可以找到使用cltranslator.token方法创建的令牌。别的任何东西可能不是可翻译的。下面包括一些适当级别语法的示例。这是请求方法的一个示例，该请求方法具有在其内创建的多个令牌。这些令牌中的每一个将在messages.txt文件中结束。这里是具有多个令牌的另一示例。这次它们是在请求之外定义的。使用上面的请求方法可以引起在<workflowname>_messages.txt文件中生成下面的行。解析器可以是相当高级的并且可以检测和处理各种编码风格，例如：解析器可以例如就最后的“)”来搜索特定方面或特征，以标记语句的结尾。结尾“)”是没有被包含在引号内的最后的“)”。该引号可以是单引号或双引号，但通常应该匹配。接下来，解析器可以识别各种输入参数，在一个实施例中它可以包括：·atts·aparts·agui解析器可以处理各种字符和/或值，诸如字符串内的“(”、“)”、“＝”和逗号，或其组合。如果translate.token包含这样的语句，该语句包含在没有单引号或双引号的情况下设置的引数，则解析器可以在编译期间发出警告。这可能意味着语言值是通过变量设置的并且这可能是一个问题。为了禁用警告，引数可以成为被称为asuppresswarnings＝true的token方法。这是一个示例：另外，利用本公开的实施例，消息可以被用来与外部系统来回通信，并且例如可以支持execution或mdhost、以及md和网络服务消息。可以在上述配置下涵盖设置外部md或http连接。在两种情况下，消息可以是从特定类别(例如clmemorydefinitionbase类别)得到的。下面是被用来与restful网络服务通信的消息类别的一个示例：md消息可以在没有响应的情况下使用例如sendmessage来发送消息；然而，如果需要响应，则可以使用sendrequest。最后，如果要保证消息(这意指接收到返回确认)，则可以包括aid＝'specificid'作为sendrequest的参数。sendrequest消息如上面所提到的，退出字可以是对话请求中的发信号通知工作流要做某事的一个或多个字的列表，通常是处理输入的任何数据并继续进行到工作流中的下一步骤。全局和工作流字可以是对于工作流中的大多数提示或所有提示可用的退出字。这些可以被用于跨工作流提供通用功能。例如，用户可能希望能够从任何对话提示退出工作流。使用全局字、例如“退出工作流(exitworkflow)”可以提供该功能，而无需在每个对话请求中明确处理它。如在下面的示例中所示的，可以将退出工作流添加到全局字的列表，并且可以将两个函数附加到其上。为了使执行函数被执行，可能需要验证函数gblvalidateexitworkflow返回true。在这里，验证函数可以仅仅是返回false的存根例程(stubroutine)。如果不存在验证功能，则它可以被假定为true。每当将“退出工作流”发送到工作流并且验证函数返回true时，执行函数gblexecuteexitworkflow可以被执行。系统全局字可以是层级3代码(例如层级)的一部分，并且提供在vpack和语音工匠(voiceartisan)中可用的相同系统菜单功能。工作流全局和工作流字可以给予层级4编程者用来设置在任何提示下可用的退出字的能力，而无需在每个提示中明确列出它们。相反，可以将字添加到特殊列表中，并且可以将用于它们的语法部分附加到所有的请求。当输入这些字中的一个时，它可以触发附加到其上的功能，这可以允许工作流具有特殊功能，比如在任何地方立即退出当前工作流。可以存在各种类型的字定义。例如，可以存在五种类型的字定义：系统全局字、工作流全局字、工作流字、退出本地字和非退出本地字。在不脱离本公开的情况下，可以存在更多或更少的字定义。系统全局字可以包括由层级2软件定义的字，并且可以通过“系统(system)”选项(即“系统说话大声一点(systemtalklouder)”)来使得由层级2可用。对于vpack和语音工匠来说，可以由各种软件包/系统(诸如软件和/或其他)依据应用程序和/或设备而在层级3代码(例如，代码/软件)之外处理系统全局字。对于设备，可以在层级3软件中处理系统字。它们被定义在文件dit_workflow/src/_platforms/android/util/system_menu.py中。例如，对于可以通过字符串system_words.add(来识别这些字。工作流全局字可以包括为层级4工作流定义的字。可以为位于层级4工作流目录中的文件workflowglobalwords.py中的每个层级4工作流定义这些字。层级3中的对话功能可以将该语法区段添加到要由层级2启用的语法区段的列表。工作流字可以由特定工作流类别来定义。可以在指定的函数中定义这些字，该函数可以被称为“addworkflowwords()”。层级3中的对话功能可以将该语法区段添加到要由层级2启用的语法区段的列表。例如，可以用字符串awords.add(来识别工作流字。本地(退出和非退出)字可以包括在提示处添加的字并且包括退出和非退出字。可以通过请求函数来添加本地字，并且可以例如用requestx方法来识别本地字·asr_alias.asr-是密钥/值的值，其被用来为特定的字定义别名。例如，如果我们想要使短语“加油(gogogo)”与“准备好”相同，那么将“加油”添加到该文件中。·asr_remove.asr-是密钥字段，它被用来从词汇表中删除任何字。利用本公开的实施例，可以定义系统、全局或工作流字。可以将所有的工作流字放入特殊的容纳器(container)中，并且工作流字的每个种类可以具有其自己的容纳器。系统全局字可以在指定的容纳器中，全局工作流字可以在另一个指定的容纳器中，而工作流字可以在又另一个指定的容纳器中，其中它可以由每个工作流来继承。如在下面的示例中所示的，可以使用示例的添加方法将字添加到其容纳器中：添加全局工作流字该添加方法可以具有下面列出的参数：·aword-要被添加到容纳器中的字，该字段是必需的。在示例中，这被设置为‘退出游戏(exitgame)’。·aexecutefunc–当输入该字时执行的函数。该字段是必需的。·avalidatefunc–当输入该字时检查的验证函数。该字段是可选的并且默认为none。·askipprompt-true/false，当我们从该函数返回时告诉对话是否应该重复最后一个提示。该字段是可选的并且默认为false。·averify-true/false，告诉对话我们是否应该要求用户验证他们想要运行针对该字的逻辑。该字段是可选的并且默认为false。·aecho-true/false，告诉对话是否回应退出字。该字段是可选的并且默认为false。·aenabled-true/false(上面未显示)，告诉对话这个字是否有效。如果没有，则它将被忽略。该字段是可选的并且默认为false。为了在中定义系统全局字，例如，可以在层级3工作流中处理系统全局字。可以在文件dit_workflow/_platforms/android/util/system_menu.py中定义可用的系统全局字，连同与它们相关联的验证和执行函数。它们可以被添加到函数addglobalsystemwords()中，该函数可以在工作流应用程序起动之前被自动调用。可能不建议对系统全局字进行任何改变，因为在层级3和层级2代码中存在依赖于它们的其他位置。为了定义工作流全局字，例如，任何给定的工作流应用程序可以具有被称为“workflowglobalwords.py”的模块和在该模块中被称为“addworkflowglobalwords”的函数。在工作流应用程序被起动之前，可以自动调用该函数。层级4编程者可以负责工作流全局字。为了定义工作流字，例如，任何给定的工作流类别可以具有被称为“addworkflowwords”的函数，其可以覆盖clworkflowbase中的存根(stub)方法。在用于你的工作流对象的__init__被调用之前，可以自动调用该函数。还可以定义本地工作流字，并且该本地工作流字包括在requestx函数中传递的那些。这些可以包括anonexitwords和aexitwords。下面示出显示工作流字和本地字的示例。添加工作流字当说出工作流字时，可以中断当前提示的执行并将其传递给附加到该字的验证函数(如果有的话)。如果验证函数返回true，则可以将控制传递给执行函数。执行函数可以根据需要而简单或复杂，并且可以包含对话、对外部系统的调用、或任何其他有用的条目。当执行函数完成时，它可以将控制返回到最初调用它的对话。图4b示出了用于‘退出游戏’的控制的流程，其中l3是层级3，l4是层级4，并且md是消息分发器。在一些情况下，可能不允许用户使用某些分类的工作流字。例如，这可以在验证提示上自动完成，当用户输入具有‘v’标志的退出字时，该验证提示可以开始。可以单独地或按组地(系统全局、全局工作流或工作流)来将字禁用。为了禁用或启用单个字，可以使用clwordscontainer类别的禁用和启用方法。它们采用一个引数，即你想要改变其状态的字。如果1是有效的，则被禁用的字可以仍是被发送给asr引擎的语法部分的一部分，但是当它被接收到时它将被工作流忽略。使单个字禁用为了使针对特定提示的工作流字的分类禁用，可以在对话函数中设置可用标志中的一个。对于系统全局字，标志可以是adisablesystemwords；对于工作流全局，标志可以是adisableglobalwords；并且对于工作流，标志可以是disableworkflowwords。使字分类禁用语法部分可以被用来告知asr引擎此时在工作流中要监听哪些字。当工作流使用标准的“请求”方法中的一个(诸如“requestdigits”)来执行来自用户的请求时，该请求可以包括语法部分。该语法部分可以是涉及可以由用户说出的一组字的密钥。在工作流中，语法部分可以由解析器基于主代码(例如，脚本)和上述文件动态地生成。每次调用requestx方法时可以启用三个语法部分，包括本地字、全局字和工作流字。本地字可以使用两种形式用于语法部分。第一种可以是默认形式并且由<pythonclass>_<functionname>组成。当requestx方法通过输入参数来定义语法部分时，可以使用第二种形式，并且该第二种形式包括：<pythonclass>_<functionname>_<grammarname>。当在一个状态(函数)中实现两个requestx方法时，可以使用第二种形式。利用本公开的实施例，可以从一系列状态来构建工作流。状态可以是用于用户浏览某个特定任务的方式，每个状态代表该特定任务的要素，并且当用户浏览工作流时，当前状态可以基于用户提供的输入来决定下一步发送给用户哪个状态。例如，层级4工作流通常可以具有欢迎或初始状态，例如工作流开始的stwelcome状态。从stwelcome状态或任何其他状态开始，可以使用所选的方法(例如setnextstate和setrepeatstate)来浏览工作流。下面示出一个简短的示例：工作流状态示例在该示例中，可以存在多个状态(例如两个、三个或更多个状态)、stwelcome(其可能是必需的)、以及stready。stwelcome状态具有可选的引数aarg。状态可以使用下面两种方法来在彼此之间浏览：setrepeatstate(其可以自动返回到当前状态)和setnextstate(其可以转到命名状态)。所有的工作流类别可以从clworkflowbase或从另一个工作流类别导出。该基本类别可以被设计为充当状态机，该状态机是可以处于许多种状态中的一种的抽象机器。当用户浏览工作流时，可以基于用户的输入将控制从一个状态传递到另一个状态。在工作流中，状态可以被表示为方法。按照惯例，状态方法可以以‘st’开头，以便将它们与工作流中的其他方法区分开。每个工作流可以具有stwelcome状态，因为这是用于工作流的默认起点。状态通常可以具有类似的结构。首先，它们可以要求用户提供一些输入。然后，基于该输入，它们可以进行一些处理(向外部系统发送消息，回应输入，进行一些计算等)并且基于结果来将用户发送到下一状态。该下一状态可以是当前状态。为了处理从状态移动到状态的机制，clworkflowbase类别可以具有许多方法，下面列出了它们的示例。clworkflowbase状态方法οsetnextstate-被用来将工作流发送到另一个状态，具有一个引数，astate(这是下一个状态方法的名称)。如果未设置astate，则默认为none，并退出工作流。οsetrepeatstate-被用来将工作流发送回当前状态的开头，不具有必需的引数οgetpreviousstate-返回对先前状态的引用οgetcurrentstate-返回对当前正在执行的状态的引用οgetnextstate-返回对设置为要执行的下一状态(如果有的话)的状态的引用οispreviousstate-具有一个必需的引数，astate，它检查先前状态引用以查看它们是否相同οiscurrentstate-具有一个必需的引数，astate，它检查当前状态引用以查看它们是否相同οisnextstate-具有一个必需的引数，astate，它检查下一个状态引用以查看它们是否相同状态示例从工作流api得到的上面的示例演示了setrepeatstate和setnextstate的用法。如果setnextstate没有引数，则状态默认为none，这将引起工作流结束。在一个示例性实施例中，有可能具有嵌套的工作流，例如，从另一个工作流内部起动工作流，或者起动在工作流内的工作流内部的工作流、等等。举例来说，当用户退出子工作流时，他们可以返回到下一个以使堆栈向上。在某些情况下，工作流设计人员可能想要进一步使堆栈向上移动，并且使用各种方法来进行帮助。示例性方法包括：clworkflowbase工作流方法·find-需要一个引数(即你正在寻找的工作流名称)，返回对工作流的引用，如果它位于当前工作流堆栈中的话·getcurrentworkflow-不采用引数，返回对当前正执行的工作流的引用·getrootworkflow-不采用引数，返回对在堆栈的顶部处的工作流的引用·replacewith-被用来将链接到类别名称的工作流类别引用以链接到同一名称的不同类别引用来替换clworkflowbase例外方法·raisereturnto-需要工作流名称，aworkflowstate是可选的并且默认为stwelcome。此方法将返回状态和被命名的工作流的执行·raiseendworkflow-引起例外的方法，该异常将导致工作流退出并返回其父工作流(如果有的话)，或者如果不存在父工作流则停止执行构建到clworkflowbase中的可以是几种方法，其可以使得更容易接入api的其他部分，比如用消息传送或日志记录。下面将描述这些。消息传送示例：·sendmessage(self,argsaadaptername＝none,*kwargs)-被用来使用以aadaptername参数命名的适配器来发送消息的包装器(wrapper)，args是传递给通用适配器的sendmessage函数的引数的列表·sendrequest(self,argsaadaptername＝none,*kwargs)-被用来使用以aadaptername参数命名的适配器来发送请求消息的包装器，args是传递给通用适配器的sendrequest函数的引数的列表。日志记录功能可以向日志记录器发送消息。如果日志记录级别被设置为等于或高于日志记录功能级别，则可以处理该消息。fatal是最低的日志记录级别，trace是最高的。·logtrace·logdebug·loginfo·logwarn·logerror·logfatal工作流还可以是可定制的。例如，可以对现有的工作流或子工作流进行子分类，以便为新的工作流所需的方法提供自定义，而不是创建全新的工作流。为了在不改变其他源文件中的引用的情况下使用新工作流而不是原始工作流，可以使用replacewith方法。该replacewith方法可以将一个类别引用变为另一个。全局高速缓存可以是方便的存储器结构，其可以在层级4工作流中的任何地方被引用，并且被用来跨主代码/程序模块(例如，模块)存储信息。为了使用全局高速缓存，可以将全局高速缓存输入主代码/程序模块(例如，模块)中，并被用作映射(global[key]＝value)。例如，global[key]本身可以检索该值。全局高速缓存的示例可以包括：全局高速缓存各种主要代码，例如还可以使用测试工具，例如在windows上的环境中工作的工具，可以被用来测试层级4工作流，而不必将工作流放在特定设备上。虽然该方法可能存在一些限制(例如执行用于任何平台的代码可能很困难或不可能)，但win_ce，它在查找层级工作流中的错误方面非常有效。在基本工作流类别clworkflowbase中，可以存在被用来在各种日志记录级别发送日志记录消息的一组日志记录函数。这些功能可以在工作流中的任何位置使用，并且每个功能可以处理不同的日志记录级别。例如，如果在workflow.ini中配置了lms，则可以将日志记录发送到lms服务器。日志函数可能需要一个引数、消息。下面列出示例函数：1.logtrace2.logdebug3.loginfo4.logwarn5.logerror6.logfatal被发送的特定日志记录语句可以取决于在workflow.ini中设置的所选的日志记录级别。在上面的列表中，例如，按从最具包括性到最不具包括性的日志记录级别的顺序来列出函数。因此，如果日志记录级别被设置为fatal，则将仅处理logfatal日志记录语句，而如果级别被设置为trace，则将处理所有的日志记录语句。示例的工作流操作/任务性能。在图5-图6中示出了在设施100中的使用过程中通信系统2的操作的示例实施例，该设施100诸如是订单履行设施或用于履行从在线零售商处购买的一个或多个物品或商品(item)a的订单的仓库。通常，各种物品a可以位于(一个或多个)存储区域/位置102或被存储在(一个或多个)存储区域/位置102中，并且当创建要求一个或多个所选物品a的订单时(例如(一个或多个)在线客户下订单)，可以将所选的物品或商品a从它们的(一个或多个)存储区域102转移到一系列拣选站104中的一个，在那里物品a可以被分类/拣选并放置在特定位置中/放置于特定位置处(例如放置在(一个或多个)箱子(bin)中)，以用于转移到包装或运送位置106，在那里可以将物品包装并运送给(一个或多个)客户。为了执行这样的工作流操作或任务，业务/设施操作工作流14(图1)通常可以设计有一个或多个任务列表或子工作流，其包含用于执行订单履行的总体任务的指令和/或过程(其可以根据工厂的/客户的偏好或其他参数而被特殊化)。这些步骤或指令可能需要各种不同的自动监视、拣选和传送系统或设备的使用和/或协作。例如，可以利用穿梭车(shuttle)116(诸如由德马泰克公司提供的)来将所选物品或一系列物品a从其存储位置102移除和收集，然后将物品转移到一个或多个传送器108以用于按线路传送到拣选站104，在该拣选站104处人员或自动拣选器112可以利用一个或多个自动系统或手持或移动设备114，诸如具有显示器120、相机122的平板电脑118、手持扫描仪诸如ir或条码扫描仪124、或用来检测和确认已经接收到(一个或多个)正确物品的其他设备。拣货员可以拣选分配给该拣选站的每个订单的履行所需的每个物品或一系列物品，并将其放置到箱子或其他运输工具中，在这之后可以将箱子运送到包装站106以便将订单包装并运送给客户。使用根据本公开的通信系统2，这些各种外围设备的通信、集成和操作以基本上无缝的方式执行这样的订单履行工作流(或者分配给每个设备/需要每个设备的每个子工作流/任务)。在一个实施例中，可以组织并分配一系列订单以由设施的所选站点、区域或单元通过工作流来实现/完成。可选地，可以发布由工作流创建的订单组或订单集以供下一个可用的单元、区域或设备来拾取。例如，穿梭车110的引擎可以向服务器或驻留有设施工作流的其他存储介质传送或发送查询，从而指示该穿梭车或设备可以自由地接受下一个订单，并且作为响应，工作流可以为穿梭车分配订单集或订单组，每个订单具有要为履行订单而收集的物品或商品列表。在接收到该分配时，穿梭车的界面引擎还可以向设施服务器发送查询，并且请求和接收由工作流提供的、订单列表上的物品或商品中的每一个的库存位置特定信息。此后，穿梭车可以执行其分配任务，将用于履行所分配订单的物品中的每一个从它们的特定库存存储位置收集，以及将所收集的物品传送到分类传送器，或者直接传送到拣选站。一旦其任务完成，穿梭车的引擎就可以报告回服务器/工作流，以确认如下事项的完成：收集其列表上的订单的商品的其分配任务已经完成并且递送给指定的拣选站。此后，工作流可以向所识别的拣选站发送查询，包括用于人员或自动拣选器根据需要对商品进行分类和拣选以完成订单的指令。工作流指令可以被发送给工作人员所携带的平板电脑或膝上型电脑，或者发送给较小的设备(诸如移动电话)，或发送给安装在拣选站处的监视器。每个特定外围设备(无论它是膝上型电脑、平板电脑、监视器等)的通信系统引擎将接收所分配的任务或订单列表，并将指导或指示其相关设备执行用于履行每个订单所需的任务，包括识别每个订单所需的特定物品或商品(即，通过扫描仪或照相机)，并通知拣选器拣选哪个物品以及将它们放置在哪里(例如，通过他们的电话、平板电脑等上的通知)。一旦工人或拣选站完成了将物品拣选和分类到用于包装和运送的箱子或包裹中、以用于履行在工作流中分配给其的客户订单中的每一个客户订单的步骤，用于拣选站的引擎或在工作人员的平板电脑或其他移动设备上的引擎可以响应于工作人员对每个订单的每个所选商品的扫描和/或他们对每个订单的履行的确认，将响应发送回工作流服务器，从而指示所分配的订单列表中的订单中的每一个已经完成。此后，当包含每个完成的订单的箱子或包裹被传送到运送站时，其他设备(诸如扫描仪、相机或光学字符读取器)可以监视进度，并且它们的引擎中的每一个可以向运送来报告此类订单箱子或包裹的进度(通过与工作流平台语言兼容的消息)，以及发送订单已运送的最终确认，包括向设施服务器提供消息，所述设施服务器链接或识别每个订单，该每个订单随其特定id或跟踪号而运送。在另外的实施例中，设施100可以包括拣选站、装载站、或具有一个或多个放置壁(put-wall)或拣选壁(pick-wall)系统或组件130(如图7中大体所示的)的其他站104。拣选/放置壁组件130可以包括例如框架/结构132，其具有多个壁、阻挡件(barrier)和/或搁架单元134，所述多个壁、阻挡件和/或搁架单元134至少部分地限定了多个分区区域或位置136，其可以被确定尺寸、被确定维度、或被配置成容置一个或多个物品a。拣选器可以将物品a放入分区区域136中，并且在将规定物品a(例如履行特定订单的物品)放入特定区域136中之后，可以从这些分区区域中取出这些物品以便利于订单的订单履行。放置/拣选壁组件130的操作和功能可以通过如下的一个或多个放置/拣选壁工作流来控制：所述一个或多个放置/拣选壁工作流与在cpu或服务器(诸如台式计算机或服务器150)上运行、或以其他方式被cpu或服务器(诸如台式计算机或服务器150)接入的一个或多个工作流引擎通信，以及/或者与在移动设备114或扫描仪142上运行、或被该移动设备114或扫描仪142接入的工作流引擎通信，该移动设备114或扫描仪142与放置/拣选壁系统130通信。台式机/服务器150使用预定的/所选的操作系统(诸如，例如基于或的操作系统)，虽然在不脱离本公开的情况下任何合适的操作系统或平台是可能的。在不脱离本公开的情况下，移动设备114或扫描仪142可以使用彼此不同的操作系统和/或台式机的操作系统(例如基于或的操作系统或其他合适的操作系统)。(一个或多个)放置/拣选壁工作流可以是设备中立的，并且包含用于执行拣选/放置壁系统130的功能或操作/在拣选/放置壁系统130处的功能或操作的业务逻辑或指令。因此，引擎可以允许台式计算机150、移动设备114和扫描仪142接入(一个或多个)放置/拣选工作流的逻辑或指令、与该逻辑或指令通信、以及/或者运行/执行该逻辑或指令，即使这些设备使用不同的操作系统。例如，如图7中所示，可以使用一个或多个传送器138在箱子或容器140中将物品a运输到放置/拣选壁组件130以及从该放置/拣选壁组件130运输物品a。然而，在不脱离本公开的情况下，还可以使用其他装置(诸如由德马泰克公司提供的)将物品a运输到放置/拣选壁组件130以及从该放置/拣选壁组件130运输物品a。每个物品a可以与特定的库存标识符(诸如存货保持单元(“sku”))相关联，并且每个物品a可以承载与每个物品a的特定标识符相关联的光学码，诸如条形码、射频识别(“rfid”)标签、或者qr码。拣选器可以从箱子或容器140移除物品a，并例如使用移动设备的相机122或扫描仪124来扫描每个物品a上的光学码。使用本公开的引擎，放置/拣选壁工作流可以控制或接入扫描仪124或移动设备114的相机122，并且还可以接入由此读取的特定光学码，并且放置/拣选壁工作流还可以指示或以其他方式控制扫描仪124或移动设备114，以将与被扫描商品a相关联且识别该被扫描商品a的所读取/接收的光学码发送到台式机/服务器150、或以其他方式传送给台式机/服务器150。在接收到识别该被扫描物品a的光学码时，拣选/放置壁工作流可以指示或以其他方式控制台式机/服务器150与放置壁系统130通信，以执行可以指示或以其他方式通知拣选器特定区域或位置136来放置被扫描物品a的功能。这可以使用按灯拣选(pick-to-light)原则来完成。例如，用于容置物品a的每个区域或位置136可以包括光源142(诸如(一个或多个)led或其他合适的光源)，并且当台式机150接收到由扫描仪124或者移动设备114的相机122读取/接收的光学码时，放置/拣选壁工作流可以使台式机150与放置/拣选壁系统130通信、或以其他方式控制放置/拣选壁系统130，以激活/点亮光源142中的至少一个，以由此指示或通知拣选器将要放置被扫描物品a的特定位置或区域136。图7示出了(一个或多个)光源可以沿结构132的外表面布置，所述光源基本上相邻于与其相关的特定区域/位置136，然而，(一个或多个)光源可以至少部分地定位在其对应的位置或区域136内，以使得该区域基本上发光以便向拣选器指示在何处激活或以其他方式放置(一个或多个)被扫描物品a。在(一个或多个)被扫描物品a的放置之后，拣选器可以激活沿着框架132布置的触摸屏146上显示的图标或一个或多个按钮144，以便向放置/拣选壁工作流指示拣选器已将特定物品a放入规定的位置136。然后，放置/拣选壁工作流可以允许扫描仪124或移动电话的相机122读取另一物品a上的光学码并重复上述过程。当工作流确定某些物品a(例如针对特定订单的当前可用物品a、或针对特定订单的物品中的每一个)已经被容置在一个或多个规定的位置/区域136中时，放置/拣选壁工作流可以通过引擎来指示或以其他方式控制台式机150与放置/拣选壁系统130通信、或以其他方式控制放置/拣选壁系统130，以点亮对应于该位置136的光源144。此后，提取器(puller)、拣选器或另一拣选器可以将这些物品a放在一个或多个箱子140中，以便运输到(一个或多个)包装或运输位置106以履行订单。在一个示例中，将物品放置到区域136中的(一个或多个)拣选器和将物品从区域136中取出的(一个或多个)提取器，可以被定位在/位于放置/拣选壁结构132的相对置侧上。由于(一个或多个)放置/拣选壁工作流可以是设备中立的，所以移动设备114、扫描仪124或其他设备可以被替换或可互换地使用，以使用它们的相应引擎来接入(一个或多个)放置/拣选壁工作流或与该(一个或多个)放置/拣选壁工作流通信，并且因此放置/拣选壁系统130的各种操作和功能、或者在放置/拣选壁系统130处执行的各种操作和功能，可以由台式机150、移动设备114、扫描仪124或其他合适的设备中的任何一个来控制，即使这样的设备可以使用不同的操作系统。例如，放置/拣选壁工作流可以被移动设备114的引擎接入，以允许用户使用移动设备114来控制放置/拣选壁系统130的操作和功能，以使得在扫描与物品a相关联的光学码中的每一个时点亮光源144，或者当拣选器激活按钮144或触摸屏146时重置扫描仪或移动设备的扫描功能。因此，可以在不同平台或操作系统上操作的各种设备能够可互换地实施，以执行(一个或多个)放置/拣选壁工作流的各个方面，以便控制或执行在拣选/放置壁组件130处的各种功能/操作。因此，利用根据本公开的原理的通信系统2，设施工作流可以被简单地定义成针对设施操作(诸如履行订单，包括按逐个订单)提供稍微标准化的设备中立的指令或过程。而用于每个不同外围设备的通信系统引擎可以被配置成操作用来通过它们的相关外围设备中的每一个来收集和解释用于其执行的工作流任务指令。因此，除了与自动化系统(比如dematic等等)一起工作之外，工作人员还可以使用不同类型的平板电脑、移动电话、扫描仪或其他外围设备来执行由工作流分配的、或从工作流检索的每个任务步骤或过程。工作流需要关注的一切是提供用于履行一系列订单的它的请求(其也可以包括所需的或规定的过程)，并且一旦已分配或接受了任务或子工作流操作(即，通过设施中的一系列设备、站点、或区域)，通信系统2内所包括的或链接的外围设备中的每一个外围设备的引擎可以独立地操作以完成任务，设施工作流可以简单地接收对所分配的任务的完成的确认，而无需主动控制每个单独的或特定外围设备的操作。因此，根据本发明的原理的通信系统使设备中立的或设备独立的工作流能够被设计、创建和编程到设施或服务器或其他存储介质中(即包括存储在云上的数据，以便远程地接入或跨多个设施接入)，以及工作流不必以任何特定编程语言来编程或利用特定的操作平台(诸如apple或)。相反，通信系统的引擎被设计成与通过各种自动化系统和/或手持计算设备来使用或可以被其使用的、多个不同的操作平台或软件/编程语言中的每一个接口，并且解释或翻译和指导它们的关联设备的工作流指令。这使得能够对设施或业务工作流进行改变或修改，而基本上不考虑在设施或工厂中使用的一个或多个编程设备所使用的特定操作平台或编程语言；并且进一步使得客户不仅能够利用不同的设备和技术，而且他们还能够以总体上将更具成本效益的方式来升级其技术设备。例如，工作人员可以利用各种不同的手持设备(诸如平板电脑、笔记本电脑、电话等)中的任何一种，每种手持设备基于偏好或易用性/熟悉程度而利用操作系统(诸如windows、或)，此外，随着诸如扫描仪、相机、条形码读取器、或其他类似设备之类的老式外围设备要么变得过时而不被它们的供应商支持，要么随着新技术变得可用，这些设备可以以总体上更无缝的方式而利用更加新的技术或设备来修改、升级和更换(包括所选的或独立的单元的更换)，因为不必创建新的、专用于设备的工作流，而是简单地需要使可与此类设备操作的引擎按照需要来更新。以上描述一般性地说明和描述了本公开的各种实施例和示例。然而，本领域技术人员将理解，在不脱离如本文中公开的本公开的精神和范围的情况下，可以对上述构造和系统进行各种改变和修改，并且旨在使上面的描述中所包含的或在附图中示出的所有事物应被解释为说明性的，而不应以限制性意义来理解。此外，本公开的范围应被解释为涵盖对以上和上述实施例的各种修改、组合、添加、更改等，其应被视为在本公开的范围内。因此，可以选择性地互换如本文中讨论的各种特征和特性，并将其应用于其他示出的和未示出的实施例，并且可以在不脱离如在所附权利要求中阐述的本发明的精神和范围的情况下进一步进行各种变化、修改和添加。当前第1页12当前第1页12