与家用电器内的至少一个部件通信以及对其进行管理的软件体系系统和方法
阅读：499发布：2022-05-01
专利汇可以提供与家用电器内的至少一个部件通信以及对其进行管理的软件体系系统和方法专利检索，专利查询，专利分析的服务。并且本 发明 涉及实施在电器的内部通信网络上并通过该内部通信网络通信的 软件 体系，该内部通信网络连接电器的各个物理部件。软件体系执行多个功能：识别对应于网络 节点 的每个部件；识别该部件的功能；识别部件的状态；提供格式良好命令 接口 ；提供内部和外部软件部件之间的通信。通过这种方式，SA用于向网络上的所有节点告知其它节点的存在、功能和状态。，下面是与家用电器内的至少一个部件通信以及对其进行管理的软件体系系统和方法专利的具体信息内容。
1.一种系统，包括：
由有用软件动态产生的存储器堆，其中所述存储器堆包括多个事件 结构，每个事件结构包括至少一个指向该事件结构外部的存储器的指 针、至少一个事件运算符和至少一个变量，和
数据获取引擎，被配置为查找存储器堆，基于所述至少一个指针、 至少一个操作符和至少一个变量估计事件条件是真还是假，并在发现真 条件时产生通知消息。
2.根据权利要求1所述的系统，包括与所述存储器堆关联的存储 器，并且所述存储器堆在编译时被分配在相关联的存储器中。
3.根据权利要求2所述的系统，包括在运行时产生事件结构的软件 体系。
4.根据权利要求3所述的系统，其中软件体系产生每个具有唯一标 识的事件结构。
5.根据权利要求3所述的系统，其中软件体系驻留在与相关联的存 储器通信的通信网络上，并且软件体系产生消息并将该消息通过该通信 网络发送到该相关联的存储器以形成事件结构。
6.根据权利要求5所述的系统，其中软件体系包括产生消息的应用 程序接口(API)。
7.根据权利要求6所述的系统，其中通信网络包括多个节点，其中 API驻留在至少一个节点上。
8.根据权利要求7所述的系统，其中通信网络包括到电器的内部通 信网络。
9.根据权利要求8所述的系统，其中节点包括驻留有API的电器的 部件。
10.根据权利要求8所述的系统，其中通信网络包括电器外部的节 点。
11.根据权利要求1所述的系统，其中每个事件结构具有唯一的标 识。
12.根据权利要求10所述的系统，包括：
控制软件，被配置为通过一系列步骤控制装置系统，以执行有用运 行循环，其中该控制软件产生事件结构。
13.根据权利要求12所述的系统，其中通知消息更改控制程序的运 行。
14.根据权利要求1所述的系统，还包括具有多个节点的网络，其中 存储器堆与网络相关联。
15.根据权利要求14所述的系统，其中所述网络包括用于电器的内 部通信网络，并且实现对电器操作的控制。
16.根据权利要求15所述的系统，其中所述网络包括内部通信网络 外部的节点，而且通知消息被发送到该网络上的节点。
17.根据权利要求16所述的系统，其中通知消息在回叫功能中被调 用。
18.根据权利要求14所述的系统，其中存储器堆驻留在一个节点 上，并且数据获取引擎驻留在另一节点上。
19.根据权利要求18所述的系统，其中至少一个节点通过网络发送 配置消息，以在存储器堆中创建事件结构。
20.根据权利要求19所述的系统，其中所述配置消息使得节点能够 在接收到通知消息后发送确认消息。
21.根据权利要求1所述的系统，其中数据获取引擎被配置为使得通 知消息可以被选择性地置于禁用状态或使能状态。
22.根据权利要求21所述的系统，其中在通知消息的状态变化时， 相应的通知消息被发送到网络上。
23.根据权利要求1所述的系统，其中事件运算符包括以下中至少一 个：大于，小于，等于，正在改变，死带，位掩码。
24.根据权利要求1所述的系统，其中数据获取引擎被配置为响应于 至少一个所述事件条件产生通知消息。
25.根据权利要求24所述的系统，其中数据获取引擎被配置为响应 于多个事件条件产生通知消息。
26.根据权利要求1所述的系统，其中数据获取引擎在产生通知消息 之前评估所有事件结构。
27.根据权利要求1所述的系统，还包括观察者引擎，用于评估由数 据获取引擎所产生的通知消息，以确定不止一个事件的累积效应。
28.一种控制系统，包括：
控制软件，被配置为通过一系列步骤控制装置系统，以执行有用运 行循环，
由该控制软件动态产生的存储器堆，该存储器堆包括多个事件结 构，每个事件结构包括至少一个指向该事件结构外部的存储器的指针、 至少一个事件运算符和至少一个变量，和
数据获取引擎，适于在控制软件运行时查找存储器堆，并被配置为 基于所述至少一个指针、至少一个操作符和至少一个变量来估计事件条 件是真还是假，并在发现真条件时产生可配置的通知消息。
29.根据权利要求28所述的控制系统，包括与所述存储器堆关联的 存储器，并且所述控制软件在控制软件编译时在相关联的存储器中分配 存储器堆。
30.根据权利要求28所述的控制系统，其中控制软件包括产生事件 结构的应用程序接口(API)。
31.根据权利要求30所述的控制系统，其中每个事件结构具有由控 制软件在运行时分配的唯一标识。
32.根据权利要求28所述的控制系统，其中响应于可配置的通知消 息改变控制软件的运行。
33.根据权利要求32所述的控制系统，其中响应于多个事件条件产 生至少一个通知消息。
34.一种数据获取方法，包括：
查找具有至少一个存储器指针、事件运算符和变量的条件参数的事 件结构的存储器堆；
通过为事件结构评估条件参数，识别评估为真的事件条件；和
在发现真条件时，产生通知消息。
35.根据权利要求34所述的方法，其中在编译时分配存储器堆。
36.根据权利要求34所述的方法，其中在运行时，根据至少一个网 络消息创建事件结构。
37.根据权利要求34所述的方法，其中存储器堆与具有内部网络的 电器的控制程序相关联。
38.根据权利要求37所述的方法，其中通过与控制程序相关联的应 用程序接口产生事件结构。
39.根据权利要求37所述的方法，其中响应于通知消息改变控制程 序的运行。
40.根据权利要求37所述的方法，其中通知消息通过内部网络被发 送到外部网络。
41.根据权利要求34所述的方法，其中每个事件结构具有唯一标识 符。
42.根据权利要求34所述的方法，其中通知消息通过具有多个节点 的网络被发送。
43.根据权利要求42所述的方法，其中通知消息通过所述网络被发 送到所述多个节点中的一个节点。
44.根据权利要求34所述的方法，其中通知消息在回叫功能上被调 用。
45.根据权利要求34所述的方法，并且选择性地使能和禁用通知消 息的产生。
46.根据权利要求45所述的方法，在选择性地使能和禁用通知消息 时，发送所述通知消息。
47.根据权利要求34所述的方法，其中条件参数的评估包括应用从 以下列表中所选择的事件运算符：大于，小于，等于，正在改变，死 带，位掩码。
48.根据权利要求34所述的方法，其中在为多个事件结构评估条件 参数之后进行通知消息的产生。
49.根据权利要求34所述的方法，包括评估多个通知消息，以确定 多个事件结构的累积效应。
50.一种通过一系列步骤控制装置系统以执行有用运行循环的方法， 该方法包括以下步骤：
运行控制程序，以通过一系列步骤指示装置的运行，
在控制程序运行期间动态地产生存储器堆，该存储器堆包括多个事 件结构，每个事件结构具有包括与事件相关的至少一个指向该事件结构 的外部存储器指针、至少一个事件运算符和至少一个变量的条件参数，
通过在控制软件运行期间查找结构的存储器堆，并为事件结构评估 条件参数，识别被估计为真的事件条件，和
在发现真条件时产生可配置的通知消息。
51.根据权利要求50所述的方法，包括在控制程序运行期间向每个 事件结构分配唯一的标识符。
52.根据权利要求50所述的方法，包括响应于通知消息，更改控制 程序的运行。
53.根据权利要求50所述的方法，选择性地使能和禁用通知消息的 产生。
54.根据权利要求50所述的方法，包括评估多个通知消息，以确定 多个事件结构的累积效应。
55.一种网络系统，包括：
定义通信网络的多个互连节点，其中至少一个节点被配置为通过该 通信网络发送消息，并且至少一个节点被配置为通过该通信网络接收消 息；
来自预定的标识符组的至少一个标识符与每个节点相关联，并只标 识可用于该节点的功能性；
其中至少一个节点通过经该通信网络发送的消息来传送所述至少一 个标识符，用于由至少一个节点接收，由此通过该通信网络公布功能 性。
56.根据权利要求55所述的网络系统，其中节点包括从包括以下内 容的列表中所选择的部件：传感器、分配器、光、过滤器、电机、除霜 器、加热器、电梯、螺线管、继电器、冷却器、电机控制器、键区控制 器和用户接口。
57.根据权利要求55所述的网络系统，其中通信网络被配置为与其 它网络通信。
58.根据权利要求55所述的网络系统，其中所述预定的标识符组是 可配置的。
59.根据权利要求55所述的网络系统，其中可用于标识符的功能性 是可配置的。
60.根据权利要求59所述的网络系统，其中可通过为标识符分配新 功能来配置功能性。
61.根据权利要求59所述的网络系统，其中可动态配置功能性。
62.根据权利要求55所述的网络系统，其中标识符除了功能性之外 还表明含义。
63.根据权利要求62所述的网络系统，其中含义可以被重新分配。
64.根据权利要求62所述的网络系统，其中含义可以根据网络而变 化。
65.根据权利要求62所述的网络系统，其中标识符的含义在节点之 间变化。
66.根据权利要求55所述的网络系统，其中至少一个节点通过在网 络上公布的标识符阵列而确定自己的身份。
67.根据权利要求66所述的网络系统，其中标识符阵列被存储在与 该至少一个节点相关联的存储器中。
68.根据权利要求55所述的网络系统，其中至少一些标识符包括关 于标识符的唯一信息。
69.根据权利要求68所述的网络系统，其中唯一信息在整个网络上 唯一地标识标识符。
70.根据权利要求68所述的网络系统，其中唯一的信息在整个网络 上唯一地标识节点。
71.根据权利要求68所述的网络系统，其中唯一信息在整个标识符 组上唯一地标识标识符。
72.根据权利要求55所述的网络系统，还包括同一节点上标识符的 多个实例，其中每个实例包括用于唯一地标识每个实例的唯一信息。
73.根据权利要求72所述的网络系统，其中附加标识符是被产生和 分配的标识符。
74.根据权利要求55所述的网络系统，其中与被配置为接收消息的 节点的功能性相关联的标识符被用于寻址用于接收消息的节点。
75.根据权利要求55所述的网络系统，其中消息从包括以下内容的 列表中选择：使用功能性的命令，对与功能性相关的信息的请求，对请 求消息的响应，接收到命令的确认。
76.根据权利要求75所述的网络系统，其中对信息的请求包括请求 标识符的请求消息。
77.根据权利要求76所述的网络系统，还包括响应于请求消息的响 应消息，用于确认至少一个标识符与至少一个节点的相关性。
78.根据权利要求77所述的网络系统，其中包含所请求的标识符的 响应消息包括所请求的标识符的实例的数量。
79.根据权利要求74所述的网络系统，其中对信息的请求寻找以下 中至少一个：指定标识符的相关性的确认，与至少一个节点相关的多个 标识符的识别，与指定节点相关的所有标识符的识别。
80.一种用于可操作地协作地执行有用运行循环的装置系统的网络系 统，该网络系统包括：
多个节点，其中每个节点与至少一个装置相关联，至少两个所述节 点适于发送消息，并且至少两个节点适于接收消息；
预定的标识符范围；
来自所述预定的标识符范围的与每个节点相关联的至少一个标识 符，用于标识哪些功能性可用于与该节点相关联的装置。
81.根据权利要求80所述的网络系统，其中多个装置的集合包括电 器。
82.根据权利要求80所述的网络系统，其中多个装置的集合包括多 个联网电器。
83.一种识别具有多个节点的网络中的节点的方法，其中每个节点具 有预定标识符组中至少一个标识符，每个标识符标识可用于该节点的至 少一个功能性，该方法包括：
至少一个节点通过该网络发送配置为查询该预定标识符组中至少一 个标识符是否存在的消息，
至少一个其它节点发送确认在该至少一个其它节点上存在该至少一 个标识符的反馈消息。
84.根据权利要求83所述的方法，其中节点忽略查询不可用标识符 是否存在的消息。
85.根据权利要求84所述的方法，其中所述节点通过不响应于所述 消息发送反馈消息来忽略所述消息。
86.根据权利要求83所述的方法，其中消息可以被广播到所述节点 中一个、一些或全部。
87.根据权利要求86所述的方法，其中消息针对特定节点。
88.根据权利要求86所述的方法，其中如果查询不可用标识符的消 息被广播到不止一个节点，则节点忽略该消息。
89.根据权利要求83所述的方法，其中所述消息是请求信息的发现 查询，所述反馈消息是包含该发现查询所请求的信息的网络消息。
90.根据权利要求89所述的方法，其中反馈消息被发送到所述节点 中的一个、一些或全部。
91.根据权利要求90所述的方法，其中反馈消息指向发送发现查询 的节点。
92.根据权利要求83所述的方法，其中反馈消息涉及估计网络完整 性、使能动态网络行为、配置节点之间交互中至少一个。
93.根据权利要求83所述的方法，其中每个标识符代表一组公共功 能性。
94.根据权利要求93所述的方法，其中所述消息可以请求涉及标识 符的至少一个功能性的信息以及关于该标识符的信息。
95.根据权利要求94所述的方法，其中标识符通过驻留在节点上的 软件模块来实施，所述消息请求关于该软件模块的功能性以及该软件模 块的身份的信息。
96.根据权利要求83所述的方法，其中通过新节点广播节点活动消 息而启动消息的发送。
97.根据权利要求83所述的方法，其中节点可以发送向任何其它节 点请求以下至少一项的消息：所支持的功能标识符中一个、一些或全 部，和唯一的标识符信息。
98.根据权利要求83所述的方法，其中反馈消息包括所请求的标识 符存在的实例的数量。
99.根据权利要求98所述的方法，其中发送消息的节点可以响应于 反馈消息发送复文消息，以请求用于唯一地识别节点处标识符的重复实 例的附加标识信息。
100.一种识别具有形成通信网络的多个互连节点的电器中的节点的 方法，其中至少一些所述节点具有对应的部件，其中所述部件可操作地 通过通信网络耦接以协作地执行有用运行循环，每个节点具有预定标识 符组中的至少一个标识符，每个标识符标识可用于对应部件的至少一个 功能性，该方法包括：
至少一个节点通过该网络发送被配置为查询该预定标识符组中至少 一个标识符是否存在的命令，
至少一个其它节点发送确认在该至少一个其它节点上存在该至少一 个标识符的反馈消息。
101.根据权利要求100所述的方法，其中消息可以被广播到所述节 点中的一个、一些或全部。
102.根据权利要求100所述的方法，其中所述命令是请求信息的发 现查询，所述反馈消息是包含该发现查询所请求的信息的网络消息。
103.根据权利要求100所述的方法，其中反馈消息涉及估计网络完 整性、使能动态网络行为、配置节点之间交互中至少一个。
104.根据权利要求100所述的方法，其中标识符通过驻留在部件上 的软件模块实施，所述命令向该软件模块请求该部件的功能性的信息以 及该软件模块的身份。
105.根据权利要求100所述的方法，其中通过新节点广播节点活动 消息而启动命令的发送。
106.根据权利要求100所述的方法，其中节点可以发送向任何其它 节点查询以下至少一项的命令：所支持的功能标识符的一个、一些或全 部，以及唯一标识符信息。
107.根据权利要求100所述的方法，其中反馈消息包括所请求的标 识符存在的实例的数量。
108.根据权利要求100所述的方法，其中发送命令的节点可以响应 于反馈消息发送复文命令，以请求用于唯一地标识节点处标识符的重复 实例的附加标识信息。
109.一种用于控制具有至少两个运行模式并通过通信网络连接以形 成协作节点网络的多个装置的系统，该系统包括：
第一软件运行层，被配置为响应于在网络上发送的消息，在第一运 行模式下控制至少一个装置的运行，
第二软件运行层，被配置为响应于在网络上发送的消息，在第二运 行模式下控制至少一个装置的运行，其中第二运行层与第一运行层提供 消息与装置运行之间不同级别的干预。
110.根据权利要求109所述的系统，其中第一和第二软件运行层允 许通过消息对装置进行不同级别的控制，以提供不同级别的干预。
111.根据权利要求110所述的系统，其中第二软件运行层允许至少 一个装置在第一运行层阻止该装置运行的条件下运行。
112.根据权利要求111所述的系统，其中第一软件运行层在第二软 件运行程允许直接控制该装置时不允许直接控制所述多个装置中的至少 一个装置。
113.根据权利要求109所述的系统，其中第一软件运行层只允许所 述装置按照执行预定运行循环的方式运行。
114.根据权利要求113所述的系统，其中第二软件运行层允许装置 在至少一个附加运行循环下运行。
115.根据权利要求114所述的系统，其中附加运行循环是以下中至 少一个：演示循环；开发循环；检错循环；诊断循环；减小一个预定运 行循环的至少一个定时步骤的时间的循环；绕过一个预定运行循环的至 少一个可操作步骤的循环；用定时步骤替换对一个预定运行循环的事件 进行响应的步骤的循环；将下层API暴露给网络的循环。
116.根据权利要求109所述的系统，还包括至少一个内部和外部客 户机，其被配置为产生用于在第一和第二运行模式之间改变运行模式的 消息。
117.根据权利要求109所述的系统，其中第一和第二软件运行层中 至少一个执行装置的协作运行，以完成一系列相关步骤来完成预定操 作。
118.根据权利要求117所述的系统，其中装置是从包括传感器、分 配器、过滤器、电机、加热器和冷却器的列表中选择的。
119.根据权利要求117所述的系统，其中所述多个装置中至少一个 子集全都位于一个电器中。
120.根据权利要求117所述的系统，其中所述多个装置包括多个联 网的电器。
121.根据权利要求109所述的系统，其中网络包括内部网络和外部 网络中至少一个。
122.根据权利要求121所述的系统，其中第二运行模式将第一软件 运行层暴露给外部网络。
123.根据权利要求109所述的系统，其中第一和第二运行模式中的 一个包括本地运行模式，第一和第二运行模式中另一个包括远程运行模 式。
124.一种用于控制通过通信网络连接的多个装置以定义可操作地在 运行循环中执行一系列步骤的机器的控制系统，该控制系统包括：
用户接口，被配置为从用户接收用于从多个运行循环中选择一个运 行循环的输入；
与网络隔离的第一系统元件，被配置为控制该机器以实施所选择的 运行循环，以定义第一控制状态；
暴露给网络的第二系统元件，被配置为通过网络控制该机器以实施 所选择的运行循环，从而定义第二控制状态。
125.根据权利要求124所述的控制系统，其中网络包括具有多个节 点的内部网络，至少一个节点具有一个或多个功能单元，每个功能单元 代表一组公共功能性。
126.根据权利要求125所述的控制系统，其中至少一个功能单元实 行对所述多个装置中至少一个装置的下层电输入和输出中的至少一个的 控制。
127.根据权利要求124所述的控制系统，其中第二系统元件包括驻 留在至少一个装置上的软件引擎，而且该软件引擎暴露通过网络发送的 网络消息以实行第二控制状态。
128.根据权利要求127所述的控制系统，其中软件引擎暴露封装在 网络消息中的命令，其中该命令用于实行第二控制状态。
129.根据权利要求124所述的控制系统，其中绕过至少一个验证和 安全校验，以便向第二系统元件提供对至少一些所述装置的下层功能性 的控制。
130.根据权利要求124所述的控制系统，其中第二系统元件可以响 应于网络消息而将该机器从第二控制状态中移除。
131.一种控制系统运行的方法，包括：
产生代表格式良好命令组的分类数据集；
利用分类数据集，从该格式良好命令组中产生格式良好命令；
响应于所产生的格式良好命令，控制系统的运行。
132.根据权利要求131所述的方法，其中通过与系统相关联的网络 上的至少一个节点完成产生分类数据集和产生格式良好命令中至少一 个。
133.根据权利要求132所述的方法，其中至少一个节点是多个用于 形成机器的内部网络的互连节点中的一个。
134.根据权利要求131所述的方法，其中控制系统的运行包括由从 以下中所选择的控制器控制系统：节点上的控制器，系统网络内且内部 网络外部的控制器，外部控制器。
135.根据权利要求134所述的方法，还包括向控制器发送格式良好 命令的步骤。
136.根据权利要求131所述的方法，其中分类数据集指示从可允许 用于控制系统的命令与控制系统所需要的命令中所选择的命令。
137.根据权利要求131所述的方法，其中分类数据集通过多个分类 级别定义，其中至少一个分类级别指示至少一个所需要的判定。
138.根据权利要求137所述的方法，其中判定是以下中至少一个： 选项的选择或拒绝，输入值设置，从多个可能的选项中选择一个选项。
139.根据权利要求138所述的方法，其中选项选自一组可用于系统 的运行循环的选项。
140.根据权利要求131所述的方法，其中通过用于控制系统的至少 一部分运行的控制器产生分类数据集。
141.根据权利要求140所述的方法，其中控制器基于以下因素中至 少一个产生分类数据集：当前运行的类型，当前运行的状态，当前运行 的任何可操作限制。
142.根据权利要求140所述的方法，其中控制器根据以下中至少一 个产生分类数据：当前可应用的资源限制，当前可应用的安全限制，用 户偏好，时间限制。
143.根据权利要求131所述的方法，还包括向至少一个命令发生器 发送分类数据集。
144.根据权利要求143所述的方法，还包括向多个命令发生器发送 分类数据集。
145.根据权利要求144所述的方法，其中控制系统运行的步骤包括 从所述多个命令发生器中至少一个控制系统。
146.根据权利要求145所述的方法，其中系统包括内部网络，至少 第一命令发生器位于内部网络内，第二命令发生器位于内部网络之外。
147.根据权利要求143所述的方法，其中至少一个命令发生器选 自：控制面板上的用户接口，外部用户接口，用户接口，资源管理系 统，家庭自动化系统，共享资源的其他系统，执行相关操作的其它系 统。
148.根据权利要求143所述的方法，其中命令发生器发送运行至少 两个系统的命令。
149.根据权利要求143所述的方法，其中分类数据集作为多个消息 被发送到命令发生器。
150.根据权利要求131所述的方法，还包括步骤：向提供用于引导 用户产生格式良好命令的用户反馈的用户接口装置发送分类数据集。
151.根据权利要求150所述的方法，其中用户反馈包括通知用户选 项不可用。
152.根据权利要求131所述的方法，其中重复执行产生分类数据集 的步骤。
153.根据权利要求131所述的方法，还包括周期地产生分类修改消 息的步骤。
154.根据权利要求131所述的方法，还包括验证格式良好命令的步 骤。
155.根据权利要求154所述的方法，其中验证格式良好命令的步骤 选自：验证命令的接收，验证命令是格式良好的，验证命令的执行。
156.根据权利要求131所述的方法，其中分类数据集的产生包括集 合多个可允许用于格式良好命令的命令分量。
157.根据权利要求156所述的方法，其中格式良好命令的产生包括 将命令分量集合成格式良好命令。
158.一种用于使可编程命令发生器能够产生用于控制运行的格式良 好命令的分类数据集，该数据集包括：
多个在格式良好命令内可允许的命令分量，
概述用于选择产生格式良好命令的命令分量的分类结构的命令分类 的分类，其中分类在选择至少一个命令分量时为该至少一个命令分量指 示形成格式良好命令所需要的任何附加的命令分量。
159.根据权利要求158所述的方法，其中分类结构包括多个分类级 别，其中至少一个分类级别指示至少一个所需要的判定。
160.根据权利要求159所述的方法，其中所需要的判定选自：选项 的选择或拒绝，输入值设置，从多个可能的选项中选择一个选项。
161.根据权利要求158所述的方法，其中分类数据集阐明从可允许 用于控制系统的命令和控制系统所需要的命令中选择的命令。
162.根据权利要求158所述的方法，其中至少一个命令分量反映状 态信息。
163.根据权利要求162所述的方法，其中状态信息选自：传感器状 态信息，循环状态信息，环境状态信息，资源信息，用户偏好信息，历 史运行信息，网络信息，控制运行模式信息，运行状态信息。
164.一种用于控制有用系统的运行的控制系统，包括：
至少一个控制器，被配置为响应于来自一组格式良好命令中的格式 良好命令，控制该有用系统的运行；
至少一个分类引擎，适于产生用于建立该组格式良好命令的分类数 据集；
至少一个命令发生器，适于使用该分类数据集产生格式良好命令；
其中分类引擎被配置为向命令发生器传送分类数据集，命令发生器 被配置为向控制器传送格式良好命令。
165.根据权利要求164所述的控制系统，包括多个控制器，其中该 至少一个分类引擎被配置为产生对应于每个控制器的分类数据集。
166.根据权利要求165所述的控制系统，包括多个命令发生器，其 中每个命令发生器可以产生用于该多个控制器中任何控制器的格式良好 命令。
167.根据权利要求164所述的控制系统，包括多个命令发生器，其 中每一个被配置为为该控制器产生良好结构化命令。
168.根据权利要求164所述的控制系统，其中电器中的有用系统和 受控的运行是电器的运行，其中该电器具有包括多个节点的内部网络， 控制器选自：一个节点上的控制器，内部网络外部的控制器，外部控制 器。
169.根据权利要求164所述的控制系统，其中分类数据集阐明从 可允许用于控制系统的命令和控制系统所需要的命令中选择的命令。
170.根据权利要求164所述的控制系统，其中分类数据集通过多 个分类级别定义，其中至少一个分类级别指示至少一个所需要的判定， 其中判定选自：选项的选择或拒绝，输入值设置，从多个可能的选项中 选择一个选项。
171.根据权利要求164所述的控制系统，其中控制器根据以下中 至少一个产生分类数据集：当前运行的类型，当前运行的状态，当前运 行的任何可操作限制。
172.根据权利要求164所述的控制系统，其中控制器根据以下中 至少一个产生分类数据集：当前可应用的资源限制，当前可应用的安全 限制，用户偏好，时间限制。
173.根据权利要求164所述的控制系统，其中命令发生器选自： 控制面板上的用户接口，外部用户接口，用户接口，资源管理系统，家 庭自动化系统，共享资源的其他系统，执行相关操作的其它系统。
174.根据权利要求164所述的控制系统，其中命令发生器是可编 程的用户接口装置，其向用户提供用于引导用户产生格式良好命令的反 馈。
175.一种网络控制系统，包括：
响应多个函数调用的软件运行层，
能够直接产生至少一些所述函数调用的物理用户接口，
被配置为调用至少一些所述函数调用的虚拟用户接口。
176.根据权利要求175所述的网络控制系统，其中虚拟用户接口 被配置为调用至少一些物理用户接口不能直接产生的函数调用。
177.根据权利要求175所述的网络控制系统，还包括互连节点的 网络，软件运行层响应于所述函数调用控制每个节点以实施运行，其中 虚拟用户接口被配置为调用函数调用，以独立于软件运行层地直接控制 节点。
178.根据权利要求177所述的网络控制系统，还包括驻留在至少 一个节点上的软件引擎，用于通过网络实施虚拟用户接口。
179.根据权利要求178所述的网络控制系统，其中软件引擎至少 驻留在那些可以被虚拟用户接口直接控制的节点上。
180.根据权利要求179所述的网络控制系统，还包括网络外部的 节点，该节点被配置为与互连节点的网络通信，其中软件引擎驻留在网 络外部的节点上。
181.根据权利要求177所述的网络控制系统，其中虚拟用户接口 在网络外部而且与网络通信，从而从远离网络的地方通过网络执行对节 点的控制。
182.根据权利要求177所述的网络控制系统，其中虚拟用户接口 在网络内部。
183.根据权利要求182所述的网络控制系统，其中网络限定电器 的内部通信网络。
184.根据权利要求183所述的网络控制系统，其中虚拟用户接口 与物理用户接口位于不同节点。
185.根据权利要求177所述的网络控制系统，其中网络上每个节 点具有一个或多个功能单元，其中每个功能单元代表一组公共功能性。
186.根据权利要求175所述的网络控制系统，其中虚拟用户接口 产自替换的软件运行层。
187.根据权利要求175所述的网络控制系统，其中替换的命令发 生器响应于事件的检测。
188.根据权利要求187所述的网络控制系统，其中事件选自：默 认，状态事件，传感器输出，软件运行层所触发的事件，网络消息。
189.根据权利要求175所述的网络控制系统，还包括具有多个装 置的网络，至少一个函数调用与和至少一个装置相关的活动相关联。
190.根据权利要求175所述的网络控制系统，其中基于规定的优 先权执行源自物理用户接口的函数调用和源自虚拟用户接口的函数调 用。
191.根据权利要求190所述的网络控制系统，其中规定的优先权 选自：
至少一个函数调用可以至少临时使来自另一源的函数调用无效；
源自物理用户接口的函数调用和源自虚拟用户接口的函数调用被批 量地处理；
函数调用可以被组合，使得在执行其它函数调用或逻辑相关的函数 调用组之前完成逻辑相关的调用组；
源自物理用户接口的函数调用和源自外部的函数调用被顺序地执 行。
192.根据权利要求175所述的网络控制系统，其中物理用户接口 包括自包含数据处理和网络装置。
193.根据权利要求192所述的网络控制系统，其中物理用户接口 选自包括蜂窝电话，计算机，网络写字板，PDA，麦克风，虚拟键盘所 组成的组。
194.一种网络控制系统，包括：
响应多个函数调用的软件运行层，
具有多个UI动作的物理用户接口，其中每个UI动作直接产生一个 所述函数调用，至少一个UI动作产生数据，
虚拟用户接口，适于调用至少一些由UI动作所产生的函数调用， 以及调用至少一个不能由UI动作产生的函数调用。
195.根据权利要求194所述的网络控制系统，其中每个UI动作具 有一个相关联的函数调用。
196.根据权利要求194所述的网络控制系统，其中每个函数调用 与一个或多个UI动作关联。
197.根据权利要求194所述的网络控制系统，其中至少一个UI动 作与函数调用关联。
198.根据权利要求194所述的网络控制系统，其中至少一个UI动 作与数据输入关联。
199.根据权利要求194所述的网络控制系统，其中物理用户接口 包括具有多个键的键区。
200.根据权利要求199所述的网络控制系统，其中每个键与相关 的函数调用关联。
201.根据权利要求199所述的网络控制系统，其中至少一个键与 至少一个相关的函数调用关联。
202.根据权利要求199所述的网络控制系统，其中至少一个键与 数据输入关联。
203.根据权利要求194所述的网络控制系统，其中虚拟用户接口 被配置为传送包括至少一个函数调用的虚拟键按下，由此该至少一个虚 拟键按下指示接收网络节点执行相关功能性。
204.根据权利要求203所述的网络控制系统，其中虚拟键按下实 现以下中至少一项：
测试相关软件；
软件的远程执行；
软件重新使用；
键按下函数调用的重新编程。
205.根据权利要求204所述的网络控制系统，其中至少一个虚拟 键按下调用多个函数调用。
206.根据权利要求205所述的网络控制系统，其中虚拟键按下的 至少一个序列调用至少一个函数调用。
207.根据权利要求194所述的网络控制系统，其中软件至少具有 第一运行层和第二运行层，其中至少一个在第一运行层中不可用的函数 调用在第二运行层可用。
208.根据权利要求194所述的网络控制系统，其中网络包括具有 多个节点的电器，而且由发送给支持该函数调用的网络节点的网络消息 封装键区的虚拟键按下。
209.根据权利要求194所述的网络控制系统，还包括互连节点的 网络，软件运行层响应于所述函数调用控制每个所述节点以实施运行， 其中虚拟用户接口被配置为调用不能由UI动作产生的函数调用，以独 立于软件运行层直接控制所述节点。
210.根据权利要求209所述的网络控制系统，还包括驻留在至少 一个节点上的软件引擎，用于通过网络实施虚拟用户接口。
211.根据权利要求210所述的网络控制系统，其中软件引擎至少 驻留在那些可以由虚拟用户接口直接控制的节点上。
技术领域
本发明涉及包括一个或多个支持与家用电器内的至少一个部件通信 以及对其进行管理的应用编程接口的软件体系。
背景技术
家用电器通常包括导致该电气的机电操作、电热操作和电气化学操 作的一个或多个部件。例如，炉子可以包括具有在其上带有存储器的印 刷电路板(PCB)的电器管理部件，以及用户接口部件，诸如由用户向 炉子电器发布命令的控制面板或键区。由于部件的多样性以及相应的实 施选择的多样性，通常很难设计、开发、测试、诊断、控制和调试基本 电器模型。该多样性是创建可协同工作、可重复使用、增值的部件的障 碍。
近年来逐渐已知通过能够发送和接收用于控制电器内部部件之间交 互的控制消息的内部通信网络将电器部件互连，这与使用多个分立电路 相反，在使用多个分立电路的情况下，每个分立电路负责相关部件之间 的、通过这些部件之间的硬连线带状缆线或其它连接器或导线实施的单 独通信。该内部网络在连接电器内部部件方面提供了一定程度的通用 性，但是，每个部件通常需要由其微处理器以及相邻硬件电路内的软件 支持，以实现网络参与。家用电器内所使用的这种内部网络的一个例子 是本申请的受让人Whirlpool，Inc.所创建的WIDE网络协议。
近年来逐渐已知通过能够发送和接收用于控制电器内部部件之间交 互的控制消息的内部通信网络将电器部件互连，这与使用多个分立电路 相反，在使用多个分立电路的情况下，每个分立电路负责相关部件之间 的、通过这些部件之间的硬连线带状缆线或其它连接器或导线实施的单 独通信。该内部网络在连接电器内部部件方面提供了一定程度的通用 性，但是，每个部件通常需要由其微处理器以及相邻硬件电路内的软件 支持，以实现网络参与。家用电器内所使用的这种内部网络的一个例子 是本申请的受让人Whirlpool，Inc.所创建的WIDE网络协议。
发明内容
本发明涉及在电器上实现并且通过电器上的内部通信网络通信的软 件体系，该内部通信网络连接电器的各个物理部件。软件体系执行多种 功能：识别对应于网络节点的每个部件；识别所识别的到网络的部件的 能力或功能；识别到网络的部件的状态；为每个部件提供适当限定的命 令接口；提供内部软件成分和不属于该软件体系的外部软件成分之间的 通信。通过这种方式，软件体系用于向网络上的所有节点通报其它节点 的存在、能力和状态，并允许这些节点相互发送和接收命令消息的功 能。
附图说明
图1是表示具有将多个部件互连的内部通信网络的家用电器的示意 图，其中每个部件具有根据本发明内嵌于其中的软件体系，家用电器还 具有表示用于与外部客户机的各种实施方式建立通信的各种网络接口卡 (NIC)的外部通信连接。
图2是图1的内部通信网络的示意图，显示了根据本发明的软件体 系(SA)设置在内部通信网络和家用电器内部物理部件的各软件成分之 间。
图3是图1的内部通信网络的示意图，示出了内部通信网络用作驻 留在两个部件(代表网络物理层且不直接与SA关联的较低层以及代表 对分组结构的支持且直接作为SA的元件的较高层)上的SA的物理支 持，其中SA被部件用于通过信息交换通信、并且与操作驻留在部件上 层的其它软件交互，以根据本发明根据部件之间交换的信息而实现结 果。
图4是用于图1所示家用电器的内部通信网络的分组结构的示意 图，该分组结构具有有效载荷部分，该有效载荷部分包括用于根据本发 明的软件体系的应用分组结构。
图5是驻留在电器的控制器上的SA(控制器SA)和驻留用于创建 相对于控制器上SA的客户机关系的部件上的SA(客户机SA)之间的 通信的示意图，其中各变量和事件在控制器SA和客户机SA之间传 送。
图5A是类似于图5的示意图，示出了客户机作为外部客户机以顾 客呼叫支持中心的形式位于远程位置上，以说明用于执行电器远程诊断 的数据的交换。
图6是类似于图5所示的示意图，示出了根据本发明包含在图1的 软件体系中的发现技术。
图7是在作为洗衣机示出的家用电器的部件内通常在如图3所示的 控制逻辑元件内运行的软件运行环境的各种示例状态的示意图。
图8的示意图示出了控制器SA基于家用电器的状态以及控制器SA 的内部状态，对于由其它SA设施发布和接收的命令的形式的各种信息 交换的响应，以验证或拒绝那些命令。
图9的示意图示出了使用绑定来链接多个数据交换，以形成客户机 SA和控制器SA之间的单个命令和/或更新。
图10是示出涉及部件的整体软件环境的SA的示意图，其中软件环 境包括各软件运行层，软件体系包括命令处理程序、更新处理程序和用 于将SA互连到家用电器内部通信网络的内部通信网络层接口。
图11是示出驻留在主控制器上的监管调度器(MAIN)调用控制器 SA的示意图，该监管调度器还调用用于展示网络上客户机SA的功能的 子例程调用。
图12是示出图11所示的内部电器应用逻辑和软件体系之间的接口 的示意图，包括回叫部分。
图13是图11所示的软件体系的示例性实施方式的示意图，包括电 器初始化部分。
图14是一对软件运行环境的示意图，每个软件运行环境对应于具 有自己的SA、且通过内部通信网络连接的不同部件。
图15示意地显示了经由网络14暴露给Parrot(模拟器)电器内其 它部件、且支持根据本发明的图1的软件体系10的分组结构28的持久 节点。
图16示意地显示了用于将外部命令翻译为键按压以测试家用电器 功能性的现有技术方法。
图17示意地显示了用户启动的键按压的交互，外部输入的软件命 令作为变量被传送到SA，以向家用电器发布命令，用于例如测试家用 电器功能性和/或改变家用电器机器的状态。
图18是示出在电器背侧所形成的凹陷中安装NIC的示意图。
图19的示意图示出了将NIC安装到电器前侧，以及从网络接口卡 的安装位置延伸到电器背侧的电线管道。
图20是包括安全屏障(safety barrier)的电器的示意图，其中安 全屏障允许来自位于电器中的RF PCB的通信并防止人员接触过量的热 和/或电。
图21的示意图示出了维护模块的使用，其中维护模块从电器获得 诊断数据并通过个人计算机经由外部网络上载诊断数据。
图21A是图21的维护模块的体系的示意图。
图22是类似于图21的示意图，其中维护模块经由电话线上载诊断 数据。
图22A是图22的维护模块的体系的示意图。
图23是冰箱形式的电器的示意图，其配备有气象站模块形式的示 例性附属模块，形成具有使气象站模块能够在没有手动配置的情况下运 行的客户机SA的部件。
图24是图1所示的家用电器的内部通信网络的分段式分组结构 (fragmentation packet structure)的示意图，具有用于处理分段分组 完整性(fragmented packet integrity)的协议，该协议在必须将一条消 息分解为多条消息时代替图4所示的协议。
图25示出代表以图2所示形式传送的一系列分段消息的分组序 列，该分组序列通过接收SA被重新形成为由分组发送者所创建的原始 内聚数据集(cohesive data set)。
图26A示意地示出中心位置、诸如主控制器PC板处可变映射信息 的位置，然后可变映射信息被传递到其它部件板。
图26B示意地示出了部件的控制器上可变映射信息的位置，其被从 网络上的其它部件收集。
图27是示出消息收发情形的UML序列图，其中为复制事件请求分 配可变地址，以允许两个请求驻留在网络中。
图28是示出表示禁止和重新使能实现事件请求的标准格式的UML 序列图。
图29是SA内被确认的事件的UML序列图，其中控制器SA在处 理下一事件之前等待来自客户机SA的确认消息一段预定的时间。
图30是示出本发明所提供的安全模式和防火墙的标准格式的UML 状态图。
图31是示出在应用消息能够被完全处理之前必须与图30的防火墙 协商的客户机之间的交互方法的UML序列图。
图32是示出SA能够实施的标准公用接口的UML类图。
图33示出SA的优选实施方式的UML类图。
图34示出SA的源代码文件的优选组织。
图35示出相互关联的UML状态图的集合，其示出了3个主状态 (COMM_IDLE，COMM_EXPECTING_ACK，和 COMM_PENDING)，其中每个主状态可能具有多个子状态。
图36示出相互关联的UML状态图的集合，其示出了4个主状态 (READY，TRANSMIT_SNAPSHOT，UPDATES_BLOCKED，和 PROCESS_DAQ_EVENTS)。
图37示出了表示两个主状态(MSG_READY和 MSG_PROCESS)的相互关联的UML状态图的集合。
图38的UML序列图示出了为了由SA在内部网络上产生网络消 息，执行部件之间内部消息的有序集合。
图39的UML序列图示出了执行软件运行环境的图33中类的消息 的有序集合。
图40的UML序列图示出了软件运行环境的图33中类的消息的有 序集合。
图41的UML序列图示出了为了处理从客户机22/16从WIDE总 线14所输入的消息所需要的消息收发，其除了发送输入消息的成功或 者失败理由的响应(ACK或API ID＝1，Op Code＝1的NAK)之外不 需要包含有意义数据的响应。
图42的UML序列图示出了为了处理从客户机22/16从WIDE总 线14输入的消息所需要的消息收发，其除了发送输入消息的成功或失 败理由的响应(ACK或API ID＝1，Op Code＝1的NAK)之外还需要 发送多个包含有意义数据的响应。
图43的UML序列图示出了为了处理从客户机22/16从WIDE总 线14输入的消息所需要的消息收发，其除了发送输入消息的成功或失 败理由的响应(ACK或API ID＝1，Op Code＝1的NAK)之外还需要 一个包含有意义数据的响应。
图44示意性示出了利用归类数据集(taxonomy dataset)来控制电 器内一个或多个部件的操作而不需要直接了解该部件的功能的归类控制 (taxonomy control)。
图45示意性示出了由包括分层结构的选项和数据输入的归类数据 集填充的用户接口，其中该用户接口引导用户选择选项和数据输入，以 产生适当形成的命令。
图46示意性示出可用于顶级选项的相关数据输入。
图47示意性示出可用于具有相关数据输入的子级选项选择的相关 数据输入。
附图说明
图1是表示具有将多个部件互连的内部通信网络的家用电器的示意 图，其中每个部件具有根据本发明内嵌于其中的软件体系，家用电器还 具有表示用于与外部客户机的各种实施方式建立通信的各种网络接口卡 (NIC)的外部通信连接。
图2是图1的内部通信网络的示意图，显示了根据本发明的软件体 系(SA)设置在内部通信网络和家用电器内部物理部件的各软件成分之 间。
图3是图1的内部通信网络的示意图，示出了内部通信网络用作驻 留在两个部件(代表网络物理层且不直接与SA关联的较低层以及代表 对分组结构的支持且直接作为SA的元件的较高层)上的SA的物理支 持，其中SA被部件用于通过信息交换通信、并且与操作驻留在部件上 层的其它软件交互，以根据本发明根据部件之间交换的信息而实现结 果。
图4是用于图1所示家用电器的内部通信网络的分组结构的示意 图，该分组结构具有有效载荷部分，该有效载荷部分包括用于根据本发 明的软件体系的应用分组结构。
图5是驻留在电器的控制器上的SA(控制器SA)和驻留用于创建 相对于控制器上SA的客户机关系的部件上的SA(客户机SA)之间的 通信的示意图，其中各变量和事件在控制器SA和客户机SA之间传 送。
图5A是类似于图5的示意图，示出了客户机作为外部客户机以顾 客呼叫支持中心的形式位于远程位置上，以说明用于执行电器远程诊断 的数据的交换。
图6是类似于图5所示的示意图，示出了根据本发明包含在图1的 软件体系中的发现技术。
图7是在作为洗衣机示出的家用电器的部件内通常在如图3所示的 控制逻辑元件内运行的软件运行环境的各种示例状态的示意图。
图8的示意图示出了控制器SA基于家用电器的状态以及控制器SA 的内部状态，对于由其它SA设施发布和接收的命令的形式的各种信息 交换的响应，以验证或拒绝那些命令。
图9的示意图示出了使用绑定来链接多个数据交换，以形成客户机 SA和控制器SA之间的单个命令和/或更新。
图10是示出涉及部件的整体软件环境的SA的示意图，其中软件环 境包括各软件运行层，软件体系包括命令处理程序、更新处理程序和用 于将SA互连到家用电器内部通信网络的内部通信网络层接口。
图11是示出驻留在主控制器上的监管调度器(MAIN)调用控制器 SA的示意图，该监管调度器还调用用于展示网络上客户机SA的功能的 子例程调用。
图12是示出图11所示的内部电器应用逻辑和软件体系之间的接口 的示意图，包括回叫部分。
图13是图11所示的软件体系的示例性实施方式的示意图，包括电 器初始化部分。
图14是一对软件运行环境的示意图，每个软件运行环境对应于具 有自己的SA、且通过内部通信网络连接的不同部件。
图15示意地显示了经由网络14暴露给Parrot(模拟器)电器内其 它部件、且支持根据本发明的图1的软件体系10的分组结构28的持久 节点。
图16示意地显示了用于将外部命令翻译为键按压以测试家用电器 功能性的现有技术方法。
图17示意地显示了用户启动的键按压的交互，外部输入的软件命 令作为变量被传送到SA，以向家用电器发布命令，用于例如测试家用 电器功能性和/或改变家用电器机器的状态。
图18是示出在电器背侧所形成的凹陷中安装NIC的示意图。
图19的示意图示出了将NIC安装到电器前侧，以及从网络接口卡 的安装位置延伸到电器背侧的电线管道。
图20是包括安全屏障(safety barrier)的电器的示意图，其中安 全屏障允许来自位于电器中的RF PCB的通信并防止人员接触过量的热 和/或电。
图21的示意图示出了维护模块的使用，其中维护模块从电器获得 诊断数据并通过个人计算机经由外部网络上载诊断数据。
图21A是图21的维护模块的体系的示意图。
图22是类似于图21的示意图，其中维护模块经由电话线上载诊断 数据。
图22A是图22的维护模块的体系的示意图。
图23是冰箱形式的电器的示意图，其配备有气象站模块形式的示 例性附属模块，形成具有使气象站模块能够在没有手动配置的情况下运 行的客户机SA的部件。
图24是图1所示的家用电器的内部通信网络的分段式分组结构 (fragmentation packet structure)的示意图，具有用于处理分段分组 完整性(fragmented packet integrity)的协议，该协议在必须将一条消 息分解为多条消息时代替图4所示的协议。
图25示出代表以图2所示形式传送的一系列分段消息的分组序 列，该分组序列通过接收SA被重新形成为由分组发送者所创建的原始 内聚数据集(cohesive data set)。
图26A示意地示出中心位置、诸如主控制器PC板处可变映射信息 的位置，然后可变映射信息被传递到其它部件板。
图26B示意地示出了部件的控制器上可变映射信息的位置，其被从 网络上的其它部件收集。
图27是示出消息收发情形的UML序列图，其中为复制事件请求分 配可变地址，以允许两个请求驻留在网络中。
图28是示出表示禁止和重新使能实现事件请求的标准格式的UML 序列图。
图29是SA内被确认的事件的UML序列图，其中控制器SA在处 理下一事件之前等待来自客户机SA的确认消息一段预定的时间。
图30是示出本发明所提供的安全模式和防火墙的标准格式的UML 状态图。
图31是示出在应用消息能够被完全处理之前必须与图30的防火墙 协商的客户机之间的交互方法的UML序列图。
图32是示出SA能够实施的标准公用接口的UML类图。
图33示出SA的优选实施方式的UML类图。
图34示出SA的源代码文件的优选组织。
图35示出相互关联的UML状态图的集合，其示出了3个主状态 (COMM_IDLE，COMM_EXPECTING_ACK，和 COMM_PENDING)，其中每个主状态可能具有多个子状态。
图36示出相互关联的UML状态图的集合，其示出了4个主状态 (READY，TRANSMIT_SNAPSHOT，UPDATES_BLOCKED，和 PROCESS_DAQ_EVENTS)。
图37示出了表示两个主状态(MSG_READY和 MSG_PROCESS)的相互关联的UML状态图的集合。
图38的UML序列图示出了为了由SA在内部网络上产生网络消 息，执行部件之间内部消息的有序集合。
图39的UML序列图示出了执行软件运行环境的图33中类的消息 的有序集合。
图40的UML序列图示出了软件运行环境的图33中类的消息的有 序集合。
图41的UML序列图示出了为了处理从客户机22/16从WIDE总 线14所输入的消息所需要的消息收发，其除了发送输入消息的成功或 者失败理由的响应(ACK或API ID＝1，Op Code＝1的NAK)之外不 需要包含有意义数据的响应。
图42的UML序列图示出了为了处理从客户机22/16从WIDE总 线14输入的消息所需要的消息收发，其除了发送输入消息的成功或失 败理由的响应(ACK或API ID＝1，Op Code＝1的NAK)之外还需要 发送多个包含有意义数据的响应。
图43的UML序列图示出了为了处理从客户机22/16从WIDE总 线14输入的消息所需要的消息收发，其除了发送输入消息的成功或失 败理由的响应(ACK或API ID＝1，Op Code＝1的NAK)之外还需要 一个包含有意义数据的响应。
图44示意性示出了利用归类数据集(taxonomy dataset)来控制电 器内一个或多个部件的操作而不需要直接了解该部件的功能的归类控制 (taxonomy control)。
图45示意性示出了由包括分层结构的选项和数据输入的归类数据 集填充的用户接口，其中该用户接口引导用户选择选项和数据输入，以 产生适当形成的命令。
图46示意性示出可用于顶级选项的相关数据输入。
图47示意性示出可用于具有相关数据输入的子级选项选择的相关 数据输入。
具体实施方式
在检视本发明的多个方面之前，简要地概述本发明是有益的。本发 明涉及一种在电器上实施并且通过电器上的内部通信网络通信的软件体 系(“SA”)，其中内部通信网络连接电器的各物理部件。
一些物理部件具有相应的控制器(主控制器、电机控制器、用户接 口等)，其中控制器可以是安装在印刷电路板上的简单微处理器。其它 部件没有控制器。通常，具有控制器的部件(而且如果存在不止一个， 则这些部件通常还支持网络)通过网络消息收发或其它形式的数据传输 协作，以直接地或者通过其它部件间接地控制所有这些部件及其包含或 附属的装置的操作，从而实现电器的操作或循环。
该SA可以(但不是必须)驻留在具有控制器的每个部件上。具有 该SA或与该SA兼容的SA变形(通过发送、接收和处理分组的能力确 定的兼容性)的那些部件形成网络上能够与其它节点通信的节点。
SA执行多种功能：识别对应于网络节点的每个部件；识别所识别 到网络部件的能力或功能；识别网络部件的状态；为每个部件提供适当 限定的命令接口；提供内部软件成分和不是SA一部分的外部软件成分 之间的通信；提供不同物理部件上非SA软件成分之间的通信。通过这 种方式，SA用于向网络上的所有节点通报其它节点的存在、能力和状 态。
SA包括多个模块，每个模块具有不同功能。模块的各种组合或所 有模块可以驻留在每个部件上。一个具有本发明基本或核心功能的模块 驻留在所有部件上。在一种预期的配置中，所有模块至少驻留在主控制 器上，这使主控制器作为主SA或控制器SA工作，而其它节点以控制 器SA的客户机关系工作。在这种配置下，所有节点通过控制器SA通 信。
SA足够健壮，以至于其可以允许没有控制器SA或具有多个控制器 SA的配置。不管配置如何，任何具有驻留SA的部件都可以相对于其他 部件作为客户机工作。
内部通信可以被直接或者通过外部网络连接到一个或多个外部部 件。外部部件也可以驻留有一个、一些或全部SA模块。
从图1开始，现在描述本发明的具体内容。图1是示出软件体系10 的一个环境的示意图，(体现在此所述的系统和方法以及本领域技术人 员公知的内容)，形式为具有将多个部件16互连的内部通信网络14的 家用电器12，其中软件体系10驻留在至少一个部件16上，以使能该部 件，并且优选地，每个附加部件16具有驻留在其中的软件体系10，或 者能够协同工作的替换物。家用电器12还具有所示的互连到各网络接 口装置20的内部/外部通信连接18，用于与各种实施方式的外部客户机 22通信。
外部客户机通常包括能够与软件体系10交互的联网硬件和软件以 及计算硬件和软件。这可以通过包括外部客户机的实施例中的软件体系 10的全部或一部分或者能够与软件体系10通信以及完全或部分交互的 软件体系10的替换物来实现。已经实现了很多能够与软件体系10完全 交互的替换部件(C dll，Visual Basic Driver，Java Driver和Active X driver)。
对于本专利申请的文本并且考虑到本申请文本的附图，应当理解， 缩写“SA”是指本申请中用附图标记10描述的“软件体系”。
此外，术语“客户机”被用于表示其上驻留全部或部分SA、并且完 全或部分使能部件功能的部件。该部件可以是内部部件或外部部件。尽 管客户机主要被用于描述由SA使能的部件，但是客户机也被用于描述 由能够在内部通信网络14上成功地交换消息并与SA通信的替换软件使 能的部件。一般地，在谈到节点的软件方面而非硬件方面时，使用术语 “客户机”。
部件16可以包括一个或多个装置。因此，本申请中所使用的术语 “装置”可以指部件或装置。装置可以是共同地形成部件或者经由电路 (例如线束)、可以执行逻辑的物理部件和具有存储器的物理部件被连 接到具有控制器的部件的任何电子元件、电热元件以及电气化学元件。
如在此所述，电器12可以是本领域技术人员公知的各种公知电器 中的任何一种。例如，电器12可以是洗衣机、甩干机、微波炉、洗碗 机、冰箱、冰箱/冷冻箱组合、单独的冷冻箱、加热柜、冷冻柜、炉子、 炉灶面和炉子的组合、灶面等等。虽然所描述的发明环境是电器环境， 但是本发明可应用于具有联网部件的任何类型的机器。
如在此所述，内部通信网络14可以是任何公知的互连管道、线路 和/或导线或适于将家用电器12的各内部部件16互连的无线系统。如本 申请背景部分所述，WIDE网络是适于提供对于支持本发明的软件体系 10所必需的内部通信的内部通信网络14。对于本领域的技术人员来 说，软件体系10显然可以在任何合适的内部网络上运行，而且在此所 提供的示例性例子(即WIDE网络)只是合适的内部通信网络14的一 个示例。
如前所述，部件16是家用电器12的任何基于处理器的部件或子部 件。适于接收和安装根据本发明的软件体系10的部件16的例子包括但 不限于电机控制微处理器、微处理器使能的键区控制器、LCD用户接 口控制器和其它通常包含在家用电器12内的装置控制。
内部/外部接口连接器或槽18适于连接多种类型的装置20，这些装 置能够在内部通信网络14以及诸如RS-232系列、各种形式的无线网 络(Zigbee、Wi-Fi等)、USB或有线以太网等的至少一个其它网络上通 信。装置20的功能可以被严格限制为协议和物理层转换，或者可以被 扩展为除了其基本协议桥接功能(base protocol bridging function)之 外还支持增值服务。
软件体系10允许家用电器12连接到的外部客户机22的例子包括 但不限于基于个人计算机的控制开发件、工厂测试应用程序、诊断应用 程序、现场测试应用程序以及与所连接的家用环境的接口。与相邻于或 远离电器12的外部环境的这种连接使得增值应用程序可以与电器12通 信。一些例子是：
●自动化工厂测试
●能量管理应用程序
●工程开发工具
●电器维护和诊断工具
●电子控制制造功能性验证测试
●消费者应用程序等。
系统级体系(参与以实现家用电器的有用目的的机械的、电的以及 软件的元件)包括软件体系10和与软件体系10分离的软件元件。在 此，系统体系的部件的微处理器内的软件元件集合(包括但不限于软件 体系10)被称为软件运行环境16A。软件体系10由3个部分组成：核 心实施、应用协议定义、一个或多个应用程序接口(在此称为“API”或 “多个API”)。
核心实施
软件体系的核心实施是在电器控制微处理器中运行的软件模块的集 合(在图3的示例是SACore、SADiscovery、SADAQ、 SAPortMemory、SAPollVariable)。如图11所示，核心实施优选在电器 控制微处理器的主(MAIN)循环中执行，这对本领域技术人员来说是 显而易见的。该核心通过内部通信网络14提供通用应用消息收发层， 并且基于能开发交叉平台连接应用的灵活设计。作为核心实施的一部 分，存在在每个电器上统一实施的核心API。此外，在统一实施不实际 的地方，可以使用发现机制(discovery mechanism)，以允许客户机适 应该非统一性。
应用协议定义
协议是用于调节网络中节点之间的数据传输的标准程序。消息用数 据的一个或多个分组在内部通信网络中发送，这些数据分组随后集合起 来形成已通告的消息。关于软件体系10存在两种可应用的定义领域。
1.分组定义：是针对组成分组的字节集合内的每个字节或者其中 一个字节内的位或位区间的预定义含义。图4和图24及其伴随的描述 代表软件体系10的分组定义。
2.消息次序和消息收发规则：协议的定义通常超过了分组定义 (1)而包括管理消息的期望有序集合的规则，该消息是完成特定有用 事物所需要的。具有消息规则的有序消息(事物)的示例在图6、9、 27、29、31中示出。
应用编程接口
API是一种通信和消息收发的契约，其规定一个网络节点如何与其 它节点通信。这通过定义可获得的功能调用、每个功能调用的变量、每 个变量的数据类型以及在某些情况下每个变量的有效值来完成。
在很多情况下，API特定于应用或电器12，因此不认为是API核 心(标准组)的软件体系10集合的一部分；软件体系10核心可以启动 多个API并将这些API暴露给客户机16、22和可能20。
系统级别的体系
软件体系10被设计为随着时间完成若干目标。
1.在现有控制体系的约束内的业务生产力。
2.通过启动和实现新控制体系的业务生产力。
3.支持和更好地启动核心业务功能“创新”、“制造能力”、“质量” 和“维护能力”。
4.通过启动具有软件体系10的制造电器启动新的成长机会，该软 件体系10除了连接器18之外还产生“可连接的”电器。该策略通过具体 化联网电子装置的成本而将连接的风险和成本降至最低。
为了实现该体系的全部潜能，可以在电器12上提供简单的连接 器，使得可以将网络卡插入该电器中。参见图1和18-22中的连接到 电器12的合适外部NIC20的示例。由于电器12已经为其内部目的而具 有内部的低成本网络14，因此用于通过内部/外部接口18将内部通信网 络14与外部NIC20连接的其它连线降至最少，而且可以按照公知方式 完成，例如通过三线串行电缆、外部连接器和安装固定设备。
软件体系10优选可以驻留在家用电器控制系统的所有部件16上。 但是，在禁止成本或其它约束的地方，软件体系可以驻留在家用电器的 控制系统内的部件16的子集上。
该“可连接”体系的示例性优点包括但不限于：外部NIC20可以在交 易之后添加，从而降低电器12的基础成本。NIC20可以是已开发好的 支持多网络技术，由于软件体系10所呈现的标准接口应用和NIC可以 是交叉平台和通用的，内部低成本网络(如WIDE网络示例)用作标 准，API框架和发现允许很多增值命令，软件体系10使用受约束的事 件来保持状态和有效利用带宽，软件体系10被设计为在运行时接受配 置，从而给程序开发员一个更为灵活的、可以缩短市场化时间的体系。
图2是图1的内部通信网络14的示意图，示出根据本发明设置在 内部通信网络14和部件16内部的软件运行环境16A中的各种软件成分 16B之间的软件体系10，该部件16组成家用电器12的控制系统。图2 的部件16代表在电器12中找到的典型部件，如电器管理器(主板或母 板)以及其它部件如电机控制和控制面板或键区接口，通常称为用户接 口。图2中的“Energy”和“Diag”标记是通过软件体系执行的典型非核心 功能的示例，如能量和功率管理(“Energy”)和故障查找或诊断 (“Diag”)。未在图2中示出的是由软件体系执行并通过标记10代表的 核心功能(API1-7和10)。
此外，软件体系10可以扩展到很多期望通过对等通信交换数据的 其它类型的系统体系。这些系统体系包括多节点系统，其中多个PCB 如电机控制、电器控制和智能传感器板利用软件体系10在电器12内通 信。图6所示的(以及后面所描述的)软件体系10发现协议可用于使 部件16产生新的行为或性能或向消费者提供新的功能，该部件16的存 在促使其它部件16适应它们的控制功能。图2的部件体系(结构化模 型)以及图6的发现行为和API ID、类型、版本的部件标识(参见API ID＝3)是体现为10的本发明实现具有新动态和智能系统体系的电器的 基础。
图3是图1的内部通信网络14的示意图，示出通过家用电器12的 内部通信网络14交换消息的典型电器控制部件16，包括下层协议， WIDE是该协议的一个示例，该下层协议负责OSI层-PHY、LINK和 部分网络层的功能，以及由根据软件体系10支持的上层协议(负责 OSI层-应用层、传输层和部分网络层的功能)。下层协议用作与软件 体系10关联的高层和电器中的部件之间的物理和链接层。通过这种方 式，软件体系10使用下层协议与实现控制器16相对于客户机22的控 制逻辑的第一软件运行层17通信，也使用第二软件层19来绕过该控制 逻辑并直接控制与控制16关联的装置。图3的装置是代表控制部件16 的功能性的物理元件。图3从软件/协议堆栈的角度示出控制体系10。
此外，图3提供了通过软件体系10启动的两种运行模式的示意 图，这些模式控制软件体系10暴露的网络消息和内部RAM、EE和其 他形式的非易失存储器16A以及输出装置层之间的访问和干预级别，输 出装置层是低级别的软件运行层16B，驻留在16A之内并提供对电连接 到部件的装置的直接控制。直接控制装置的输出装置层16B通过直接访 问微处理器端口地址存储器来进行直接控制，该微处理器端口地址存储 器又映射到微处理器的物理管脚，该微处理器又通过各种电设备连接到 电机械装置。
图3的软件运行层1代表特定于电器的软件成分16B，其将软件体 系10接收的网络消息连接到应用控制逻辑，从而导致应用控制逻辑采 取某种动作。如果电器处于开发状态(图3中用A标记的开关)，则附 加的软件运行层2(由API5(下层API)和API7(存储器/端口API) 及其实施和替换逻辑)使得API5和API7的网络消息可以改变物理存 储器16A和装置的状态。通过这种方式，可以与通常根据软件运行层1 的运行循环控制装置和存储器的应用软件无关地控制该装置和存储器。 该直接控制允许该装置的每个功能都得到独立的控制，这在开发或诊断 过程中是非常有利的。
软件运行层2可以通过由软件体系10暴露的特殊的网络消息和为 电器的各种状态定制的附加逻辑来进行状态改变(图7所示的例子)。 在开发状态期间，优选在用户通过图3的用户接口与电器交互时，软件 运行层1不会接收有关的用户接口输入。而是由软件运行层2接收来自 用户接口的输入。接着，软件运行层2可以与图3的替换逻辑交互。替 换逻辑又可以对软件运行层1的控制逻辑进行功能调用，更改存储器中 的值，或者更改所连接的多个装置的状态。但是，在开发状态期间软件 运行层1不能实现用户接口(LED、灯、蜂鸣器、文本和图形显示器 等)的状态。开发状态促使软件运行层1的控制逻辑无效，除非从软件 运行层2调用。在开发状态期间，API5和7的实施逻辑以及替换逻辑 完全控制电器12及其关联部件。
当接收到特殊的网络消息时，开发状态返回到(图7的)空闲状 态。此外，预计一系列键按压中的至少一个预定键按压还可能导致从开 发状态转换为空闲状态。
软件运行层1与运行层2是否启动无关地运行。开发状态的目的是 允许和实现事先没有想到的运行循环。该途径的优点是在图1中示出了 一些的电器的实施和配置不需要对电器的任何部件16进行新的软件修 改，因为电器具有通过软件体系10来支持任何想到的实施或配置的能 力。
这种能力有很多用途。该用途包括但不限于：
1.可以向用软件体系10启动的电器添加新的功能部件，从而不需 要修改事先存在的功能部件就能完成新的行为特性和运行循环。
这样的例子包括：
a.向洗衣机、甩干机、炉子和微波炉添加流控制
b.向电器添加能量和其他资源管理部件
c.添加除了内部网络14之外还能连接到外部网络的联网部件
d.向商业电器添加读卡器以产生有偿使用使用模型。
e.添加包括用于由客户机节点或电器或与用户界面交互的用户选 择和调用的附加运行循环的存储装置。
2.执行诊断测试，该诊断测试可以通过促使每个输出顺序地验证 所期望的结果来完成(示例：加热器通电-观察到温度上升，进料阀通 电-观察到水平面上升，冰碾碎电机-观察到碾碎装置的旋转)
3.执行自动的成批测试
4.执行自动的性能测试和DOE实施
5.执行自动的寿命测试
6.执行部件16单位测试和自动的回归测试
7.执行自动的ECM测试
8.执行其他形式的特殊调试和测试
9.促使替换客户机装置(例如PC)控制电器12，以允许使用替换 的软件运行环境16A将可选择的运行循环域开发和测试为通常在最后生 产内嵌计算部件16上所需要的，该替换软件运行环境16A提供生产力 更高的编程环境，从而导致新电器模型的上市时间缩短。
图4是用于图1所示的家用电器12的内部通信网络14的分组结构 24的示意图，该分组结构具有有效载荷部分26，包括用于根据本发明 的软件体系10的应用分组结构28。分组结构28代表软件体系10可以 创建并发送给其它部件16和22(具有软件体系10或者设计为可用分组 结构28运行的软件体系10的变形)以用于有意义的数据交换的良好形 成的消息。分组结构28占据分组结构24内的位置26，但是分组结构 28可以在分组结构24的变形中占据替换位置。28A代表在28内根据分 组结构28的API Id和Op代码定义的分组结构。
在网络协议中，分组(有时也称为消息)是顺序发送的字节的集 合，代表一条完整消息的全部或一部分。通常，分组由包括路由信息的 标题、作为数据的主体(也称为“有效载荷”)和有时包含校验和(即 CRC和)或结束符如“结束”标志的尾部。有效载荷是包含在分组内的 字节的集合。有效载荷是在两个节点16的应用层之间传送的数据。网 络和协议的功能是将有效载荷从一个节点运送到另一个节点。有时一个 协议就作为另一个协议的有效载荷发送，按照这种方式协议可以嵌套或 形成堆栈。变量称为具有相关值的存储器位置。一个或多个变量可以包 括该有效载荷。事物是代表多个节点之间的完整数据交换的一系列消息 或分组。
分组和有效载荷之间的关系可以对可获得带宽的有效使用产生影 响。要考虑的权衡是在应用层要求的上下文中将有效载荷从一个节点传 送到另一个节点所需要的开销量。
协议分组结构24作为例如标识为oxED的第一标题字节，接着是 具有4个部分的地址字节。地址字节的第一部分包括第0、1、2位的目 标部分(D)。地址字节的第二部分包括第3位的广播部分(B)。地址 字节的第三部分包括第4、5、6位的源部分(S)。地址字节的第四部分 包括第7位的保留部分(R)。地址字节的后面是由包括0-3位的维护 数据单元长度(SDU-L)和包括4-7位的SAP标识符组成的标识字节。 SAP标识符定义所附有效载荷26的结构。SAP4表示所附的SDU26由 与软件体系10关联的分组结构28定义。标识字节后面是维护数据单 元，其通常称为协议分组结构24的“有效载荷”并且通常由附图标记26 表示。有效载荷26后面是标准有效字节，如高字节、低字节组合，或 被本领域的技术人员统称为CRC16-CCITT。
应用分组结构28由协议分组结构24的有效载荷部分26形成。在 该应用分组结构28内执行由软件体系10允许的通信协议和数据交换。 应用分组结构28的第一字节包含由应用分组结构28的特定实例携带的 标识符(API ID)，是1-255的整数。应用分组结构28的第二字节在操 作码中(在此缩写为op码)包含1-31中的一个整数在位0-4，后面是 位5的命令或反馈(Cmd/Fb)标志、位6的分区(Flag)标志，以及 位7中的更多消息等待(MMP)标志。应用分组结构28的字节3-15包 括应用分组结构28的特定实例的有效载荷(即消息数据)。
基本上，软件体系10使用内部通信网络14的网络分组结构24的 两个字节的有效载荷26来用于附加协议。API ID是组织为功能单元的 Op码集合的唯一标识符。0xFF(255)和0x01(1)优选是保留的。Op码是 API内的唯一ID，其定义和标识单个的命令或反馈消息。每个API是 有关的类型(两个字节)和版本(两个字节)，从而允许随着时间创建 可识别、功能上相关的消息(op码)组的大型库。
优选的，x1F(31)是用于Op码的保留值。Cmd/Fb标志表示该消 息被分类为命令还是反馈。命令是要求采取行为的某种消息，而反馈是 只包含信息(确认，事件数据等)的某种消息。优选的，Cmd/Fb标志 对命令是0，对反馈是1。
Frag标志指明所接收的消息是否被发送者因为下层协议SDU26的 大小限制而分为多个消息(片段)。该消息的第一片段采用图4的结 构。该消息的所有随后的片段采用图24的结构。Frag标志优选一直置 位到分段的消息结束为止。
MMP标志表示事件作为单个消息发送但是通过协议约束在一起， 从而客户机可以将事件分组在一起作为微控制器的一次扫描的完整快 照。MMP标志优选一直置位到快照的最后一条消息发送出去为止。图 9以及伴随的讨论提供了关于约束消息的更多细节。
MMP标志向软件体系10提供了将电器12的状态表达为在快照中 约束在一起的独立含义的反馈变量的函数的能力。
当电器12的内部状态改变时，可能发送多个事件，这些事件合起 来描述电器12的新状态。描述状态变化所需要的事件数量是特定于电 器12的状态的。因此，使用特殊协议分隔符来允许数量特定于实施方 式的反馈变量与特定的电器状态变化关联。由于这些事件是有独立含义 的，因此该途径是优选的，因为事件(数据)集合的所有排列可以通过 使用MMP来创建。这导致标识命名空间(API Id和Op码)的有效使 用，因为在客户机要求发送新的数据组合时不需要新的标识符。总的来 说，MMP及其有关规则允许动态和虚拟的数据集合，从而消除了对特 定于特殊应用情况的解决方案的需要。在图9中，示出MMP标志的净 效应。
MMP标志还为内嵌的实施提供了抑制无效瞬时条件的能力。作为 电器状态转换，一组相关变量可以非常快速地变化几次。当电器状态用 作为单独的事件发送的独立反馈变量(反馈消息)表达而没有结合机制 时，可能发生模糊或无效的瞬时状态。此外，如果客户机在无效瞬时状 态期间执行业务逻辑，则逻辑错误可能导致不正确的控制或用户显示行 为。因此参照称为“状态完整性”的这一节来获得关于异步数据收集如何 是在微处理器的每次扫描内同步收集并且在MMP启动的快照内传送的 数据的次等途径的示例。此外，消息结合可以用于将独立的命令调用组 合在一起，从而可以批量处理这些命令调用。
应用协议28还管理进入的消息。总的来说，网络允许异步过程通 信，从而通过在短的时间窗内发送过多请求为一个网络接点产生超过另 一个网络节点的处理能力的潜力。为了防止消息超出限度，根据本发 明，采用允许发送者在发送第二个消息之前等待确认的协议。
该特征允许软件体系10基于软件体系10的执行状态8为该确认使 用枚举。通过这种方式，描述消息成功或失败的必要信息只用很少的消 息传达。命令发送者对发送的每条命令都接收枚举的确认。最普遍的是 积极的ACK，这表示该节点准备好接收下一条命令。所有其它枚举都 是故障的形式。故障的特征是确认字节的剩下254个可能的值。在该 254个值的范围内，一些得到标准化，一些保留给特定于应用的故障 码。
Frag和MMP允许软件体系10的用户在设计应用消息收发策略时 具有灵活性。如果开发人员选择使用非常大的消息，则可以使用Frag， 从而可以通过将原始的大数据组作为结构28的多个分组内的多个较小 的数据组来发送大于有效载荷28A的消息(即在此所示的示例性应用分 组结构28内的13个字节)。
通过相同的令牌，如果开发人员选择使用较小的消息(情况通常如 此)但是期望将这些消息组合在一起，则可以使用MMP。例如，如果 3个字节的10条消息分别需要作为一个组发送从而客户机应用可以知道 这些消息与微控制器的同一次扫描有关，则前面的9个消息具有被置位 的MMP，后面的消息组具有MMP＝0。
下面给出为软件体系10定义的API的总结，然后详细描述每一个 命令和反馈消息。该途径的优点是允许开发人员选择软件体系10内是 用于开发的当前阶段的模块(即单元测试、工程测试、产生等)。此 外，编辑某些模块使得开发者可以在禁止RAM/ROM资源的情况下使 用部分软件体系10。API用它们当前选择的应用程序接口标识符(API ID)来描述，但是可以采用任何标识符而不会脱离本发明的范围。由该 特定API实现的有关功能在每个API下面列举出来。圆点功能(“●”) 是从软件体系10发送给客户机(例如内部客户机16或外部客户机22) 的反馈消息，非圆点功能是从客户机(16，22)发送给软件体系10的 命令。
注意到在本申请中使用了约定俗成。“扩展”是指一个API可以建立 在基本级别API的功能之上的能力。扩展关键字表示：当APIx“扩 展”API y时，API x＝API x+API y。该注解简化了记录保存和API存档 的任务。换句话说，API x还包括在API y中规定的功能。如果API x 和API y分别指定具有相同Op码的功能，则API x实施的实现可优先 进行。
下面的表格描述核心API(API ID＝1)：
●消息确认 ●公布Heartbeat ●设置Heartbeat阶段 ●新的Heartbeat阶段 ●读取存储器 ●公布存储器数据 ●读取EE ●公布EE数据 ●发送事件 ●公布事件
下面的表格描述了基本数据获取API
(基本DAQ，API ID＝2，类型＝1)：
●创建数字事件 ●创建字节事件 ●清除事件 ●公布清除的事件 ●复位SA ●公布复位的SA ●置位外部接通 ●公布外部接通 ●置位外部断开 ●公布外部断开
下面的表格描述扩展的数据获取API(扩展的DAQ，API ID＝2， 类型＝2)：
扩展的DAQ包括运行时的基本DAQ。
●获得事件数据 ●公布数字事件数据 ●公布字节事件数据 ●建立远程数字事件 ●建立远程字节事件 ●获得远程变量数据 ●公布远程变量数据
下面的表格描述发现API(API ID＝3)：
●找到节点 ●公布节点 ●获得API ●公布API ●获得API信息 ●公布API信息 ●获得实例信息 ●公布实例信息
下面的表格描述核心调试API(API ID＝4)：
●公布饱和 ●饱和消息的寄存
下面的表格描述下层API(API ID ＝5)：
●置位开发状态 ●公布状态 ●TBD(特定于电器)
下面的表格描述核心键按压API(API ID＝6)：
●按压键(键索引) ●公布键按压(键索引)
下面的表格描述核心存储器/端口API(API ID＝7)：
●写入存储器 ●写入EE
能量管理API是API ID＝8。与其他API一样，能量API由Op码 的集合组成，每个Op码代表涉及能量管理的有用功能，并且具有是达 到这些功能的合适参数的关联字节集合。
下面的表格描述轮询变量API(API ID＝10)：
●读取轮询变量 公布轮询变量
核心API(在此API ID＝1)是可以部署的软件体系10的最小子 集。但是，可以想到开发与分组结构28兼容的其他实施例。规定设计 参照图5的两个硬编码的数据获取机制。
在核心API中，一种协议机制即图5的发送事件允许客户机(16， 22)请求事件源发送所有事件或发送一套特定的事件。通过这种方式， 在事件体系的框架内实现轮询类型而无需单独的消息定义或实施结构和 逻辑。此外，该机制实现了文件的系统启动条件。例如：如果所有网络 节点在系统通电时同时发送所有事件，在客户机16或22的软件内更可 能发生误操作，其中在此的软件成分由于通电条件而不能准确处理多个 消息。
DAQ API(API ID＝2)代表由软件体系10实现的用于部件16的 动态机制查询。该特征允许客户机16/22配置内嵌的软件引擎(一种结 构阵列，该阵列的元素实例化和存储在动态存储器堆(heap)【参见图 33的DynamicMemoryHeap，包含NVOEvent结构的集合】)，该软件 引擎将一部分微处理器存储器与事件操作码(描述在下面的表格中)和 变量关联。指向存储器的指针、存储器的值、事件操作码和操作码变量 存储在存储器堆的结构阵列中(图33包含NVOEvent结构的 Heap[])。如图5所示，DAQ引擎可以用两种方式配置：
1.驻留在相同微处理器中并与软件体系10分离的应用软件可以按 照图5的箭头所示从DAQ Init()软件成分来配置DAQ30。
2.其次，外部客户机可以使用DAQ API(在此所述的)从网络14 配置DAQ。
每一种DAQ配置方法的有理数分为3段讨论。
如在图36的处理DAQ时间状态图中所示，在执行DAQ引擎时， DAQ引擎对每个事件结构迭代，从而针对事件操作符和变量检查关联 的存储器位置。如果事件条件估计是真，则消息缓冲器在内部存储器内 构成从而反映与该事件条件关联的数据。如果迭代完成，则产生通报消 息并优选广播给网络。替换的，通报消息可以发送给特定的部件16，如 果分配附加的存储器来存储最初请求或配置该事件的部件的网络标识 符。
开发人员可使用几个事件操作符。例子包括：正在改变(on change)，大于，小于，等于，死带(deadband)，位掩码等。提供 DAQ API的几个Op码用于在运行时控制存储器堆，如：清除事件，添 加事件，外部通报接通/关闭，获得事件，获得事件数据等。
总之，软件体系10支持用于数据收集的4个机制(所有机制都在 图5中示出)。如上所述的4个机制中的两个机制取决于DAQ。另外两 个机制也在上面简要描述过，是硬编码的。每个机制可以共存在软件体 系10内。每个机制以消耗其它资源为代价提供某种优化。
1.在客户机配置的数据获取机制中，产生动态事件。如果微处理 电器有足够的RAM/ROM容量则可以使用该方法，而且如果客户机是 PC应用时该方法用得最普遍。利用DAQ API，开发人员可以再使用代 码，需要更少的引擎时间，平衡已证明可再使用的事件模块，很灵活 (例如可以在运行时配置)，而且存在网络带宽的优化。但是，该方法 比硬编码方法需要更多的RAM/ROM，而且内嵌的客户机不能在运行 时访问所需要的数据文件。
在客户机配置的数据获取机制中，DAQ引擎30必须具有存储器位 置以便观察事件。对于变量映射，在客户机是如图26所示的PC应用时 这是很实际的。但是，当客户机例如是实施软件体系10的其他控制板 时，访问变量映射是不实际的。因此，本发明为位于实施软件体系10 的节点的存储器中的内嵌变量映射提供了功能。该变量映射将API和 Op码与如图26B所示的变量地址连接起来。因为为了在所述节点上注 册事件，该客户机只需要知道该变量的API和Op码，而不是具体的存 储器地址。
利用内嵌在由客户机配置的数据获取机制中的变量映射，可能出现 限制特定客户机创建事件的情况，因为相关的API和Op码对已经由其 它节点注册。在这种情况下，本发明向该节点提供请求关于该内嵌的变 量映射的信息的功能。在该信息中包含了变量的存储器地址。利用该信 息，客户机节点可以采用该变量的地址和不同于事先尝试的API与Op 代码对来注册同一变量的事件(参见图27)。
2.由客户机配置的DAQ是自配置的DAQ。在这种情况下，内部逻 辑使用DAQ引擎在图33的DynamicMemoryHeap中创建NVOEvent 结构。这在要实现的事件在设计时是固定的且已知的，而且存在足够的 RAM和ROM资源来再使用DAQ30的不同引擎(包含在DAQ30内的 逻辑)时是一种有用的机制。因此该方法具有与由客户机配置的动态事 件机制相同的优点，而且比(下面描述的)硬编码方法需要更多的 RAM/ROM。
3.在硬编码事件模块中，开发人员可以优化网络带宽，优化 RAM/ROM的使用以及适应DAQ API。但是，该机制需要定制编码的 解决方案来产生事件，而且不依赖于图36所示的DAQ30的软件和逻 辑。
4.利用核心API提供的硬编码的轮询方法，开发人员可以通过创建 定制编码的解决方案来优化RAM/ROM的使用。轮询一般是浪费网络 带宽的，但有时候也因为其简单性而使用。
图5示出每种类型的潜在数据获取方法的一个示例。软件体系10 的安装可以支持这4中方法中的一种、一些或全部。安装10和客户机 16分别可以具有在它们上面初始化的DAQ API。软件体系10可以具有 一个或多个硬编码的轮询变量、一个或多个硬编码的事件、和/或所述的 DAQ引擎30。各种变量和事件在主软件体系安装和客户机之间传输。 例如，各种硬编码的轮询变量在软件体系10和客户机16之间通过读取 轮询变量和公布轮询变量方法来交换。各种硬编码的事件在软件体系10 和客户机16之间通过发送事件和公布事件方法来交换。创建事件方法 由发送给DAQ引擎30的DAQ Init引擎调用，该DAQ引擎30又与客 户机16通过发送事件和公布事件方法来交换产生的事件。软件体系10 中的DAQ引擎30还可以创建通过从客户机16接收的创建事件方法所 接收的事件。
图5A是示出安装了根据本发明的软件体系10的家用电器12和位 于远处的客户机16之间的通信的示意图，该客户机16例如是如图5A 所示的顾客呼叫支持中心。电器12具有连接到其内部网络14的接口 18，和能使电器12与外部客户机12通信的网络接口20.图5A的示意图 示出顾客服务中心，其使用DAQ引擎5创建事件功能建立起变量监视 并诊断家用电器12的毛病而不需要向住地发出服务车。
软件体系10可以定制为考虑不同实施平台的需要。RAM和ROM 空间和时间的复杂性是可以管理的，对存储器位置的访问以及断开时间 也是可以管理的。所有这些都位于预定的参数文件中。应当理解这些参 数可以重新命名、更改、重新打字、添加或删除而不会脱离本发明的范 围。
发现API(API ID＝3)实现了“Plug’n Play(即插即用)”体系的 概念。发现API暗示物理网络节点或客户机16可以获得n个功能，每 个功能都由公知的、具有唯一ID、类型和版本的API封装。这些API 是便携式的(意味着他们代表功能而且与微处理器、软件语言和网络拓 扑结构无关)而且可在其它可应用其中的功能的部件上重新使用。发现 协议(在图6的API3中描述)允许客户机学习部件16和部件16包含 的功能组(API)之间的关联。
图6示出典型的发现API序列。由于在存储器中没有代表其它由软 件体系10启动的部件的结构，客户机16、22发送命令以找到电器内由 软件体系启动的部件16(通过发布“找到节点”的命令)。启动的部件回 答说它们确实已经启动(通过发布广播的“公布节点”命令)。然后，客 户机16发送命令以识别在每个启动的节点上存在什么样的API(通过 发布“找到API”命令)。每个已启动的节点用包含其API ID的有界消息 回答(通过用“公布API”消息来回答)。然后，客户机16、22发布命令 以识别关于在每个已启动的节点上找到的各API的信息(通过发布“获 得API信息”命令)。每个已启动的节点用包含关于该节点具有的API 的信息的有界消息(该消息的目的和结构在图9中描述)来回应。该消 息可以包括特定API Id的类型、版本和发生次数(或实例个数)。在一 个部件16内的特定API的实例个数超过1的情况下(意味着有多个相 同的API安装在部件16上，例如可能使用多个炉子控制API的一个多 灶炉子的情况)，客户机16发布命令以获得关于每个API实例的信息 (通过发布“获得实例信息”命令)。软件体系10用请求的信息来响应 (通过“公布实例信息”命令)。多个相同的实例由软件体系用伪API ID 自动编号。
此外，当由软件体系10启动并具有软件体系10的子部件即API Id ＝3的Discovery的部件16初始化时，该部件16自动发送宣布自己的 消息(API点＝3，Op码＝2publishSANode())。
而且，如果软件体系的用户这样选择，则图6的Discovery序列可 以通过省略消息1和2(Op码分别是1和2)来更改。该方法是有效 的，因为客户机可能通过发布Opma＝3消息，即导致由软件体系10启 动的所有部件都响应的getSAAPI(collection)来初始化发现，因此在大多 数情况下避免了对消息1和2的需要。
还想到缩写的消息序列可以达到与上述发现序列相同的结果。在缩 写的发现序列中，每个节点在通电之后发布在一条消息内包含在上述发 现序列中的全部信息的消息。接收该消息的每个节点用关于其自身的相 同信息答复，从而向刚刚通电的节点提供来自所有已经通电的节点的可 发现信息。
发现API协议机制允许客户机16在运行时找到本地实体而不需要 事先的编译时间编程。此外，该机制允许客户机16确定所期望的部件 是存在还是没有。根据这样的知识，客户机可以配置自身和/或向用户提 供合适的推断的功能。
下层API(API ID＝5)通过网络14暴露允许客户机控制(激活) 电连接到包含部件16的输出装置以及提供对代表电连接的输入装置的 当前状态和可能的状态历史记录的数值进行读取和/或写入访问的功能。 典型的输出示例是阀门、继电器、可控硅开关元件、LED、灯、蜂鸣器 等等。典型的输入示例是按下键、开关、传感器(例如压力、温度和超 温度)等。在优选实施例中，下层API以及存储器-端口API只在电 器12的软件体系10的图3的“开发状态”下才可获得。“开发状态”只能 从图7的示例性电器状态图的电器12的“空闲状态”进入。而且在该优 选实施例中，如果任何用户接口行为是在“开发状态”期间通过键区、 LCD或电器12的其他用户接口装置初始化的，则电器12可以回到图7 的“空闲状态”，并设置每个输出返回其未激活状态。用于初始化“开发 状态”的消息可以在下层API的消息定义规范中找到。(参见API5，Op 码2)。该网络消息定义为允许电器12进入开发状态。在开发状态下， 启动特殊的API并暴露给网络14，该API允许客户机16直接控制电器 12的电子输出。在开发状态下，面向生产的业务规则如确认被绕过，从 而给予客户机16对电子子系统的完全控制。
下层API可用于实施电器的非标准操作，因为电器可以按照不是根 据由驻留在主控制器上的电器软件运行层实施的预定运行循环之一的方 式来运行。通过这种方式，下层API可以认为是启动附加的运行循环。 附加运行循环的一些示例包括：示范循环；开发循环；检错循环；诊断 循环；减少预定运行循环之一的至少一个时间步骤的时间的循环；绕过 预定运行循环之一的至少一个运行步骤的循环；代替响应预定运行循环 之一的事件的步骤的定时步骤的循环；以及将下层API暴露给网络的循 环。
键按下API(API6)允许客户机16按下虚拟键。这提供了用于了 练习和测试软件的等价方法而无需物理键区的机械或人工激活。
注意在本申请中使用的约定俗成。“扩展”是指一个API可以建立在 基本级别API的功能之上的能力。扩展关键字表示：当APIx“扩 展”API y时，API x＝API x+API y。该注解简化了记录保存和API存档 的任务。换句话说，API x还包括在API y中规定的功能。如果API x 和API y分别指定具有相同Op码的功能，则API x实施的实现可优先 进行。
家用电器的内部通信网络所采用的分组结构的有效载荷部分的示例 性应用分组如下所示。该应用分组根据API分组。
核心API：API ID＝1(类型3，版本1)。下面的应用分组代表从 软件体系10指向客户机10的用于发布确认的消息(发布确认)。该消 息由软件体系10发送给前一消息的发送者。该消息包含代表由软件体 系10处理的前一命令的结果的列举值。一般来说，确认的接收表示发 送者可以初始化下一条消息。
API ID Op码 字节3 字节4 字节5 1 1:公布确认 原因代码 API OpCode
注意事先接收的命令(正在确认的命令)的API和op码包含在有 效载荷的字节4和字节5中。这向确认的接收者(发送原始命令的部件 16)提供关于事先发送的命令正在得到确认的确定性。(事先发送的命 令具有API Id和Op码的唯一标识符)。应当注意在附图和说明书中， 一般假定ACK而且该ACK不连续重复或存档，上述应用分组的原因 代码的列举值在下面的表格中示出。
原因代码的列举值 原因代码名称 编程注释 0 READY＊ 该命令被成功执行，SA准备好接受其它 命令。 1 BUSY＊ SA模块当前忙于执行命令。通常只是内 部状态。 2 REJECTED＊ 发送给SA的命令遭到拒绝，因为还有另 外的命令仍在处理中。 3 ACK_EVEVT 该命令没有执行，因为SA当前正在等待 确认。 4 UNSUPPORTED 该命令因为某种原因没有受到支持并且不 执行。(准备好下一条命令) 5 UNSUP_OP_CODE 该命令由于无效的Op码而不被支持且不 执行。 6 UNSUP_UNAVAILA BLE 该命令由于当前在该状态下不可获得而不 被支持且不执行。(就绪) 7 UNSUP_INVALID_P ARAM 该命令由于无效或超出有界参数而不被支 持且不执行。(就绪) 8 UNSUP_OUT_OF_ MEMORY 该命令由于动态heap被忘记而不被支持 且不执行。(就绪) 9 UNSUP_DOOR_OP EN 该命令由于电器门打开而不被支持且不执 行。(就绪) 10 UNSUP_BOUND_C MD_INCOMPLETE 该有界命令在指定的暂停时间之前没有被 完全接收，从而没有完全执行。(就绪) 11 UNSUP_CANNOT_ PAUSE_NOW 由于电器处理的状态而不能暂停。 200-255 特定于应用 应用开发人员可以在其应用中使用这些返 回值。由开发人员决定是否存档这些特定 于应用的原因代码。
＊0-3保留给软件体系10使用
下面的应用分组代表从软件体系10向客户机(16或22)的用于公 布heartbeat的广播消息(公布heartbeat)。该消息定期地由软件体系 10发送。这使得注册了事件的节点可以在事件源中保持信心。换句话 说，heartbeat保证连接的完整性。可替换的，客户机(16或22)可以 确定，在软件体系10相信与产生和发送事件关联的事务结束之前，由 软件体系10发送的每个事件或一些事件应当接收由客户机发送给软件 体系10的确认。如果特定的事件是用根据消息说明API2，Op码＝1， 2，12或13的“确认”的分类符创建的，则在接收到根据由API Id1和 Op码1指定的消息的确认消息时，软件体系10定义与产生和发送该事 件关联的事务已经完成。
公布Heartbeat在软件体系10接收到命令之后才会发送。这可以用 于防止在通电期间的通信量阻塞。(通信量阻塞是指客户机16或22的 软件内的误操作，其中客户机16或22内的软件成分不能准确地处理由 于通电条件而产生的多个消息)。公布Heartbeat将被暂停到接收了复位 SA消息之后，该复位SA消息将在下面针对核心DAQ API和Op码8 描述，但是公布Heartbeat会在下一条命令之后恢复。这是反馈消息。
API ID Op码 字节3-字节F 1 2:heartbeat
下面的应用分组代表从客户机指向软件体系10的用于设置 heartbeat周期的消息(设置Heartbeat周期)，该消息设置软件体系10 发送heartbeat消息的频率。示例性的频率范围从0秒(不发送)到 3600秒(1个小时)。
API ID Op码 字节3 字节4 字节5-字节F 1 3: setHeartbeatPeriod Sec MSB Sec LSB
下面的应用分组代表从软件体系10到客户机的用于发布heartbeat 周期的消息(发布Heartbeat周期)。该消息是对设置Heartbeat周期的 响应。该消息是必要的，因此如果第二客户机更改了该heartbeat周 期，将通知第一客户机。需要不变的heartbeat周期的客户机应当是用 DAQ API来建立具有恒定广播操作符的事件，参见DAQ API Id＝2， Op码1，字节9＝4，5或6(参见更改操作符表格)。
API ID Op码 字节3 字节4 字节5-字节F 1 16: newHeartbeatPeriod Sec MSB Sec LSB
下面的应用分组代表从客户机到软件体系10的用于读取存储器尤 其是RAM的消息(读取存储器)。该消息发送给软件体系10，并导致 “公布存储器数据”的响应，该消息在下面示出(Op码4)并且包含在下 面分组的字节3-7中指定的值。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节8 -字节 F 1 5:readMemory 地址 高字节 地址 中间字 节 地址 低字节 大小 MSB 大小 LSB
下面的应用分组代表从客户机导向软件体系10的用于读取存储器 的消息(读取)。该消息发送给软件体系10并且导致“公布数据”的响应 (Op码＝8)，该消息在下面示出并且包含在下面的读取分组、字节3- 7中指定的值。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节8 -字节 F 1 6:readEE 地址 高字节 地址 中间字 节 地址 低字节 大小 MSB 大小 LSB
下面的应用分组代表从软件体系10指向客户机的用于公布存储器 数据的消息(公布存储器数据)，并且是读取存储器的响应。
API ID Op码 字节3 字节4 字节5 字节6 字节n 字节8 -字节 F 1 4:publishMemoryData 数据 MSB 数据 数据 ... 数据 LSB
下面的应用分组代表从软件体系10指向客户机的用于公布EE存储 器数据的消息(公布EE数据)，并且是读取EE的响应。
API ID Op码 字节3 字节4 字节5 字节6 字节n 字节8 -字 节F 1 8:publishEEData 数据 MSB 数据 数据 ... 数据 LSB
下面的应用分组代表从客户机指向软件体系10的用于发送事件的 消息(发送事件)。该消息指示软件体系10发送指定的事件而不考虑事 件触发判断标准。
注意：事件Id是与Op码同义使用的。在描述作为API一部分的 事件时，事件Id是用于Op码的更具说明性的术语。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节 8- 字节 F 1 7:发送事件 API id (0xFF＝ 全部) EventId# (0xFF＝ 全部) EventId# EventId# EventId#
注意：下面使用的注释在本文件中通篇重复并只在这里描述。如果 字节3包含保留值0xFF，则软件体系10将字节3解释为代表所有API Id。否则，字节3就指定特定的API Id。类似的，如果字节4包含 0xFF，则软件体系10将字节4解释为代表在字节3中指定的一个或多 个API的所有事件。否则，字节4就包含一个事件Id。字节5到字节n 包含一个事件Id。
下面的申请分组代表从软件体系10指向客户机的用于发布时间的 广播消息(发布事件)，并且是上述发送事件消息的响应。替换的，如 果正在使用DAQ引擎，则当满足事件触发判断标准时发送该消息。下 面，API Id和Op码注释为“由客户机定义”。这是指API ID和Op码 由DAQ API(API Id＝2)的createEvevt命令(由客户机发送)分配， 具体在Op码1和2的字节7和8以及Op码12和13的字节3和4 中。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节8 -字 节F 由客户 机定义 由客户机定义 数据 MSB 数据 数据 ... 数据 LSB
核心DAQ API：API ID＝2(类型3，版本1)。下面的应用分组代 表从客户机指向软件体系10的用于创建数值事件的消息(创建数值事 件)。通过API Id＝2和Op码＝1或2标识的该消息允许客户机创建和 配置反馈变量[图33的NVOEvent结构]。字节7和8用于分配将用于 在事件条件使得事件消息得以产生时填满公布事件消息(API Id 1)中 的字段的标识符(API Id和Op码)。所产生的事件消息是在前面对核 心API的描述中找到的形式，其中对消息分组标以“公布事件”。标识符 API Id和Op码分别位于公布事件消息的字节1和2中。在这些字节中 找到的值可以通过下面为DAQ API、Op码1和2定义的消息分配。字 节3-5包含软件运行环境的存储器中的地址，该软件运行环境将用于 通过作为估计规则的列举的字节9以及作为估计规则的变量的字节A和 B代表的事件条件作估计。字节6指定应当相对于字节9、A和B被估 计为单个数值的相邻字节的数量。
在该节示例性应用分组之后将详细讨论与上述应用分组的字节9关 联的事件操作符，并且在标明在创建基于数字的事件时可获得的事件操 作符的表格中示出。另外，字节C还对应于导致确认事件或未确认事件 (下面讨论)的分类。参见图29中确认事件的操作的例子。
下面的应用分组代表从客户机指向软件体系10的用于创建字节事 件的消息(创建字节事件)。通过API Id＝2和Op码＝1或2标识的消 息定义允许客户机创建和配置反馈变量(事件)。Op码2的消息规格的 目的是类似的，但是具有为某些应用使用情况提供用途的不同的实施方 式。API Id2和Op码2在功能上与API 1和Op码1的不同之处在于， 依据字节A的值确定是通过字节3-5和字节6指定的范围内的仅一个 字节还是所有字节都基于字节9的更改操作符和字节B的更改值来估 计。而在Op码1的情况下，所指定的直接被估计为一个数字。在Op 码2的情况下，根据在字节A中指定的值，每个字节或仅一个字节将根 据字节9中指定的更改操作符和字节B中指定的更改值来独立地估计。
在该节示例性应用分组之后将详细讨论与上述应用分组的字节8关 联的事件操作符，并且在标明在创建基于字节的事件时可获得的事件操 作符的表格中示出。另外，字节C还对应于导致确认事件或未确认事件 (下面讨论)的分类。参见图29中确认事件的操作的例子。
下面的应用分组代表从客户机指向软件体系10的用于清除事件的 消息(清除事件)。清除事件消息允许客户机清除事先用创建事件Op码 (1或2，如上所述)创建的事件定义。如果需要在多条命令之间进行 同步，客户机可以用MMP标志向软件体系10发送多个清除事件命 令。
API ID Op码 字节3 字节4 字节5 字节6 字节n 字节 8- 字节 F 2 3:clearEvent API Id (0xFF＝ 全部) EventId# (0xFF＝ 全部) EventId# EventId# EventId#
下面的应用分组代表从软件体系10到客户机的用于公布事件被清 除的广播消息(公布事件被清除)，并且是清除事件的响应。该消息通 知软件体系10的客户机何时从现有的软件体系节点接口中去除Op码或 API。
下面的应用分组代表从客户机到软件体系10的用于复位软件体系 10的消息(复位SA)。复位SA命令指示软件体系10重新初始化到好 像刚开始通电时。
API ID Op码 2 8:resetSA
下面的应用分组代表来自软件体系10的广播消息，用于通知软件 体系10已经复位(公布SA复位)，该消息是复位SA的响应。
API ID Op码 2 9:publishSAReset
下面的应用分组代表从客户机到软件体系10的用于打开针对指定 事件的外部通告的消息(接通外部)。该命令指示软件体系10向外部向 客户机通告该事件。参见图28中使用该命令的示例。
API ID Op码 字节3 字节4 字节5 字节6 字节n 2 10:setExternalEventOn API Id OpCode OpCode OpCode OpCode
下面的应用分组代表来自软件体系10的用于通知指定事件的外部 通告已经打开的广播消息(向外部公布打开)，并且是接通外部的响 应。参见28中该命令的结果的示例。
API ID Op码 字节3 字节4 字节5 字节6 字节n 2 10:publishExternalOn API Id OpCode OpCode OpCode OpCode
下面的应用分组代表从客户机指向软件体系10的用于关闭指定事 件的外部通告的消息(关闭外部)。该命令指示软件体系不向外不向客 户机通告该事件。
API ID Op码 字节3 字节4 字节5 字节6 字节n 2 11:setExternalEventOff API Id OpCode OpCode OpCode OpCode
下面的应用分组代表来自软件体系10的用于通知指定事件的外部 通告已经关闭的广播消息(向外部公布关闭)，并且是关闭外部的响 应。
API ID Op码 字节3 字节4 字节5 字节6 字节n 2 10:publishExternalOff API Id OpCode OpCode OpCode OpCode
核心DAQ API：API ID＝2(类型4，版本1-扩展类型3，版本 1)。下面的应用分组代表从客户机指向软件体系10的用于获取事件数 据的消息(获取事件数据)。获取事件数据指示软件体系10发送指定数 据的定义。该定义是在创建事件Op码消息中发送的数据的镜像，该消 息在上面作为核心DAQ API的Op码1或2示出。软件体系10用公布 事件数据消息的集合响应，这些消息如下所示。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节 8- 字节 F 2 5:getEventData API id (0xFF＝ 全部) EventId# (0xFF＝ 全部) EventId# EventId# EventId#
下面的应用分组代表从软件体系10指向客户机的用于公布数字事 件数据的消息(公布数字事件数据)，并且是获得事件数据的响应。每 个事件定义都在分离的内部网络消息中报告，并且通过与图4的28的 MMP标志关联的快照规则管理。事件定义包含关于在创建数字事件中 的事件的信息。
在该节示例性应用分组之后将详细讨论与上述应用分组的字节8关 联的事件操作符，并且在标明在创建基于数字的事件时可获得的事件操 作符的表格中示出。
下面的应用分组代表从软件体系10指向客户机的用于公布字节事 件数据的消息(公布字节事件数据)，并且是获得事件数据的响应。每 个事件定义都在分离的内部网络消息中报告，并且通过与图4的28的 MMP标志关联的快照规则管理。事件定义包含关于在创建字节事件中 的事件的信息。
在该节示例性应用分组之后将详细讨论与上述应用分组的字节8关 联的事件操作符，并且在标明在创建基于字节的事件时可获得的事件操 作符的表格中示出。
下面的应用分组代表从客户机指向软件体系10的用于创建远程数 字事件的消息(创建远程数字事件)。该消息允许客户机或内嵌系统中 的其它模块使用内嵌变量映射来配置与现有的API和Op码关联的反馈 变量。尽管数量可以是4个字节，更改值可限制为两个字节。图26B示 出内嵌的变量映射。图27定义3个网络节点之间的交互，其中节点A 在节点B上成功创建远程数字事件。节点C试着进行相同的工作，但 是通过与节点B的交互，这可以完成该请求的目的而不需要复制标识符 (API和Op码)。其完成的原因是因为节点C可以向节点B查询存储 器中初始标识符的地址，从而可以选择替换(非复制的)的标识符。然 后将该替换的标识符用于通过向具有原始存储器地址和替换标识符的节 点B发送(参见图27中的消息8)新消息来创建远程数字事件。
图26B示出内嵌的变量映射。图27定义3个网络节点之间的交 互，其中节点A在节点B上成功创建远程数字事件。节点C试着进行 相同的工作，但是通过与节点B的交互，这可以完成该请求的目的而不 需要复制标识符(API和Op码)。其完成的原因是因为节点C可以向 节点B查询存储器中初始标识符的地址，从而可以选择替换(非复制 的)的标识符。然后将该替换的标识符用于通过向具有原始存储器地址 和替换标识符的节点B发送(参见图27中的消息8)新消息来创建远 程数字事件。
下面的应用分组代表从客户机指向软件体系10的用于创建远程字 节事件的消息(创建远程字节事件)。该消息允许客户机或内嵌系统中 的其它模块使用内嵌变量映射来配置与现有的API和Op码关联的反馈 变量。
图26B示出内嵌的变量映射。图27定义3个网络节点之间的交 互，其中节点A在节点B上成功创建远程数字事件。节点C试着进行 相同的工作，但是通过与节点B的交互，这可以完成该请求的目的而不 需要复制标识符(API和Op码)。其完成的原因是因为节点C可以向 节点B查询存储器中初始标识符的地址，从而可以选择替换(非复制 的)的标识符。然后将该替换的标识符用于通过向具有原始存储器地址 和替换标识符的节点B发送(参见图27中的消息8)新消息来创建远 程数字事件。
下面的应用分组代表从客户机向软件体系10发送的用于从内嵌的 变量映射中获得远程变量数据的消息(获得远程变量数据)。该消息指 示软件体系公布涉及存在于内嵌的变量映射中的数据的信息。参见图27 中使用该命令的示例。
API ID Op码 字节3 字节4 字节5 字节n 2 14:getRemoteVarData API Id OpCode OpCode OpCode
下面的应用分组代表从软件体系10发送给客户机的用于公布远程 变量数据的消息(公布远程变量数据)，而且是获得远程变量数据的响 应。该消息报告来自内嵌的变量映射的数据，如API、Op码、大小和 地址。
核心发现API：API ID＝3(类型3，版本1)。参照图6，下面的应 用分组代表来自客户机的用于找到软件体系10的节点的广播消息(找 到节点)。该广播消息使得节点可以找到软件体系10的其它节点。
API ID Op码 字节3 3 1:findNodes
下面的应用分组代表来自软件体系10的允许软件体系向其它参与 14的部件公告其存在的广播消息(发布节点)。该消息是在软件体系10 的节点通电或复位时发送，或者作为对找到节点的响应而发送。另外， 该消息可以在软件体系10的节点通过第二发现过程(给自己)添加 API或向现有的API添加Op码时发送。当客户机动态地向软件体系10 添加API或Op码(通过DAQ Op1，2，12，13)时不发送发布节点。反馈 消息的有效载荷包含防火墙密码，该密码由软件体系10的防火墙安全 特征使用(参见图31中该特征的示例)。这使得该消息的发送者成为网 络14中“受信”的节点。
API ID Op码 字节3 字节4 3 2:publishSANode 防火墙密码MSB 防火墙密码LSB
下面的应用分组代表可以从客户机发送或广播给软件体系10的用 于获得软件体系10的API的消息(获得API)。该定向消息允许客户机 发现由软件体系10的具体节点支持的API。API Id在电器内必须是唯 一的。
API ID Op码 字节3-字节F 3 3:getAPIs
下面的应用分组代表从软件体系10到客户机的用于发布软件体系 10的API的广播消息(发布API)。该消息是获得API的响应，而且是 允许客户机发现由软件体系10的发送节点支持的API的定向消息。
API ID Op码 字节3 字节4 字节5 字节n 字节7-字 节F 3 4:publishAPIs API# API# API# API n
下面的应用分组代表可以从客户机发送或广播给软件体系10的用 于获得API信息的消息(获得API信息)。该定向消息允许客户机发现 关于指定API的版本和类型信息。
c Op码 字节3 字节4 字节5 字节n 字节7-字 节F 3 5:getAPIInfo API# (0xFF＝全 部) API# API# API n
下面的应用分组代表从软件体系10到客户机的用于发布API信息 的定向消息(公布API信息)，并且是获得API信息的响应。该定相信 息允许客户机发现关于指定API的版本和类型信息。每个API都有一 个消息，而且这些消息利用图4的MMP标志约束。
字节4和5代表可以用作API的特定子分类的指示的API类型。 类型的值可用于确定子部件(API)之间的兼容性考虑。字节6和7代 表(特定类型的)API的版本。该值可用于表示对功能的调试定位或更 改。对于类型，其启动了运行时兼容性检查，该检查可以告知客户机该 版本是否兼容。可替换的，字节407可与字节3结合起来用于形成5字 节类标识符，其中类是指类库中的类定义(本领域技术人员可以理 解)。利用替换的方法，字节3(API Id)是运行时对象处理程序，字节 3-7在数值上链接地形成类id。
与字节8关联的实例个数向客户机标明API具有多个实例。客户机 可以跟随下面描述的获得实例信息来找到属于该API的实例Id。Descr Char 1-Descr Char n是可以有助于开发者的可选特征。描述性的文本可 用于注释API Id。例如，“上”或“下”可用于双炉灶的两个灶穴。
下面的应用分组代表从客户机到软件体系10的用于获得实例信息 的定向消息(获得实例信息)。该定向消息允许客户机发现报告API的 多于一个实例的API的实例Id。任何API的第一实例都使用API Id作 为其实例Id。如果在相同的可寻址节点上存在具有一个API Id的多个 实例，则向随后的实例动态地分配实例Id。当一个物理网络节点上存在 一个API的多个实例时，这些动态分配的Id可以代替API Id使用。
API ID Op码 字节3 字节4 字节5 字节n 字节7-字 节F 3 7:getInstanceInfo API# (0xFF＝全 部) API# API# API n
下面的应用分组代表从软件体系10到客户机的用于发布实例信息 的广播消息(发布实例信息)，并且是获得实例信息的响应。该定向消 息允许客户机发现实例Id。任何API的第一实例都使用API Id作为其 实例Id。如果在相同的可寻址节点上存在具有一个API Id的多个实 例，则向随后的实例动态地分配实例Id。这些动态分配的Id通过上述 公布API信息消息通信。为统一起见，公布API信息是为第一实例发 送的(即当API Id＝实例Id时)。对API实例存在一个消息，该消息使 用MMP标志来约束。当一个物理网络节点上存在一个API的多个实例 时，实例Id的值可以代替API Id使用。
1允许API子分类或专门化。例如，API Id可以指洗衣机API，类 型可以指定特定的洗衣机模型。
2启动版本控制(即对功能性的调试固定或更改)。启动运行时兼容 性检查，该检查可以通报客户机这些版本是否兼容。
3允许客户机将实例Id与其物理功能关联。例如“上”或“下”可用于 双炉灶的两个灶穴。
优选地，Descr Char 1-Descr Char n允许客户机将实例Id与其物 理功能关联。例如，“上”或“下”可用于双炉灶的两个灶穴。但是，软件 体系10的用户可以使用Descr Char 1-Descr Char n用于任何有用的目 的。
核心Debug API：API ID＝4(类型1，版本1)。下面的应用分组 代表从软件体系到客户机的用于发布饱和的广播消息(发布饱和)。饱 和发生在内部网络14的支持层不能运送软件体系10已经放入 WIDE14A的发送队列中的数据时。Aa110没有队列；如果WIDE14A 不能维护该发送数据，则软件体系10发送发布饱和消息。
API ID Op码 字节3-字节F 4 1:publishSaturation
下面的应用分组代表从客户机到软件体系10的用于设置饱和的寄 存器的定向消息(饱和的寄存)。客户机将该消息发送到软件体系节 点，该节点动饱和消息。只有启动饱和的节点才能禁止饱和。
API ID Op码 字节3-字节F 字节4-字节F 4 2:Saturation on或 off 1＝打开 2＝关闭
下层API：API ID＝5(类型1，版本1)。下面的应用分组代表来 自软件体系10的用于公布状态的广播消息(公布状态)。
该消息由于更改了机器的内部状态而发送，由正常的循环过程、用 户交互、下面的Op码2或通过网络14接收的其它消息产生。
API ID Op码 字节3 字节4-字节F 5 1:publishState 状态列举
示例性的机器状态列举值在下面的表格中给出。根据本发明的实施 例，运行状态包括在内。但是在某些情况下，运行状态有些模糊，附加 的阶段变量必须暴露，从而可以写入恰当的客户机端的业务逻辑。在替 换实施例中，消除运行状态以有利于更精细和确定性的状态机，其中每 个状态的每一阶段正确存档。在该实施例中，在用于附加列举的字节中 存在足够的地址空间。
机器状态列举 空闲 1 运行 2 编程 3 默认 4 开发 5 循环结束 6 暂停 7 保留 8 保留 9 保留 10 特定于电器 11-255
下面的应用分组代表从客户机到软件体系10的用于在开发状态和 空闲状态之间拨动用于管理图7的状态的家用电器12软件运行环境16 的定向消息。注意开发状态未在图7中示出，但是本领域的技术人员可 以想到开发状态只能从空闲状态进入而且在退出时返回到空闲状态。
API ID Op码 字节3-字节F 字节4-字节F 5 2:setDevelopmentState 1＝打开 2＝关闭
核心键按下API：API ID＝6(类型1，版本1)。下面的应用分组 代表从客户机到软件体系10的用于按下键的定向消息(键按下)。该定 向消息允许客户机发送虚拟的键按下。键索引由于在内嵌处理器中使用 的编码技术而不能被发现；因此，键索引可以手动地或通过其它自动机 制从源代码文件中提取。
API ID Op码 字节3-字节F 字节4-字节F 6 1:pressKey 键索引
下面的应用分组代表从软件体系10到客户机的用于公布键按下的 广播消息(公布键按下)。
API ID Op码 字节3-字节F 字节4-字节F 6 2:PublishKeyPress 键索引
示例性的键按下索引列举值在下面的表格中给出。
键按下索引列举 开始 1 取消 2 暂停 3 保留 4-25 特定于应用 26-255
存储器/端口API：API ID＝7(类型3，版本1)。下面的应用分组 代表从客户机到软件体系10的用于写入存储器的定向消息(写入存储 器)。存储器/端口API通过图3的开发状态启动，关联的交互类似于上 面描述的图3的开发状态和下层API(API ID＝7)之间的关联。
该定向消息允许客户机写入指定的RAM位置。写入到指定的 RAM位置只限于单个分组。在目前的实施例中，这是28的28A中示 出的13个字节。(28的)MMP＝1对该消息无效。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节n 7 1:writeMemory 地址 高字节 地址 中间字 节 地址 低字节 数据字 节 数据字 节 数据字 节
下面的应用分组代表从客户机到软件体系10的用于写入存储器的 定向消息(写入)。写入到指定的RAM位置只限于单个分组。在目前 的实施例中，这是28的28A中示出的13个字节。(28的)MMP＝1对 该消息无效。
存储器端口
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节n 7 2:writeEE 地址 高字节 地址 中间字 节 地址 低字节 数据字 节 数据字 节 数据字 节
轮询变量API：API ID＝10(类型1，版本1)。参照图5，下面的 应用分组代表从客户机到软件体系10的用于读取轮询变量的定向消息 (读取轮询变量)。该消息指示软件体系10发送下面示出的公布轮询变 量消息，以针对只用于轮询的变量。轮询变量可以是由开发人员为具体 应用硬编码的，而且可以在RAM/ROM资源不允许使用DAQ API时使 用。
API ID Op码 字节3 字节4 字节5 字节6-字节F 10 1:readPollVariable(s) 事件Id 1 (0xFF＝ 全部) 事件Id 2 事件Id n
下面的应用分组代表从软件体系10到客户机的用于公布轮询变量 的定向消息(公布轮询变量)，并且是读取轮询变量的响应。对在初始 化读取轮询变量消息中指定的每个轮询变量索引存在一条消息。
API ID Op码 字节3 字节 4 字节 5 字节 6 字节 7 字节n 字节 9-字 节F 10 事件ID n: (publishPollVariable) 数据 MSB 数据 数据 数据 ... 数据 LSB
上面在DAQ API一节中讨论了事件操作符的注释。创建事件数字 和字节消息(DAQ API Op码1和2)的字节9以及 CreateNumRemoteEvent和CreateByteRemoteEvent(DAQ API Op码 12和13)的字节5是在图33的NVOEventStructure中示出的事件更改 操作符。操作符是向软件体系10描述软件体系10应当产生事件消息的 数学条件的指示。下面的表格描述了事件操作符的例子。事件操作符的 变量取决于正在创建的事件的类型(op码分别为1和2的基于数字或基 于字节)。
事件操作符是具有两个变量的DAQ API的一部分：基本(类型 1)和扩展(类型2)。注意该表格中的第五列，其指明每个事件操作符 对于DAQ API的多个修订版本(4)的可获得性。
下面的表格给出可在创建基于数字的事件(API ID 2，Op码1和 12)时使用的事件操作符：
名称 操作符Id(字 节8) Arg 1(字节 9) Arg 2(字节 A) DAQ API类型 可用性 改变中 0 - - 1，2，3，4 死带 1 死带Val (MSB) 死带Val (LSB) 2，3，4 校验值＝＝ 2 比较Val (MSB) 比较Val (LSB) 2，3，4 界限<＝|＝> 3 比较Val (MSB) 比较Val (LSB) 2，3，4 25msec增量 4 - 时间＝val＊25ms 1，2，3，4 秒 5 - 时间＝val＊(sec) 1，2，3，4 分 6 - 时间＝val＊(min) 1，2，3，4 保留 7 - - - BIND 8 API Id:DAQ＝2 事件Id 此时不可用
下面的表格给出可在创建基于字节的事件(API ID 2，Op码2和 13)时使用的事件操作符：
名称 操作符Id(字 节8) Arg 1(字节 9) Arg 2(字节 A) DAQ API类型 可用性 改变中 0 偏移(1-大小) 1，2，3，4 死带 1 偏移(1-大小) 死带Val 2，3，4 校验值＝＝ 2 偏移(1-大小) 比较Val 2，3，4 界限<＝|＝> 3 偏移(1-大小) 比较Val 2，3，4 25msec增量 4 - 时间＝val＊25ms 1，2，3，4 秒 5 - 时间＝val＊(sec) 1，2，3，4 分 6 - 时间＝val＊(min) 1，2，3，4 位掩码 7 偏移 掩码 1，2，3，4 BIND 8 API Id:DAQ＝2 事件Id 此时不可用
BIND操作符允许客户机16由一个事件触发产生多个存储事件。换 句话说，一旦分配了事件ID，就可以创建将在最初的主事件被触发时 自动发送出去的后续事件。
在用改变中操作符建立起基于字节的事件(op码＝3)之后，字节 9中的值255将指示软件体系10对通过地址和大小变量指定的范围内的 所有字节都进行更改检测。
位掩码操作符实现了监视字节内的位转换的功能。掩码值应当设置 为使得位＝1表示“关心”，位＝0表示“不关心”。如果设置为“不关心”， 则在该比特位上的值变换不会导致事件的产生。
Aa110没有提供针对时间同步的明确的解决方案，但是提供了启动 机制。远程客户机16、22创建被周期性广播的事件的能力使得远程客 户机16、22可以保持与电器同步的日时钟时间。由于软件体系10可能 不会向API明确地暴露日时钟时间，因此客户机16、22可以存储存有 日时间的地址。
Aa110核心具有一些设计考虑，这些考虑可以用来产生在此所述的 本发明的替换实施例。
下面的项目可在确定软件体系10的核心实施的替换实施例时考 虑：
●消息体系
●有效载荷结构或消息大小
●多个有效载荷消息完整性检查
●状态察觉消息收发
●API版本确定-发现
●连接完整性
●流量控制和确认消息
○返回无效
○返回有效
○发出
○通电条件
●状态完整性
●键按下vs.逻辑API
●多节点网络
○多个节点
○多个客户机
○同一网络上的多个API实施
○同一网络节点上的多个API实施
○使用相同Op码的API-命名空间
○SAP分配
○SAP发现
消息体系
消息体系是主要的设计元素，其解决方案具有很多非独立的设计结 果。内部通信网络14协议28与以前的网络相反为由事件驱动的消息提 供了新的可能性。要考虑的要素是如果节点注册了通知消息它们是否要 彼此轮询。
轮询是节点定期地向请求更新值的数据持有人发送消息的一种实践 (例如，连续地每100ms请求一次数据)。轮询通常实施得更为简单而 且使用更为普遍，并且可以保持通过每个请求验证的连接完整性。但 是，在轮询时客户机必须连续不断地请求信息。网络带宽被不变的数据 占满(带宽是在给定时间段内可以通过通信信道的数据量，存在一些影 响带宽的因素，例如：网络上的节点数量，发送频率(波特率)，协议 开销(CRC，确认，源/目的ID等)，传输协议硬件，而且电缆连接控 制带宽的限度，但是应用协议负责使可用的带宽得到最大效率的使 用)。轮询体系不会伸缩：当节点增多时消息的数量指数增长。假定在 每个节点上存在其他每个节点都需要的信息：消息数量＝n^2-n。数据通 常不与控制的存储器同步，消息延迟可能达到轮询率的两倍。
产生事件是在特定条件下用新的数据值通知注册为数据持有人的节 点的一种实践。数据持有人接着负责在数据满足最初在注册期间规定的 判断标准时向观测节点发送消息。(例如仅在数据改变时发送数据)。在 产生事件的模型中，由于数据仅在其改变时才被发送，因此带宽使用得 到了优化。该模型良好地随着消息流量而伸缩，并且将延迟降至最低。 数据与控制同步。但是需要连接确认(heartbeat)。否则客户机可能不 知道事件源何时离线。替换的，产生事件模型中的连接确认可以利用作 为从时间观测者返回事件源的附加消息的确认来完成。当事件源发送事 件消息时，在接收到确认消息之前事件源不会认为该事务已完成。在超 时时间过去之后，事件源可能重新发送该事件。该过程可以重复确认事 件发送重试的可配置次数。
在产生事件体系中，可能需要图9中由28的MMP管理的消息结 合。这是一种用于将根据微控制器的同一次“扫描”产生的事件分组的机 制。
在这种情况下，优选实施例是产生事件模型，因为产生事件具有上 述优点而且针对产生事件的缺点的补救措施比较简单。连接确认利用 heartbeat和/或确认事件来解决。在使用heartbeat时，事件源定期发送 事件，从而该节点的所有事件监听者可以知道该事件源是健康的。类似 的，将heartbeat实施为其频率是可编程的还可用于通报所有事件定购 者该事件源是健康的。Heartbeat周期可从网络配置。在此详细描述的 确认事件是一种替换方法，可以附加于heartbeat或可编程heartbeat使 用以保证连接的完整性。消息结合由每个消息分组28的有效载荷中的 消息分界位来解决。这使得软件体系10驱动器可以收集对应于同一次 微控制器扫描的消息，并将这些消息一起提交给应用层。
采用本发明的作为DAQ30了解的子部件，软件体系允许客户机16 通过内部通信网络14动态地注册到电器控制部件16(由软件体系10启 动并包括软件体系DAQ30的可选子部件)，以便接收在指定存储器位置 处的值何时相对于指定条件变化的通知。这将电器控制16从具有硬编 码的反馈变量中解放出来，并允许实时反馈来根据电器而改变，从而不 需要客户机的轮询(基于事件的更新按照需要准确广播)。
采用图33的动态存储器堆，即保留给运行时可配置反馈消息的存 储器，其中该存储器堆的大小可在编译时配置。已经发现每个反馈事件 变量需要大约10字节的RAM。在该存储器堆中记录的事件(图33的 NVOEvent)可以通过由客户机发布给由软件体系启动的部件的内部通 信网络14命令来添加或复位，该软件体系也安装了可选的子部件 DAQ30。
有效载荷结构28A
有效载荷结构的一个示例是由成组的多个变量一起构成(在设计 时)的静态复合有效载荷，从而对于一个事务来说客户机可以向电器12 内的部件发送完整的命令，或接收该部件的完整状态。在命令的情况 下，客户机可能不想要改变有效载荷中的每个变量，因此需要必要的状 态更新来对命令有效载荷填充不打算改变的变量的当前状态。此外，改 变的变量可能无法字节映射为一个有效载荷定义，从而导致包含散布 的、已更改和未更改的数据的多个消息。
在简单的有效载荷结构中，只有一个变量可以存在于有效载荷中。 该有效载荷具有更为简单和容易的实施，而且可以近似于动态复合有效 载荷(下面将描述)。但是，由于消息开销与数据的比例更大带宽没有 得到优化，而且作为变量需要的消息结合是单独发送的。
在动态复合有效载荷结构中，有效载荷不是在设计时静态定义的， 而是由发送节点动态建立的。在这种情况下，有效载荷的长度由发送者 希望发送的数据确定，此外，在有效载荷中必须包含标识符和可能的分 隔符，这使得接收方的分析器可以分解有效载荷的组成部分。重申一 次，接收节点必须具有复杂到足以将多个变量有效载荷分成其组成部分 的分析器。该有效载荷结构优化了带宽，但是由于分析器所需要的复杂 性可能增大ROM需要。对应用协议也增加了一些开销，因为动态复合 有效载荷必须嵌入op码长度作为消息的一部分，需要由接收部件进行 额外的分析，而且可能难以理解和实施。
本发明的优选实施例是对应用协议采用简单的有效载荷结构。动态 复合有效载荷的复杂度可能难以对软件体系10中采用的消息进行成本 效益分析。为了最大化软件体系10的使用，优选接口的复杂度应当被 最小化。通过使用复合有效载荷，由于其复杂特性，可能妨碍了软件体 系10的使用，尤其是对于内嵌的客户机。简单的有效载荷是对动态复 合有效载荷的良好近似，尽管可能有额外的消息开销(即，对每个内部 通信网络14的消息存在5个字节的开销)。还有另外两个字节的开销用 于支持软件体系10应用协议28。这为每个内部通信网络14消息协议 24留下13个字节用于在某些特定于应用条件下的数据。使用静态的复 合有效载荷可能不灵活和比较浪费。
图9的消息结合是用在每个消息分组的有效载荷中使用MMP位来 解决的。这使得软件体系10驱动器可以收集对应于同一次微处理器扫 描的消息，并将这些消息一起提交给应用层。
状态察觉命令
相对于电器12的用户接口，电器12就像个状态机。当按下键时， 该状态机从一个状态转换到另一个状态。对于每个状态都知道对下一次 推动哪些键是有效的候选键。类似的，还知道对下一次推动哪些键是无 效的。
总的来说，当按下无效的键时，电器12产生声音警报以告诉用户 该电器处于不适于该键的状态。相同的概念也适用于希望发送有效命令 的外部客户机，虽然该客户机可能不发送键按下。
一般来说，对于电器控制开发出两种类型的状态机：键按下状态机 (如上所述)和过程状态机。典型的过程状态机的例子在图7示出。
图7是示出家用电器12的各种状态的示意图，该家用电器在图7 中例如是洗衣机，而且从软件体系10的交互到各种状态32以及默认故 障模式34。示例性洗衣机的各种状态32在图7示为空闲、洗衣、漂 洗、旋转和暂停。该示例电器12的其他状态以及不同电器12的状态是 可以想到的，图7所示的例子只是举例而已。
过程状态机的状态可以报告给外部客户机16.但是在检查时，可以 看见图7的过程状态机不针对来自所有可能的用户输入的事件(即时钟 设置、旋转速度选择、负荷大小选项等)。一般来说，电器控制中的逻 辑具有最终其它条款以处理没有预定的所有其他情况。
假定希望客户机16理解管理控制的状态变化的规则，从而可以避 免客户机16发送无效命令。考虑到客户机16不会发送键按下这个事 实，设计者必须理解无法得到允许客户机一方确认的文档或数据结构 (即在发送请求之前确认)。最后，这可能导致可能发送命令的客户机 应用，接收部件由于其基于图7的示例性状态的确认逻辑而不运行。
该解决方案不仅对带宽使用有影响，而且对应用的总体稳健性以及 终端用户的满意度也有影响。从带宽的角度来说，可以说消息不会导致 期望的行动，而是错误代码或重试是带宽的浪费(假定可以防止)。用 用户满意度的角度，防止用户出错的应用通常被认为比允许用户出错然 后用对话框解释发生了什么事的应用更为“友好”。
根据本发明设想了状态合适命令的各种实施例。
采用客户机编码的规则部分，状态信息的子集用于为了防止无效请 求而开发情况逻辑或控制状态的仿真。该模型通常不更改控制体系，但 是可以让客户机和控制很容易不同步。该规则和逻辑开发可以基于反复 试验(例如编码、测试、重新编码)。客户机设计可能快速展开，从而 产生设计不好的程序代码。
采用设计时基于状态的API数据模型，开发出数据模型，从而客户 机可以解释该数据模型而且防止无效请求。实际上，状态和有效op码 之间存在相关(op码是消息标识符)。其优点是Op码或API的开发者 也负责向客户机的开发者发布信息(在设计时)，从而允许设计者在客 户机上仿真状态机。该仿真的状态机使得客户机应用不会发送无效请 求。控制需要暴露在API数据模型中定义的每个状态。设计时的数据模 型要求控制开发者负责交流管理Op码实用的状态规则。客户机和控制 可能很容易失去同步，因为数据在运行时无法使用。必须创建反映写入 代码的文档。该文档必须维护和公布。该文档必须分析或转换到客户机 端的逻辑，并且不会在所有时候工作。电器状态可以在命令刚被发送时 改变，从而导致无效命令。
采用运行时基于状态的API数据模型，该解决方案与前一解决方案 相同，只是该数据模型不是在设计时在开发者之间共享，而是在运行时 在客户机和控制之间共享。对于要从控制告知的数据需要一些额外的消 息收发。在该运行时数据模型中，控制的开发者必须负责通报管理Op 码使用的状态规则。客户机可以在运行时发现Op码/状态相关的定义。 客户机和控制总是同步，而且客户机和开发者的活动是优化的-无需手 动翻译为文档/从文档手动翻译过来。需要额外的代码(ROM)(一次性 写入)用于排列和分解Op码/状态相关的定义。需要将一些网络带宽用 于传输数据，而且由于传输数据产生一定的启动延迟。这不会在所有时 候都产生。状态可以在命令正被发送时改变，从而导致无效命令。
采用后命令确认列举模型，上面的三个选择具有防止客户机发布该 命令以控制在无效状态的目的。该解决方案没有尝试这种预清空。而是 允许客户机应用随时发送任何命令。如果该命令无效，则产生确认，从 而客户机可以采取合适的行动。该确认可以包括或不包括列举的原因代 码。在后命令原因代码模型中，不改变控制体系，而是客户机更可能发 送将会遭到拒绝的命令。客户机开发者必须设计一种策略来应付拒绝确 认，由于被拒绝命令消息的频率而导致终端用户经验可能不是很令人愉 快。
采用组合了设计和运行时数据模型的设计时命令传统和源代码分析 模型，对内嵌代码的结构具有最小的影响，并且传达了期望的运行时功 能。这通过产生客户机一端的分析器来完成，该分析器可以分析内嵌的 源代码，并确定要为每个外部Op码监控的变量。对该解决方案的要求 是：(1)每个非诊断外部命令(Op码)具有关联的单个布尔变量，该 变量代表执行所需要的允许状态；(2)采用命名传统，使得分析器可以 将每个允许变量与对应的外部Op码关联。在源代码分析模型中，控制 的开发者负责通报管理Op码使用的状态规则。客户机16可以在运行时 发现等待确定恰当版本的Op码/状态相关定义，并且客户机和控制总是 与恰当的版本同步。不需要额外的参考文档，但是对于编码实践、每次 扫描要执行的附加逻辑、所需要的很小的额外RAM和ROM存在并非 不重要的改变，而且只有高级的客户机才能够分析源代码。
采用学习客户机模型，该解决方案不需要更改内嵌式系统。在这种 情况下，客户机会在每个遭到拒绝的命令之后“学习”，并且建立会随着 时间完成期望的运行时行为的客户机一端的允许映射。在学习客户机模 型中，不改变控制体系，但是其假定是在拒绝时估计正确的状态变量。 如果没有观测到状态变量，这客户机不能了解是什么导致了该拒绝。
已经发现这些选项的一些是优选的实施例。现在，主要的优选实施 例是运行时API数据模型。该设计的示例性优点是家庭控制应用。但是 该模型需要额外的内嵌设计。由于当前的商业环境没有产生对该实施例 的需要，因此一直采用后命令确认，直到采用运行时API数据模型(也 称为分类引擎)的成本效益变得更有利时为止。
Aa110的挑战之一是要提供功能而不影响电器12的生产计划。 Aa110可以实施确认的请求模型。NVORecipeStatus(APIID＝1，Op 码＝1)是优选的、由软件体系10在接收到每个消息之后发送的确认消 息。
API版本确定-图6的发现
尽管软件体系10的核心与任何API无关，但是软件体系10的目的 是要暴露多个API。期望API将随着时间不断添加到软件体系10中更 为实际。想到这一点，就需要考虑API发现和版本确定。
还可以想到随着软件体系10应用增长，微处理器资源将不足以同 时支持所有的软件体系10API和功能。通过采用编译器的指示，软件体 系10可以配置为使得在机器的开发寿命期间API将会为同一个模型出 现和再出现。
发现是软件体系10的长期成功的关键。Aa110的基本目的是在客 户机16和控制部件16之间扮演中间件的角色。假定下面描述的情形， 客户机16就需要查询控制以发现当前的功能是什么。如果不存在某些 功能(即编译时判断)，则期望应用能够体面地停止运行并通知用户该 应用的支持目前没有编译到电器控制软件中。
存在很多客户机实施以及很多交叉平台和特定于平台的API。编译 器指示可以被开发为包括或不包括软件体系10的某些功能。在控制上 可能不会允许软件体系10的所有可能的功能同时存在于微处理器上。
在此涉及API的版本确定和发现方法的本发明的各种实施例都没有 脱离本法明的范围。
采用基于模型号的发现模型，客户机负责理解控制的功能。这可以 采用基于客户机的数据结构、远程数据库、或者类似OSGi的运行时代 码运送工具来完成，这种运行时代码运送工具包括所有关于电器12的 特定模型号的相关信息。在基于模型号的发现模型中，对电器控制没有 额外的要求。但是，模型号通常不是在产品开发周期开始时分配的，因 此在早期软件开发中不能获得该模型号。模型号由于颜色机制、商标和 其它枝节因素可能变化。不同的API由于编译器指示可以驻留在同一模 型上。可能需要客户机负责在发现后获得功能定义或等价代码。
采用基于API ID的发现模型，基于API的发现一点也不取决于模 型号，而是将任何产品都定义为精心定义的接口的集合。该技术允许相 同的API驻留在多个产品上，从而导致某种再利用。在基于API ID的 发现模型中，对API ID的参考补偿了基于模型号方法的缺点。该模型 允许多个产品共享相同的编译器指示和相同的API定义，并且能够促进 软件体系10的子功能再利用。但是，客户机可以负责在发现后获取功 能定义或等价代码，可能需要额外的管理开销以维持和分配唯一的 API，而且可能需要来自控制微处理器的额外资源来支持发现Op码 (即额外的消息收发)。
采用功能发现模型(也称为分类引擎)，该模型将API发现作为附 加的步骤。除了API的ID之外，客户机还请求和获得对应于该API的 数据定义。换句话说，客户机发现每个功能调用，每个功能调用变量， 以及每个变量的有效值。在功能发现模型中，不需要第二查找来获取功 能定义。该模型接近UPnP或Web服务类型概念，并为转换到可由数 据驱动的LCD屏幕用户接口设置了基础。但是，这一概念在用于低富 裕机械键区和执行器时可能有成本缺陷。而且为了利用该技术的优点， 客户机16必须开发该功能定义的解释器，该解释器可能需要软件体系 10子功能开发者更多的建模努力以及来自控制微处理器的明显更多的资 源。
已经发现，在准备该应用时，基于API ID的发现模型是优选的实 施例。除了API ID之外，每个API可以具有类型和版本，从而API的 很多不同置换可以长时间存在。这使得协议更为灵活(例如对特定电器 12如甩干机可以有很多类型的API，以及每种类型存在不同的版本：甩 干机API，水平甩干机类型，版本1)。
根据本发明，发现可以通过很多方式启动。在通电时，用软件体系 10启动的每个节点在内部通信网络14上广播称为公布节点的消息。
其次，节点随时可以在内部通信网络14上广播称为找到节点的消 息。该消息将导致所有节点用公布节点的消息响应。该API已参照图5 和发现API详细讨论。
由于发现是软件体系10的关键，因此版本确定是成功发现的关 键。用于调整API发现的相同道理可用于API版本确定。版本确定允 许客户机找出更多关于已经发现的API的信息。
在API发现期间，API版本和类型要在与API ID相同的数据结构 内报告。例如，可以采用简单的号码冲撞方法。此外，可以想到APIID 和版本号具有一或两个字节或n个字节的数据结构。
连接完整性
在产生事件体系中，连接完整性是个问题；而在轮询体系中，连接 完整性是固有的。在产生事件体系中，客户机16可以成功注册以收听 反馈(例如针对温度读取)。一旦注册完成，客户机就依赖控制来通报 温度的变化。这样，客户机将网络问题解释为恒定的温度。相比较而 言，在轮询体系中，客户机不断向控制查询温度反馈，其响应或缺乏将 立即表明连接的完整性。
采用可选的heartbeat模型来执行连接完整性，客户机必须注册用 于基于网络的heartbeat。采用自动的heartbeat模型，软件体系10在 通知寄存缓冲器不满时自动产生heartbeat。Heartbeat可以是广播消息 或指向特定节点的消息。
在可选的heartbeat模型中，如果存在不需要该模型的实例，则可 以取消heartbeat。在需要该模型的实例中，客户机必须配置软件体系 10以产生heartbeat。在自动的heartbeat模型中，不需要期望的功能- 软件体系10本身就很稳健。在广播heartbeat中，只需发送更少的消 息，定制的heartbeat可以通过基于时间的事件更新来完成，而且定制 heartbeat具有更简单的实施。但是，这可以导致从不参与软件体系10 协作的其它网络节点来处理消息。而且，没有正确处理广播消息的节点 可能误解释了到来的消息。在定向的heartbeat模型中，只有启动的节 点需要处理软件体系10应用协议。但是可以采用定向的heartbeat模型 发送更多的消息。
对于本发明，已经发现优选的实施例是用于连接完整性的 heartbeat，具体地说，广播消息可以用于heartbeat。不喜欢该广播 heartbeat速率的客户机可以替换地使用基于周期时间的NVO事件更 新。使heartbeat自动化可以减轻客户机的负担。相对于包含在软件体 系10中的API来说，下面的功能作为核心API(Id＝1)的一部分受到 支持：heartbeat消息，设置heartbeat周期。Heartbeat优选在从客户 机16接收到第一消息时以默认周期自动启动。
用于连接完整性的另外可选的优选方法可以引入到软件体系10 中。已经发现随着软件体系的应用增长，确定需要额外的连接完整性的 方法。采用用于连接完整性的heartbeat方法对很多应用情形都是适用 的。选择该方法是因为它代表了带宽利用和事件源的置信水平之间良好 的平衡。但是，由软件体系10发送的事件消息可能无法由计划的事件 定购者处理，即使该事件定购者没有检测到遗漏的heartbeat。在这种 情况下，时间定购者不能检测故障，因此不能采取校正措施。在检测到 遗漏的heartbeat的情况下，该校正措施是事件定购者可能请求事件源 重新发送(所有)事件的(全部或子集)，从而该事件定购者具有最新 的数据。为了解决可能的未检测到的故障模式，通过软件体系10提供 了连接完整性的第二种方法。该方法作为经过确认的事件公知，其允许 每个事件消息的完整性得到单独的管理。图29示出经过确认的事件的 功能。在图29的说明中描述了涉及经过确认的事件的更多细节。
流量(流)控制
可配置的异步过程是强大的，但是在配置超过其物理处理和带宽限 制时就可能出现故障。引入了用于在4种公知故障情形中防止饱和的机 构：返回无效请求，返回有效请求，发出消息事件，以及通电条件。
返回无效请求-它像是客户机格式化和发送无法被控制正确分析和 理解或者可能通过控制的状态而无效的请求。
返回有效请求-无需考虑，客户机可以请求控制在该控制能够处理 第一任务之前完成第二任务。
在缓冲模型中，可以使用接收缓冲器，从而允许客户机发送很多请 求而不考虑控制服务这些请求的能力。在该模型中，客户机没有责任， 即使该模型的实施更为简单。但是缓冲没有解决流控制的问题；它只是 延迟了这个问题，或使得这个问题更不容易或更少发生，而且缓冲需要 更多的RAM。
在流控制模型中，可以使用消息收发，从而客户机在发送第二请求 之前需要等到控制准备好为止。在流控制模型中，流控制问题得到了非 常稳健的解决，故障模式被消除。但是客户机必须实施流控制协议。
在经过确认的请求模型中，控制向每个客户机请求提供积极或否定 的响应。在经过确认的请求模型中，该模型允许客户机16开发简单的 重试或发现情形。但是，该模型需要更多的带宽用于确认，而且需要额 外的ROM和设计。
在未确认请求模型中，客户机请求是未经确认的-客户机必须使用 状态信息来确定该命令是否成功。在未确认请求模型中，利用了更少的 带宽和ROM。但是，应用用户经历可能不好，客户机应用不指明所发 布的命令是否成功，因此不能自动启动重试，用户注意到未成功的命令 并需要手动重复该命令行为。
已经确定本发明的优选实施例是具有经过确认的命令模型的流控制 协议。此外，确认可以列举，从而客户机过程可以开发尽可能稳健的恢 复情形。由于本发明中前面提到的确认消息为经过确认的命令提供了 API和Op码，因此客户机可以识别得到响应的命令。这防止在多个控 制板网络中的冲突，其中位于电器内的多个控制板全都使用软件体系 10。流控制和命令确认是允许客户机尽可能快速地发送数据而不会使控 制饱和的技术。优点是非常灵敏的应用而不会引入不需要的延迟或不期 望的应用错误。
流控制的优点是利用公布确认，API点＝1，Op码1来达到的。每 个命令都用公布确认响应来确认。新的命令仅在接收了READY(就 绪)或UNSUPPORTED(不支持)的公布确认值之后才允许。公布确 认使状态机用于如图8所示的命令流控制。
图8是示出图1的软件体系10如何根据本发明与到来的命令交户 并基于家用电器的状态确认或拒绝该命令的示意图。在图8中用附图标 记36示出各种流控制状态指示符，如基于各种命令38和发布的响应40 的POWER_UP，READY，BUSY，REJECTED，UN_SUPPORTED。
发出消息事件(反馈)。在微控制器的每次扫描期间，软件体系10 的DAQ30收集代表必须在总线上发送出去的事件的字节阵列(参见图 36的处理DAQ事件状态)。Aa110的DAQ30可以如图5所示配置，因 此客户机可以配置软件体系10以传送比通信总线的带宽所允许的更多 的数据(即过配置)。
为了防止这一点，可以采用配置限制模型来限制客户机16配置软 件体系10的能力以避免该问题。在缓冲模型中，软件体系10可以配备 发送缓冲器。在饱和消息模型中，软件体系10检测何时向传输层提交 了太多的数据从而该数据可能无法发送给客户机。在要求重新启动模型 中，事件发布暂停，事件饱和消息发送出去和/或广播。一旦接收到 SendEvents(例如255＝全部)消息就重新开始产生事件。在不重新启 动模型中，发送和/或广播饱和消息，然后软件体系10继续产生事件。
在发送缓冲器模型中，客户机没有责任，客户机实施更为简单。但 是，缓冲没有解决问题；它只是延缓或使得该问题更不可能或更少频率 地发生，并需要更多的RAM。
在配置限制模型中，该模型会防止问题，从而不需要恢复过程，不 可能推导出配置限制，该限制基于相对于软件体系10处于随机特性的 机器状态变换。
在饱和消息模型中，客户机可以检测软件体系10在至少一次扫描 中无法向内部通信网络14提交新的数据。客户机无法确定该数据是否 丢失，饱和消息也不一定意味着存在故障，只是可能丢失了数据。
在不重新启动模型中，客户机没有责任，但是不强迫客户机的开发 者实施饱和恢复过程，客户机的开发者无法觉察到事件可能由于软件体 系10的过配置而丢失。这种类型的故障不是灾难性的，因此客户机应 用可能忘记数据的丢失。
在要求重新启动模型中，客户机的开发者必须考虑饱和故障及其对 应用的暗示，这防止找到漏洞的临时努力，而且故障模式是灾难性的和/ 或明显的。但是，客户机必须实施饱和恢复过程，而且在要求重新启动 过程期间可能存在暂时的延迟。
在什么也不做模型中，避免了不需要的工作，但是可能出现无法预 见的状况，从而导致客户机的开发者花时间去解决可能按程序诊断的问 题。
确定不要求通过编译器指示提供重新启动的饱和消息是本发明的优 选实施例。饱和消息必须在其它事件进入传输层发送缓冲器之前成功发 送出去。下面的消息收发功能作为软件体系10调试API(APIId＝4) 的一部分受到支持：获得饱和和注册饱和消息。
作为如图4所示的分组结构28，软件体系10的所有分组采用可能 导致命令空间冲突的Cmb/Fb标志。因此可以使用用于区别的Cmb/Fb 标志在相同的API下重叠Op码。
通电条件。如果软件体系10节点经历电力的短暂缺失或者微复 位，客户机可能具有针对软件体系10模块变量的不正确快照。为了实 现稳健的运行，软件体系10可以通知其客户机前面输出的变量不再被 认为是有效的。在考虑短暂的条件时，软件体系10的配置可能存储在 非易失存储器中，这使得可以进行通信的自动恢复。
在广播消息模型中，软件体系10发送特殊的广播消息，以通知所 有客户机在通电时“清空其缓存”。可以理解客户机16的一些应用可能 不需要考虑该故障模式，因此不会使用该特殊消息。还已知软件体系的 软件运行环境会在heartbeat周期内经历故障(导致其内部存储器的复 位)和恢复。由于只有heartbeat作为检测装置，该快速恢复会产生这 样的可能性：客户机16存储器所保存的来自软件体系的软件运行环境 的存储器的特定值的副本不再对应于该软件运行环境的存储器内的当前 值。为了解决该故障情况，通电消息可以包含在软件体系10中。该消 息与heartbeat无关，并且向任何客户机16表明软件体系10的软件运 行环境的存储器的任何以前保存的值很可能无效，而且客户机应当通过 使用API 1 Op码7的sendEvent消息来重新获取当前值。还要理解， 客户机应当以合适的方式暂停或修改对这些存储值进行运算的任何逻辑 或计算，直到重新获得当前值为止。
在丢失heartbeat模型中，软件体系10可以停止其heartbeat，使 得客户机可以确定恰当的故障模式行为。但是如上所述，heartbeat模 型的丢失不会覆盖所有的故障情况。这在使用自动恢复模型时尤其如 此。
在自动恢复模型中，软件体系10可以在通电或复位之后从最后的 已知状态中自动恢复正常运行。在自动恢复模型中，客户机可能将接收 的信息误解释为不会发生的状态变化。换句话说，对于在复位或通电之 前存在的状态A以及初始通电状态-状态B；不需要另外指明代表通电 或复位的状态I，客户机可以将状态A到状态B的变化解释为不通过状 态I。
在要求重新启动模型中，客户机的开发者必须考虑上面的段落及其 对应用的实施。则可以防止暂时的难以找到漏洞，因为故障是灾难性的 而且容易识别和定位。但是，客户机必须实施暂时的恢复过程，而且在 重新定购/数据重新获取过程期间可能存在瞬时延迟。
已确定在通电/复位之后需要重新定购的heartbeat模型是本发明的 优选实施方式。指明初始条件的状态的特殊广播消息的优点也被理解为 在软件运行环境中的资源允许这种附加特征时是有用的指示。即使通过 使heartbeat的暂停时间很小而使得heartbeat机制近似于通电消息机制 的使用，当软件运行系统的资源约束不是禁止性的时，优选解决方案还 是包括通电消息。为此，作为可选特征，软件体系10支持API Id＝3， Op码＝2的通电消息，即publishSANode。可能需要重新定购，因为动 态事件触发器存储在RAM中而且会在通电时丢失。
优选地，软件体系10模块除了可选的通电消息publishSANode之 外不发送任何消息，直到该模块检测到客户机为止。通过接收到有效命 令来检测到客户机。一旦检测到客户机，可配置的heartbeat消息开始 广播，然后软件体系10准备好正常运行。因此，如果用于软件体系10 的主微处理器经历了通电/复位，则客户机通过检测到heartbeat消息 (参见APIId＝1 Op码＝2)的缺乏和可选地通过检测到消息 publishSANode(参见APIId＝3 Op码＝2)来得到通报。
状态完整性
Aa110的图5的DAQ30提供了优于市面上买到的DAQ系统的一 些区别优点。Aa110可以暴露微处理器存储器中的任何变量。一般来说 也包括感兴趣的I/O信号。现有技术的DAQ不能做到这一点。Aa110 还可以通过一个3线插座提供给生产机器，而现有技术的DAQ仿真器 需要更多的布线或硬件。现有技术的DAQ在消费者领域测试的范围内 是不实际的。Aa110可以部署在生产系统上。与调制解调器耦合的 Aa110可以提供远程监控。
使得软件体系10不同于现有技术装置的最为基本的方面是，软件 体系10作为模块化子例程(图36和图11的 SA_ProcessOutgoingEvents)由微处理器的main()函数同时调用。这保 证在微处理器的执行引擎扫描微处理器存储器时，客户机可以具有微处 理器存储器的完整的逐次扫描的快照(在网络带宽的限制内)。这开启 了从低成本仿真到使用软件体系10的混合算法开发的很多感兴趣的可 能性，从而实现PC辅助的与生产电子装置的协处理。
现在描述异步数据收集和同步数据收集方法的比较。在异步收集 中：
1.假定A和B是电器控制存储器内的变量。
2.假定C在客户机中计算为A和B的乘积的变量。
3.假定A＝23，B＝67。
4.客户机轮询A：A＝23。
5.A和B改变。A＝56，B＝77。
6.客户机轮询B：B＝77。
7.客户机计算C：C＝A＊B＝23＊77(A和B的这种组合绝不会在微 处理器上发生)。
8.客户机将C的无效值提交给顾客或应用的终端用户。
大多数应用用异步数据收集工作。它简单和一目了然。但是，与异 步收集关联的问题对于调试和识别来说特别花时间。
在同步收集中，客户机用软件体系10定义或注册A和B。这使得 软件体系10可以在每次扫描时维持A和B的坐标值。
1.客户机注册A和B。
2.客户机请求发送全部。
3.A和B的当前值由控制发送给客户机。
4.A和B改变。A＝56，B＝77。
5.控制发送包含A＝56和B＝77的有界事件。
6.客户机不计算C直到达到该界限或结束分隔符位为止。
7.客户机计算C：C＝23＊77。
8.客户机提交正确的C值。
对于同步数据收集，数据收集是稳健而且虚拟地防弹的。它实现了 还没有概念化的应用，而且允许生产软件的“实时”调试w/o对生产电子 装置的特殊编码。但是，在控制上需要额外的RAM以维持“关心”变量 或属性列表的客户机的快照。
已经确定软件体系10优选可以支持和促进同步数据收集技术。但 是，异步存储器轮询可在核心API(API ID＝1)中提供。
对于采用的同步数据收集技术，应当讨论有界更新的概念。有界更 新是作为在主微处理器的Main()循环执行的同一扫描期间获得的电器状 态的快照而分组在一起的事件。电器控制主循环允许用DAQ API注册 的反馈变量的迭代更新(例如每25ms)。监视每个注册的变量，而且只 有根据它们的存储器监视器更改操作符改变值的变量才作为更新广播给 客户机。当更新正在被广播时，不允许新的更新，以及时保存快照。采 用如图4的应用协议28中所示的软件体系10标题的字节2中的MMP 标志向客户机通报快照。
当图4的28的MMP为真时，更多的消息等待该快照。当MMP 为假时，当前消息是快照中最后的消息。因此如果快照的第一消息是该 快照中的唯一消息，则MMP是错误的。
图9的示例示出具有确认的有界命令(循环+温度+MMP)，后面 是两个连续的有界更新。有界是指协议的元素向接收者表明更多的消息 正来自源而且通过接收部件的应用逻辑进行的数据处理应当延迟到分组 结构28内的协议的有界指示符(MMP位7)表明事务完成为止，在该 事务时由应用逻辑进行的数据处理得到允许。有界命令通过附图标记42 示出，两个连续的有界更新分别通过附图标记44、46示出。注意在有 界命令执行完成之前更新没有开始，这为客户机提供了滤除暂时的反馈 数据的能力。有界命令由相同的机制，即28中找到的MMP作为有界 更新提供，以便向应用提供更大水平的控制。
图9的示例是概念性的。实际的机制是在28中找到的MMP。但是 为了图解的目的，有界命令以初始的“开始”命令引发符(MMP置位) 开始，并包括用于将洗衣机循环设置为洗衣，配方状态为就绪，水温为 适中，配方状态再次为就绪的命令，最后是循环开始指示符，接着是命 令结束符(MMP未置位)。可以注意到，在图9中更新(例如通过产生 事件)被禁止，以防止更新在有界命令结束之前发生。此外，“处理命 令”指示符在电器12的整个有界命令处理期间周期性地出现，以说明从 客户机16通过内部通信网络14发布的命令的某些部分正在接受处理。
在有界更新44中，该更新又一次启动(因为该更新在有界命令42 开始时遭到禁止)，以允许电器12向客户机16报告其具的状态。在有 界更新44所示的例子中，示出确认状态为就绪，循环报告为洗衣，该 状态报告为正在运行，洗衣桶报告为满的，水泵报告是开着的，温度报 告是适中的。开始和结束指示符又围住有界更新44。这些开始和结束指 示符可以利用如在图4中讨论的应用分组结构28中的标志MMP报 告，或者利用网络协议领域的技术人员公知的其它方法报告。
在有界更新46中，洗衣桶报告为摇晃，水泵报告是关着的，电动 机报告是开着的。开始和结束指示符(MMP)又围住有界更新44。
API策略(键按下vs.逻辑API)
在几乎所有情况中，电器12由集成的键区控制。内嵌的软件处理 由键区所产生的键按下或用户事件，并采取动作。实际上，键按下处理 功能是用于电器的API。在这一节要考虑的问题是该API是否是最佳方 法，或者是否应当为外部客户机16、22开发第二API。
在键按下模型中，为了使用键按下API，外部客户机22必须创建 虚拟键按下并将其通过网络发送。必须在了解集成键区的情况下设计外 部客户机22，从而可以正确产生这些键按下，而且为了产生键按下，需 要外部网络接口卡。在该模型中，不需要修改底层键区编程。但是，客 户机22必须监视当前键区状态，以确定达到所期望的状态所需要的键 按下。如果键区的设计改变，而不是机器能力改变，则客户机API必须 改变。该体系通过在中间层(middle tier)和持久层(persistence tier) 之间设置表现层(presentation tier)，从而打破了软件开发的最佳实 践。对于在基本键区接口中不存在的能量管理、维护和诊断、测试等等 将需要扩展的命令。必须有一种方法将逻辑API以及杠杆作用 (leverage)和尽可能多的确认码与键按下处理例程关联，而不需要复 制代码。
相比之下，在逻辑API模型中，逻辑API是从机器功能的抽象而 不是键区的设计中开发而来。例如，使用键按下在欧洲炉子上的烘烤可 能需要客户机读取循环刻度盘的编码器位置，并通过编程改变编码器以 对应于烘烤设置。如果使用逻辑API，客户机只需要发送用于设置循环 的Op码以及针对烘烤的列举值：{0x01，0x01}(setCycle(Bake))。在逻辑 API模型中，客户机16不需要关心键区状态、键区设计或键按下处理 例程。API与键区设计的更改无关，允许扩展的命令，并且是工业上的 最佳实践。
已经确定软件体系10使用集成了键按下处理例程的逻辑API。逻 辑API暴露了很多扩展命令，这些扩展命令启动了各种增值应用。在电 器控制中，如果在用户接口上按下一个键或者发布外部命令，它作为普 通的进入点而直接映射为逻辑API函数调用(例如如果按下洗衣键或者 发布外部的洗衣网络命令，则调用安装了软件体系10的洗衣机中的 SetCycle(WASH))。逻辑API函数致力于按照参数化方式描述一组功 能，从而该函数可以再利用。例如，温度的非逻辑专门函数可以是 IncrementTemp()或DecrementTemp()，这些函数无法轻易地用于将温 度设置为任何值。但是逻辑API函数可以是： SetTemperature(newTemp，or temp++，or temp--)。键按下和外部命令都 可以使用后一个函数。
Aa110的命令处理程序可以包括使内嵌软件响应逻辑命令(例如 setCycle(Bake))或键按下(例如在炉子电器12上按下“烘烤”按钮)的 方法。该方法翻译输入的键按下，并导致对逻辑API内的合适函数的调 用。
在该逻辑API函数中存在尽可能多的确认和基于状态的逻辑，从而 外部命令与键按下获得一样的处理并且执行相同的代码。该API可以在 无需对电器控制软件进行大的重新设计的条件下实施。只有顾客接口管 理器软件必须重新组织和分组以作为针对每个键按下命令的进入点来调 用API函数。但是这不是软件体系10的要求。Aa110只用于最小化必 须写入的代码量。如果逻辑API函数的一个集合不能提供给外部命令引 擎，则散布在电器控制中的确认和状态逻辑必须针对每个外部命令重 复，从而导致更大的代码量和增加了错误的概率。
标识：多节点问题
上面关于API版本确定和发现的讨论建立了用于发现驻留在任何安 装了软件体系10的节点上的API的机制的优点。对于下个步骤存在另 外的考虑：
1.多个节点
2.多个客户机
3.实施同一API的多个安装的节点
4.具有多个复制的API的单一节点
5.使用同一Op码的多个API
6.SAP分配
7.客户机发现支持软件体系10协议的节点
多个节点。有可能网络上的多个部件都要实施软件体系10。因此， 应当考虑具有多个实施软件体系10的部件的网络。
在正面模式模型中，正面模式用于产生对一个对象集合的简单访 问。这通过产生设置在客户机和各种目标对象之间的软件层来完成，从 而客户机具有与单一对象连接的简单接口。该单一源由此负责将请求传 递给合适的目标对象。在正面模式模型中，更容易管理该模型，因为 API是集中定义的。在大多数应用中，正面向客户机呈现更为简单的接 口。但是，该模型要求编译时间设计将其它节点的API包含在正面节点 中。正面需要额外的RAM/ROM以处理请求并将请求传递给目标节 点。而且，如果两节点对彼此来说是客户机，则正面模式会创建不需要 的处理，因为正面节点首先只通过自己的正面请求以便将该请求传递给 目标节点。
在分布式服务模型中，该方法使用发现协议作为让客户机找到目标 对象的方法。客户机负责与每个目标对象之间的独立交互。换句话说， 客户机将发现软件体系10节点，然后查询每个节点它们支持什么样的 API。在分布式服务模型中，该模型伸缩自如，从而部件可以在运行时 插在一起。但是，该模型可能需要多个文档来管理网络变量定义 (API)。
已经确定软件体系10使用分布式服务模型来管理在网络14上启动 的多个节点。正面方法可能不太好，因为对目标对象API的更改需要更 改正面(更改，编译，下载，测试)。而在由良好的重新要素分解工具 支持的一次编译时间环境中，正面可能是很好的选择。在分布式环境 中，更为灵活的分布式服务模型将允许更快的开发和灵活的配置。但 是，在一些情况下在系统的每个微处理器上可能没有足够的资源来支持 软件体系10。在另一些情况下，可能存在继承协议，而且不希望对遗传 板进行修改。在这些情况下，正面可能是分布式服务模型的好的替代 品。
多个客户机。如图1所示，网络14上的多个节点或客户机16实施 软件体系10。因此，应当考虑多次发生10的网络。一个主要的考虑是 时间注册和通报。如果多个客户机用软件体系10注册事件，则软件体 系10应当可以管理事件发布。
利用节点ID指导的消息事件产生模型，软件体系10存储每个事件 请求者的节点ID，使得在触发该事件时，会向请求节点发送定向消 息。在该模型中，消息只发送给关心事件的节点。但是，该模型要求对 每个消息有一个字节来存储节点ID，并且需要更多的RAM来为每个请 求节点产生附加的存储器结构。
在具有API ID标识符的节点ID指导的消息事件产生中，利用该方 法，软件体系10存储每个事件请求者的节点ID，使得在触发该事件 时，会向请求节点发送定向消息。此外，主节点的API ID包含在该事 件中。该模型允许客户机传输层更好地在内部路由消息。但是，该模型 还要求对每个消息有一个字节来存储节点ID，并且需要更多的RAM来 为每个请求节点产生附加的存储器结构。
在广播消息事件产生模型中，利用该方法，软件体系10不跟踪事 件请求者的节点ID。在触发该事件时，软件体系10发送广播消息。在 该模型中，软件体系10的实施更为简单和更小，不需要为每个消息花 费一个字节来存储节点ID。但是，广播可能产生由其它节点处理的不 需要的事件。
第四种混合方法，也是优选的方法，包括将广播消息用于消除存储 节点ID的需要的模型。但是，客户机要在DAQ的事件产生消息中包含 APIID和Op码(API Id 2，Op码1，2，12，13)，使得他们能被动态 分配(如下面讨论的)。利用该方法，所产生的事件消息将包含分配的 APIID和Op码(如在API Id＝1的publishEvent消息中所示)。在该消 息(publishEvent)中，图4的28的字节1和字节2的APIID和Op码 是由客户机16利用事件产生消息(上面引用的)分配的。
已经确定在此描述的软件体系10使用包括APIID和Op码的广播 消息收发模型。这将提供通过用API ID存储来换取节点ID存储进行的 路由的优点。假定下面是对SAP讨论，广播消息收发的风险大大减 小。尽管一定数量的处理将由节点用于丢弃与节点无关的消息，但是这 仍然比定向消息优越，因为定向消息最终会导致网络的饱和以及软件体 系10的饱和。包括API ID使得客户机可以用动态API来配置控制，这 将在未来刺激更好的模块化设计。
在多个节点上使用相同的API。有可能一些可选的网络部件将实施 与UI或电器管理器板(即维护/诊断或能量)相同的API。这使得可选 的网络部件16可以向外部客户机22表明自己。因此，软件体系10可 以允许客户机16、22与两个物理节点交互-每个节点都实施相同的 API。该设计的考虑在于几个其它节点的交集，类似的，其分辨能力是 事先存在的设计解决方案的组合。
可选节点可以通过动态的成员资格实现。客户机可以通过发现API (参见图6)找出哪些节点支持协议28。也可以通过发现查询每个节点 以找出支持什么样的API。Op码不是全局唯一的，但是与API ID和 Op码耦合的内部通信网络14节点id是唯一的。API ID内嵌在每个事 件中。
总结一下，客户机首先可以发现软件体系10节点，然后发现每个 节点的支持API。客户机然后可以启动与每个节点的每个API的交互。 由于每个分组24包括节点ID和API ID，因此客户机和目标都可以避 免命名空间的冲突，并将消息路由到合适的应用空间。
在同一网络节点上的多个API实例。存在这样的电器12设计，该 设计将自身出借给在同一微处理器上的API再利用。示例包括双灶炉子 (即两个单独受控的烘烤室)或者两格子的冷冻箱。换句话说，在一些 情况下，存在多个炉灶执行相同功能并且因此能通过相同API受控。针 对这种情况的设计方法已经讨论过。
在唯一功能名称模型中，设计者针对每个命令或变量创建具有唯一 Op码的API ID，而不考虑再利用该定义。换句话说，Op码10＝下炉 灶设置温度，Op码11＝上炉灶设置温度。在该唯一功能名称模型中， 在发现期间的消息收发更少，但是该模型不能促进模块化设计和代码的 再利用。
在多个API ID模型中，设计者使用相同的Op码定义，但是为每 个API实例分配唯一的API ID。在该模型中，在发现期间的消息收发 更少，而且该模型促进模块化设计和再利用。但是该模型导致以更快的 速率消耗可获得的API ID。
在实例ID模型中，软件体系10动态地向每个API实例分配API ID，但第一实例除外。API的第一实例由全局API ID知识库标识。为 了做到这一点，软件体系10指定API ID(例如246-255)作为保留的 API以动态分配给API实例。该模型促进模块化设计和代码的再利用， 并且不消耗API ID。但是在发现期间存在更多的消息收发。
Aa110是设计为以稳健方式允许对象发现并彼此合作的面相对象的 协议。这些要求的基础是：(1)合作实体必须可以唯一的寻址，从而可 以恰当地在网络上路由消息，(2)合作实体必须可唯一识别，从而他们 的消息收发合约、交互的规则以及兼容性考虑可以得到理解。在单一的 运行时环境中，编译器可以强迫执行第(2)项。在联网或分布式环境 中，内嵌的编译器通常不解决第(2)项。
合作实体(对象或API)寻址的唯一性通过组合3位节点ID(在图 4的24的地址字段中找到)和8位的API或实例ID(在图4的28的字 节1中找到)来管理。任何包含这两个信息的网络消息都可以被正确路 由。这为每个网络节点提供了255个唯一的合作实体(或对象)。
实体标识通过8位API ID(例如类标识符)、两字节类型ID(即子 类或规范说明)以及两字节版本ID(即类型ID意味着目的，版本ID 意味着兼容性)来定义。
这种两层的方法与标识的唯一性分离地识别寻址的唯一性。这种分 离通过从每个分组中去掉4个字节的标识信息提供了对带宽更有效的利 用。反过来客户机必须缓存标识信息，并且按照地址的总共11位来索 引该标识信息。
已经确定实例ID模型是本发明的优选实施例。发现API(API ID ＝3)支持消息中的实例ID、公布API信息、获得实例信息和公布实例 信息。实例化是非常有力的概念，可以通过在协议中的使用来举例说 明。
API-Op码命名空间。串行网络上的消息通常具有ASCII或数字 标识符，以允许消息的接收者将包含在消息中的数据路由给合适的内部 函数。该函数接着对有效载荷中的剩余数据进行运算。
有效载荷中的剩余数据是在文档中在运行时定义的。该文档描述了 有效载荷中每一位和/或每一字节的含义。根据该文档，特定于每个有效 载荷定义开发了内部软件消息处理程序。因此通常对每个唯一的Op码 和Cmb/Fb对存在一个消息处理程序。
正常情况下，如果存在多个共享相同Op码的独立有效载荷定义而 没有任何额外的识别机制，则接收者不可能将该消息路由给合适的消息 处理程序。但是，本发明提供了Cmb/Fb标志来支持叠加或Op码使 用，该标识用于区分。因此，本发明提供了重叠使用相同Op码的命令 及其对应的反馈消息的功能。
这一节讨论了可用于向消息有效载荷定义提供唯一标识的技术。
在全局唯一的Op码模型中，利用该方法，Op码必须是全局唯一 的。换句话说，必须向每个平台或API开发者分配一个Op码范围内 (例如350-385)，该范围一定不能与任何其他项目的Op码范围重 叠。该模型由于要求多余ID的范围分配而是低效的。此外，API开发 者不能控制其Op码标号机制，而且该模型要求一定数量级的更多合作 的确定(信息传递)。
在全局唯一的API ID模型中，利用该方法Op码被分组为形成 API的逻辑集合。为API分配由API ID、类型和版本组成的全局唯一 的ID。因此，在此的Op码只需要在该API中是唯一。在这种模型 中，不需要分配多余的ID，API开发者可以在Op码＝1时开始，该模 型只需要很少的信息协作来避免命名空间的冲突。
已经发现本发明采用全局唯一的APIID策略作为优选实施例。作为 软件体系10核心API一部分的某些固定Op码，回复到共同的开始号 码(1)，而且优选可以向核心API分配为1的API ID。
SAP分配。在24中的SAP识别Wide有效载荷或SDU26的结构。 它与前面描述的API ID的概念相同。SAP的优点也相同，因为输入的 消息需要被识别和路由给正确的内部处理程序(或快速丢弃)。在这里 讨论的WIDE网络14中，存在16个可获得的SAP。Aa110为SAP成 员资格定制判断标准。在这种情况中，内部通信网络14管理员可以批 准软件体系10应用协议并向软件体系10分配官方SAP。也可以想出协 议24的其它网络标识符而不会脱离本发明的范围。例如，可以在内部 网络14上向软件体系10分配为1的默认SAP。
SAP(或其他子协议标识符)允许内部通信网络14节点参与软件 体系10和非体系10的消息收发。Aa110SAP适合全局体系，并且向软 件体系10添加了更多的范围。内部通信网络14SAP是来自技术和实践 观点的可靠的概念。保证特定于网络14的ID为软件体系10提供了全 局可见性和官方可接受性，这可以有助于增加其使用并促进它成为全球 标准。
图5的软件体系10发现。在上一节中，建立了软件体系10的API ID类似于内部通信网络14的SAP。类似的，在上一节中，建立了软件 体系客户机16通过查询发现API的优点，API驻留在软件体系10的每 个物理节点上。
类似的问题和/或解决方案可以呈现给软件体系10发现。如果维护 工具希望动态地发现所有的软件体系10API，首先就需要发现支持软件 体系10协议的内部通信网络14节点的节点ID。这可以通过发送软件 体系10节点会响应的广播命令的广播消息模型来完成。在该模型中， 软件体系10可以广播添加到软件体系10中新的API，或者可以广播添 加了实施软件体系10的新网络14节点。图6的发现API用作软件体系 10发现的机制。轮询发现消息和简单的广播消息都可以获得而且将在发 现API(API ID ＝3)中讨论。
多有效载荷消息的完整性
Aa110标题中的Frag，即字节2的位6，使得软件体系10协议可 以发送大于底层协议(即内部通信网络4的有效载荷)的有效载荷。如 果Frag置位，接收者应当意识到当前的消息将分段成多个分组或片 段。
在消息片段id模型中，分段的消息的第一片段使用如图4所述的标 准分组结构。该初始片段提供消息的API、Op码和Cmd/Fb标识。该 消息的所有后续片段优选具有图24所述的分段消息结构。在该结构 中，Frag标志仍然存在(与MMP标志一起)以增强数据。但是，字节 2现在在位5中包含更多片段未决标志(MFP)、位3-4中包含消息id (MID)、在位0-2中包含片段id(FID)。
MFP标志告知接收者应当期待当前消息的至少另一个片段。MFP 从1转变为0告知接收者当前分组是当前消息的最后一个分组。MID提 供了每一个消息的一个2位标识符。因此，向每个分段的消息(一组片 段)分配MID，该MID然后对每个随后的分段消息(一组片段)都增 加。MID增加到3，接着回滚到0。FID为消息内的每个片段提供一个 3位的标识符。因此对于特定的消息，总是向第一片段分配为0的 FID。对于该消息的每个后续片段，FID将增加。FID增加到7，接着 回滚到0。
通过本发明提供的片段协议允许接收者检查分段消息的完整性。通 过监视Frag和MFP标志，接收者可以保证分段消息没有错误内容。通 过检查MID没有在接收单个分段消息时更改，接收者可以保证两个分 离的分段消息不会融合(也许由于丢失的片段)。通过检查FID随着每 个片段正确地增加，接收者可以保证消息内没有丢失片段(或没有按照 顺序接收)。参见图25中消息片段id模型的示例。
在和CRC模型中，该解决方案利用了公知的现有循环冗余校验和 (CRC)的概念。额外的两字节CRC可以添加到多有效载荷消息的最 后一个有效载荷的后面。CRC是连接为一个组合的有效载荷的所有有 效载荷字节的CRC代表。发送者产生该CRC。接收者根据公知方法验 证该CRC。在和CRC模型中，该解决方案重利用已经建立和公知的 CRC算法，但是CRC算法比帧计数器更复杂，而且CRC可能不容易 由第三方携带。因此，已经确定消息片段id模型是根据本发明确定软件 体系10中的多有效载荷消息的完整性的优选实施例。消息片段id模型 更容易由第三方实施，而且更容易添加到现有体系10中。
软件组织
针对软件体系10，下面借助图10讨论代码组织和实施文件。图10 是示出根据本发明的图1的软件体系10与包含各种软件成分16B的部 件16的软件运行环境16A的关系的示意图，其中软件体系10包括命令 处理程序50、更新处理程序48，和用于将软件体系10连接到内部通信 网络软件运行层14A的内部通信网络层接口52，该内部通信网络软件 运行层14A创建数据并通过家用电器12的通信网络14发送该数据。而 且还示出软件运行环境16A中的其他软件成分16B如何调用和与软件 体系10的部件(50，52，48)交互的例子。
为了产生软件运行环境16A的更通用的实施，去掉UI管理器(软 件运行环境16A内的几个软件成分16B之一)之间的相关性。在该实 施中，软件运行环境16A的主执行循环11调用50。以前相信以前的实 施由于与涉及UI_Manager16B的执行时序关联的时序细节提供软件体 系10的更为精确和稳健的性能。
为了定义软件体系10的第一层细节，示出3个主软件成分(子部 件)：更新处理程序48，命令处理程序50，内部通信网络层接52。更 新处理程序48与DAQ引擎30交互以识别标志DAQ运行中的更新的 信息，从而内部通信网络层接口52可以处理所述信息，从而导致与内 部通信网络软件运行层14A的交互，从而导致分组结构24传送到网络 14上。命令处理程序50验证和处理从内部通信网络层接口52输入的命 令，从而根据分组结构28的标识符API Id和Op码值调用合适的软件 运行函数。内部通信网络层接口52打算解除软件体系10的特定部分与 内部通信网络软件运行层14A、图1的网络14和图4的分组结构24的 耦合(尽可能实际)。内部通信网络层接口52与内部通信网络软件运行 层14A连接，后者根据图4的定义产生数据并通过家用电器12的通信 网络14发送数据。
图1所示的软件体系10的软件运行层子部件48、50、52一起协作 来管理与其他也具有软件体系10的部件16或22或者能够与分组结构 24交互的替换物的通信。
图34示出用于本发明的几种实施文件。
SA_prm.h。软件体系10包括可配置参数和命令列举。
SACore.c.h。该用于软件体系10核心软件的文件包含用于处理命 令、管理流控制反馈和产生动态更新的电器数据的快照的更新处理程序 48和命令处理程序50。
SAAppSpecific.c/.h。该用于软件体系10核心软件的文件包含用于 驱动特定类型的电器12的特定于电器的命令处理程序和命令实施(例 如具体指导管理洗衣机和与该洗衣机通信的文件)。不是通用于所有电 器12的任何命令都在该函数中实施。这些命令列举在SA_prm.h中， 而且由命令处理程序调用。
SAWideComm.c/.h。该文件包含内部通信网络14应用层52，其提 供与内部通信网络14协议连接的接口，并控制消息结合为快照、控制 对进入命令的分析，并且控制对更新标志的处理以发送更新消息。
SADaq.c/.h。这些文件包含DAQ引擎30的全部功能。由此，涉及 更新处理程序48和事件产生的所有功能都包含在此。
SADiscovery.c/.h。这些文件包含实施软件体系10的节点的所有功 能，用于发现实施软件体系10的其它节点(以及其它节点的对应功 能)。
SAVaiableMap.h。该文件包含内嵌的变量映射，其使得可以通过外 部客户机产生事件而无需知道存储的变量地址。
图11示出软件体系10与电器控制之间的示例接口，其中根据本发 明图1的软件体系10由管理调度器(MAIN)调用3次。还示出MAIN 调用WIDE.WideExec()。WIDE.WideExec()随后根据图33调用软件体 系10，其中软件体系10的部件WideCommHandler暴露了函数 SA_AcceptData()和SA_BuildData()。还示出MAIN调用 SA_WideComm()(也是由软件体系10的部件暴露的函数)，这最终导 致如图33所示调用软件运行环境16A的部件WIDE的函数 WIDE.QueueMsg()。
图13是图11所示的软件体系的示例性实施，包括电器初始化部 分。初始化函数在进入图11所示的主执行循环之前从初始化例程调用 SA_Init()。
下面的表格示出如何管理API的文档例子，包括用于控制通过软件 体系10的API暴露的功能的部署的编译器指示机制。
API名称 API ID 类型 版本 编译器指示 ROM使用 RAM 使用 注释 核心 1 1 2 SA_COR 1810 43 基于注册 的30个动 态事件 数据获取 (DAQ) 2 1 2 SA_DAQ 1658 373 基于注册 的30个动 态事件 (10字节 RAM/事 件) 数据获取扩 展 (包括 SA_DAQ) 2 2 1 SA_DAQ_EXT SA_DAQ+1064 DAQ 基于注册 的30个动 态事件(包 括 SA_DAQ) 发现 3 1 1 SA_DISC 516 3 调试 4 1 1 SA_DEBG 下层 5 1 1 SA_LOLV 键按下 6 1 1 SA_KEPR 存储器端口 API 7 1 1 SA_PORT 342 0 能量管理 8 1 1 SA_ENGY GMCL 9 1 1 SA_GMCL 轮询变量 10 1 1 SA_POLL 维护和诊断 11 1 1 SA_DIAG 未使用 (140- 240) 非标准 (241- 245) 保留给API 实例Id (246- 255)
在上面的表格中，241-254范围内的API Id可以在不考虑标准的 情况下使用。他们意欲赋予设计者在期望再利用最小的应用中使用软件 体系10的灵活性。在这种情况下，这会消除为预计是“离线”的消息集 合开发特定API Id和类型的需要。这些Id还可以用作还没有接收到官 方ID的候选标准API。此外在上面的表格中，RAM和ROM估计是使 用MotorolaHC08 Cosmic Compiler版本4.3f来进行的，其中软件体系 10配置为允许30个动态事件(即存储器堆大小＝300字节)、定义7个 API和15字节的最大命令大小。
图14是组合了根据本发明的图1的软件体系的虚拟路由器的示意 图，其示出一对软件体系实施之间的映射。图14的虚拟路由器是封装 软件体系10的API实施(对象，参见图4的路由器的每一侧的API1- 8)的软件设计，使得内嵌客户机(应用逻辑、算法、逼和循环、定序 器和状态机)和内嵌部件(软件体系10API实施：诸如除霜器、加热 器、温度传感器、阀门等对象)之间的协作同一和一致，而不考虑实体 是通过网络协作还是共享运行时环境。
图14示出这样标出的6个唯一的协作示例，其示出存在于分离的 硬件部件16上并且通过网络14连接的一对软件运行环境16A如何使用 软件运行环境16A的各种软件成分16B来产生右手和左手软件运行环 境的运行逻辑59和软件成分16B之间的透明访问。
在描述协作示例之前，描述图14的结构将有助于理解该协作示 例。每个软件运行环境16A包含所包含的有用软件运行部件(16B)的 子集的代表，包括：软件体系10，内部通信网络层接口14A， DAQ30，硬件提取层80。
硬件提取层80包括：用于封装所连接的电路的特定固定地址的机 制，软件运行层80将运行在在该电路上；按照以下形式(之一)封装 16B出现的软间接口(28，28A或82)：28是通过软件体系10交换的 消息的分组表示(字节的有序集合)，28A是通过软件体系10交换的消 息的分组表示(字节的有序集合)，其只代表由软件运行部件84或86 期望的应用有效载荷28A(有效数据变量)，82是28或28A的替换表 示，其中目的和数据值和产生的行为在功能上相同，但是不是字节的有 序集合的形式。82是具有通过单独命名的变量代表的变量的唯一软件功 能的形式，该变量的值从28A导出或者通过从28A导出的字节的有序 集合代表。
应用GDM84(全局设计模块)是作为全局设计模块公知的16B的 变形，这是经过了标准开发过程的标准软件运行部件，包括函数和非函 数要求、测试、存档和实施指导。特定于电器的应用GDM地址涉及例 如除霜器、加热器、闭门器。应用GDM可以分为至少两种变形。变形 1包含与59不同的特定于应用的逻辑，用于管理行为和从包括多个其他 84和86在内的其他软件运行部件集合收集信息。变形2包含不同于59 的特定于应用的逻辑，用于管理行为和从具体的电子机械装置或传感器 如加热器、电梯、发动机、阀门、螺线管、继电器、压力和温度传感器 收集信息。变形2可以配置为解决通过该装置的具体制造商变形、通过 装置的基于通过应用要求确定的使用模式的具体配置，或者通过产生未 在此提到的具体问题的因素集合而变得重要的具体问题。
基础结构GDM86解决与图1的软件体系的应用无关的连续发生的 具体问题。它们可以在多个电器如冰箱、炉灶面、洗碗机、甩干机、洗 衣机等等之间再利用。基础结构GDM可以分为至少两种变形。变形1 与电部件或电约束的连续组合而导致的具体问题关联。一些例子包括： 制造接口约束，装置占空因数，电负荷特征，其例子包括涌入电流限制 和稳定状态电流限制，或者其他约束如模拟到数字的转换模式，其例子 包括4-20mA电流循环vs.0-5V直流模拟电压反馈。变形2与电器和 作为效用函数公知的独立于应用的软件成分关联。它们提供了由包括59 和80的其它16B部件使用的逻辑。变形2可以包含或使用对86的变形 1的参照。例子包括定时器，跨0检测，和其他有用的软件成分，这些 软件成分的目的比通过应用或电机械要求驱动更为实用。
内嵌的虚拟路由器70提供封装层，通过该封装层(部件16的软件 运行层16A的)应用逻辑59和硬件提取层80包括的部件、DAQ30、 应用逻辑59的其它实例或应用逻辑59中的部件或其他任何有用部件 16B之间的体系依赖性(由通过14连接的至少两个软件运行环境内部 或之间的其它16B访问或暴露给其它16B的一个部件16B的方法[16B 的例子是30，84，86])最小或被消除。
由其他软件成分16B用于获得对任何其它软件成分16B的参照的软 件成分72存在于(其中获得的16B可以是软件运行环境16A的一部 分)：相同的硬件部件16，通过14连接的不同的硬件部件16，通过包 括14在内的网络段的组合连接的不同硬件部件22，或者通过14连接的 不同电器12的不同硬件部件16，第一电器12的两次发生12、14之间 的不同网络段的组合。
软件成分72还为驻留在相同的软件运行环境16A内的其他软件成 分提供用于公布必要的标识和/或路由信息到72的存储器中从而启动72 的上述列举的用途的机制。标识和路由信息可以与驻留在相同的软件运 行环境内的部件关联，或者标识和路由信息可以涉及与驻留在相同的软 件运行环境内的部件分离的部件，但是通过驻留在相同的软件运行环境 内的部件知道。
70的存储器中的结构74可以接收消息或者提供用于调用消息的函 数，并且可以发送消息或者提供用于发布信息的调回函数。这些具有 28、28A或82的访问定义的结构对应于诸如80、59内的部件的软件成 分或位于上述列举72中的任何其他有用软件成分的发生，以及将信息 路由给该软件成分或者路由给具有74的相同或类似目的的合适中间软 件成分的功能。
现在查看可能的协作示例，期望基于发现查询产生和填充70的结 构74，该发现查询包含访问既可以识别又可以路由的具体软件成分16B 的请求，表明所述访问的调用，或者通过能够代表自己或其他部件16B 调用70的软件成分16B产生和填充70的结构74，从而导致结构74的 产生和填充。
协作1：命令通过右手软件运行环境16A的软件成分59发布，并 通过包含在74的集合中的软件成分接收，其中在相同软件运行环境的 部件70内具有API 1标识符。采用包含在70内的标识和路由信息，通 过API 1识别的部件通过其它局部软件运行层10和14A发送所接收的 信息，而且最后通过14发送和通过左手软件运行环境的14A接收。然 后该消息通过10处理，并且路由到左手软件运行环境的74内的合适部 件。使用包含在相同软件运行部件70内的标识和路由信息的合适左手 软件运行部件74接着调用包含在左手软件运行环境硬件提取层80中的 API1的实施或向其发送消息。由此右手软件运行环境的软件成分59内 的应用逻辑调用时是在左手软件运行环境中的函数，而无需包含在其中 用于实现所述调用的信息。因此，图14表明的设计的值是应用逻辑59 可以相对于其他软件运行部件16B的位置再利用，该其他软件运行部件 16B位于通过网络14或者可能包括14的多个网络段连接的多个软件运 行环境16A内。
协作2：在这种情况下，消息的初始化从左手软件运行环境16A的 59开始。示出最后调用在相同软件运行环境内使用在协作1中详细描述 的相同方法的软件成分(在这种情况下是API2)的情况。因此，在协 作2中，示出设置在应用逻辑59发生到某个其他有用软件成分(硬件 提取层80的API 2)之间的替换体系对任何一种的实施没有影响。此 外，软件成分70的目的是提供这种功能，软件成分70可以符合通过软 件体系10设置的标识和接口要求。
协作3-6示出内嵌虚拟路由器70的其它用途。用于完成这些变形 的机制与在协作1和2中描述的相同。包括他们是为了示出该设计的有 用性以及涉及DAQ30可获得的期望的其它消息模式。应用逻辑59的本 地事件监听者(3)和远程事件监听者(4)都具有与DAQ引擎30的代 表的互连，该互连不仅提供与本地软件运行环境中的DAQ的连接，还 提供与驻留在远程运行环境中的DAQ的连接。基于DAQ事件的发生 而由DAQ产生的消息可以通过70中可获得的机制传送给本地(6)和 远方(5)。
图15是采用12的体系建立的非典型电器的示意图，该电器包括作 为部件组合的永久节点54，该部件包括根据本发明的图1的软件体系 10。现有技术的内嵌系统是为了提供PCB本地的数据持久性，而根据 本发明的永久节点通过软件体系10的机制和/或内嵌虚拟路由器70提供 暴露给部件16和22的永久服务。
在每个客户机的通过内部网络彼此通信的部件内，示出每个部件 16、电器12和永久节点54上的连接器和协议(RS-232，无线的， WIDE等)的各种示例。总的来说，永久节点54是可被共享网络14、 20或运行时连接的所有部件16发现和使用的逻辑实体。该实体提供读 取、写入和存储信息所需要的服务和协议机制。
如上所讨论的，电器12是“状态”驱动的机器，通常具有用户接 口，用户使用该用户接口可以改变电器12的状态(例如将洗衣机从空 闲状态变为“洗衣”状态)。由于开发了需要与电器12进行外部通信的应 用(例如测试，诊断，远程控制等)，因此存在3种可能的技术来执行 该接口：(1)将外部命令翻译为键按下(参见图16和讨论)；(2)采用 定制软件来执行更改状态的命令(参见图16及讨论)；或者(3)简单 地将键按下翻译为逻辑API(参见图17及讨论)。
图16是现有技术方法的示意图，通过该方法外部命令翻译为键按 下以测试家用电器的功能。在该现有技术方法中，用户通过一个或多个 键按下56以更改电器的状态(该电器在图16中称为“状态机”12)从而 影响电器的功能58来启动电器12。为了测试电器的功能58，用户准备 外部命令60，并且(1)将外部命令60翻译成键按下56；或者(2)准 备定制软件62，该定制软件仿真状态机电器12以尝试复制电器功能 58。这可能很困难和容易出错。
在一种运行和测试电器的新方法中，图17是由用户启动的键按下 56和外部馈入的软件命令60(通常来自客户机)的交互的示意图，该 键按下56和外部馈入的软件命令60都作为变量传递给根据本发明的图 1的软件体系10用于向家用电器12发布命令，以例如测试家用电器的 功能58和/或更改家用电器12的状态(即实际运行)。
参照图17讨论的方法是新颖的，因为不是翻译外部消息，将电器 12作为封闭系统来对待，而是与消息是作为外部键按下还是电器12本 地或远程的软件命令接收无关地暴露电器12的功能。消息(命令)通 过软件体系10的API(现在与现有技术的“封闭”系统相反是开放式系 统)处理，同时给用户保留键按下验证和反馈。
当前，电器控制软件不是建立来验证和执行外部命令。为了弥补这 一点，电器API定义为包括用户功能以及下层机器控制命令。在正常运 行期间，在按下键或者发布外部命令时，该键按下或命令作为共用进入 点而直接映射为用户功能API函数调用(例如，在用户接口[键区]上按 下洗衣键或者发布外部的洗衣命令都会导致立即调用setCycle(WASH) 函数，而不管电器12的状态如何)。所有验证和基于状态的行为都存在 于该函数内部，从而外部命令与键按下56得到相同的对待，而且执行 相同的代码。
该API可以不对电器控制软件进行主要的重新设计就实施。只需要 识别用户接口软件以作为任何命令的进入点而调用API函数，而不是只 是对状态机12内部的键按下进行反应。使用图17的方法使得电器12 的制造商可以分开地测试和诊断键区/用户接口。这节省了在电器开发、 诊断和测试时的事件和精力。这也消除了对复杂机械键区启动装置以及 传统上要用于测试用户接口和电器功能的机械执行硬件的需要。
此外，电器12API含有用于将电器送入诊断或工厂测试模式的命 令。在该模式中，所有基于状态的行为和命令验证代码都无效，以允许 下层API。在该模式中的API命令可以访问和控制电器12的下层部 件，如读取和写入EEPROM、按下键(56)、读取传感器值、写入循环 参数、执行转接和其他执行器等。
参照软件体系10讨论的API接口是面向对象的软件分组，其在一 个对象(电器功能)具有多个需要与该对象交互的客户机(例如键按下 56和外部命令60)是高效的。这是一种新的方法，因为电器目前不包 含面向对象的软件，而且通常被视为是封闭系统并只具有一个客户机： 用户接口键。本发明设想电器12通过引入内部通信总线(即网络14) 和外部连接20而具有多个客户机。这些客户机可以包括网页应用、诊 断工具、测试工具和家庭自动化系统等。
具有在此所述的API软件体系的电器12是“将来验证”的，并且可 用于顾客可能需要的很多高级远程应用。这些应用可以包括能量管理、 改进的维护和诊断工具以及远程控制和监视。此外，由于API是进入所 有电器功能的进入点，顾客可以受益于电器12的改进的自动化开发测 试和工厂测试。
Aa110还设想虚拟装置模型可以觉察物理装置(电器12)的当前功 能。例如，如果炉子在烘烤，则电器时钟不能修改。功能的同步是一种 打算允许虚拟模型基于装置的状态识别装置功能的变化的通用解决方 案。
目前，该目的通过为每个电器12写入的代码实现。包含在软件体 系10中的解决方案用通用的解决方案代替特定于装置的代码。该解决 方案包括附加消息，其中软件体系10广播包含无效命令的当前集合 (API和Op码)。该信息在运行时考虑，从而可以按照用户可能只能修 改可被修改的装置特性的方式来表达用户接口，从而没有给予顾客机会 来修改目前由实际装置指示是不变的装置特征。
Aa110是应用和工具的交叉乘积系统。这些应用有助于增加在产品 开发过程中的质量和投放市场的速度。这通过与存储在电器12内的存 储器中的数据交互来完成。
为了保持灵活性、可配置姓和通用性，应用通过规定需要的数值存 储器位置(地址)来与电器交互。但每次当电器中的软件改变时，存储 器中的这些位置可以移来移去，并具有非常不同的含义。为了解决该问 题，创建了变量映射文件标准和发生器。
变量映射文件发生器提取写入代码的软件名称(文本描述)并将该 名称与该数据的数值地址和大小关联。然后该发生器按照标准文件格式 输出该信息。这在每次改变和编译代码时执行。该标准文件中的信息提 供与编译器和数据位于存储器中什么位置无关的独立性。
然后通过任何希望与基于软件体系10的电器12交互的任何应用读 取变量映射文件。应用是对照数据的有意义的文本名称而不是数据的数 值地址来编码的，这大大简化了应用的开发。
变量映射文件格式和使用过程描述在下面的表格中。
模块 变量名称 地址 大小 appman.h Hour_Timer 0213 1 appman.h Zonel 020e 3 appman.h Zonel.Act_Temp 0210 1 appman.h Zonel.Zone_State_Tmr 020f 1 appman.h Zonel.Zone_State 020e 1
采用变量映射工作的方法示例包括以下步骤。
1.工程师建立对照位于电器控制中的有意义的数据的文本描述名 称而编码的应用。
2.电器控制代码变化，从而导致有意义的应用数据具有新的位 置。
3.工程师编译新的电器代码，这也自动产生关联的变量映射文 件。新的代码和变量映射文件一起部署。
4.当应用是对照新代码运行时，只要该应用具有恰当的变量映射 文件，该应用就不需要改变。
5.如果应用需要新的数据，则可以从变量映射文件中很容易识别 或检索出该数据。
因此如上所述，开发工程师只需要记得上面表格中“变量名称”列， 不需要不断查找在“地址”栏中不断变化的地址值。
现在参照图18，为了举例的目的而示作炉子的家用电器12具有内 部通信总线200，而且该家用电器12可以通过类似于上述网络接口连接 器20的网络接口卡(NIC)204耦合到外部网络202。NIC是用于将计 算机或其他客户机连接到网络的公知装置，任何合适的NIC都可用于电 器12。根据本发明的实施例，NIC204电连接到内部通信总线200，并 将内部通信总线协议适应于标准通信协议，如TCP/IP和GSM，从而电 器12可以通过外部网络202如局域网(LAN)和/或广域网(WAN)与 外部客户机(未示出)通信。因此，外部客户机可以与涉及电器12驻 留在内部网络14上的各种内部部件的软件体系10通信。例如，图18 中的电器12示作包括用户接口(UI)208和传感器-执行器板210，每 一个都包括印刷电路板(PCB)和对应的软件体系10，而且外部客户机 可以通过NIC204与软件体系10通信。
NIC204可以通过任何合适的安装装置安装到电器12的优选从外部 设置的通信总线200上，这在计算机网络领域中是公知的。根据本发明 的实施例，通信总线200位于限定与电器12的器壁齐平的开口214的 凹陷212中，该器壁例如是后壁216，如图18所示。当通信总线200位 于凹陷212中时，通信总线200和NIC204(在安装到通信总线200之 后)受到防止在运输电器12过程中可能发生的损坏的保护。
NIC204可以在制造时与电器12一起提供，或者可以作为附件与电 器12分开购买。因此，顾客可以选择购买没有连接到外部网络202的 功能的电器12，并在以后升级该电器12以添加连接，如果需要的话。
NIC204可以通过有线连接或无线地与外部网络202通信。例如， NIC204可以通过无线红外(IR)通信或其他短程无线装置与外部网络 202通信。在这种情况中，NIC204优选安装在电器12的正面218以推 动稳健的通信。根据本发明的实施例，NIC204可以安装在电器的正面 218上的凹陷220中，如图19针对炉子所示。如果安装到电器的正面 218，则NIC204可以通过设置在线路管道224中的导线连接到电器的背 部222，该线路管道224从正面218的安装凹陷220延伸到电器12的背 部222，在背部电线进入电器12。
有线通信的另一个例子是射频(RF)通信。例如，RF印刷电路板 (PCB)226可以位于电器12内部，这需要RF PCB226和外部安装的 天线之间的连接。可替换的，RF PCB226可以安装在电器12外部，但 是该配置需要RF PCB226和电器控制电路之间的电连接，而且安装者 必须在安装RF PCB226期间打开电器12的内部或内箱228。根据本发 明的实施例，RF PCB226安装在电器12内部，而且热和电的不良导 体-非金属保险隔板作为电器内箱228的一部分提供。示例性的保险隔 板230是塑料窗，如Plexiglas窗，与电器内箱228集成在一起，如图 20为说明目的针对炉子形式的电器12所示。保险隔板230允许RF与 内部安装的RF PCB226通信而无需外部天线，并防止人员接触过多的 热量或触电。
现在参照图21，电器12可以用硬件配置以有助于电器12的维护和 诊断。在一个实施例中，配置适用于可消除地与电器12上的标准通信 总线连接的维护模块232以记录诊断数据，例如通过与内部网络14上 的软件体系10通信。维护模块可以很容易连接到内部网络14。维护模 块232与电器12的连接通过图21的步骤1来代表。接着维护模块232 从电器12去掉并连接到个人计算机234，例如通过USB端口或其他合 适的标准通信总线。维护模块232与计算机234的连接通过图21的步 骤2代表。在维护模块232连接到计算机234之后，维护模块232优选 自动连接到互联网，并将诊断数据加载到远程客户机(未示出)上，如 图21的步骤3所示。远程客户机处理诊断数据以识别电器问题或故 障，并潜在地防止维修电话，如果该问题或故障需要维修电话的话，从 而优化维修电话的效果和效率。可选的，维护模块232可以基于诊断数 据下载定制测试脚本，以便在电器12上运行测试以进一步诊断或消除 该问题或故障。图21中的步骤4表示维护模块232与电器12重新连接 以执行该测试脚本。
维护模块232的示例性体系在图21A中示出。维护模块232包括一 对通信总线，如外部串行总线。根据所示出的实施例，维护模块在一端 包括USB236用于连接到个人计算机，而在对立的一端具有RS- 232(EIA-232)总线238用于连接到电器12，尤其是连接到驻留在电器内 部网络14的各个节点上的软件体系10。维护模块232还包括存储器 240，如闪存，用于存储诊断数据、测试脚本和其他数据。闪存240与 控制维护模块232的运行的维护逻辑242通信。
图22示出用于维护和诊断电器12的替换硬件体系。该体系类似于 图21所示出的体系，只是个人计算机234被电话线244代替，维护模 块232适用于连接到电话线244。由此，图22的替换体系更适于没有个 人计算机或者个人计算机没有连接到互联网的电器用户。用于获得诊断 数据的过程与参照图21所述的相同；但是，不是将维护模块232连接 到个人计算机234，用户将维护模块232连接到标准电话插座246，维 护模块232通过电话线244自动连接到互联网。
下面参照图22A，用于图22的系统的维护模块232类似于图21A 示出的维护模块232，只是USB236被电话线插座248代替，如RJ11 插座，该电话线插座用于将维护模块232的调制解调器250与电话线 244连接以建立与互联网的连接。
上述维护模块232可以在制造时与电器12一起提供，或在电器12 销售期间或售后作为附件销售。其它各种附件模块的类型可以随着电器 12一起提供，或者由顾客以后购买以升级电器12。示例性的附件模块 可以包括可操作地连接到内部网络14和外部网络202而且可以在安装 到电器12上时让用户看到的显示器。显示器可以向用户通报各种数 据，包括但不限于诸如运行状态的数据，涉及电器并通过内部网络14 上的软件体系10获得的数据，或者通过外部网络202从互联网下载的 信息。示例性的附件模块是气象站模块252，其在图23中示出安装在以 冰箱的形式示出的电器12上。除了显示与天气有关的信息或可从外部 网络202下载的其他信息之外，气象站模块252的显示器还可以包括具 有选择区域254的一个或多个触摸板或触摸屏256，用于控制冰箱的各 种操作，如控制冰分配和灯，用于访问冰箱的设置如温度。
图24示出分段消息的优选分组结构。这种分组结构优选通报消息 有效载荷何时大于底层协议的有效载荷。该分段分组结构前面已经在涉 及多有效载荷消息的完整性中描述过；但是在此简要总结如下。在分段 消息中，图4所述的标准分组结构优选用在第一片段中。所有后续片段 优选使用图24所述的分组结构。这些协议之间的区别在于字节2。
为了分段消息的完整性，Frag标志应当置位。MFP标志(更多的 片段)应当置位到分段消息的最后一个片段为止。MID(消息id)为每 个分段消息一个处理程序或id，从而防止分开的分段消息融合。FID (片段id)基于分段消息的每个片段一个处理程序或id，从而允许检测 丢失的片段。更为深入的解释可以在多有效载荷消息的完整性中找到。
图25提供在图24中讨论的分段协议的示例性操作。该协议的解释 可以在多有效载荷消息的完整性中找到。
图26A和26B代表用于查找地址和标识符信息的替换体系，使得 可以建立很好形成的消息并发送给图10的软件体系，从而导致在图5 的DAQ30中产生事件。如前所述，DAQ引擎30要求变量的存储器地 址用于事件注册。图26A示出利用由客户机配置的数据获取机制的例 子，其中客户机(计算机或其它客户机)保存将变量名与其存储器位置 关联的当前存储器映射。除了标识符(API Id和Op码)之外，该存储 器地址也用于构建良好成型的消息，该消息发送给DAQ从而导致DAQ 事件的产生。图26示出使用客户机配置的数据获取机制的示例，其中 客户机(即另一个控制板)不知道期望的事件变量的存储器地址。在这 种情况下，客户机可以利用本发明的内嵌式变量映射功能。由此，客户 机只需要提供API Id和Op码，而且不需要在将要发送给DAQ的良好 成型的消息中包括变量的存储器地址。因为在这种情况下，DAQ的软 件执行获取通过标识符指定的变量的存储器位置的附加任务。一旦获得 该存储器位置，DAQ就使用在图26A的前一种情况中引用的相同的函 数调用来创建包含在DAQ存储器堆中的DAQ的事件结构阵列的事件 结构。
图26A的变量映射信息将变量符号名称与它们在16A的存储器中 的地址关联。图26A将变量标识符(API Id和Op码)与它们在16的 存储器中的地址关联。替换体系的合理性在于它们支持与可能发现用符 号名称(符号名称趋向于有意义，而且传达变量的有用性)工作是有利 的人员的交互，以及与软件体系10的其它实例或一些部件16或22或 可以与软件体系10交互的其它软件成分交互。在基于软件的交互(非 人员交户)中，有利的是不使用符号名称，因为它们的存储器来存储， 更多的带宽来发送，以及更多的计算循环来处理。相反可以用数字标识 符来代替符号名称。Aa110使用数字标识符API ID和Op码作为符号名 称的数字替代符。额外的数字标识可用于API Id的任何有效发生。前 一个数字标识足以为驻留在网络14上的每一个部件16提供唯一的索 引，后一个数字标识，即额外的标识信息可以利用需要前一个数字标识 API Id部分的第二查询来获得。然后组合在一起，API Id和额外的数字 标识(后一个)提供了可以表示在软件体系10内的可能软件成分全体 中唯一的标识。
图27提供了采用内嵌变量映射的由客户机配置的数据获取机制的 使用示例。在此，节点A使用公开知道的API X和Op码Y在节点B 上注册链接到期望的事件变量的事件。接着，节点尝试利用API X和 Op码Y注册相同事件。由于该API ID和Op码对以前曾由节点A注 册过，因此节点C的请求找到拒绝。但是，接着节点C用获得远程变 量数据命令从远程(内嵌的)变量映射请求数据。节点B用信息响应， 包括期望的变量的存储器地址。节点C接着使用该存储器地址注册事 件，但这一次是用不同的API ID和Op码对。
图27还可以被认为是公开了两个涉及在图26B中建议的事件产生 的消息情形。第一情形描述了节点A和节点B之间的消息收发，这两 个节点都通过内部通信网络14通信，节点B与软件体系10兼容。在第 一种情况中，节点B可能同意来自节点A的请求。第二种情形描述了 节点A和节点B之间的消息收发，这两个节点都通过内部通信网络14 通信而且与软件体系10兼容。在这种情况下，节点B无法同意来自节 点C的请求，因为消息3中的API ID和Op码已经由前一个请求分 配。在这种情况下，节点B适当响应，导致来自节点C的查询(5)， 从而导致来自节点B的网络消息(6)，其包含允许节点C重新产生图 33的相同NVOEvent存储器结构所需要的信息，以及节点B的软件体 系10的图33的DynamicMemoryHeap唯一的API ID和Op码。
图28示出由本发明提供的可配置事件通知功能。优选地，事件在 默认触发时只通知外部客户机。但是，可能期望该外部通知在有些时候 “沉默”而实际上不从DAQ引擎30中去掉事件。此外，可能期望在事件 发生时通知软件体系10内的内部应用。由此，本发明提供了这样的功 能。如前所述，可以采用DAQ API内的设置外部事件开/关命令来更改 外部通知。此外，软件体系10优选提供内部功能来打开和关闭内部通 知。图28示出在可能的配置下的事件通知示例。
通过这种方式，本发明可以禁止和重新启动图33的NVOEvent在 内部通信网络14上的实现。此外，还可以禁止和重新启动图33的 NVOEvent实现为发送给软件体系10的相同软件运行环境16A内的软 件成分16B的内部消息。
图29示出本发明中经过确认的事件的功能。在经过确定的事件 中，软件体系等待来自客户机的确认消息一段预定的时间，直到处理下 个事件为止。如果预定的时间段结束，则执行预定次数的重试。优选 地，假定所有事件默认情况下都是未确认。因此，在向客户机发送事件 之后，DAQ引擎30立即处理下个事件。但是，一些应用需要确认这些 事件以保证消息被事件请求者接收。采用该技术，发送者可以在未接收 到确认时重新发送该事件。该确认证明请求者已经接收到该事件。提供 经过确认的事件的选择的优选实施例的优点在于，由请求者根据应用需 要决定是否需要确认。因此，当请求者在与DAQ30连接的接口中采用 由软件体系10提供的机制来产生事件，消息28A包含了提供该事件是 得到确认还是未被确认的进一步分类。如图29中的示例所示，在发生 确认事件时，软件体系阻断所有其他事件，同时等待来自客户机的确 认。如果没有接收到确认，则软件体系10在可配置的时间量之后重新 发送该事件。该重试序列将发生可配置的次数，直到最后软件体系停止 尝试发送该事件并通过失败的回叫功能通知该应用。
图30示出在本发明中提供的安全特征。由于外部节点执行关键功 能可以通过前面描述的协议进行，因此本发明提供了防火墙机制来限制 对命令执行的访问。认为是对安全性很关键的命令可以在编译前表格中 列出，优选在文件SAVariableMap.h中。命令可以具体列出(具有API ID和Op码)或作为全部API(具有具体的API和Op码＝0xFF)列 出。在该表格中列出的命令要求在防火墙之后。如图30所示，发明提 供了3级安全访问：拒绝访问，授权访问，临时授权访问。
优选地，所有节点默认状态下都以拒绝访问的访问级别开始。在该 访问级别中，只允许该节点执行防火墙前面的命令。由此不允许执行防 火墙之后的命令(或者在防火墙表格中列出的)。在成功提交永久密码 (在公布节点反馈消息的有效载荷中)之后，节点被提升至授权访问的 安全级别。在该访问级别中，允许该节点执行防火墙之前以及之后的所 有命令。为了进行防火墙之后的临时访问，节点可以成功地提交临时的 访问密码(在公布节点反馈消息的有效载荷中)。在该访问级别中，节 点访问防火墙之前以及之后的所有命令一段可配置的时间。该时间结束 之后，该节点的访问级别回复到其以前的状态。
具体地说，图30设想两个密码，每个密码代表通过命令防火墙的 逻辑识别的安全级别。当广播DAQ API的消息即公布SA节点消息 时，密码由部件或客户机发送。(参见字节3和4或Op码2)。一个密 码代表对认为是在防火墙之后的所有特殊命令进行永久访问。第二密码 向认为是在防火墙之后的所有特殊命令授予临时访问。无需密码，客户 机可以访问认为是在防火墙之前的所有命令。负责将软件体系10安装 到家用电器12的部件16上的工程师确定哪些命令在图30的防火墙之 前，哪些命令在该防火墙之后。
图31示出由本发明提供并在图30中示出的防火墙安全的运行的示 例。默认的，节点不能访问防火墙之后的命令。由此如图所示，如果不 能访问的节点试图执行受到防护的命令，则遭到拒绝。在提交错误的密 码之后，受到防护的命令还是被拒绝。只有在成功提交密码之后，才允 许该节点执行受到防护的命令。
图32示出软件体系10可以实施的标准公共接口。示出的是 ApplicationSpecificAPI，其还由设计者根据该应用的需要配置的有用的 功能。还示出与软件运行环境的其它软件成分的关联，软件体系10就 与该软件运行环境关联。
图33示出软件体系10的优选实施。示出执行和支持通过图32表 示的功能所需要的内部函数和存储器分配。还示出辅助类(Command Handler，Dynamic Memory Heap，Update Handler，NVOEvent， TimeHandler，WIDECommHandler，MessageParser和 AppSpecificCommandHandler)，其示出所需要的内部函数和存储器分 配的功能分组。还示出辅助类之间的关联。
图34软件体系10的源代码文件的优选组织。
图35示出3个主要状态(COMM_IDLE， COMM_EXPEXTING_ACK和COMM_PENDING)相互之间相关的 状态图的集合，每个状态可能具有多个子状态等。在此所代表的功能涉 及图33所示的协作关联。其调用也在图11中参照为从软件运行系统的 MAIN执行循环调用到软件体系10上的标准接口函数。
软件运行环境6A的MAIN函数(在图33和图11中示出)调用 SA类定义中示出的SA_WideComm()(其中SA及其聚合功能是软件体 系10)。该函数调用的结果在图35中示出。如图11所示，MAIN在软 件运行系统执行时定期调用SA_WideComm()。
图35示出与MAIN的第二次间接交互，这是MAIN对WIDE函数 WIDE_EXE()调用的结果。该协作在图11和图35中示出。在这种情况 下，WIDE_EXE()函数调用内的WIDE软件运行层14A调用 WIDE.BuildData()，后者又调用52中的 SA.WideCommHandler.SA_BuildData()。在图35中，该调用在 COMM_PENDING状态中示出。该执行路径在当前一状态 COMM_IDLE中COMM_IDLE的子状态内的逻辑导致针对WIDE网 络14的未决外发消息时进行。如图33所示，该状态变化通过调用函数 WIDE.QueueMessage()来实现。该调用导致调用图35的 COMM_PENDING状态内包含的逻辑。
图35的COMM_EXPEXTING_ACK状态是最初利用表明所需要 的确认的特殊指示符创建的外发事件的结果。如果正在 COMM_PENDING状态中运行的事件(也称为更新)需要确认，状态 从COMM_PENDING变为COMM_EXPEXTING_ACK。在这种情况 下，通过重新进入COMM_PENDING状态来重新发送该事件，如果暂 停时间结束而又没有接收到期望的确认消息的话。该过程要一直重复到 接收到确认或者超过可配置的重试参数(MAX_EVEVT_RETRY，每次 重新发送事件时该参数都增加)为止。
图36示出相互之间相关的状态图的集合。示出4个主要状态 (READY，TRANSMIT SNAPSHOT，UPDATES_BLOCKED， PROCESS_DAQ_EVENTS)。在此表示的功能涉及图33所示的协作关 联。其调用也在图11中引用为从软件运行环境的MAIN执行循环11调 用到软件体系10上的标准接口函数之一。
图36表示的功能的目的是估计图33的结构(NVOEvent)31，以 确定是否发生了发送事件的条件，收集该条件，并设置合适的标志 (Updates_Pending和Bounded Updates)，从而在35的状态机执行 时，由DAQ30检测到的事件条件实现为到WIDE总线14上的WIDE 分组24.
图37示出两个主要状态(MSG_READY和MSG_PROCESS)。在 此代表的功能涉及图33所示的协作关联，其中WIDE调用 SA.WideCommHandler.SA.AcceptData()。调用这些状态机也在图11中 引用为从软件运行环境的MAIN执行循环11调用到软件体系10上的函 数，其中MAIN调用SA.SA_ProccessIncomingEvents()。这些相互之间 相关的状态机管理到来命令的执行，响应请求，和处理事件。
图38示出执行软件运行环境的图33中的类的消息的有序集合。这 些消息代表针对在图39、40、41和42中标记为“发送WIDE消息”的共 用逻辑集的执行逻辑。从MAIN和WIDE(通过WIDE_WXE())的调 用在图11示出。
图39示出执行软件运行环境的图33中的类的消息的有序集合。这 些消息代表在包含软件体系10的软件运行环境内的交互。来自MAIN 的调用在图11中示出。该图示出向DynamicMemoryHeap添加良好成 型的NVOEvent存储器结构所需要的消息收发。
图40示出软件运行环境的图33中的类的消息的有序集合。这些消 息代表在包含软件体系10的软件运行环境内的交互。该图示出图37的 消息执行。来自MAIN的调用在图11中示出。由该图代表的功能的目 的是估计在DynamicMemoryHeap内获得的NVOEvent存储器结构， 收集这些存储器结构及其事件触发判断标准得到满足的合适的数据值， 并保证为了通知其他客户机16/22满足该触发器判断标准的NVOEvent 和关联的数据值的目的，分组24实现到内部通信网络14上。
图41、42、43为了处理来自网络14的到来命令(NVO)的目的示 出软件运行环境的图33中的类的消息的有序集合。这些消息代表包含 在软件体系10的软件运行环境中的交互。从MAIN和WIDE(通过 WIDE_WXE())的调用在图11示出。在下面各段中单独描述的图代表 用于执行的替换路径的3种情况。
图41示出处理来自客户机22/16的从内部通信网络14到来的消息 所需要的消息收发，该客户机不需要包含有意义数据的响应[Command- NotReponse]，而包含发送到来消息的成功或失败原因的响应(API ID ＝1，Op码＝1的ACK或NAK)。
图42示出处理来自客户机22/16的从WIDE总线14到来的消息所 需要的消息收发，该客户机需要多个包含有意义数据的响应消息 [Commmand-MultipleResponseRequired]以及发送到来消息的成功或失 败原因的响应(API ID＝1，Op码＝1的ACK或NAK)。
图43示出处理来自客户机22/16的从内部通信网络14到来的消息 所需要的消息收发，该客户机需要一个包含有意义数据的响应消息 [Commmand-SingleResponseRequired]以及发送到来消息的成功或失败 原因的响应(API ID＝1，Op码＝1的ACK或NAK)。
分类控制
是用新的控制装置来控制电器的典型现有技术方法是使该新控制装 置的软件部件复制电器控制器的逻辑，使得新的控制装置不会疏忽地请 求电器控制器的软件部件执行不能进行的操作。该现有技术方法还需要 电器和新控制装置之间涉及电器的当前状态的通信。该现有技术方法是 低效的，因为它要求复制新控制和装置和电器控制器上的逻辑。此外， 该现有技术方法要求每次将电器控制器引入新的控制装置中时都必须写 入新软件。
控制分类的目的是要避免要求复制控制装置和受控电器中的两个交 互软件部件之间的软件逻辑(通常称为业务逻辑)。具体地说，这允许 控制装置中的命令发生器很容易控制电器而除了控制分类本身之外不需 要任何关于正在受到控制的电器的信息。这可以实现“通用”控制装置的 引入以控制新的电器，将控制装置适用于新提供的循环或加入电器中的 功能，并让电器在提供不同的运行循环或功能的运行模式之间切换。还 控制电器更容易让用户使用，因为只需要向用户展现当前可由该电器提 供的选择。
本发明使用结构化的分类数据集来有效地告知控制装置控制装置所 需要的信息，以便为电器产生格式良好的(well formed)命令。在此使 用的格式良好的命令是有意义而且可由电器执行的命令。数据集传送的 信息包括执行该格式良好的命令所需要的选项和数据输入的分层结构。 在优选实施例中，还包括语义或上下文信息，用于以文字或图标的形式 通报可获得的选项，从而用户可以理解可获得的选择并输入合适的数 据。这优选通过与任意或非用户友好的标识元素关联的数据集内的标记 来完成。这使得必须解释和处理分类的软件部件的逻辑与分类在用户接 口上的呈现分离(如外语，标签，单位)。
参照图44，其概括性地示出本发明的改进的控制结构和方法，受控 的电器12具有软件部件2 16B，该软件部件包括电器控制器和状态发生 器。用于控制电器的控制装置16、22具有软件部件1 16B，该软件部件 包括命令发生器、选择创建器和状态解释器。控制装置16、22可以是 可编程用户接口如pda、web写字板、小区电话、连接到电器或客户机 装置的LCD。
设置在电器控制器16和逻辑中的分类体系可替换的设置在远程位 置，如设置在控制装置或互联网上。分类体系包括分类发生器、分类引 擎、分类翻译器和分类结构。分类体系产生定义分类能力的分类数据 集，其有助于：通过软件部件1产生格式良好的命令，该命令可以通过 分类引擎和可选的通过分类翻译器转换为由软件部件2执行的其他格式 良好的命令；通过软件部件1产生用户接口内容；在呈现给用户接口之 前验证状态信息。每个部件及其相互关系都在下面详细描述。
分类数据集的产生
分类数据集从电器控制器16的运行功能中产生，该电器控制器16 按照允许软件部件1中的命令发生器解释该数据集以完成几种结果的方 式构成。具体地说，分类引擎有时使用分类结构和状态察觉信息来产生 反映可由电器提供给当前可由电器获得的命令的统一选项的子集的分类 数据集。
例如，分类数据集描述由软件部件16B支持的可获得函数，每个函 数变量，以及数据结构中每个变量的有效值。此外，分类数据集定义反 馈变量的有效值。由于这在数据结构中，因此它可以按照需要发送和重 新发送给客户机16或22。由于运行循环发展和可获得的命令或者该命 令的变量的有效值改变，分类数据集发生改变。此外，当运行循环从 Idle(空闲)开始发展时，额外的命令可以提供出来或者变得无效。
具体地说，选择创建器注册分类管理器以接收给予新分类引擎的通 知。为了响应，分类管理器将对所有已知分类引擎的引用发回选择创建 器。然后选择创建器从每个分类引擎请求分类功能数据集。分类引擎评 估包括软件部件2的控制器逻辑分类结构或可替换地评估用于产生分类 功能数据集的文档。然后选择创建器配备适用于应用结束点(应用结束 点的示例是用于控制或维护或其他中间应用层如能量控制器或家庭自动 化模式如休假或晚安的用户接口)的一组伪命令结构，这些命令是选项 的分层结构，并且将这些结构传递给应用结束点，从而允许应用结束点 得到配置。替换的，选择创建器可以直接配置应用结束点。
数据集的通信和使用
当控制装置与电器联网时，分类管理器在软件部件1和分类体系之 间建立关系，以允许命令发生器查询分类数据集是否存在，向软件体系 1提供对分类数据集的访问，并允许命令发生器和状态解释器定购分类 数据集更新。分类翻译器是可选的部件，如果软件部件1和2没有被设 计为与分类数据集的相同实施例共同使用，则分类翻译器就在软件部件 1和2之间翻译分类数据集。
将分类数据集传送给软件部件2的控制器以及软件部件1的选择创 建器。可选的，分类翻译器将分类数据集翻译为命令发生器的不同的示 意定义。
命令发生器使用分类数据集来建立和填充一组可由用户接口或其它 客户机应用选择的命令结构，包括一组有效命令、该命令的有效变量、 每个变量的有效值。具体地说，命令发生器使用分类数据集建立一个或 多个格式良好的命令，然后可以将该命令发送给控制器。由于分类数据 集可以在不同的时刻由分类引擎复位并发送，或者该数据集可以通过来 自分类引擎的修改而更新，因此软件部件1可以具有当前的命令结构 组，然后该命令结构组可由用户接口或其他客户机应用选择。
由此实际上通过采用分类体系，软件部件2或其代理(分类引擎) 向软件部件1通报可以由软件部件1解释的规则集，从而软件部件1不 请求软件部件2的其自身无法供给的东西，并且不对设置为无效值的状 态变量进行操作。
在应用结束点可以开始执行之前，应用结束点用状态解释器请求或 注册状态更新。这将使得在执行逻辑之前以及在用户接口部件交付之 前，应用结束点可以具有来自状态发生器的有效状态变量。状态解释器 将处理分类正确的状态数据集，并根据分类功能数据集验证这些数据 集。状态解释器通过分类引擎请求或注册来自软件部件2的状态发生器 的状态更新。在接收到分类正确的状态时，状态解释器向应用结束点提 供新的状态值。
应用结束点执行，从而导致软件部件2的当前状态的提交以及可选 择的伪命令结构的提交。每次从伪命令结构中选择时，选择创建器都填 充在分类功能数据集中找到的一组有效的子命令，这组子命令适用于由 应用结束点进一步选择。在结束选择时，包含所有伪命令的结构被传递 给命令发生器。
命令发生器建立分类正确的格式良好的命令并且可选地通过分类翻 译器，通过分类引擎在软件部件2的控制器上调用该命令。
执行
将格式良好的命令传送给电器的控制器并由电器执行。
典型的，该命令将导致软件部件2的有关存储器发生状态变化，该 状态变化会触发由状态发生器创建的状态更新，并导致应用结束点的新 的状态提交。状态的变化导致新的功能分类或者可以替代原始功能分类 的一部分的部分功能分类。新的功能分类导致一组不同的有效选择用于 控制软件部件2的运行循环。
验证
状态解释器使用分类数据集从状态发生器验证由分类引擎或翻译器 发送的状态更新。此外，作为分类数据集的来源的分类结构，允许控制 器根据该结构完全验证到来的命令，而无需数据集之外的附加逻辑。例 如，分类结构可以在概念上认为是一个或多个判决树，分类的每一级形 成不同的判决分支或一组判决分支，每个选项和/或数据输入可以形成不 同的级别。电器的运行循环要求用户在形成格式良好的命令时选择该选 项和/或数据输入。这些选择可以与判决树相比较以确认每个循环、循环 属性或循环选项都在判决树的合适分支内。如果期望的运行循环、属性 和选项没有在该命令中，则表明该命令含有错误。分类结构由此用于向 用户接口填充可用的、针对电器的给定状态的选项和数据输入，而且也 用作验证所产生的命令的逻辑。
分类数据集是作为对象或软件结构的分类结构的数据代表。分类数 据集包含所有针对电器当前状态的可用的命令、选项和设置，以及当前 状态时的所有有效状态值。例如，电器包括通过内部网络互连的多个部 件。每个部件可以具有一个或多个装置。每个装置具有一个或多个功 能，每个功能具有一个或多个设置。所有装置的所有功能都不必在电器 的每个状态时可用。这样，分类数据集包括针对当前可用的所有装置的 所有选项和数据输入。
图45-48示出在微波炉的用户接口16、22的环境中的分类控制的 示例，该分类控制具有表明电器12当前状态下可用的功能的分类数据 集。用户可以从该数据集的参数中选择以形成格式良好的命令，该命令 将被发布以用于控制电器12的操作。
图45示出选项和数据输入的可用分层结构。该分层结构的顶级从 循环100开始，其示出具有煮、解冻、煮马铃薯、蒸煮、自动重新加热 和餐盘作为示例。用户必须从顶级中选择一个选项。
一旦用户从顶级中进行了选择，该分层结构的基于顶级选择的下一 级就呈献给用户。在图46中，用户选择了“煮”选项，用户接口然后以 时间102和功率电平104的形式显示可用于该选项而且是形成格式良好 的命令所需要的数据输入。
图47示出顶级的选择暴露了子集的选项。在图47中，选择解冻， 这呈现出子集类型“肉”106.用户必须选择合适的肉选项来完成格式良好 的命令。数据输入以重量108和解冻电平110的形式呈现，而且必须选 择以完成格式良好的命令。
一旦用户从用户接口可访问的分类数据集中选择了这些选项和数据 输入，命令发生器就形成格式良好的命令并发送给电器的部件上的软件 部件2以便于实行。这仅在格式良好的命令经历了验证过程之后才进 行。软件部件2的控制器和逻辑使用该格式良好的命令控制装置的操作 以实行该格式良好的命令。
分类数据集和格式良好命令的创建证明是有用的。图45的微波炉 的公开了多个烹饪循环的分类数据集的创建是由选择创建器根据分类功 能数据集建立的，该分类功能数据集用XML显示如下：
units＝″seconds″max＝″6039″min＝″60″inc＝″1″/>
units＝″％″max＝″100″min＝″50″inc＝″10″/>
|
|
|
etc
如果图45的微波炉的用户选择用“转盘打开”在90％功率时“煮”30 秒，分类计划的格式良好命令将可选地传送给分类翻译器和分类。命令 形式为：
分类引擎接着穿越分类结构以便将分类计划的格式良好命令转换为 分组结构28的软件部件2的控制器的格式良好命令。分类结构是分类 功能数据集的超集。对于上述每个可指明的命令要素(即，循环，功 率，持续时间和转盘)，都在分类结构内关联形成有效载荷28A所需要 的附加的关键字和值的集合。这些关键字包括API Id，Op码，以及有 效载荷28A中的位置索引，其中位置索引可以是字节偏移量或位偏移 量。
分类数据集可以建立为直接代表软件体系10的API的可能命令领 域，从而为维修、工厂或实验室工程师或技师提供有用功能。
虽然结合具体的实施例描述了本发明，可以理解这只是举例而不是 限制，所附权利要求的范围应当与现有技术允许的范围一样宽。
相关申请的交叉引用
本申请要求2005年6月9日提交的美国专利申请60/595148的优先 权，在此通过引用合并该申请的公开内容。
一些物理部件具有相应的控制器(主控制器、电机控制器、用户接 口等)，其中控制器可以是安装在印刷电路板上的简单微处理器。其它 部件没有控制器。通常，具有控制器的部件(而且如果存在不止一个， 则这些部件通常还支持网络)通过网络消息收发或其它形式的数据传输 协作，以直接地或者通过其它部件间接地控制所有这些部件及其包含或 附属的装置的操作，从而实现电器的操作或循环。
该SA可以(但不是必须)驻留在具有控制器的每个部件上。具有 该SA或与该SA兼容的SA变形(通过发送、接收和处理分组的能力确 定的兼容性)的那些部件形成网络上能够与其它节点通信的节点。
SA执行多种功能：识别对应于网络节点的每个部件；识别所识别 到网络部件的能力或功能；识别网络部件的状态；为每个部件提供适当 限定的命令接口；提供内部软件成分和不是SA一部分的外部软件成分 之间的通信；提供不同物理部件上非SA软件成分之间的通信。通过这 种方式，SA用于向网络上的所有节点通报其它节点的存在、能力和状 态。
SA包括多个模块，每个模块具有不同功能。模块的各种组合或所 有模块可以驻留在每个部件上。一个具有本发明基本或核心功能的模块 驻留在所有部件上。在一种预期的配置中，所有模块至少驻留在主控制 器上，这使主控制器作为主SA或控制器SA工作，而其它节点以控制 器SA的客户机关系工作。在这种配置下，所有节点通过控制器SA通 信。
SA足够健壮，以至于其可以允许没有控制器SA或具有多个控制器 SA的配置。不管配置如何，任何具有驻留SA的部件都可以相对于其他 部件作为客户机工作。
内部通信可以被直接或者通过外部网络连接到一个或多个外部部 件。外部部件也可以驻留有一个、一些或全部SA模块。
从图1开始，现在描述本发明的具体内容。图1是示出软件体系10 的一个环境的示意图，(体现在此所述的系统和方法以及本领域技术人 员公知的内容)，形式为具有将多个部件16互连的内部通信网络14的 家用电器12，其中软件体系10驻留在至少一个部件16上，以使能该部 件，并且优选地，每个附加部件16具有驻留在其中的软件体系10，或 者能够协同工作的替换物。家用电器12还具有所示的互连到各网络接 口装置20的内部/外部通信连接18，用于与各种实施方式的外部客户机 22通信。
外部客户机通常包括能够与软件体系10交互的联网硬件和软件以 及计算硬件和软件。这可以通过包括外部客户机的实施例中的软件体系 10的全部或一部分或者能够与软件体系10通信以及完全或部分交互的 软件体系10的替换物来实现。已经实现了很多能够与软件体系10完全 交互的替换部件(C dll，Visual Basic Driver，Java Driver和Active X driver)。
对于本专利申请的文本并且考虑到本申请文本的附图，应当理解， 缩写“SA”是指本申请中用附图标记10描述的“软件体系”。
此外，术语“客户机”被用于表示其上驻留全部或部分SA、并且完 全或部分使能部件功能的部件。该部件可以是内部部件或外部部件。尽 管客户机主要被用于描述由SA使能的部件，但是客户机也被用于描述 由能够在内部通信网络14上成功地交换消息并与SA通信的替换软件使 能的部件。一般地，在谈到节点的软件方面而非硬件方面时，使用术语 “客户机”。
部件16可以包括一个或多个装置。因此，本申请中所使用的术语 “装置”可以指部件或装置。装置可以是共同地形成部件或者经由电路 (例如线束)、可以执行逻辑的物理部件和具有存储器的物理部件被连 接到具有控制器的部件的任何电子元件、电热元件以及电气化学元件。
如在此所述，电器12可以是本领域技术人员公知的各种公知电器 中的任何一种。例如，电器12可以是洗衣机、甩干机、微波炉、洗碗 机、冰箱、冰箱/冷冻箱组合、单独的冷冻箱、加热柜、冷冻柜、炉子、 炉灶面和炉子的组合、灶面等等。虽然所描述的发明环境是电器环境， 但是本发明可应用于具有联网部件的任何类型的机器。
如在此所述，内部通信网络14可以是任何公知的互连管道、线路 和/或导线或适于将家用电器12的各内部部件16互连的无线系统。如本 申请背景部分所述，WIDE网络是适于提供对于支持本发明的软件体系 10所必需的内部通信的内部通信网络14。对于本领域的技术人员来 说，软件体系10显然可以在任何合适的内部网络上运行，而且在此所 提供的示例性例子(即WIDE网络)只是合适的内部通信网络14的一 个示例。
如前所述，部件16是家用电器12的任何基于处理器的部件或子部 件。适于接收和安装根据本发明的软件体系10的部件16的例子包括但 不限于电机控制微处理器、微处理器使能的键区控制器、LCD用户接 口控制器和其它通常包含在家用电器12内的装置控制。
内部/外部接口连接器或槽18适于连接多种类型的装置20，这些装 置能够在内部通信网络14以及诸如RS-232系列、各种形式的无线网 络(Zigbee、Wi-Fi等)、USB或有线以太网等的至少一个其它网络上通 信。装置20的功能可以被严格限制为协议和物理层转换，或者可以被 扩展为除了其基本协议桥接功能(base protocol bridging function)之 外还支持增值服务。
软件体系10允许家用电器12连接到的外部客户机22的例子包括 但不限于基于个人计算机的控制开发件、工厂测试应用程序、诊断应用 程序、现场测试应用程序以及与所连接的家用环境的接口。与相邻于或 远离电器12的外部环境的这种连接使得增值应用程序可以与电器12通 信。一些例子是：
●自动化工厂测试
●能量管理应用程序
●工程开发工具
●电器维护和诊断工具
●电子控制制造功能性验证测试
●消费者应用程序等。
系统级体系(参与以实现家用电器的有用目的的机械的、电的以及 软件的元件)包括软件体系10和与软件体系10分离的软件元件。在 此，系统体系的部件的微处理器内的软件元件集合(包括但不限于软件 体系10)被称为软件运行环境16A。软件体系10由3个部分组成：核 心实施、应用协议定义、一个或多个应用程序接口(在此称为“API”或 “多个API”)。
核心实施
软件体系的核心实施是在电器控制微处理器中运行的软件模块的集 合(在图3的示例是SACore、SADiscovery、SADAQ、 SAPortMemory、SAPollVariable)。如图11所示，核心实施优选在电器 控制微处理器的主(MAIN)循环中执行，这对本领域技术人员来说是 显而易见的。该核心通过内部通信网络14提供通用应用消息收发层， 并且基于能开发交叉平台连接应用的灵活设计。作为核心实施的一部 分，存在在每个电器上统一实施的核心API。此外，在统一实施不实际 的地方，可以使用发现机制(discovery mechanism)，以允许客户机适 应该非统一性。
应用协议定义
协议是用于调节网络中节点之间的数据传输的标准程序。消息用数 据的一个或多个分组在内部通信网络中发送，这些数据分组随后集合起 来形成已通告的消息。关于软件体系10存在两种可应用的定义领域。
1.分组定义：是针对组成分组的字节集合内的每个字节或者其中 一个字节内的位或位区间的预定义含义。图4和图24及其伴随的描述 代表软件体系10的分组定义。
2.消息次序和消息收发规则：协议的定义通常超过了分组定义 (1)而包括管理消息的期望有序集合的规则，该消息是完成特定有用 事物所需要的。具有消息规则的有序消息(事物)的示例在图6、9、 27、29、31中示出。
应用编程接口
API是一种通信和消息收发的契约，其规定一个网络节点如何与其 它节点通信。这通过定义可获得的功能调用、每个功能调用的变量、每 个变量的数据类型以及在某些情况下每个变量的有效值来完成。
在很多情况下，API特定于应用或电器12，因此不认为是API核 心(标准组)的软件体系10集合的一部分；软件体系10核心可以启动 多个API并将这些API暴露给客户机16、22和可能20。
系统级别的体系
软件体系10被设计为随着时间完成若干目标。
1.在现有控制体系的约束内的业务生产力。
2.通过启动和实现新控制体系的业务生产力。
3.支持和更好地启动核心业务功能“创新”、“制造能力”、“质量” 和“维护能力”。
4.通过启动具有软件体系10的制造电器启动新的成长机会，该软 件体系10除了连接器18之外还产生“可连接的”电器。该策略通过具体 化联网电子装置的成本而将连接的风险和成本降至最低。
为了实现该体系的全部潜能，可以在电器12上提供简单的连接 器，使得可以将网络卡插入该电器中。参见图1和18-22中的连接到 电器12的合适外部NIC20的示例。由于电器12已经为其内部目的而具 有内部的低成本网络14，因此用于通过内部/外部接口18将内部通信网 络14与外部NIC20连接的其它连线降至最少，而且可以按照公知方式 完成，例如通过三线串行电缆、外部连接器和安装固定设备。
软件体系10优选可以驻留在家用电器控制系统的所有部件16上。 但是，在禁止成本或其它约束的地方，软件体系可以驻留在家用电器的 控制系统内的部件16的子集上。
该“可连接”体系的示例性优点包括但不限于：外部NIC20可以在交 易之后添加，从而降低电器12的基础成本。NIC20可以是已开发好的 支持多网络技术，由于软件体系10所呈现的标准接口应用和NIC可以 是交叉平台和通用的，内部低成本网络(如WIDE网络示例)用作标 准，API框架和发现允许很多增值命令，软件体系10使用受约束的事 件来保持状态和有效利用带宽，软件体系10被设计为在运行时接受配 置，从而给程序开发员一个更为灵活的、可以缩短市场化时间的体系。
图2是图1的内部通信网络14的示意图，示出根据本发明设置在 内部通信网络14和部件16内部的软件运行环境16A中的各种软件成分 16B之间的软件体系10，该部件16组成家用电器12的控制系统。图2 的部件16代表在电器12中找到的典型部件，如电器管理器(主板或母 板)以及其它部件如电机控制和控制面板或键区接口，通常称为用户接 口。图2中的“Energy”和“Diag”标记是通过软件体系执行的典型非核心 功能的示例，如能量和功率管理(“Energy”)和故障查找或诊断 (“Diag”)。未在图2中示出的是由软件体系执行并通过标记10代表的 核心功能(API1-7和10)。
此外，软件体系10可以扩展到很多期望通过对等通信交换数据的 其它类型的系统体系。这些系统体系包括多节点系统，其中多个PCB 如电机控制、电器控制和智能传感器板利用软件体系10在电器12内通 信。图6所示的(以及后面所描述的)软件体系10发现协议可用于使 部件16产生新的行为或性能或向消费者提供新的功能，该部件16的存 在促使其它部件16适应它们的控制功能。图2的部件体系(结构化模 型)以及图6的发现行为和API ID、类型、版本的部件标识(参见API ID＝3)是体现为10的本发明实现具有新动态和智能系统体系的电器的 基础。
图3是图1的内部通信网络14的示意图，示出通过家用电器12的 内部通信网络14交换消息的典型电器控制部件16，包括下层协议， WIDE是该协议的一个示例，该下层协议负责OSI层-PHY、LINK和 部分网络层的功能，以及由根据软件体系10支持的上层协议(负责 OSI层-应用层、传输层和部分网络层的功能)。下层协议用作与软件 体系10关联的高层和电器中的部件之间的物理和链接层。通过这种方 式，软件体系10使用下层协议与实现控制器16相对于客户机22的控 制逻辑的第一软件运行层17通信，也使用第二软件层19来绕过该控制 逻辑并直接控制与控制16关联的装置。图3的装置是代表控制部件16 的功能性的物理元件。图3从软件/协议堆栈的角度示出控制体系10。
此外，图3提供了通过软件体系10启动的两种运行模式的示意 图，这些模式控制软件体系10暴露的网络消息和内部RAM、EE和其 他形式的非易失存储器16A以及输出装置层之间的访问和干预级别，输 出装置层是低级别的软件运行层16B，驻留在16A之内并提供对电连接 到部件的装置的直接控制。直接控制装置的输出装置层16B通过直接访 问微处理器端口地址存储器来进行直接控制，该微处理器端口地址存储 器又映射到微处理器的物理管脚，该微处理器又通过各种电设备连接到 电机械装置。
图3的软件运行层1代表特定于电器的软件成分16B，其将软件体 系10接收的网络消息连接到应用控制逻辑，从而导致应用控制逻辑采 取某种动作。如果电器处于开发状态(图3中用A标记的开关)，则附 加的软件运行层2(由API5(下层API)和API7(存储器/端口API) 及其实施和替换逻辑)使得API5和API7的网络消息可以改变物理存 储器16A和装置的状态。通过这种方式，可以与通常根据软件运行层1 的运行循环控制装置和存储器的应用软件无关地控制该装置和存储器。 该直接控制允许该装置的每个功能都得到独立的控制，这在开发或诊断 过程中是非常有利的。
软件运行层2可以通过由软件体系10暴露的特殊的网络消息和为 电器的各种状态定制的附加逻辑来进行状态改变(图7所示的例子)。 在开发状态期间，优选在用户通过图3的用户接口与电器交互时，软件 运行层1不会接收有关的用户接口输入。而是由软件运行层2接收来自 用户接口的输入。接着，软件运行层2可以与图3的替换逻辑交互。替 换逻辑又可以对软件运行层1的控制逻辑进行功能调用，更改存储器中 的值，或者更改所连接的多个装置的状态。但是，在开发状态期间软件 运行层1不能实现用户接口(LED、灯、蜂鸣器、文本和图形显示器 等)的状态。开发状态促使软件运行层1的控制逻辑无效，除非从软件 运行层2调用。在开发状态期间，API5和7的实施逻辑以及替换逻辑 完全控制电器12及其关联部件。
当接收到特殊的网络消息时，开发状态返回到(图7的)空闲状 态。此外，预计一系列键按压中的至少一个预定键按压还可能导致从开 发状态转换为空闲状态。
软件运行层1与运行层2是否启动无关地运行。开发状态的目的是 允许和实现事先没有想到的运行循环。该途径的优点是在图1中示出了 一些的电器的实施和配置不需要对电器的任何部件16进行新的软件修 改，因为电器具有通过软件体系10来支持任何想到的实施或配置的能 力。
这种能力有很多用途。该用途包括但不限于：
1.可以向用软件体系10启动的电器添加新的功能部件，从而不需 要修改事先存在的功能部件就能完成新的行为特性和运行循环。
这样的例子包括：
a.向洗衣机、甩干机、炉子和微波炉添加流控制
b.向电器添加能量和其他资源管理部件
c.添加除了内部网络14之外还能连接到外部网络的联网部件
d.向商业电器添加读卡器以产生有偿使用使用模型。
e.添加包括用于由客户机节点或电器或与用户界面交互的用户选 择和调用的附加运行循环的存储装置。
2.执行诊断测试，该诊断测试可以通过促使每个输出顺序地验证 所期望的结果来完成(示例：加热器通电-观察到温度上升，进料阀通 电-观察到水平面上升，冰碾碎电机-观察到碾碎装置的旋转)
3.执行自动的成批测试
4.执行自动的性能测试和DOE实施
5.执行自动的寿命测试
6.执行部件16单位测试和自动的回归测试
7.执行自动的ECM测试
8.执行其他形式的特殊调试和测试
9.促使替换客户机装置(例如PC)控制电器12，以允许使用替换 的软件运行环境16A将可选择的运行循环域开发和测试为通常在最后生 产内嵌计算部件16上所需要的，该替换软件运行环境16A提供生产力 更高的编程环境，从而导致新电器模型的上市时间缩短。
图4是用于图1所示的家用电器12的内部通信网络14的分组结构 24的示意图，该分组结构具有有效载荷部分26，包括用于根据本发明 的软件体系10的应用分组结构28。分组结构28代表软件体系10可以 创建并发送给其它部件16和22(具有软件体系10或者设计为可用分组 结构28运行的软件体系10的变形)以用于有意义的数据交换的良好形 成的消息。分组结构28占据分组结构24内的位置26，但是分组结构 28可以在分组结构24的变形中占据替换位置。28A代表在28内根据分 组结构28的API Id和Op代码定义的分组结构。
在网络协议中，分组(有时也称为消息)是顺序发送的字节的集 合，代表一条完整消息的全部或一部分。通常，分组由包括路由信息的 标题、作为数据的主体(也称为“有效载荷”)和有时包含校验和(即 CRC和)或结束符如“结束”标志的尾部。有效载荷是包含在分组内的 字节的集合。有效载荷是在两个节点16的应用层之间传送的数据。网 络和协议的功能是将有效载荷从一个节点运送到另一个节点。有时一个 协议就作为另一个协议的有效载荷发送，按照这种方式协议可以嵌套或 形成堆栈。变量称为具有相关值的存储器位置。一个或多个变量可以包 括该有效载荷。事物是代表多个节点之间的完整数据交换的一系列消息 或分组。
分组和有效载荷之间的关系可以对可获得带宽的有效使用产生影 响。要考虑的权衡是在应用层要求的上下文中将有效载荷从一个节点传 送到另一个节点所需要的开销量。
协议分组结构24作为例如标识为oxED的第一标题字节，接着是 具有4个部分的地址字节。地址字节的第一部分包括第0、1、2位的目 标部分(D)。地址字节的第二部分包括第3位的广播部分(B)。地址 字节的第三部分包括第4、5、6位的源部分(S)。地址字节的第四部分 包括第7位的保留部分(R)。地址字节的后面是由包括0-3位的维护 数据单元长度(SDU-L)和包括4-7位的SAP标识符组成的标识字节。 SAP标识符定义所附有效载荷26的结构。SAP4表示所附的SDU26由 与软件体系10关联的分组结构28定义。标识字节后面是维护数据单 元，其通常称为协议分组结构24的“有效载荷”并且通常由附图标记26 表示。有效载荷26后面是标准有效字节，如高字节、低字节组合，或 被本领域的技术人员统称为CRC16-CCITT。
应用分组结构28由协议分组结构24的有效载荷部分26形成。在 该应用分组结构28内执行由软件体系10允许的通信协议和数据交换。 应用分组结构28的第一字节包含由应用分组结构28的特定实例携带的 标识符(API ID)，是1-255的整数。应用分组结构28的第二字节在操 作码中(在此缩写为op码)包含1-31中的一个整数在位0-4，后面是 位5的命令或反馈(Cmd/Fb)标志、位6的分区(Flag)标志，以及 位7中的更多消息等待(MMP)标志。应用分组结构28的字节3-15包 括应用分组结构28的特定实例的有效载荷(即消息数据)。
基本上，软件体系10使用内部通信网络14的网络分组结构24的 两个字节的有效载荷26来用于附加协议。API ID是组织为功能单元的 Op码集合的唯一标识符。0xFF(255)和0x01(1)优选是保留的。Op码是 API内的唯一ID，其定义和标识单个的命令或反馈消息。每个API是 有关的类型(两个字节)和版本(两个字节)，从而允许随着时间创建 可识别、功能上相关的消息(op码)组的大型库。
优选的，x1F(31)是用于Op码的保留值。Cmd/Fb标志表示该消 息被分类为命令还是反馈。命令是要求采取行为的某种消息，而反馈是 只包含信息(确认，事件数据等)的某种消息。优选的，Cmd/Fb标志 对命令是0，对反馈是1。
Frag标志指明所接收的消息是否被发送者因为下层协议SDU26的 大小限制而分为多个消息(片段)。该消息的第一片段采用图4的结 构。该消息的所有随后的片段采用图24的结构。Frag标志优选一直置 位到分段的消息结束为止。
MMP标志表示事件作为单个消息发送但是通过协议约束在一起， 从而客户机可以将事件分组在一起作为微控制器的一次扫描的完整快 照。MMP标志优选一直置位到快照的最后一条消息发送出去为止。图 9以及伴随的讨论提供了关于约束消息的更多细节。
MMP标志向软件体系10提供了将电器12的状态表达为在快照中 约束在一起的独立含义的反馈变量的函数的能力。
当电器12的内部状态改变时，可能发送多个事件，这些事件合起 来描述电器12的新状态。描述状态变化所需要的事件数量是特定于电 器12的状态的。因此，使用特殊协议分隔符来允许数量特定于实施方 式的反馈变量与特定的电器状态变化关联。由于这些事件是有独立含义 的，因此该途径是优选的，因为事件(数据)集合的所有排列可以通过 使用MMP来创建。这导致标识命名空间(API Id和Op码)的有效使 用，因为在客户机要求发送新的数据组合时不需要新的标识符。总的来 说，MMP及其有关规则允许动态和虚拟的数据集合，从而消除了对特 定于特殊应用情况的解决方案的需要。在图9中，示出MMP标志的净 效应。
MMP标志还为内嵌的实施提供了抑制无效瞬时条件的能力。作为 电器状态转换，一组相关变量可以非常快速地变化几次。当电器状态用 作为单独的事件发送的独立反馈变量(反馈消息)表达而没有结合机制 时，可能发生模糊或无效的瞬时状态。此外，如果客户机在无效瞬时状 态期间执行业务逻辑，则逻辑错误可能导致不正确的控制或用户显示行 为。因此参照称为“状态完整性”的这一节来获得关于异步数据收集如何 是在微处理器的每次扫描内同步收集并且在MMP启动的快照内传送的 数据的次等途径的示例。此外，消息结合可以用于将独立的命令调用组 合在一起，从而可以批量处理这些命令调用。
应用协议28还管理进入的消息。总的来说，网络允许异步过程通 信，从而通过在短的时间窗内发送过多请求为一个网络接点产生超过另 一个网络节点的处理能力的潜力。为了防止消息超出限度，根据本发 明，采用允许发送者在发送第二个消息之前等待确认的协议。
该特征允许软件体系10基于软件体系10的执行状态8为该确认使 用枚举。通过这种方式，描述消息成功或失败的必要信息只用很少的消 息传达。命令发送者对发送的每条命令都接收枚举的确认。最普遍的是 积极的ACK，这表示该节点准备好接收下一条命令。所有其它枚举都 是故障的形式。故障的特征是确认字节的剩下254个可能的值。在该 254个值的范围内，一些得到标准化，一些保留给特定于应用的故障 码。
Frag和MMP允许软件体系10的用户在设计应用消息收发策略时 具有灵活性。如果开发人员选择使用非常大的消息，则可以使用Frag， 从而可以通过将原始的大数据组作为结构28的多个分组内的多个较小 的数据组来发送大于有效载荷28A的消息(即在此所示的示例性应用分 组结构28内的13个字节)。
通过相同的令牌，如果开发人员选择使用较小的消息(情况通常如 此)但是期望将这些消息组合在一起，则可以使用MMP。例如，如果 3个字节的10条消息分别需要作为一个组发送从而客户机应用可以知道 这些消息与微控制器的同一次扫描有关，则前面的9个消息具有被置位 的MMP，后面的消息组具有MMP＝0。
下面给出为软件体系10定义的API的总结，然后详细描述每一个 命令和反馈消息。该途径的优点是允许开发人员选择软件体系10内是 用于开发的当前阶段的模块(即单元测试、工程测试、产生等)。此 外，编辑某些模块使得开发者可以在禁止RAM/ROM资源的情况下使 用部分软件体系10。API用它们当前选择的应用程序接口标识符(API ID)来描述，但是可以采用任何标识符而不会脱离本发明的范围。由该 特定API实现的有关功能在每个API下面列举出来。圆点功能(“●”) 是从软件体系10发送给客户机(例如内部客户机16或外部客户机22) 的反馈消息，非圆点功能是从客户机(16，22)发送给软件体系10的 命令。
注意到在本申请中使用了约定俗成。“扩展”是指一个API可以建立 在基本级别API的功能之上的能力。扩展关键字表示：当APIx“扩 展”API y时，API x＝API x+API y。该注解简化了记录保存和API存档 的任务。换句话说，API x还包括在API y中规定的功能。如果API x 和API y分别指定具有相同Op码的功能，则API x实施的实现可优先 进行。
下面的表格描述核心API(API ID＝1)：
●消息确认 ●公布Heartbeat ●设置Heartbeat阶段 ●新的Heartbeat阶段 ●读取存储器 ●公布存储器数据 ●读取EE ●公布EE数据 ●发送事件 ●公布事件
下面的表格描述了基本数据获取API
(基本DAQ，API ID＝2，类型＝1)：
●创建数字事件 ●创建字节事件 ●清除事件 ●公布清除的事件 ●复位SA ●公布复位的SA ●置位外部接通 ●公布外部接通 ●置位外部断开 ●公布外部断开
下面的表格描述扩展的数据获取API(扩展的DAQ，API ID＝2， 类型＝2)：
扩展的DAQ包括运行时的基本DAQ。
●获得事件数据 ●公布数字事件数据 ●公布字节事件数据 ●建立远程数字事件 ●建立远程字节事件 ●获得远程变量数据 ●公布远程变量数据
下面的表格描述发现API(API ID＝3)：
●找到节点 ●公布节点 ●获得API ●公布API ●获得API信息 ●公布API信息 ●获得实例信息 ●公布实例信息
下面的表格描述核心调试API(API ID＝4)：
●公布饱和 ●饱和消息的寄存
下面的表格描述下层API(API ID ＝5)：
●置位开发状态 ●公布状态 ●TBD(特定于电器)
下面的表格描述核心键按压API(API ID＝6)：
●按压键(键索引) ●公布键按压(键索引)
下面的表格描述核心存储器/端口API(API ID＝7)：
●写入存储器 ●写入EE
能量管理API是API ID＝8。与其他API一样，能量API由Op码 的集合组成，每个Op码代表涉及能量管理的有用功能，并且具有是达 到这些功能的合适参数的关联字节集合。
下面的表格描述轮询变量API(API ID＝10)：
●读取轮询变量 公布轮询变量
核心API(在此API ID＝1)是可以部署的软件体系10的最小子 集。但是，可以想到开发与分组结构28兼容的其他实施例。规定设计 参照图5的两个硬编码的数据获取机制。
在核心API中，一种协议机制即图5的发送事件允许客户机(16， 22)请求事件源发送所有事件或发送一套特定的事件。通过这种方式， 在事件体系的框架内实现轮询类型而无需单独的消息定义或实施结构和 逻辑。此外，该机制实现了文件的系统启动条件。例如：如果所有网络 节点在系统通电时同时发送所有事件，在客户机16或22的软件内更可 能发生误操作，其中在此的软件成分由于通电条件而不能准确处理多个 消息。
DAQ API(API ID＝2)代表由软件体系10实现的用于部件16的 动态机制查询。该特征允许客户机16/22配置内嵌的软件引擎(一种结 构阵列，该阵列的元素实例化和存储在动态存储器堆(heap)【参见图 33的DynamicMemoryHeap，包含NVOEvent结构的集合】)，该软件 引擎将一部分微处理器存储器与事件操作码(描述在下面的表格中)和 变量关联。指向存储器的指针、存储器的值、事件操作码和操作码变量 存储在存储器堆的结构阵列中(图33包含NVOEvent结构的 Heap[])。如图5所示，DAQ引擎可以用两种方式配置：
1.驻留在相同微处理器中并与软件体系10分离的应用软件可以按 照图5的箭头所示从DAQ Init()软件成分来配置DAQ30。
2.其次，外部客户机可以使用DAQ API(在此所述的)从网络14 配置DAQ。
每一种DAQ配置方法的有理数分为3段讨论。
如在图36的处理DAQ时间状态图中所示，在执行DAQ引擎时， DAQ引擎对每个事件结构迭代，从而针对事件操作符和变量检查关联 的存储器位置。如果事件条件估计是真，则消息缓冲器在内部存储器内 构成从而反映与该事件条件关联的数据。如果迭代完成，则产生通报消 息并优选广播给网络。替换的，通报消息可以发送给特定的部件16，如 果分配附加的存储器来存储最初请求或配置该事件的部件的网络标识 符。
开发人员可使用几个事件操作符。例子包括：正在改变(on change)，大于，小于，等于，死带(deadband)，位掩码等。提供 DAQ API的几个Op码用于在运行时控制存储器堆，如：清除事件，添 加事件，外部通报接通/关闭，获得事件，获得事件数据等。
总之，软件体系10支持用于数据收集的4个机制(所有机制都在 图5中示出)。如上所述的4个机制中的两个机制取决于DAQ。另外两 个机制也在上面简要描述过，是硬编码的。每个机制可以共存在软件体 系10内。每个机制以消耗其它资源为代价提供某种优化。
1.在客户机配置的数据获取机制中，产生动态事件。如果微处理 电器有足够的RAM/ROM容量则可以使用该方法，而且如果客户机是 PC应用时该方法用得最普遍。利用DAQ API，开发人员可以再使用代 码，需要更少的引擎时间，平衡已证明可再使用的事件模块，很灵活 (例如可以在运行时配置)，而且存在网络带宽的优化。但是，该方法 比硬编码方法需要更多的RAM/ROM，而且内嵌的客户机不能在运行 时访问所需要的数据文件。
在客户机配置的数据获取机制中，DAQ引擎30必须具有存储器位 置以便观察事件。对于变量映射，在客户机是如图26所示的PC应用时 这是很实际的。但是，当客户机例如是实施软件体系10的其他控制板 时，访问变量映射是不实际的。因此，本发明为位于实施软件体系10 的节点的存储器中的内嵌变量映射提供了功能。该变量映射将API和 Op码与如图26B所示的变量地址连接起来。因为为了在所述节点上注 册事件，该客户机只需要知道该变量的API和Op码，而不是具体的存 储器地址。
利用内嵌在由客户机配置的数据获取机制中的变量映射，可能出现 限制特定客户机创建事件的情况，因为相关的API和Op码对已经由其 它节点注册。在这种情况下，本发明向该节点提供请求关于该内嵌的变 量映射的信息的功能。在该信息中包含了变量的存储器地址。利用该信 息，客户机节点可以采用该变量的地址和不同于事先尝试的API与Op 代码对来注册同一变量的事件(参见图27)。
2.由客户机配置的DAQ是自配置的DAQ。在这种情况下，内部逻 辑使用DAQ引擎在图33的DynamicMemoryHeap中创建NVOEvent 结构。这在要实现的事件在设计时是固定的且已知的，而且存在足够的 RAM和ROM资源来再使用DAQ30的不同引擎(包含在DAQ30内的 逻辑)时是一种有用的机制。因此该方法具有与由客户机配置的动态事 件机制相同的优点，而且比(下面描述的)硬编码方法需要更多的 RAM/ROM。
3.在硬编码事件模块中，开发人员可以优化网络带宽，优化 RAM/ROM的使用以及适应DAQ API。但是，该机制需要定制编码的 解决方案来产生事件，而且不依赖于图36所示的DAQ30的软件和逻 辑。
4.利用核心API提供的硬编码的轮询方法，开发人员可以通过创建 定制编码的解决方案来优化RAM/ROM的使用。轮询一般是浪费网络 带宽的，但有时候也因为其简单性而使用。
图5示出每种类型的潜在数据获取方法的一个示例。软件体系10 的安装可以支持这4中方法中的一种、一些或全部。安装10和客户机 16分别可以具有在它们上面初始化的DAQ API。软件体系10可以具有 一个或多个硬编码的轮询变量、一个或多个硬编码的事件、和/或所述的 DAQ引擎30。各种变量和事件在主软件体系安装和客户机之间传输。 例如，各种硬编码的轮询变量在软件体系10和客户机16之间通过读取 轮询变量和公布轮询变量方法来交换。各种硬编码的事件在软件体系10 和客户机16之间通过发送事件和公布事件方法来交换。创建事件方法 由发送给DAQ引擎30的DAQ Init引擎调用，该DAQ引擎30又与客 户机16通过发送事件和公布事件方法来交换产生的事件。软件体系10 中的DAQ引擎30还可以创建通过从客户机16接收的创建事件方法所 接收的事件。
图5A是示出安装了根据本发明的软件体系10的家用电器12和位 于远处的客户机16之间的通信的示意图，该客户机16例如是如图5A 所示的顾客呼叫支持中心。电器12具有连接到其内部网络14的接口 18，和能使电器12与外部客户机12通信的网络接口20.图5A的示意图 示出顾客服务中心，其使用DAQ引擎5创建事件功能建立起变量监视 并诊断家用电器12的毛病而不需要向住地发出服务车。
软件体系10可以定制为考虑不同实施平台的需要。RAM和ROM 空间和时间的复杂性是可以管理的，对存储器位置的访问以及断开时间 也是可以管理的。所有这些都位于预定的参数文件中。应当理解这些参 数可以重新命名、更改、重新打字、添加或删除而不会脱离本发明的范 围。
发现API(API ID＝3)实现了“Plug’n Play(即插即用)”体系的 概念。发现API暗示物理网络节点或客户机16可以获得n个功能，每 个功能都由公知的、具有唯一ID、类型和版本的API封装。这些API 是便携式的(意味着他们代表功能而且与微处理器、软件语言和网络拓 扑结构无关)而且可在其它可应用其中的功能的部件上重新使用。发现 协议(在图6的API3中描述)允许客户机学习部件16和部件16包含 的功能组(API)之间的关联。
图6示出典型的发现API序列。由于在存储器中没有代表其它由软 件体系10启动的部件的结构，客户机16、22发送命令以找到电器内由 软件体系启动的部件16(通过发布“找到节点”的命令)。启动的部件回 答说它们确实已经启动(通过发布广播的“公布节点”命令)。然后，客 户机16发送命令以识别在每个启动的节点上存在什么样的API(通过 发布“找到API”命令)。每个已启动的节点用包含其API ID的有界消息 回答(通过用“公布API”消息来回答)。然后，客户机16、22发布命令 以识别关于在每个已启动的节点上找到的各API的信息(通过发布“获 得API信息”命令)。每个已启动的节点用包含关于该节点具有的API 的信息的有界消息(该消息的目的和结构在图9中描述)来回应。该消 息可以包括特定API Id的类型、版本和发生次数(或实例个数)。在一 个部件16内的特定API的实例个数超过1的情况下(意味着有多个相 同的API安装在部件16上，例如可能使用多个炉子控制API的一个多 灶炉子的情况)，客户机16发布命令以获得关于每个API实例的信息 (通过发布“获得实例信息”命令)。软件体系10用请求的信息来响应 (通过“公布实例信息”命令)。多个相同的实例由软件体系用伪API ID 自动编号。
此外，当由软件体系10启动并具有软件体系10的子部件即API Id ＝3的Discovery的部件16初始化时，该部件16自动发送宣布自己的 消息(API点＝3，Op码＝2publishSANode())。
而且，如果软件体系的用户这样选择，则图6的Discovery序列可 以通过省略消息1和2(Op码分别是1和2)来更改。该方法是有效 的，因为客户机可能通过发布Opma＝3消息，即导致由软件体系10启 动的所有部件都响应的getSAAPI(collection)来初始化发现，因此在大多 数情况下避免了对消息1和2的需要。
还想到缩写的消息序列可以达到与上述发现序列相同的结果。在缩 写的发现序列中，每个节点在通电之后发布在一条消息内包含在上述发 现序列中的全部信息的消息。接收该消息的每个节点用关于其自身的相 同信息答复，从而向刚刚通电的节点提供来自所有已经通电的节点的可 发现信息。
发现API协议机制允许客户机16在运行时找到本地实体而不需要 事先的编译时间编程。此外，该机制允许客户机16确定所期望的部件 是存在还是没有。根据这样的知识，客户机可以配置自身和/或向用户提 供合适的推断的功能。
下层API(API ID＝5)通过网络14暴露允许客户机控制(激活) 电连接到包含部件16的输出装置以及提供对代表电连接的输入装置的 当前状态和可能的状态历史记录的数值进行读取和/或写入访问的功能。 典型的输出示例是阀门、继电器、可控硅开关元件、LED、灯、蜂鸣器 等等。典型的输入示例是按下键、开关、传感器(例如压力、温度和超 温度)等。在优选实施例中，下层API以及存储器-端口API只在电 器12的软件体系10的图3的“开发状态”下才可获得。“开发状态”只能 从图7的示例性电器状态图的电器12的“空闲状态”进入。而且在该优 选实施例中，如果任何用户接口行为是在“开发状态”期间通过键区、 LCD或电器12的其他用户接口装置初始化的，则电器12可以回到图7 的“空闲状态”，并设置每个输出返回其未激活状态。用于初始化“开发 状态”的消息可以在下层API的消息定义规范中找到。(参见API5，Op 码2)。该网络消息定义为允许电器12进入开发状态。在开发状态下， 启动特殊的API并暴露给网络14，该API允许客户机16直接控制电器 12的电子输出。在开发状态下，面向生产的业务规则如确认被绕过，从 而给予客户机16对电子子系统的完全控制。
下层API可用于实施电器的非标准操作，因为电器可以按照不是根 据由驻留在主控制器上的电器软件运行层实施的预定运行循环之一的方 式来运行。通过这种方式，下层API可以认为是启动附加的运行循环。 附加运行循环的一些示例包括：示范循环；开发循环；检错循环；诊断 循环；减少预定运行循环之一的至少一个时间步骤的时间的循环；绕过 预定运行循环之一的至少一个运行步骤的循环；代替响应预定运行循环 之一的事件的步骤的定时步骤的循环；以及将下层API暴露给网络的循 环。
键按下API(API6)允许客户机16按下虚拟键。这提供了用于了 练习和测试软件的等价方法而无需物理键区的机械或人工激活。
注意在本申请中使用的约定俗成。“扩展”是指一个API可以建立在 基本级别API的功能之上的能力。扩展关键字表示：当APIx“扩 展”API y时，API x＝API x+API y。该注解简化了记录保存和API存档 的任务。换句话说，API x还包括在API y中规定的功能。如果API x 和API y分别指定具有相同Op码的功能，则API x实施的实现可优先 进行。
家用电器的内部通信网络所采用的分组结构的有效载荷部分的示例 性应用分组如下所示。该应用分组根据API分组。
核心API：API ID＝1(类型3，版本1)。下面的应用分组代表从 软件体系10指向客户机10的用于发布确认的消息(发布确认)。该消 息由软件体系10发送给前一消息的发送者。该消息包含代表由软件体 系10处理的前一命令的结果的列举值。一般来说，确认的接收表示发 送者可以初始化下一条消息。
API ID Op码 字节3 字节4 字节5 1 1:公布确认 原因代码 API OpCode
注意事先接收的命令(正在确认的命令)的API和op码包含在有 效载荷的字节4和字节5中。这向确认的接收者(发送原始命令的部件 16)提供关于事先发送的命令正在得到确认的确定性。(事先发送的命 令具有API Id和Op码的唯一标识符)。应当注意在附图和说明书中， 一般假定ACK而且该ACK不连续重复或存档，上述应用分组的原因 代码的列举值在下面的表格中示出。
原因代码的列举值 原因代码名称 编程注释 0 READY＊ 该命令被成功执行，SA准备好接受其它 命令。 1 BUSY＊ SA模块当前忙于执行命令。通常只是内 部状态。 2 REJECTED＊ 发送给SA的命令遭到拒绝，因为还有另 外的命令仍在处理中。 3 ACK_EVEVT 该命令没有执行，因为SA当前正在等待 确认。 4 UNSUPPORTED 该命令因为某种原因没有受到支持并且不 执行。(准备好下一条命令) 5 UNSUP_OP_CODE 该命令由于无效的Op码而不被支持且不 执行。 6 UNSUP_UNAVAILA BLE 该命令由于当前在该状态下不可获得而不 被支持且不执行。(就绪) 7 UNSUP_INVALID_P ARAM 该命令由于无效或超出有界参数而不被支 持且不执行。(就绪) 8 UNSUP_OUT_OF_ MEMORY 该命令由于动态heap被忘记而不被支持 且不执行。(就绪) 9 UNSUP_DOOR_OP EN 该命令由于电器门打开而不被支持且不执 行。(就绪) 10 UNSUP_BOUND_C MD_INCOMPLETE 该有界命令在指定的暂停时间之前没有被 完全接收，从而没有完全执行。(就绪) 11 UNSUP_CANNOT_ PAUSE_NOW 由于电器处理的状态而不能暂停。 200-255 特定于应用 应用开发人员可以在其应用中使用这些返 回值。由开发人员决定是否存档这些特定 于应用的原因代码。
＊0-3保留给软件体系10使用
下面的应用分组代表从软件体系10向客户机(16或22)的用于公 布heartbeat的广播消息(公布heartbeat)。该消息定期地由软件体系 10发送。这使得注册了事件的节点可以在事件源中保持信心。换句话 说，heartbeat保证连接的完整性。可替换的，客户机(16或22)可以 确定，在软件体系10相信与产生和发送事件关联的事务结束之前，由 软件体系10发送的每个事件或一些事件应当接收由客户机发送给软件 体系10的确认。如果特定的事件是用根据消息说明API2，Op码＝1， 2，12或13的“确认”的分类符创建的，则在接收到根据由API Id1和 Op码1指定的消息的确认消息时，软件体系10定义与产生和发送该事 件关联的事务已经完成。
公布Heartbeat在软件体系10接收到命令之后才会发送。这可以用 于防止在通电期间的通信量阻塞。(通信量阻塞是指客户机16或22的 软件内的误操作，其中客户机16或22内的软件成分不能准确地处理由 于通电条件而产生的多个消息)。公布Heartbeat将被暂停到接收了复位 SA消息之后，该复位SA消息将在下面针对核心DAQ API和Op码8 描述，但是公布Heartbeat会在下一条命令之后恢复。这是反馈消息。
API ID Op码 字节3-字节F 1 2:heartbeat
下面的应用分组代表从客户机指向软件体系10的用于设置 heartbeat周期的消息(设置Heartbeat周期)，该消息设置软件体系10 发送heartbeat消息的频率。示例性的频率范围从0秒(不发送)到 3600秒(1个小时)。
API ID Op码 字节3 字节4 字节5-字节F 1 3: setHeartbeatPeriod Sec MSB Sec LSB
下面的应用分组代表从软件体系10到客户机的用于发布heartbeat 周期的消息(发布Heartbeat周期)。该消息是对设置Heartbeat周期的 响应。该消息是必要的，因此如果第二客户机更改了该heartbeat周 期，将通知第一客户机。需要不变的heartbeat周期的客户机应当是用 DAQ API来建立具有恒定广播操作符的事件，参见DAQ API Id＝2， Op码1，字节9＝4，5或6(参见更改操作符表格)。
API ID Op码 字节3 字节4 字节5-字节F 1 16: newHeartbeatPeriod Sec MSB Sec LSB
下面的应用分组代表从客户机到软件体系10的用于读取存储器尤 其是RAM的消息(读取存储器)。该消息发送给软件体系10，并导致 “公布存储器数据”的响应，该消息在下面示出(Op码4)并且包含在下 面分组的字节3-7中指定的值。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节8 -字节 F 1 5:readMemory 地址 高字节 地址 中间字 节 地址 低字节 大小 MSB 大小 LSB
下面的应用分组代表从客户机导向软件体系10的用于读取存储器 的消息(读取)。该消息发送给软件体系10并且导致“公布数据”的响应 (Op码＝8)，该消息在下面示出并且包含在下面的读取分组、字节3- 7中指定的值。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节8 -字节 F 1 6:readEE 地址 高字节 地址 中间字 节 地址 低字节 大小 MSB 大小 LSB
下面的应用分组代表从软件体系10指向客户机的用于公布存储器 数据的消息(公布存储器数据)，并且是读取存储器的响应。
API ID Op码 字节3 字节4 字节5 字节6 字节n 字节8 -字节 F 1 4:publishMemoryData 数据 MSB 数据 数据 ... 数据 LSB
下面的应用分组代表从软件体系10指向客户机的用于公布EE存储 器数据的消息(公布EE数据)，并且是读取EE的响应。
API ID Op码 字节3 字节4 字节5 字节6 字节n 字节8 -字 节F 1 8:publishEEData 数据 MSB 数据 数据 ... 数据 LSB
下面的应用分组代表从客户机指向软件体系10的用于发送事件的 消息(发送事件)。该消息指示软件体系10发送指定的事件而不考虑事 件触发判断标准。
注意：事件Id是与Op码同义使用的。在描述作为API一部分的 事件时，事件Id是用于Op码的更具说明性的术语。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节 8- 字节 F 1 7:发送事件 API id (0xFF＝ 全部) EventId# (0xFF＝ 全部) EventId# EventId# EventId#
注意：下面使用的注释在本文件中通篇重复并只在这里描述。如果 字节3包含保留值0xFF，则软件体系10将字节3解释为代表所有API Id。否则，字节3就指定特定的API Id。类似的，如果字节4包含 0xFF，则软件体系10将字节4解释为代表在字节3中指定的一个或多 个API的所有事件。否则，字节4就包含一个事件Id。字节5到字节n 包含一个事件Id。
下面的申请分组代表从软件体系10指向客户机的用于发布时间的 广播消息(发布事件)，并且是上述发送事件消息的响应。替换的，如 果正在使用DAQ引擎，则当满足事件触发判断标准时发送该消息。下 面，API Id和Op码注释为“由客户机定义”。这是指API ID和Op码 由DAQ API(API Id＝2)的createEvevt命令(由客户机发送)分配， 具体在Op码1和2的字节7和8以及Op码12和13的字节3和4 中。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节8 -字 节F 由客户 机定义 由客户机定义 数据 MSB 数据 数据 ... 数据 LSB
核心DAQ API：API ID＝2(类型3，版本1)。下面的应用分组代 表从客户机指向软件体系10的用于创建数值事件的消息(创建数值事 件)。通过API Id＝2和Op码＝1或2标识的该消息允许客户机创建和 配置反馈变量[图33的NVOEvent结构]。字节7和8用于分配将用于 在事件条件使得事件消息得以产生时填满公布事件消息(API Id 1)中 的字段的标识符(API Id和Op码)。所产生的事件消息是在前面对核 心API的描述中找到的形式，其中对消息分组标以“公布事件”。标识符 API Id和Op码分别位于公布事件消息的字节1和2中。在这些字节中 找到的值可以通过下面为DAQ API、Op码1和2定义的消息分配。字 节3-5包含软件运行环境的存储器中的地址，该软件运行环境将用于 通过作为估计规则的列举的字节9以及作为估计规则的变量的字节A和 B代表的事件条件作估计。字节6指定应当相对于字节9、A和B被估 计为单个数值的相邻字节的数量。
在该节示例性应用分组之后将详细讨论与上述应用分组的字节9关 联的事件操作符，并且在标明在创建基于数字的事件时可获得的事件操 作符的表格中示出。另外，字节C还对应于导致确认事件或未确认事件 (下面讨论)的分类。参见图29中确认事件的操作的例子。
下面的应用分组代表从客户机指向软件体系10的用于创建字节事 件的消息(创建字节事件)。通过API Id＝2和Op码＝1或2标识的消 息定义允许客户机创建和配置反馈变量(事件)。Op码2的消息规格的 目的是类似的，但是具有为某些应用使用情况提供用途的不同的实施方 式。API Id2和Op码2在功能上与API 1和Op码1的不同之处在于， 依据字节A的值确定是通过字节3-5和字节6指定的范围内的仅一个 字节还是所有字节都基于字节9的更改操作符和字节B的更改值来估 计。而在Op码1的情况下，所指定的直接被估计为一个数字。在Op 码2的情况下，根据在字节A中指定的值，每个字节或仅一个字节将根 据字节9中指定的更改操作符和字节B中指定的更改值来独立地估计。
在该节示例性应用分组之后将详细讨论与上述应用分组的字节8关 联的事件操作符，并且在标明在创建基于字节的事件时可获得的事件操 作符的表格中示出。另外，字节C还对应于导致确认事件或未确认事件 (下面讨论)的分类。参见图29中确认事件的操作的例子。
下面的应用分组代表从客户机指向软件体系10的用于清除事件的 消息(清除事件)。清除事件消息允许客户机清除事先用创建事件Op码 (1或2，如上所述)创建的事件定义。如果需要在多条命令之间进行 同步，客户机可以用MMP标志向软件体系10发送多个清除事件命 令。
API ID Op码 字节3 字节4 字节5 字节6 字节n 字节 8- 字节 F 2 3:clearEvent API Id (0xFF＝ 全部) EventId# (0xFF＝ 全部) EventId# EventId# EventId#
下面的应用分组代表从软件体系10到客户机的用于公布事件被清 除的广播消息(公布事件被清除)，并且是清除事件的响应。该消息通 知软件体系10的客户机何时从现有的软件体系节点接口中去除Op码或 API。
下面的应用分组代表从客户机到软件体系10的用于复位软件体系 10的消息(复位SA)。复位SA命令指示软件体系10重新初始化到好 像刚开始通电时。
API ID Op码 2 8:resetSA
下面的应用分组代表来自软件体系10的广播消息，用于通知软件 体系10已经复位(公布SA复位)，该消息是复位SA的响应。
API ID Op码 2 9:publishSAReset
下面的应用分组代表从客户机到软件体系10的用于打开针对指定 事件的外部通告的消息(接通外部)。该命令指示软件体系10向外部向 客户机通告该事件。参见图28中使用该命令的示例。
API ID Op码 字节3 字节4 字节5 字节6 字节n 2 10:setExternalEventOn API Id OpCode OpCode OpCode OpCode
下面的应用分组代表来自软件体系10的用于通知指定事件的外部 通告已经打开的广播消息(向外部公布打开)，并且是接通外部的响 应。参见28中该命令的结果的示例。
API ID Op码 字节3 字节4 字节5 字节6 字节n 2 10:publishExternalOn API Id OpCode OpCode OpCode OpCode
下面的应用分组代表从客户机指向软件体系10的用于关闭指定事 件的外部通告的消息(关闭外部)。该命令指示软件体系不向外不向客 户机通告该事件。
API ID Op码 字节3 字节4 字节5 字节6 字节n 2 11:setExternalEventOff API Id OpCode OpCode OpCode OpCode
下面的应用分组代表来自软件体系10的用于通知指定事件的外部 通告已经关闭的广播消息(向外部公布关闭)，并且是关闭外部的响 应。
API ID Op码 字节3 字节4 字节5 字节6 字节n 2 10:publishExternalOff API Id OpCode OpCode OpCode OpCode
核心DAQ API：API ID＝2(类型4，版本1-扩展类型3，版本 1)。下面的应用分组代表从客户机指向软件体系10的用于获取事件数 据的消息(获取事件数据)。获取事件数据指示软件体系10发送指定数 据的定义。该定义是在创建事件Op码消息中发送的数据的镜像，该消 息在上面作为核心DAQ API的Op码1或2示出。软件体系10用公布 事件数据消息的集合响应，这些消息如下所示。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节 8- 字节 F 2 5:getEventData API id (0xFF＝ 全部) EventId# (0xFF＝ 全部) EventId# EventId# EventId#
下面的应用分组代表从软件体系10指向客户机的用于公布数字事 件数据的消息(公布数字事件数据)，并且是获得事件数据的响应。每 个事件定义都在分离的内部网络消息中报告，并且通过与图4的28的 MMP标志关联的快照规则管理。事件定义包含关于在创建数字事件中 的事件的信息。
在该节示例性应用分组之后将详细讨论与上述应用分组的字节8关 联的事件操作符，并且在标明在创建基于数字的事件时可获得的事件操 作符的表格中示出。
下面的应用分组代表从软件体系10指向客户机的用于公布字节事 件数据的消息(公布字节事件数据)，并且是获得事件数据的响应。每 个事件定义都在分离的内部网络消息中报告，并且通过与图4的28的 MMP标志关联的快照规则管理。事件定义包含关于在创建字节事件中 的事件的信息。
在该节示例性应用分组之后将详细讨论与上述应用分组的字节8关 联的事件操作符，并且在标明在创建基于字节的事件时可获得的事件操 作符的表格中示出。
下面的应用分组代表从客户机指向软件体系10的用于创建远程数 字事件的消息(创建远程数字事件)。该消息允许客户机或内嵌系统中 的其它模块使用内嵌变量映射来配置与现有的API和Op码关联的反馈 变量。尽管数量可以是4个字节，更改值可限制为两个字节。图26B示 出内嵌的变量映射。图27定义3个网络节点之间的交互，其中节点A 在节点B上成功创建远程数字事件。节点C试着进行相同的工作，但 是通过与节点B的交互，这可以完成该请求的目的而不需要复制标识符 (API和Op码)。其完成的原因是因为节点C可以向节点B查询存储 器中初始标识符的地址，从而可以选择替换(非复制的)的标识符。然 后将该替换的标识符用于通过向具有原始存储器地址和替换标识符的节 点B发送(参见图27中的消息8)新消息来创建远程数字事件。
图26B示出内嵌的变量映射。图27定义3个网络节点之间的交 互，其中节点A在节点B上成功创建远程数字事件。节点C试着进行 相同的工作，但是通过与节点B的交互，这可以完成该请求的目的而不 需要复制标识符(API和Op码)。其完成的原因是因为节点C可以向 节点B查询存储器中初始标识符的地址，从而可以选择替换(非复制 的)的标识符。然后将该替换的标识符用于通过向具有原始存储器地址 和替换标识符的节点B发送(参见图27中的消息8)新消息来创建远 程数字事件。
下面的应用分组代表从客户机指向软件体系10的用于创建远程字 节事件的消息(创建远程字节事件)。该消息允许客户机或内嵌系统中 的其它模块使用内嵌变量映射来配置与现有的API和Op码关联的反馈 变量。
图26B示出内嵌的变量映射。图27定义3个网络节点之间的交 互，其中节点A在节点B上成功创建远程数字事件。节点C试着进行 相同的工作，但是通过与节点B的交互，这可以完成该请求的目的而不 需要复制标识符(API和Op码)。其完成的原因是因为节点C可以向 节点B查询存储器中初始标识符的地址，从而可以选择替换(非复制 的)的标识符。然后将该替换的标识符用于通过向具有原始存储器地址 和替换标识符的节点B发送(参见图27中的消息8)新消息来创建远 程数字事件。
下面的应用分组代表从客户机向软件体系10发送的用于从内嵌的 变量映射中获得远程变量数据的消息(获得远程变量数据)。该消息指 示软件体系公布涉及存在于内嵌的变量映射中的数据的信息。参见图27 中使用该命令的示例。
API ID Op码 字节3 字节4 字节5 字节n 2 14:getRemoteVarData API Id OpCode OpCode OpCode
下面的应用分组代表从软件体系10发送给客户机的用于公布远程 变量数据的消息(公布远程变量数据)，而且是获得远程变量数据的响 应。该消息报告来自内嵌的变量映射的数据，如API、Op码、大小和 地址。
核心发现API：API ID＝3(类型3，版本1)。参照图6，下面的应 用分组代表来自客户机的用于找到软件体系10的节点的广播消息(找 到节点)。该广播消息使得节点可以找到软件体系10的其它节点。
API ID Op码 字节3 3 1:findNodes
下面的应用分组代表来自软件体系10的允许软件体系向其它参与 14的部件公告其存在的广播消息(发布节点)。该消息是在软件体系10 的节点通电或复位时发送，或者作为对找到节点的响应而发送。另外， 该消息可以在软件体系10的节点通过第二发现过程(给自己)添加 API或向现有的API添加Op码时发送。当客户机动态地向软件体系10 添加API或Op码(通过DAQ Op1，2，12，13)时不发送发布节点。反馈 消息的有效载荷包含防火墙密码，该密码由软件体系10的防火墙安全 特征使用(参见图31中该特征的示例)。这使得该消息的发送者成为网 络14中“受信”的节点。
API ID Op码 字节3 字节4 3 2:publishSANode 防火墙密码MSB 防火墙密码LSB
下面的应用分组代表可以从客户机发送或广播给软件体系10的用 于获得软件体系10的API的消息(获得API)。该定向消息允许客户机 发现由软件体系10的具体节点支持的API。API Id在电器内必须是唯 一的。
API ID Op码 字节3-字节F 3 3:getAPIs
下面的应用分组代表从软件体系10到客户机的用于发布软件体系 10的API的广播消息(发布API)。该消息是获得API的响应，而且是 允许客户机发现由软件体系10的发送节点支持的API的定向消息。
API ID Op码 字节3 字节4 字节5 字节n 字节7-字 节F 3 4:publishAPIs API# API# API# API n
下面的应用分组代表可以从客户机发送或广播给软件体系10的用 于获得API信息的消息(获得API信息)。该定向消息允许客户机发现 关于指定API的版本和类型信息。
c Op码 字节3 字节4 字节5 字节n 字节7-字 节F 3 5:getAPIInfo API# (0xFF＝全 部) API# API# API n
下面的应用分组代表从软件体系10到客户机的用于发布API信息 的定向消息(公布API信息)，并且是获得API信息的响应。该定相信 息允许客户机发现关于指定API的版本和类型信息。每个API都有一 个消息，而且这些消息利用图4的MMP标志约束。
字节4和5代表可以用作API的特定子分类的指示的API类型。 类型的值可用于确定子部件(API)之间的兼容性考虑。字节6和7代 表(特定类型的)API的版本。该值可用于表示对功能的调试定位或更 改。对于类型，其启动了运行时兼容性检查，该检查可以告知客户机该 版本是否兼容。可替换的，字节407可与字节3结合起来用于形成5字 节类标识符，其中类是指类库中的类定义(本领域技术人员可以理 解)。利用替换的方法，字节3(API Id)是运行时对象处理程序，字节 3-7在数值上链接地形成类id。
与字节8关联的实例个数向客户机标明API具有多个实例。客户机 可以跟随下面描述的获得实例信息来找到属于该API的实例Id。Descr Char 1-Descr Char n是可以有助于开发者的可选特征。描述性的文本可 用于注释API Id。例如，“上”或“下”可用于双炉灶的两个灶穴。
下面的应用分组代表从客户机到软件体系10的用于获得实例信息 的定向消息(获得实例信息)。该定向消息允许客户机发现报告API的 多于一个实例的API的实例Id。任何API的第一实例都使用API Id作 为其实例Id。如果在相同的可寻址节点上存在具有一个API Id的多个 实例，则向随后的实例动态地分配实例Id。当一个物理网络节点上存在 一个API的多个实例时，这些动态分配的Id可以代替API Id使用。
API ID Op码 字节3 字节4 字节5 字节n 字节7-字 节F 3 7:getInstanceInfo API# (0xFF＝全 部) API# API# API n
下面的应用分组代表从软件体系10到客户机的用于发布实例信息 的广播消息(发布实例信息)，并且是获得实例信息的响应。该定向消 息允许客户机发现实例Id。任何API的第一实例都使用API Id作为其 实例Id。如果在相同的可寻址节点上存在具有一个API Id的多个实 例，则向随后的实例动态地分配实例Id。这些动态分配的Id通过上述 公布API信息消息通信。为统一起见，公布API信息是为第一实例发 送的(即当API Id＝实例Id时)。对API实例存在一个消息，该消息使 用MMP标志来约束。当一个物理网络节点上存在一个API的多个实例 时，实例Id的值可以代替API Id使用。
1允许API子分类或专门化。例如，API Id可以指洗衣机API，类 型可以指定特定的洗衣机模型。
2启动版本控制(即对功能性的调试固定或更改)。启动运行时兼容 性检查，该检查可以通报客户机这些版本是否兼容。
3允许客户机将实例Id与其物理功能关联。例如“上”或“下”可用于 双炉灶的两个灶穴。
优选地，Descr Char 1-Descr Char n允许客户机将实例Id与其物 理功能关联。例如，“上”或“下”可用于双炉灶的两个灶穴。但是，软件 体系10的用户可以使用Descr Char 1-Descr Char n用于任何有用的目 的。
核心Debug API：API ID＝4(类型1，版本1)。下面的应用分组 代表从软件体系到客户机的用于发布饱和的广播消息(发布饱和)。饱 和发生在内部网络14的支持层不能运送软件体系10已经放入 WIDE14A的发送队列中的数据时。Aa110没有队列；如果WIDE14A 不能维护该发送数据，则软件体系10发送发布饱和消息。
API ID Op码 字节3-字节F 4 1:publishSaturation
下面的应用分组代表从客户机到软件体系10的用于设置饱和的寄 存器的定向消息(饱和的寄存)。客户机将该消息发送到软件体系节 点，该节点动饱和消息。只有启动饱和的节点才能禁止饱和。
API ID Op码 字节3-字节F 字节4-字节F 4 2:Saturation on或 off 1＝打开 2＝关闭
下层API：API ID＝5(类型1，版本1)。下面的应用分组代表来 自软件体系10的用于公布状态的广播消息(公布状态)。
该消息由于更改了机器的内部状态而发送，由正常的循环过程、用 户交互、下面的Op码2或通过网络14接收的其它消息产生。
API ID Op码 字节3 字节4-字节F 5 1:publishState 状态列举
示例性的机器状态列举值在下面的表格中给出。根据本发明的实施 例，运行状态包括在内。但是在某些情况下，运行状态有些模糊，附加 的阶段变量必须暴露，从而可以写入恰当的客户机端的业务逻辑。在替 换实施例中，消除运行状态以有利于更精细和确定性的状态机，其中每 个状态的每一阶段正确存档。在该实施例中，在用于附加列举的字节中 存在足够的地址空间。
机器状态列举 空闲 1 运行 2 编程 3 默认 4 开发 5 循环结束 6 暂停 7 保留 8 保留 9 保留 10 特定于电器 11-255
下面的应用分组代表从客户机到软件体系10的用于在开发状态和 空闲状态之间拨动用于管理图7的状态的家用电器12软件运行环境16 的定向消息。注意开发状态未在图7中示出，但是本领域的技术人员可 以想到开发状态只能从空闲状态进入而且在退出时返回到空闲状态。
API ID Op码 字节3-字节F 字节4-字节F 5 2:setDevelopmentState 1＝打开 2＝关闭
核心键按下API：API ID＝6(类型1，版本1)。下面的应用分组 代表从客户机到软件体系10的用于按下键的定向消息(键按下)。该定 向消息允许客户机发送虚拟的键按下。键索引由于在内嵌处理器中使用 的编码技术而不能被发现；因此，键索引可以手动地或通过其它自动机 制从源代码文件中提取。
API ID Op码 字节3-字节F 字节4-字节F 6 1:pressKey 键索引
下面的应用分组代表从软件体系10到客户机的用于公布键按下的 广播消息(公布键按下)。
API ID Op码 字节3-字节F 字节4-字节F 6 2:PublishKeyPress 键索引
示例性的键按下索引列举值在下面的表格中给出。
键按下索引列举 开始 1 取消 2 暂停 3 保留 4-25 特定于应用 26-255
存储器/端口API：API ID＝7(类型3，版本1)。下面的应用分组 代表从客户机到软件体系10的用于写入存储器的定向消息(写入存储 器)。存储器/端口API通过图3的开发状态启动，关联的交互类似于上 面描述的图3的开发状态和下层API(API ID＝7)之间的关联。
该定向消息允许客户机写入指定的RAM位置。写入到指定的 RAM位置只限于单个分组。在目前的实施例中，这是28的28A中示 出的13个字节。(28的)MMP＝1对该消息无效。
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节n 7 1:writeMemory 地址 高字节 地址 中间字 节 地址 低字节 数据字 节 数据字 节 数据字 节
下面的应用分组代表从客户机到软件体系10的用于写入存储器的 定向消息(写入)。写入到指定的RAM位置只限于单个分组。在目前 的实施例中，这是28的28A中示出的13个字节。(28的)MMP＝1对 该消息无效。
存储器端口
API ID Op码 字节3 字节4 字节5 字节6 字节7 字节n 7 2:writeEE 地址 高字节 地址 中间字 节 地址 低字节 数据字 节 数据字 节 数据字 节
轮询变量API：API ID＝10(类型1，版本1)。参照图5，下面的 应用分组代表从客户机到软件体系10的用于读取轮询变量的定向消息 (读取轮询变量)。该消息指示软件体系10发送下面示出的公布轮询变 量消息，以针对只用于轮询的变量。轮询变量可以是由开发人员为具体 应用硬编码的，而且可以在RAM/ROM资源不允许使用DAQ API时使 用。
API ID Op码 字节3 字节4 字节5 字节6-字节F 10 1:readPollVariable(s) 事件Id 1 (0xFF＝ 全部) 事件Id 2 事件Id n
下面的应用分组代表从软件体系10到客户机的用于公布轮询变量 的定向消息(公布轮询变量)，并且是读取轮询变量的响应。对在初始 化读取轮询变量消息中指定的每个轮询变量索引存在一条消息。
API ID Op码 字节3 字节 4 字节 5 字节 6 字节 7 字节n 字节 9-字 节F 10 事件ID n: (publishPollVariable) 数据 MSB 数据 数据 数据 ... 数据 LSB
上面在DAQ API一节中讨论了事件操作符的注释。创建事件数字 和字节消息(DAQ API Op码1和2)的字节9以及 CreateNumRemoteEvent和CreateByteRemoteEvent(DAQ API Op码 12和13)的字节5是在图33的NVOEventStructure中示出的事件更改 操作符。操作符是向软件体系10描述软件体系10应当产生事件消息的 数学条件的指示。下面的表格描述了事件操作符的例子。事件操作符的 变量取决于正在创建的事件的类型(op码分别为1和2的基于数字或基 于字节)。
事件操作符是具有两个变量的DAQ API的一部分：基本(类型 1)和扩展(类型2)。注意该表格中的第五列，其指明每个事件操作符 对于DAQ API的多个修订版本(4)的可获得性。
下面的表格给出可在创建基于数字的事件(API ID 2，Op码1和 12)时使用的事件操作符：
名称 操作符Id(字 节8) Arg 1(字节 9) Arg 2(字节 A) DAQ API类型 可用性 改变中 0 - - 1，2，3，4 死带 1 死带Val (MSB) 死带Val (LSB) 2，3，4 校验值＝＝ 2 比较Val (MSB) 比较Val (LSB) 2，3，4 界限<＝|＝> 3 比较Val (MSB) 比较Val (LSB) 2，3，4 25msec增量 4 - 时间＝val＊25ms 1，2，3，4 秒 5 - 时间＝val＊(sec) 1，2，3，4 分 6 - 时间＝val＊(min) 1，2，3，4 保留 7 - - - BIND 8 API Id:DAQ＝2 事件Id 此时不可用
下面的表格给出可在创建基于字节的事件(API ID 2，Op码2和 13)时使用的事件操作符：
名称 操作符Id(字 节8) Arg 1(字节 9) Arg 2(字节 A) DAQ API类型 可用性 改变中 0 偏移(1-大小) 1，2，3，4 死带 1 偏移(1-大小) 死带Val 2，3，4 校验值＝＝ 2 偏移(1-大小) 比较Val 2，3，4 界限<＝|＝> 3 偏移(1-大小) 比较Val 2，3，4 25msec增量 4 - 时间＝val＊25ms 1，2，3，4 秒 5 - 时间＝val＊(sec) 1，2，3，4 分 6 - 时间＝val＊(min) 1，2，3，4 位掩码 7 偏移 掩码 1，2，3，4 BIND 8 API Id:DAQ＝2 事件Id 此时不可用
BIND操作符允许客户机16由一个事件触发产生多个存储事件。换 句话说，一旦分配了事件ID，就可以创建将在最初的主事件被触发时 自动发送出去的后续事件。
在用改变中操作符建立起基于字节的事件(op码＝3)之后，字节 9中的值255将指示软件体系10对通过地址和大小变量指定的范围内的 所有字节都进行更改检测。
位掩码操作符实现了监视字节内的位转换的功能。掩码值应当设置 为使得位＝1表示“关心”，位＝0表示“不关心”。如果设置为“不关心”， 则在该比特位上的值变换不会导致事件的产生。
Aa110没有提供针对时间同步的明确的解决方案，但是提供了启动 机制。远程客户机16、22创建被周期性广播的事件的能力使得远程客 户机16、22可以保持与电器同步的日时钟时间。由于软件体系10可能 不会向API明确地暴露日时钟时间，因此客户机16、22可以存储存有 日时间的地址。
Aa110核心具有一些设计考虑，这些考虑可以用来产生在此所述的 本发明的替换实施例。
下面的项目可在确定软件体系10的核心实施的替换实施例时考 虑：
●消息体系
●有效载荷结构或消息大小
●多个有效载荷消息完整性检查
●状态察觉消息收发
●API版本确定-发现
●连接完整性
●流量控制和确认消息
○返回无效
○返回有效
○发出
○通电条件
●状态完整性
●键按下vs.逻辑API
●多节点网络
○多个节点
○多个客户机
○同一网络上的多个API实施
○同一网络节点上的多个API实施
○使用相同Op码的API-命名空间
○SAP分配
○SAP发现
消息体系
消息体系是主要的设计元素，其解决方案具有很多非独立的设计结 果。内部通信网络14协议28与以前的网络相反为由事件驱动的消息提 供了新的可能性。要考虑的要素是如果节点注册了通知消息它们是否要 彼此轮询。
轮询是节点定期地向请求更新值的数据持有人发送消息的一种实践 (例如，连续地每100ms请求一次数据)。轮询通常实施得更为简单而 且使用更为普遍，并且可以保持通过每个请求验证的连接完整性。但 是，在轮询时客户机必须连续不断地请求信息。网络带宽被不变的数据 占满(带宽是在给定时间段内可以通过通信信道的数据量，存在一些影 响带宽的因素，例如：网络上的节点数量，发送频率(波特率)，协议 开销(CRC，确认，源/目的ID等)，传输协议硬件，而且电缆连接控 制带宽的限度，但是应用协议负责使可用的带宽得到最大效率的使 用)。轮询体系不会伸缩：当节点增多时消息的数量指数增长。假定在 每个节点上存在其他每个节点都需要的信息：消息数量＝n^2-n。数据通 常不与控制的存储器同步，消息延迟可能达到轮询率的两倍。
产生事件是在特定条件下用新的数据值通知注册为数据持有人的节 点的一种实践。数据持有人接着负责在数据满足最初在注册期间规定的 判断标准时向观测节点发送消息。(例如仅在数据改变时发送数据)。在 产生事件的模型中，由于数据仅在其改变时才被发送，因此带宽使用得 到了优化。该模型良好地随着消息流量而伸缩，并且将延迟降至最低。 数据与控制同步。但是需要连接确认(heartbeat)。否则客户机可能不 知道事件源何时离线。替换的，产生事件模型中的连接确认可以利用作 为从时间观测者返回事件源的附加消息的确认来完成。当事件源发送事 件消息时，在接收到确认消息之前事件源不会认为该事务已完成。在超 时时间过去之后，事件源可能重新发送该事件。该过程可以重复确认事 件发送重试的可配置次数。
在产生事件体系中，可能需要图9中由28的MMP管理的消息结 合。这是一种用于将根据微控制器的同一次“扫描”产生的事件分组的机 制。
在这种情况下，优选实施例是产生事件模型，因为产生事件具有上 述优点而且针对产生事件的缺点的补救措施比较简单。连接确认利用 heartbeat和/或确认事件来解决。在使用heartbeat时，事件源定期发送 事件，从而该节点的所有事件监听者可以知道该事件源是健康的。类似 的，将heartbeat实施为其频率是可编程的还可用于通报所有事件定购 者该事件源是健康的。Heartbeat周期可从网络配置。在此详细描述的 确认事件是一种替换方法，可以附加于heartbeat或可编程heartbeat使 用以保证连接的完整性。消息结合由每个消息分组28的有效载荷中的 消息分界位来解决。这使得软件体系10驱动器可以收集对应于同一次 微控制器扫描的消息，并将这些消息一起提交给应用层。
采用本发明的作为DAQ30了解的子部件，软件体系允许客户机16 通过内部通信网络14动态地注册到电器控制部件16(由软件体系10启 动并包括软件体系DAQ30的可选子部件)，以便接收在指定存储器位置 处的值何时相对于指定条件变化的通知。这将电器控制16从具有硬编 码的反馈变量中解放出来，并允许实时反馈来根据电器而改变，从而不 需要客户机的轮询(基于事件的更新按照需要准确广播)。
采用图33的动态存储器堆，即保留给运行时可配置反馈消息的存 储器，其中该存储器堆的大小可在编译时配置。已经发现每个反馈事件 变量需要大约10字节的RAM。在该存储器堆中记录的事件(图33的 NVOEvent)可以通过由客户机发布给由软件体系启动的部件的内部通 信网络14命令来添加或复位，该软件体系也安装了可选的子部件 DAQ30。
有效载荷结构28A
有效载荷结构的一个示例是由成组的多个变量一起构成(在设计 时)的静态复合有效载荷，从而对于一个事务来说客户机可以向电器12 内的部件发送完整的命令，或接收该部件的完整状态。在命令的情况 下，客户机可能不想要改变有效载荷中的每个变量，因此需要必要的状 态更新来对命令有效载荷填充不打算改变的变量的当前状态。此外，改 变的变量可能无法字节映射为一个有效载荷定义，从而导致包含散布 的、已更改和未更改的数据的多个消息。
在简单的有效载荷结构中，只有一个变量可以存在于有效载荷中。 该有效载荷具有更为简单和容易的实施，而且可以近似于动态复合有效 载荷(下面将描述)。但是，由于消息开销与数据的比例更大带宽没有 得到优化，而且作为变量需要的消息结合是单独发送的。
在动态复合有效载荷结构中，有效载荷不是在设计时静态定义的， 而是由发送节点动态建立的。在这种情况下，有效载荷的长度由发送者 希望发送的数据确定，此外，在有效载荷中必须包含标识符和可能的分 隔符，这使得接收方的分析器可以分解有效载荷的组成部分。重申一 次，接收节点必须具有复杂到足以将多个变量有效载荷分成其组成部分 的分析器。该有效载荷结构优化了带宽，但是由于分析器所需要的复杂 性可能增大ROM需要。对应用协议也增加了一些开销，因为动态复合 有效载荷必须嵌入op码长度作为消息的一部分，需要由接收部件进行 额外的分析，而且可能难以理解和实施。
本发明的优选实施例是对应用协议采用简单的有效载荷结构。动态 复合有效载荷的复杂度可能难以对软件体系10中采用的消息进行成本 效益分析。为了最大化软件体系10的使用，优选接口的复杂度应当被 最小化。通过使用复合有效载荷，由于其复杂特性，可能妨碍了软件体 系10的使用，尤其是对于内嵌的客户机。简单的有效载荷是对动态复 合有效载荷的良好近似，尽管可能有额外的消息开销(即，对每个内部 通信网络14的消息存在5个字节的开销)。还有另外两个字节的开销用 于支持软件体系10应用协议28。这为每个内部通信网络14消息协议 24留下13个字节用于在某些特定于应用条件下的数据。使用静态的复 合有效载荷可能不灵活和比较浪费。
图9的消息结合是用在每个消息分组的有效载荷中使用MMP位来 解决的。这使得软件体系10驱动器可以收集对应于同一次微处理器扫 描的消息，并将这些消息一起提交给应用层。
状态察觉命令
相对于电器12的用户接口，电器12就像个状态机。当按下键时， 该状态机从一个状态转换到另一个状态。对于每个状态都知道对下一次 推动哪些键是有效的候选键。类似的，还知道对下一次推动哪些键是无 效的。
总的来说，当按下无效的键时，电器12产生声音警报以告诉用户 该电器处于不适于该键的状态。相同的概念也适用于希望发送有效命令 的外部客户机，虽然该客户机可能不发送键按下。
一般来说，对于电器控制开发出两种类型的状态机：键按下状态机 (如上所述)和过程状态机。典型的过程状态机的例子在图7示出。
图7是示出家用电器12的各种状态的示意图，该家用电器在图7 中例如是洗衣机，而且从软件体系10的交互到各种状态32以及默认故 障模式34。示例性洗衣机的各种状态32在图7示为空闲、洗衣、漂 洗、旋转和暂停。该示例电器12的其他状态以及不同电器12的状态是 可以想到的，图7所示的例子只是举例而已。
过程状态机的状态可以报告给外部客户机16.但是在检查时，可以 看见图7的过程状态机不针对来自所有可能的用户输入的事件(即时钟 设置、旋转速度选择、负荷大小选项等)。一般来说，电器控制中的逻 辑具有最终其它条款以处理没有预定的所有其他情况。
假定希望客户机16理解管理控制的状态变化的规则，从而可以避 免客户机16发送无效命令。考虑到客户机16不会发送键按下这个事 实，设计者必须理解无法得到允许客户机一方确认的文档或数据结构 (即在发送请求之前确认)。最后，这可能导致可能发送命令的客户机 应用，接收部件由于其基于图7的示例性状态的确认逻辑而不运行。
该解决方案不仅对带宽使用有影响，而且对应用的总体稳健性以及 终端用户的满意度也有影响。从带宽的角度来说，可以说消息不会导致 期望的行动，而是错误代码或重试是带宽的浪费(假定可以防止)。用 用户满意度的角度，防止用户出错的应用通常被认为比允许用户出错然 后用对话框解释发生了什么事的应用更为“友好”。
根据本发明设想了状态合适命令的各种实施例。
采用客户机编码的规则部分，状态信息的子集用于为了防止无效请 求而开发情况逻辑或控制状态的仿真。该模型通常不更改控制体系，但 是可以让客户机和控制很容易不同步。该规则和逻辑开发可以基于反复 试验(例如编码、测试、重新编码)。客户机设计可能快速展开，从而 产生设计不好的程序代码。
采用设计时基于状态的API数据模型，开发出数据模型，从而客户 机可以解释该数据模型而且防止无效请求。实际上，状态和有效op码 之间存在相关(op码是消息标识符)。其优点是Op码或API的开发者 也负责向客户机的开发者发布信息(在设计时)，从而允许设计者在客 户机上仿真状态机。该仿真的状态机使得客户机应用不会发送无效请 求。控制需要暴露在API数据模型中定义的每个状态。设计时的数据模 型要求控制开发者负责交流管理Op码实用的状态规则。客户机和控制 可能很容易失去同步，因为数据在运行时无法使用。必须创建反映写入 代码的文档。该文档必须维护和公布。该文档必须分析或转换到客户机 端的逻辑，并且不会在所有时候工作。电器状态可以在命令刚被发送时 改变，从而导致无效命令。
采用运行时基于状态的API数据模型，该解决方案与前一解决方案 相同，只是该数据模型不是在设计时在开发者之间共享，而是在运行时 在客户机和控制之间共享。对于要从控制告知的数据需要一些额外的消 息收发。在该运行时数据模型中，控制的开发者必须负责通报管理Op 码使用的状态规则。客户机可以在运行时发现Op码/状态相关的定义。 客户机和控制总是同步，而且客户机和开发者的活动是优化的-无需手 动翻译为文档/从文档手动翻译过来。需要额外的代码(ROM)(一次性 写入)用于排列和分解Op码/状态相关的定义。需要将一些网络带宽用 于传输数据，而且由于传输数据产生一定的启动延迟。这不会在所有时 候都产生。状态可以在命令正被发送时改变，从而导致无效命令。
采用后命令确认列举模型，上面的三个选择具有防止客户机发布该 命令以控制在无效状态的目的。该解决方案没有尝试这种预清空。而是 允许客户机应用随时发送任何命令。如果该命令无效，则产生确认，从 而客户机可以采取合适的行动。该确认可以包括或不包括列举的原因代 码。在后命令原因代码模型中，不改变控制体系，而是客户机更可能发 送将会遭到拒绝的命令。客户机开发者必须设计一种策略来应付拒绝确 认，由于被拒绝命令消息的频率而导致终端用户经验可能不是很令人愉 快。
采用组合了设计和运行时数据模型的设计时命令传统和源代码分析 模型，对内嵌代码的结构具有最小的影响，并且传达了期望的运行时功 能。这通过产生客户机一端的分析器来完成，该分析器可以分析内嵌的 源代码，并确定要为每个外部Op码监控的变量。对该解决方案的要求 是：(1)每个非诊断外部命令(Op码)具有关联的单个布尔变量，该 变量代表执行所需要的允许状态；(2)采用命名传统，使得分析器可以 将每个允许变量与对应的外部Op码关联。在源代码分析模型中，控制 的开发者负责通报管理Op码使用的状态规则。客户机16可以在运行时 发现等待确定恰当版本的Op码/状态相关定义，并且客户机和控制总是 与恰当的版本同步。不需要额外的参考文档，但是对于编码实践、每次 扫描要执行的附加逻辑、所需要的很小的额外RAM和ROM存在并非 不重要的改变，而且只有高级的客户机才能够分析源代码。
采用学习客户机模型，该解决方案不需要更改内嵌式系统。在这种 情况下，客户机会在每个遭到拒绝的命令之后“学习”，并且建立会随着 时间完成期望的运行时行为的客户机一端的允许映射。在学习客户机模 型中，不改变控制体系，但是其假定是在拒绝时估计正确的状态变量。 如果没有观测到状态变量，这客户机不能了解是什么导致了该拒绝。
已经发现这些选项的一些是优选的实施例。现在，主要的优选实施 例是运行时API数据模型。该设计的示例性优点是家庭控制应用。但是 该模型需要额外的内嵌设计。由于当前的商业环境没有产生对该实施例 的需要，因此一直采用后命令确认，直到采用运行时API数据模型(也 称为分类引擎)的成本效益变得更有利时为止。
Aa110的挑战之一是要提供功能而不影响电器12的生产计划。 Aa110可以实施确认的请求模型。NVORecipeStatus(APIID＝1，Op 码＝1)是优选的、由软件体系10在接收到每个消息之后发送的确认消 息。
API版本确定-图6的发现
尽管软件体系10的核心与任何API无关，但是软件体系10的目的 是要暴露多个API。期望API将随着时间不断添加到软件体系10中更 为实际。想到这一点，就需要考虑API发现和版本确定。
还可以想到随着软件体系10应用增长，微处理器资源将不足以同 时支持所有的软件体系10API和功能。通过采用编译器的指示，软件体 系10可以配置为使得在机器的开发寿命期间API将会为同一个模型出 现和再出现。
发现是软件体系10的长期成功的关键。Aa110的基本目的是在客 户机16和控制部件16之间扮演中间件的角色。假定下面描述的情形， 客户机16就需要查询控制以发现当前的功能是什么。如果不存在某些 功能(即编译时判断)，则期望应用能够体面地停止运行并通知用户该 应用的支持目前没有编译到电器控制软件中。
存在很多客户机实施以及很多交叉平台和特定于平台的API。编译 器指示可以被开发为包括或不包括软件体系10的某些功能。在控制上 可能不会允许软件体系10的所有可能的功能同时存在于微处理器上。
在此涉及API的版本确定和发现方法的本发明的各种实施例都没有 脱离本法明的范围。
采用基于模型号的发现模型，客户机负责理解控制的功能。这可以 采用基于客户机的数据结构、远程数据库、或者类似OSGi的运行时代 码运送工具来完成，这种运行时代码运送工具包括所有关于电器12的 特定模型号的相关信息。在基于模型号的发现模型中，对电器控制没有 额外的要求。但是，模型号通常不是在产品开发周期开始时分配的，因 此在早期软件开发中不能获得该模型号。模型号由于颜色机制、商标和 其它枝节因素可能变化。不同的API由于编译器指示可以驻留在同一模 型上。可能需要客户机负责在发现后获得功能定义或等价代码。
采用基于API ID的发现模型，基于API的发现一点也不取决于模 型号，而是将任何产品都定义为精心定义的接口的集合。该技术允许相 同的API驻留在多个产品上，从而导致某种再利用。在基于API ID的 发现模型中，对API ID的参考补偿了基于模型号方法的缺点。该模型 允许多个产品共享相同的编译器指示和相同的API定义，并且能够促进 软件体系10的子功能再利用。但是，客户机可以负责在发现后获取功 能定义或等价代码，可能需要额外的管理开销以维持和分配唯一的 API，而且可能需要来自控制微处理器的额外资源来支持发现Op码 (即额外的消息收发)。
采用功能发现模型(也称为分类引擎)，该模型将API发现作为附 加的步骤。除了API的ID之外，客户机还请求和获得对应于该API的 数据定义。换句话说，客户机发现每个功能调用，每个功能调用变量， 以及每个变量的有效值。在功能发现模型中，不需要第二查找来获取功 能定义。该模型接近UPnP或Web服务类型概念，并为转换到可由数 据驱动的LCD屏幕用户接口设置了基础。但是，这一概念在用于低富 裕机械键区和执行器时可能有成本缺陷。而且为了利用该技术的优点， 客户机16必须开发该功能定义的解释器，该解释器可能需要软件体系 10子功能开发者更多的建模努力以及来自控制微处理器的明显更多的资 源。
已经发现，在准备该应用时，基于API ID的发现模型是优选的实 施例。除了API ID之外，每个API可以具有类型和版本，从而API的 很多不同置换可以长时间存在。这使得协议更为灵活(例如对特定电器 12如甩干机可以有很多类型的API，以及每种类型存在不同的版本：甩 干机API，水平甩干机类型，版本1)。
根据本发明，发现可以通过很多方式启动。在通电时，用软件体系 10启动的每个节点在内部通信网络14上广播称为公布节点的消息。
其次，节点随时可以在内部通信网络14上广播称为找到节点的消 息。该消息将导致所有节点用公布节点的消息响应。该API已参照图5 和发现API详细讨论。
由于发现是软件体系10的关键，因此版本确定是成功发现的关 键。用于调整API发现的相同道理可用于API版本确定。版本确定允 许客户机找出更多关于已经发现的API的信息。
在API发现期间，API版本和类型要在与API ID相同的数据结构 内报告。例如，可以采用简单的号码冲撞方法。此外，可以想到APIID 和版本号具有一或两个字节或n个字节的数据结构。
连接完整性
在产生事件体系中，连接完整性是个问题；而在轮询体系中，连接 完整性是固有的。在产生事件体系中，客户机16可以成功注册以收听 反馈(例如针对温度读取)。一旦注册完成，客户机就依赖控制来通报 温度的变化。这样，客户机将网络问题解释为恒定的温度。相比较而 言，在轮询体系中，客户机不断向控制查询温度反馈，其响应或缺乏将 立即表明连接的完整性。
采用可选的heartbeat模型来执行连接完整性，客户机必须注册用 于基于网络的heartbeat。采用自动的heartbeat模型，软件体系10在 通知寄存缓冲器不满时自动产生heartbeat。Heartbeat可以是广播消息 或指向特定节点的消息。
在可选的heartbeat模型中，如果存在不需要该模型的实例，则可 以取消heartbeat。在需要该模型的实例中，客户机必须配置软件体系 10以产生heartbeat。在自动的heartbeat模型中，不需要期望的功能- 软件体系10本身就很稳健。在广播heartbeat中，只需发送更少的消 息，定制的heartbeat可以通过基于时间的事件更新来完成，而且定制 heartbeat具有更简单的实施。但是，这可以导致从不参与软件体系10 协作的其它网络节点来处理消息。而且，没有正确处理广播消息的节点 可能误解释了到来的消息。在定向的heartbeat模型中，只有启动的节 点需要处理软件体系10应用协议。但是可以采用定向的heartbeat模型 发送更多的消息。
对于本发明，已经发现优选的实施例是用于连接完整性的 heartbeat，具体地说，广播消息可以用于heartbeat。不喜欢该广播 heartbeat速率的客户机可以替换地使用基于周期时间的NVO事件更 新。使heartbeat自动化可以减轻客户机的负担。相对于包含在软件体 系10中的API来说，下面的功能作为核心API(Id＝1)的一部分受到 支持：heartbeat消息，设置heartbeat周期。Heartbeat优选在从客户 机16接收到第一消息时以默认周期自动启动。
用于连接完整性的另外可选的优选方法可以引入到软件体系10 中。已经发现随着软件体系的应用增长，确定需要额外的连接完整性的 方法。采用用于连接完整性的heartbeat方法对很多应用情形都是适用 的。选择该方法是因为它代表了带宽利用和事件源的置信水平之间良好 的平衡。但是，由软件体系10发送的事件消息可能无法由计划的事件 定购者处理，即使该事件定购者没有检测到遗漏的heartbeat。在这种 情况下，时间定购者不能检测故障，因此不能采取校正措施。在检测到 遗漏的heartbeat的情况下，该校正措施是事件定购者可能请求事件源 重新发送(所有)事件的(全部或子集)，从而该事件定购者具有最新 的数据。为了解决可能的未检测到的故障模式，通过软件体系10提供 了连接完整性的第二种方法。该方法作为经过确认的事件公知，其允许 每个事件消息的完整性得到单独的管理。图29示出经过确认的事件的 功能。在图29的说明中描述了涉及经过确认的事件的更多细节。
流量(流)控制
可配置的异步过程是强大的，但是在配置超过其物理处理和带宽限 制时就可能出现故障。引入了用于在4种公知故障情形中防止饱和的机 构：返回无效请求，返回有效请求，发出消息事件，以及通电条件。
返回无效请求-它像是客户机格式化和发送无法被控制正确分析和 理解或者可能通过控制的状态而无效的请求。
返回有效请求-无需考虑，客户机可以请求控制在该控制能够处理 第一任务之前完成第二任务。
在缓冲模型中，可以使用接收缓冲器，从而允许客户机发送很多请 求而不考虑控制服务这些请求的能力。在该模型中，客户机没有责任， 即使该模型的实施更为简单。但是缓冲没有解决流控制的问题；它只是 延迟了这个问题，或使得这个问题更不容易或更少发生，而且缓冲需要 更多的RAM。
在流控制模型中，可以使用消息收发，从而客户机在发送第二请求 之前需要等到控制准备好为止。在流控制模型中，流控制问题得到了非 常稳健的解决，故障模式被消除。但是客户机必须实施流控制协议。
在经过确认的请求模型中，控制向每个客户机请求提供积极或否定 的响应。在经过确认的请求模型中，该模型允许客户机16开发简单的 重试或发现情形。但是，该模型需要更多的带宽用于确认，而且需要额 外的ROM和设计。
在未确认请求模型中，客户机请求是未经确认的-客户机必须使用 状态信息来确定该命令是否成功。在未确认请求模型中，利用了更少的 带宽和ROM。但是，应用用户经历可能不好，客户机应用不指明所发 布的命令是否成功，因此不能自动启动重试，用户注意到未成功的命令 并需要手动重复该命令行为。
已经确定本发明的优选实施例是具有经过确认的命令模型的流控制 协议。此外，确认可以列举，从而客户机过程可以开发尽可能稳健的恢 复情形。由于本发明中前面提到的确认消息为经过确认的命令提供了 API和Op码，因此客户机可以识别得到响应的命令。这防止在多个控 制板网络中的冲突，其中位于电器内的多个控制板全都使用软件体系 10。流控制和命令确认是允许客户机尽可能快速地发送数据而不会使控 制饱和的技术。优点是非常灵敏的应用而不会引入不需要的延迟或不期 望的应用错误。
流控制的优点是利用公布确认，API点＝1，Op码1来达到的。每 个命令都用公布确认响应来确认。新的命令仅在接收了READY(就 绪)或UNSUPPORTED(不支持)的公布确认值之后才允许。公布确 认使状态机用于如图8所示的命令流控制。
图8是示出图1的软件体系10如何根据本发明与到来的命令交户 并基于家用电器的状态确认或拒绝该命令的示意图。在图8中用附图标 记36示出各种流控制状态指示符，如基于各种命令38和发布的响应40 的POWER_UP，READY，BUSY，REJECTED，UN_SUPPORTED。
发出消息事件(反馈)。在微控制器的每次扫描期间，软件体系10 的DAQ30收集代表必须在总线上发送出去的事件的字节阵列(参见图 36的处理DAQ事件状态)。Aa110的DAQ30可以如图5所示配置，因 此客户机可以配置软件体系10以传送比通信总线的带宽所允许的更多 的数据(即过配置)。
为了防止这一点，可以采用配置限制模型来限制客户机16配置软 件体系10的能力以避免该问题。在缓冲模型中，软件体系10可以配备 发送缓冲器。在饱和消息模型中，软件体系10检测何时向传输层提交 了太多的数据从而该数据可能无法发送给客户机。在要求重新启动模型 中，事件发布暂停，事件饱和消息发送出去和/或广播。一旦接收到 SendEvents(例如255＝全部)消息就重新开始产生事件。在不重新启 动模型中，发送和/或广播饱和消息，然后软件体系10继续产生事件。
在发送缓冲器模型中，客户机没有责任，客户机实施更为简单。但 是，缓冲没有解决问题；它只是延缓或使得该问题更不可能或更少频率 地发生，并需要更多的RAM。
在配置限制模型中，该模型会防止问题，从而不需要恢复过程，不 可能推导出配置限制，该限制基于相对于软件体系10处于随机特性的 机器状态变换。
在饱和消息模型中，客户机可以检测软件体系10在至少一次扫描 中无法向内部通信网络14提交新的数据。客户机无法确定该数据是否 丢失，饱和消息也不一定意味着存在故障，只是可能丢失了数据。
在不重新启动模型中，客户机没有责任，但是不强迫客户机的开发 者实施饱和恢复过程，客户机的开发者无法觉察到事件可能由于软件体 系10的过配置而丢失。这种类型的故障不是灾难性的，因此客户机应 用可能忘记数据的丢失。
在要求重新启动模型中，客户机的开发者必须考虑饱和故障及其对 应用的暗示，这防止找到漏洞的临时努力，而且故障模式是灾难性的和/ 或明显的。但是，客户机必须实施饱和恢复过程，而且在要求重新启动 过程期间可能存在暂时的延迟。
在什么也不做模型中，避免了不需要的工作，但是可能出现无法预 见的状况，从而导致客户机的开发者花时间去解决可能按程序诊断的问 题。
确定不要求通过编译器指示提供重新启动的饱和消息是本发明的优 选实施例。饱和消息必须在其它事件进入传输层发送缓冲器之前成功发 送出去。下面的消息收发功能作为软件体系10调试API(APIId＝4) 的一部分受到支持：获得饱和和注册饱和消息。
作为如图4所示的分组结构28，软件体系10的所有分组采用可能 导致命令空间冲突的Cmb/Fb标志。因此可以使用用于区别的Cmb/Fb 标志在相同的API下重叠Op码。
通电条件。如果软件体系10节点经历电力的短暂缺失或者微复 位，客户机可能具有针对软件体系10模块变量的不正确快照。为了实 现稳健的运行，软件体系10可以通知其客户机前面输出的变量不再被 认为是有效的。在考虑短暂的条件时，软件体系10的配置可能存储在 非易失存储器中，这使得可以进行通信的自动恢复。
在广播消息模型中，软件体系10发送特殊的广播消息，以通知所 有客户机在通电时“清空其缓存”。可以理解客户机16的一些应用可能 不需要考虑该故障模式，因此不会使用该特殊消息。还已知软件体系的 软件运行环境会在heartbeat周期内经历故障(导致其内部存储器的复 位)和恢复。由于只有heartbeat作为检测装置，该快速恢复会产生这 样的可能性：客户机16存储器所保存的来自软件体系的软件运行环境 的存储器的特定值的副本不再对应于该软件运行环境的存储器内的当前 值。为了解决该故障情况，通电消息可以包含在软件体系10中。该消 息与heartbeat无关，并且向任何客户机16表明软件体系10的软件运 行环境的存储器的任何以前保存的值很可能无效，而且客户机应当通过 使用API 1 Op码7的sendEvent消息来重新获取当前值。还要理解， 客户机应当以合适的方式暂停或修改对这些存储值进行运算的任何逻辑 或计算，直到重新获得当前值为止。
在丢失heartbeat模型中，软件体系10可以停止其heartbeat，使 得客户机可以确定恰当的故障模式行为。但是如上所述，heartbeat模 型的丢失不会覆盖所有的故障情况。这在使用自动恢复模型时尤其如 此。
在自动恢复模型中，软件体系10可以在通电或复位之后从最后的 已知状态中自动恢复正常运行。在自动恢复模型中，客户机可能将接收 的信息误解释为不会发生的状态变化。换句话说，对于在复位或通电之 前存在的状态A以及初始通电状态-状态B；不需要另外指明代表通电 或复位的状态I，客户机可以将状态A到状态B的变化解释为不通过状 态I。
在要求重新启动模型中，客户机的开发者必须考虑上面的段落及其 对应用的实施。则可以防止暂时的难以找到漏洞，因为故障是灾难性的 而且容易识别和定位。但是，客户机必须实施暂时的恢复过程，而且在 重新定购/数据重新获取过程期间可能存在瞬时延迟。
已确定在通电/复位之后需要重新定购的heartbeat模型是本发明的 优选实施方式。指明初始条件的状态的特殊广播消息的优点也被理解为 在软件运行环境中的资源允许这种附加特征时是有用的指示。即使通过 使heartbeat的暂停时间很小而使得heartbeat机制近似于通电消息机制 的使用，当软件运行系统的资源约束不是禁止性的时，优选解决方案还 是包括通电消息。为此，作为可选特征，软件体系10支持API Id＝3， Op码＝2的通电消息，即publishSANode。可能需要重新定购，因为动 态事件触发器存储在RAM中而且会在通电时丢失。
优选地，软件体系10模块除了可选的通电消息publishSANode之 外不发送任何消息，直到该模块检测到客户机为止。通过接收到有效命 令来检测到客户机。一旦检测到客户机，可配置的heartbeat消息开始 广播，然后软件体系10准备好正常运行。因此，如果用于软件体系10 的主微处理器经历了通电/复位，则客户机通过检测到heartbeat消息 (参见APIId＝1 Op码＝2)的缺乏和可选地通过检测到消息 publishSANode(参见APIId＝3 Op码＝2)来得到通报。
状态完整性
Aa110的图5的DAQ30提供了优于市面上买到的DAQ系统的一 些区别优点。Aa110可以暴露微处理器存储器中的任何变量。一般来说 也包括感兴趣的I/O信号。现有技术的DAQ不能做到这一点。Aa110 还可以通过一个3线插座提供给生产机器，而现有技术的DAQ仿真器 需要更多的布线或硬件。现有技术的DAQ在消费者领域测试的范围内 是不实际的。Aa110可以部署在生产系统上。与调制解调器耦合的 Aa110可以提供远程监控。
使得软件体系10不同于现有技术装置的最为基本的方面是，软件 体系10作为模块化子例程(图36和图11的 SA_ProcessOutgoingEvents)由微处理器的main()函数同时调用。这保 证在微处理器的执行引擎扫描微处理器存储器时，客户机可以具有微处 理器存储器的完整的逐次扫描的快照(在网络带宽的限制内)。这开启 了从低成本仿真到使用软件体系10的混合算法开发的很多感兴趣的可 能性，从而实现PC辅助的与生产电子装置的协处理。
现在描述异步数据收集和同步数据收集方法的比较。在异步收集 中：
1.假定A和B是电器控制存储器内的变量。
2.假定C在客户机中计算为A和B的乘积的变量。
3.假定A＝23，B＝67。
4.客户机轮询A：A＝23。
5.A和B改变。A＝56，B＝77。
6.客户机轮询B：B＝77。
7.客户机计算C：C＝A＊B＝23＊77(A和B的这种组合绝不会在微 处理器上发生)。
8.客户机将C的无效值提交给顾客或应用的终端用户。
大多数应用用异步数据收集工作。它简单和一目了然。但是，与异 步收集关联的问题对于调试和识别来说特别花时间。
在同步收集中，客户机用软件体系10定义或注册A和B。这使得 软件体系10可以在每次扫描时维持A和B的坐标值。
1.客户机注册A和B。
2.客户机请求发送全部。
3.A和B的当前值由控制发送给客户机。
4.A和B改变。A＝56，B＝77。
5.控制发送包含A＝56和B＝77的有界事件。
6.客户机不计算C直到达到该界限或结束分隔符位为止。
7.客户机计算C：C＝23＊77。
8.客户机提交正确的C值。
对于同步数据收集，数据收集是稳健而且虚拟地防弹的。它实现了 还没有概念化的应用，而且允许生产软件的“实时”调试w/o对生产电子 装置的特殊编码。但是，在控制上需要额外的RAM以维持“关心”变量 或属性列表的客户机的快照。
已经确定软件体系10优选可以支持和促进同步数据收集技术。但 是，异步存储器轮询可在核心API(API ID＝1)中提供。
对于采用的同步数据收集技术，应当讨论有界更新的概念。有界更 新是作为在主微处理器的Main()循环执行的同一扫描期间获得的电器状 态的快照而分组在一起的事件。电器控制主循环允许用DAQ API注册 的反馈变量的迭代更新(例如每25ms)。监视每个注册的变量，而且只 有根据它们的存储器监视器更改操作符改变值的变量才作为更新广播给 客户机。当更新正在被广播时，不允许新的更新，以及时保存快照。采 用如图4的应用协议28中所示的软件体系10标题的字节2中的MMP 标志向客户机通报快照。
当图4的28的MMP为真时，更多的消息等待该快照。当MMP 为假时，当前消息是快照中最后的消息。因此如果快照的第一消息是该 快照中的唯一消息，则MMP是错误的。
图9的示例示出具有确认的有界命令(循环+温度+MMP)，后面 是两个连续的有界更新。有界是指协议的元素向接收者表明更多的消息 正来自源而且通过接收部件的应用逻辑进行的数据处理应当延迟到分组 结构28内的协议的有界指示符(MMP位7)表明事务完成为止，在该 事务时由应用逻辑进行的数据处理得到允许。有界命令通过附图标记42 示出，两个连续的有界更新分别通过附图标记44、46示出。注意在有 界命令执行完成之前更新没有开始，这为客户机提供了滤除暂时的反馈 数据的能力。有界命令由相同的机制，即28中找到的MMP作为有界 更新提供，以便向应用提供更大水平的控制。
图9的示例是概念性的。实际的机制是在28中找到的MMP。但是 为了图解的目的，有界命令以初始的“开始”命令引发符(MMP置位) 开始，并包括用于将洗衣机循环设置为洗衣，配方状态为就绪，水温为 适中，配方状态再次为就绪的命令，最后是循环开始指示符，接着是命 令结束符(MMP未置位)。可以注意到，在图9中更新(例如通过产生 事件)被禁止，以防止更新在有界命令结束之前发生。此外，“处理命 令”指示符在电器12的整个有界命令处理期间周期性地出现，以说明从 客户机16通过内部通信网络14发布的命令的某些部分正在接受处理。
在有界更新44中，该更新又一次启动(因为该更新在有界命令42 开始时遭到禁止)，以允许电器12向客户机16报告其具的状态。在有 界更新44所示的例子中，示出确认状态为就绪，循环报告为洗衣，该 状态报告为正在运行，洗衣桶报告为满的，水泵报告是开着的，温度报 告是适中的。开始和结束指示符又围住有界更新44。这些开始和结束指 示符可以利用如在图4中讨论的应用分组结构28中的标志MMP报 告，或者利用网络协议领域的技术人员公知的其它方法报告。
在有界更新46中，洗衣桶报告为摇晃，水泵报告是关着的，电动 机报告是开着的。开始和结束指示符(MMP)又围住有界更新44。
API策略(键按下vs.逻辑API)
在几乎所有情况中，电器12由集成的键区控制。内嵌的软件处理 由键区所产生的键按下或用户事件，并采取动作。实际上，键按下处理 功能是用于电器的API。在这一节要考虑的问题是该API是否是最佳方 法，或者是否应当为外部客户机16、22开发第二API。
在键按下模型中，为了使用键按下API，外部客户机22必须创建 虚拟键按下并将其通过网络发送。必须在了解集成键区的情况下设计外 部客户机22，从而可以正确产生这些键按下，而且为了产生键按下，需 要外部网络接口卡。在该模型中，不需要修改底层键区编程。但是，客 户机22必须监视当前键区状态，以确定达到所期望的状态所需要的键 按下。如果键区的设计改变，而不是机器能力改变，则客户机API必须 改变。该体系通过在中间层(middle tier)和持久层(persistence tier) 之间设置表现层(presentation tier)，从而打破了软件开发的最佳实 践。对于在基本键区接口中不存在的能量管理、维护和诊断、测试等等 将需要扩展的命令。必须有一种方法将逻辑API以及杠杆作用 (leverage)和尽可能多的确认码与键按下处理例程关联，而不需要复 制代码。
相比之下，在逻辑API模型中，逻辑API是从机器功能的抽象而 不是键区的设计中开发而来。例如，使用键按下在欧洲炉子上的烘烤可 能需要客户机读取循环刻度盘的编码器位置，并通过编程改变编码器以 对应于烘烤设置。如果使用逻辑API，客户机只需要发送用于设置循环 的Op码以及针对烘烤的列举值：{0x01，0x01}(setCycle(Bake))。在逻辑 API模型中，客户机16不需要关心键区状态、键区设计或键按下处理 例程。API与键区设计的更改无关，允许扩展的命令，并且是工业上的 最佳实践。
已经确定软件体系10使用集成了键按下处理例程的逻辑API。逻 辑API暴露了很多扩展命令，这些扩展命令启动了各种增值应用。在电 器控制中，如果在用户接口上按下一个键或者发布外部命令，它作为普 通的进入点而直接映射为逻辑API函数调用(例如如果按下洗衣键或者 发布外部的洗衣网络命令，则调用安装了软件体系10的洗衣机中的 SetCycle(WASH))。逻辑API函数致力于按照参数化方式描述一组功 能，从而该函数可以再利用。例如，温度的非逻辑专门函数可以是 IncrementTemp()或DecrementTemp()，这些函数无法轻易地用于将温 度设置为任何值。但是逻辑API函数可以是： SetTemperature(newTemp，or temp++，or temp--)。键按下和外部命令都 可以使用后一个函数。
Aa110的命令处理程序可以包括使内嵌软件响应逻辑命令(例如 setCycle(Bake))或键按下(例如在炉子电器12上按下“烘烤”按钮)的 方法。该方法翻译输入的键按下，并导致对逻辑API内的合适函数的调 用。
在该逻辑API函数中存在尽可能多的确认和基于状态的逻辑，从而 外部命令与键按下获得一样的处理并且执行相同的代码。该API可以在 无需对电器控制软件进行大的重新设计的条件下实施。只有顾客接口管 理器软件必须重新组织和分组以作为针对每个键按下命令的进入点来调 用API函数。但是这不是软件体系10的要求。Aa110只用于最小化必 须写入的代码量。如果逻辑API函数的一个集合不能提供给外部命令引 擎，则散布在电器控制中的确认和状态逻辑必须针对每个外部命令重 复，从而导致更大的代码量和增加了错误的概率。
标识：多节点问题
上面关于API版本确定和发现的讨论建立了用于发现驻留在任何安 装了软件体系10的节点上的API的机制的优点。对于下个步骤存在另 外的考虑：
1.多个节点
2.多个客户机
3.实施同一API的多个安装的节点
4.具有多个复制的API的单一节点
5.使用同一Op码的多个API
6.SAP分配
7.客户机发现支持软件体系10协议的节点
多个节点。有可能网络上的多个部件都要实施软件体系10。因此， 应当考虑具有多个实施软件体系10的部件的网络。
在正面模式模型中，正面模式用于产生对一个对象集合的简单访 问。这通过产生设置在客户机和各种目标对象之间的软件层来完成，从 而客户机具有与单一对象连接的简单接口。该单一源由此负责将请求传 递给合适的目标对象。在正面模式模型中，更容易管理该模型，因为 API是集中定义的。在大多数应用中，正面向客户机呈现更为简单的接 口。但是，该模型要求编译时间设计将其它节点的API包含在正面节点 中。正面需要额外的RAM/ROM以处理请求并将请求传递给目标节 点。而且，如果两节点对彼此来说是客户机，则正面模式会创建不需要 的处理，因为正面节点首先只通过自己的正面请求以便将该请求传递给 目标节点。
在分布式服务模型中，该方法使用发现协议作为让客户机找到目标 对象的方法。客户机负责与每个目标对象之间的独立交互。换句话说， 客户机将发现软件体系10节点，然后查询每个节点它们支持什么样的 API。在分布式服务模型中，该模型伸缩自如，从而部件可以在运行时 插在一起。但是，该模型可能需要多个文档来管理网络变量定义 (API)。
已经确定软件体系10使用分布式服务模型来管理在网络14上启动 的多个节点。正面方法可能不太好，因为对目标对象API的更改需要更 改正面(更改，编译，下载，测试)。而在由良好的重新要素分解工具 支持的一次编译时间环境中，正面可能是很好的选择。在分布式环境 中，更为灵活的分布式服务模型将允许更快的开发和灵活的配置。但 是，在一些情况下在系统的每个微处理器上可能没有足够的资源来支持 软件体系10。在另一些情况下，可能存在继承协议，而且不希望对遗传 板进行修改。在这些情况下，正面可能是分布式服务模型的好的替代 品。
多个客户机。如图1所示，网络14上的多个节点或客户机16实施 软件体系10。因此，应当考虑多次发生10的网络。一个主要的考虑是 时间注册和通报。如果多个客户机用软件体系10注册事件，则软件体 系10应当可以管理事件发布。
利用节点ID指导的消息事件产生模型，软件体系10存储每个事件 请求者的节点ID，使得在触发该事件时，会向请求节点发送定向消 息。在该模型中，消息只发送给关心事件的节点。但是，该模型要求对 每个消息有一个字节来存储节点ID，并且需要更多的RAM来为每个请 求节点产生附加的存储器结构。
在具有API ID标识符的节点ID指导的消息事件产生中，利用该方 法，软件体系10存储每个事件请求者的节点ID，使得在触发该事件 时，会向请求节点发送定向消息。此外，主节点的API ID包含在该事 件中。该模型允许客户机传输层更好地在内部路由消息。但是，该模型 还要求对每个消息有一个字节来存储节点ID，并且需要更多的RAM来 为每个请求节点产生附加的存储器结构。
在广播消息事件产生模型中，利用该方法，软件体系10不跟踪事 件请求者的节点ID。在触发该事件时，软件体系10发送广播消息。在 该模型中，软件体系10的实施更为简单和更小，不需要为每个消息花 费一个字节来存储节点ID。但是，广播可能产生由其它节点处理的不 需要的事件。
第四种混合方法，也是优选的方法，包括将广播消息用于消除存储 节点ID的需要的模型。但是，客户机要在DAQ的事件产生消息中包含 APIID和Op码(API Id 2，Op码1，2，12，13)，使得他们能被动态 分配(如下面讨论的)。利用该方法，所产生的事件消息将包含分配的 APIID和Op码(如在API Id＝1的publishEvent消息中所示)。在该消 息(publishEvent)中，图4的28的字节1和字节2的APIID和Op码 是由客户机16利用事件产生消息(上面引用的)分配的。
已经确定在此描述的软件体系10使用包括APIID和Op码的广播 消息收发模型。这将提供通过用API ID存储来换取节点ID存储进行的 路由的优点。假定下面是对SAP讨论，广播消息收发的风险大大减 小。尽管一定数量的处理将由节点用于丢弃与节点无关的消息，但是这 仍然比定向消息优越，因为定向消息最终会导致网络的饱和以及软件体 系10的饱和。包括API ID使得客户机可以用动态API来配置控制，这 将在未来刺激更好的模块化设计。
在多个节点上使用相同的API。有可能一些可选的网络部件将实施 与UI或电器管理器板(即维护/诊断或能量)相同的API。这使得可选 的网络部件16可以向外部客户机22表明自己。因此，软件体系10可 以允许客户机16、22与两个物理节点交互-每个节点都实施相同的 API。该设计的考虑在于几个其它节点的交集，类似的，其分辨能力是 事先存在的设计解决方案的组合。
可选节点可以通过动态的成员资格实现。客户机可以通过发现API (参见图6)找出哪些节点支持协议28。也可以通过发现查询每个节点 以找出支持什么样的API。Op码不是全局唯一的，但是与API ID和 Op码耦合的内部通信网络14节点id是唯一的。API ID内嵌在每个事 件中。
总结一下，客户机首先可以发现软件体系10节点，然后发现每个 节点的支持API。客户机然后可以启动与每个节点的每个API的交互。 由于每个分组24包括节点ID和API ID，因此客户机和目标都可以避 免命名空间的冲突，并将消息路由到合适的应用空间。
在同一网络节点上的多个API实例。存在这样的电器12设计，该 设计将自身出借给在同一微处理器上的API再利用。示例包括双灶炉子 (即两个单独受控的烘烤室)或者两格子的冷冻箱。换句话说，在一些 情况下，存在多个炉灶执行相同功能并且因此能通过相同API受控。针 对这种情况的设计方法已经讨论过。
在唯一功能名称模型中，设计者针对每个命令或变量创建具有唯一 Op码的API ID，而不考虑再利用该定义。换句话说，Op码10＝下炉 灶设置温度，Op码11＝上炉灶设置温度。在该唯一功能名称模型中， 在发现期间的消息收发更少，但是该模型不能促进模块化设计和代码的 再利用。
在多个API ID模型中，设计者使用相同的Op码定义，但是为每 个API实例分配唯一的API ID。在该模型中，在发现期间的消息收发 更少，而且该模型促进模块化设计和再利用。但是该模型导致以更快的 速率消耗可获得的API ID。
在实例ID模型中，软件体系10动态地向每个API实例分配API ID，但第一实例除外。API的第一实例由全局API ID知识库标识。为 了做到这一点，软件体系10指定API ID(例如246-255)作为保留的 API以动态分配给API实例。该模型促进模块化设计和代码的再利用， 并且不消耗API ID。但是在发现期间存在更多的消息收发。
Aa110是设计为以稳健方式允许对象发现并彼此合作的面相对象的 协议。这些要求的基础是：(1)合作实体必须可以唯一的寻址，从而可 以恰当地在网络上路由消息，(2)合作实体必须可唯一识别，从而他们 的消息收发合约、交互的规则以及兼容性考虑可以得到理解。在单一的 运行时环境中，编译器可以强迫执行第(2)项。在联网或分布式环境 中，内嵌的编译器通常不解决第(2)项。
合作实体(对象或API)寻址的唯一性通过组合3位节点ID(在图 4的24的地址字段中找到)和8位的API或实例ID(在图4的28的字 节1中找到)来管理。任何包含这两个信息的网络消息都可以被正确路 由。这为每个网络节点提供了255个唯一的合作实体(或对象)。
实体标识通过8位API ID(例如类标识符)、两字节类型ID(即子 类或规范说明)以及两字节版本ID(即类型ID意味着目的，版本ID 意味着兼容性)来定义。
这种两层的方法与标识的唯一性分离地识别寻址的唯一性。这种分 离通过从每个分组中去掉4个字节的标识信息提供了对带宽更有效的利 用。反过来客户机必须缓存标识信息，并且按照地址的总共11位来索 引该标识信息。
已经确定实例ID模型是本发明的优选实施例。发现API(API ID ＝3)支持消息中的实例ID、公布API信息、获得实例信息和公布实例 信息。实例化是非常有力的概念，可以通过在协议中的使用来举例说 明。
API-Op码命名空间。串行网络上的消息通常具有ASCII或数字 标识符，以允许消息的接收者将包含在消息中的数据路由给合适的内部 函数。该函数接着对有效载荷中的剩余数据进行运算。
有效载荷中的剩余数据是在文档中在运行时定义的。该文档描述了 有效载荷中每一位和/或每一字节的含义。根据该文档，特定于每个有效 载荷定义开发了内部软件消息处理程序。因此通常对每个唯一的Op码 和Cmb/Fb对存在一个消息处理程序。
正常情况下，如果存在多个共享相同Op码的独立有效载荷定义而 没有任何额外的识别机制，则接收者不可能将该消息路由给合适的消息 处理程序。但是，本发明提供了Cmb/Fb标志来支持叠加或Op码使 用，该标识用于区分。因此，本发明提供了重叠使用相同Op码的命令 及其对应的反馈消息的功能。
这一节讨论了可用于向消息有效载荷定义提供唯一标识的技术。
在全局唯一的Op码模型中，利用该方法，Op码必须是全局唯一 的。换句话说，必须向每个平台或API开发者分配一个Op码范围内 (例如350-385)，该范围一定不能与任何其他项目的Op码范围重 叠。该模型由于要求多余ID的范围分配而是低效的。此外，API开发 者不能控制其Op码标号机制，而且该模型要求一定数量级的更多合作 的确定(信息传递)。
在全局唯一的API ID模型中，利用该方法Op码被分组为形成 API的逻辑集合。为API分配由API ID、类型和版本组成的全局唯一 的ID。因此，在此的Op码只需要在该API中是唯一。在这种模型 中，不需要分配多余的ID，API开发者可以在Op码＝1时开始，该模 型只需要很少的信息协作来避免命名空间的冲突。
已经发现本发明采用全局唯一的APIID策略作为优选实施例。作为 软件体系10核心API一部分的某些固定Op码，回复到共同的开始号 码(1)，而且优选可以向核心API分配为1的API ID。
SAP分配。在24中的SAP识别Wide有效载荷或SDU26的结构。 它与前面描述的API ID的概念相同。SAP的优点也相同，因为输入的 消息需要被识别和路由给正确的内部处理程序(或快速丢弃)。在这里 讨论的WIDE网络14中，存在16个可获得的SAP。Aa110为SAP成 员资格定制判断标准。在这种情况中，内部通信网络14管理员可以批 准软件体系10应用协议并向软件体系10分配官方SAP。也可以想出协 议24的其它网络标识符而不会脱离本发明的范围。例如，可以在内部 网络14上向软件体系10分配为1的默认SAP。
SAP(或其他子协议标识符)允许内部通信网络14节点参与软件 体系10和非体系10的消息收发。Aa110SAP适合全局体系，并且向软 件体系10添加了更多的范围。内部通信网络14SAP是来自技术和实践 观点的可靠的概念。保证特定于网络14的ID为软件体系10提供了全 局可见性和官方可接受性，这可以有助于增加其使用并促进它成为全球 标准。
图5的软件体系10发现。在上一节中，建立了软件体系10的API ID类似于内部通信网络14的SAP。类似的，在上一节中，建立了软件 体系客户机16通过查询发现API的优点，API驻留在软件体系10的每 个物理节点上。
类似的问题和/或解决方案可以呈现给软件体系10发现。如果维护 工具希望动态地发现所有的软件体系10API，首先就需要发现支持软件 体系10协议的内部通信网络14节点的节点ID。这可以通过发送软件 体系10节点会响应的广播命令的广播消息模型来完成。在该模型中， 软件体系10可以广播添加到软件体系10中新的API，或者可以广播添 加了实施软件体系10的新网络14节点。图6的发现API用作软件体系 10发现的机制。轮询发现消息和简单的广播消息都可以获得而且将在发 现API(API ID ＝3)中讨论。
多有效载荷消息的完整性
Aa110标题中的Frag，即字节2的位6，使得软件体系10协议可 以发送大于底层协议(即内部通信网络4的有效载荷)的有效载荷。如 果Frag置位，接收者应当意识到当前的消息将分段成多个分组或片 段。
在消息片段id模型中，分段的消息的第一片段使用如图4所述的标 准分组结构。该初始片段提供消息的API、Op码和Cmd/Fb标识。该 消息的所有后续片段优选具有图24所述的分段消息结构。在该结构 中，Frag标志仍然存在(与MMP标志一起)以增强数据。但是，字节 2现在在位5中包含更多片段未决标志(MFP)、位3-4中包含消息id (MID)、在位0-2中包含片段id(FID)。
MFP标志告知接收者应当期待当前消息的至少另一个片段。MFP 从1转变为0告知接收者当前分组是当前消息的最后一个分组。MID提 供了每一个消息的一个2位标识符。因此，向每个分段的消息(一组片 段)分配MID，该MID然后对每个随后的分段消息(一组片段)都增 加。MID增加到3，接着回滚到0。FID为消息内的每个片段提供一个 3位的标识符。因此对于特定的消息，总是向第一片段分配为0的 FID。对于该消息的每个后续片段，FID将增加。FID增加到7，接着 回滚到0。
通过本发明提供的片段协议允许接收者检查分段消息的完整性。通 过监视Frag和MFP标志，接收者可以保证分段消息没有错误内容。通 过检查MID没有在接收单个分段消息时更改，接收者可以保证两个分 离的分段消息不会融合(也许由于丢失的片段)。通过检查FID随着每 个片段正确地增加，接收者可以保证消息内没有丢失片段(或没有按照 顺序接收)。参见图25中消息片段id模型的示例。
在和CRC模型中，该解决方案利用了公知的现有循环冗余校验和 (CRC)的概念。额外的两字节CRC可以添加到多有效载荷消息的最 后一个有效载荷的后面。CRC是连接为一个组合的有效载荷的所有有 效载荷字节的CRC代表。发送者产生该CRC。接收者根据公知方法验 证该CRC。在和CRC模型中，该解决方案重利用已经建立和公知的 CRC算法，但是CRC算法比帧计数器更复杂，而且CRC可能不容易 由第三方携带。因此，已经确定消息片段id模型是根据本发明确定软件 体系10中的多有效载荷消息的完整性的优选实施例。消息片段id模型 更容易由第三方实施，而且更容易添加到现有体系10中。
软件组织
针对软件体系10，下面借助图10讨论代码组织和实施文件。图10 是示出根据本发明的图1的软件体系10与包含各种软件成分16B的部 件16的软件运行环境16A的关系的示意图，其中软件体系10包括命令 处理程序50、更新处理程序48，和用于将软件体系10连接到内部通信 网络软件运行层14A的内部通信网络层接口52，该内部通信网络软件 运行层14A创建数据并通过家用电器12的通信网络14发送该数据。而 且还示出软件运行环境16A中的其他软件成分16B如何调用和与软件 体系10的部件(50，52，48)交互的例子。
为了产生软件运行环境16A的更通用的实施，去掉UI管理器(软 件运行环境16A内的几个软件成分16B之一)之间的相关性。在该实 施中，软件运行环境16A的主执行循环11调用50。以前相信以前的实 施由于与涉及UI_Manager16B的执行时序关联的时序细节提供软件体 系10的更为精确和稳健的性能。
为了定义软件体系10的第一层细节，示出3个主软件成分(子部 件)：更新处理程序48，命令处理程序50，内部通信网络层接52。更 新处理程序48与DAQ引擎30交互以识别标志DAQ运行中的更新的 信息，从而内部通信网络层接口52可以处理所述信息，从而导致与内 部通信网络软件运行层14A的交互，从而导致分组结构24传送到网络 14上。命令处理程序50验证和处理从内部通信网络层接口52输入的命 令，从而根据分组结构28的标识符API Id和Op码值调用合适的软件 运行函数。内部通信网络层接口52打算解除软件体系10的特定部分与 内部通信网络软件运行层14A、图1的网络14和图4的分组结构24的 耦合(尽可能实际)。内部通信网络层接口52与内部通信网络软件运行 层14A连接，后者根据图4的定义产生数据并通过家用电器12的通信 网络14发送数据。
图1所示的软件体系10的软件运行层子部件48、50、52一起协作 来管理与其他也具有软件体系10的部件16或22或者能够与分组结构 24交互的替换物的通信。
图34示出用于本发明的几种实施文件。
SA_prm.h。软件体系10包括可配置参数和命令列举。
SACore.c.h。该用于软件体系10核心软件的文件包含用于处理命 令、管理流控制反馈和产生动态更新的电器数据的快照的更新处理程序 48和命令处理程序50。
SAAppSpecific.c/.h。该用于软件体系10核心软件的文件包含用于 驱动特定类型的电器12的特定于电器的命令处理程序和命令实施(例 如具体指导管理洗衣机和与该洗衣机通信的文件)。不是通用于所有电 器12的任何命令都在该函数中实施。这些命令列举在SA_prm.h中， 而且由命令处理程序调用。
SAWideComm.c/.h。该文件包含内部通信网络14应用层52，其提 供与内部通信网络14协议连接的接口，并控制消息结合为快照、控制 对进入命令的分析，并且控制对更新标志的处理以发送更新消息。
SADaq.c/.h。这些文件包含DAQ引擎30的全部功能。由此，涉及 更新处理程序48和事件产生的所有功能都包含在此。
SADiscovery.c/.h。这些文件包含实施软件体系10的节点的所有功 能，用于发现实施软件体系10的其它节点(以及其它节点的对应功 能)。
SAVaiableMap.h。该文件包含内嵌的变量映射，其使得可以通过外 部客户机产生事件而无需知道存储的变量地址。
图11示出软件体系10与电器控制之间的示例接口，其中根据本发 明图1的软件体系10由管理调度器(MAIN)调用3次。还示出MAIN 调用WIDE.WideExec()。WIDE.WideExec()随后根据图33调用软件体 系10，其中软件体系10的部件WideCommHandler暴露了函数 SA_AcceptData()和SA_BuildData()。还示出MAIN调用 SA_WideComm()(也是由软件体系10的部件暴露的函数)，这最终导 致如图33所示调用软件运行环境16A的部件WIDE的函数 WIDE.QueueMsg()。
图13是图11所示的软件体系的示例性实施，包括电器初始化部 分。初始化函数在进入图11所示的主执行循环之前从初始化例程调用 SA_Init()。
下面的表格示出如何管理API的文档例子，包括用于控制通过软件 体系10的API暴露的功能的部署的编译器指示机制。
API名称 API ID 类型 版本 编译器指示 ROM使用 RAM 使用 注释 核心 1 1 2 SA_COR 1810 43 基于注册 的30个动 态事件 数据获取 (DAQ) 2 1 2 SA_DAQ 1658 373 基于注册 的30个动 态事件 (10字节 RAM/事 件) 数据获取扩 展 (包括 SA_DAQ) 2 2 1 SA_DAQ_EXT SA_DAQ+1064 DAQ 基于注册 的30个动 态事件(包 括 SA_DAQ) 发现 3 1 1 SA_DISC 516 3 调试 4 1 1 SA_DEBG 下层 5 1 1 SA_LOLV 键按下 6 1 1 SA_KEPR 存储器端口 API 7 1 1 SA_PORT 342 0 能量管理 8 1 1 SA_ENGY GMCL 9 1 1 SA_GMCL 轮询变量 10 1 1 SA_POLL 维护和诊断 11 1 1 SA_DIAG 未使用 (140- 240) 非标准 (241- 245) 保留给API 实例Id (246- 255)
在上面的表格中，241-254范围内的API Id可以在不考虑标准的 情况下使用。他们意欲赋予设计者在期望再利用最小的应用中使用软件 体系10的灵活性。在这种情况下，这会消除为预计是“离线”的消息集 合开发特定API Id和类型的需要。这些Id还可以用作还没有接收到官 方ID的候选标准API。此外在上面的表格中，RAM和ROM估计是使 用MotorolaHC08 Cosmic Compiler版本4.3f来进行的，其中软件体系 10配置为允许30个动态事件(即存储器堆大小＝300字节)、定义7个 API和15字节的最大命令大小。
图14是组合了根据本发明的图1的软件体系的虚拟路由器的示意 图，其示出一对软件体系实施之间的映射。图14的虚拟路由器是封装 软件体系10的API实施(对象，参见图4的路由器的每一侧的API1- 8)的软件设计，使得内嵌客户机(应用逻辑、算法、逼和循环、定序 器和状态机)和内嵌部件(软件体系10API实施：诸如除霜器、加热 器、温度传感器、阀门等对象)之间的协作同一和一致，而不考虑实体 是通过网络协作还是共享运行时环境。
图14示出这样标出的6个唯一的协作示例，其示出存在于分离的 硬件部件16上并且通过网络14连接的一对软件运行环境16A如何使用 软件运行环境16A的各种软件成分16B来产生右手和左手软件运行环 境的运行逻辑59和软件成分16B之间的透明访问。
在描述协作示例之前，描述图14的结构将有助于理解该协作示 例。每个软件运行环境16A包含所包含的有用软件运行部件(16B)的 子集的代表，包括：软件体系10，内部通信网络层接口14A， DAQ30，硬件提取层80。
硬件提取层80包括：用于封装所连接的电路的特定固定地址的机 制，软件运行层80将运行在在该电路上；按照以下形式(之一)封装 16B出现的软间接口(28，28A或82)：28是通过软件体系10交换的 消息的分组表示(字节的有序集合)，28A是通过软件体系10交换的消 息的分组表示(字节的有序集合)，其只代表由软件运行部件84或86 期望的应用有效载荷28A(有效数据变量)，82是28或28A的替换表 示，其中目的和数据值和产生的行为在功能上相同，但是不是字节的有 序集合的形式。82是具有通过单独命名的变量代表的变量的唯一软件功 能的形式，该变量的值从28A导出或者通过从28A导出的字节的有序 集合代表。
应用GDM84(全局设计模块)是作为全局设计模块公知的16B的 变形，这是经过了标准开发过程的标准软件运行部件，包括函数和非函 数要求、测试、存档和实施指导。特定于电器的应用GDM地址涉及例 如除霜器、加热器、闭门器。应用GDM可以分为至少两种变形。变形 1包含与59不同的特定于应用的逻辑，用于管理行为和从包括多个其他 84和86在内的其他软件运行部件集合收集信息。变形2包含不同于59 的特定于应用的逻辑，用于管理行为和从具体的电子机械装置或传感器 如加热器、电梯、发动机、阀门、螺线管、继电器、压力和温度传感器 收集信息。变形2可以配置为解决通过该装置的具体制造商变形、通过 装置的基于通过应用要求确定的使用模式的具体配置，或者通过产生未 在此提到的具体问题的因素集合而变得重要的具体问题。
基础结构GDM86解决与图1的软件体系的应用无关的连续发生的 具体问题。它们可以在多个电器如冰箱、炉灶面、洗碗机、甩干机、洗 衣机等等之间再利用。基础结构GDM可以分为至少两种变形。变形1 与电部件或电约束的连续组合而导致的具体问题关联。一些例子包括： 制造接口约束，装置占空因数，电负荷特征，其例子包括涌入电流限制 和稳定状态电流限制，或者其他约束如模拟到数字的转换模式，其例子 包括4-20mA电流循环vs.0-5V直流模拟电压反馈。变形2与电器和 作为效用函数公知的独立于应用的软件成分关联。它们提供了由包括59 和80的其它16B部件使用的逻辑。变形2可以包含或使用对86的变形 1的参照。例子包括定时器，跨0检测，和其他有用的软件成分，这些 软件成分的目的比通过应用或电机械要求驱动更为实用。
内嵌的虚拟路由器70提供封装层，通过该封装层(部件16的软件 运行层16A的)应用逻辑59和硬件提取层80包括的部件、DAQ30、 应用逻辑59的其它实例或应用逻辑59中的部件或其他任何有用部件 16B之间的体系依赖性(由通过14连接的至少两个软件运行环境内部 或之间的其它16B访问或暴露给其它16B的一个部件16B的方法[16B 的例子是30，84，86])最小或被消除。
由其他软件成分16B用于获得对任何其它软件成分16B的参照的软 件成分72存在于(其中获得的16B可以是软件运行环境16A的一部 分)：相同的硬件部件16，通过14连接的不同的硬件部件16，通过包 括14在内的网络段的组合连接的不同硬件部件22，或者通过14连接的 不同电器12的不同硬件部件16，第一电器12的两次发生12、14之间 的不同网络段的组合。
软件成分72还为驻留在相同的软件运行环境16A内的其他软件成 分提供用于公布必要的标识和/或路由信息到72的存储器中从而启动72 的上述列举的用途的机制。标识和路由信息可以与驻留在相同的软件运 行环境内的部件关联，或者标识和路由信息可以涉及与驻留在相同的软 件运行环境内的部件分离的部件，但是通过驻留在相同的软件运行环境 内的部件知道。
70的存储器中的结构74可以接收消息或者提供用于调用消息的函 数，并且可以发送消息或者提供用于发布信息的调回函数。这些具有 28、28A或82的访问定义的结构对应于诸如80、59内的部件的软件成 分或位于上述列举72中的任何其他有用软件成分的发生，以及将信息 路由给该软件成分或者路由给具有74的相同或类似目的的合适中间软 件成分的功能。
现在查看可能的协作示例，期望基于发现查询产生和填充70的结 构74，该发现查询包含访问既可以识别又可以路由的具体软件成分16B 的请求，表明所述访问的调用，或者通过能够代表自己或其他部件16B 调用70的软件成分16B产生和填充70的结构74，从而导致结构74的 产生和填充。
协作1：命令通过右手软件运行环境16A的软件成分59发布，并 通过包含在74的集合中的软件成分接收，其中在相同软件运行环境的 部件70内具有API 1标识符。采用包含在70内的标识和路由信息，通 过API 1识别的部件通过其它局部软件运行层10和14A发送所接收的 信息，而且最后通过14发送和通过左手软件运行环境的14A接收。然 后该消息通过10处理，并且路由到左手软件运行环境的74内的合适部 件。使用包含在相同软件运行部件70内的标识和路由信息的合适左手 软件运行部件74接着调用包含在左手软件运行环境硬件提取层80中的 API1的实施或向其发送消息。由此右手软件运行环境的软件成分59内 的应用逻辑调用时是在左手软件运行环境中的函数，而无需包含在其中 用于实现所述调用的信息。因此，图14表明的设计的值是应用逻辑59 可以相对于其他软件运行部件16B的位置再利用，该其他软件运行部件 16B位于通过网络14或者可能包括14的多个网络段连接的多个软件运 行环境16A内。
协作2：在这种情况下，消息的初始化从左手软件运行环境16A的 59开始。示出最后调用在相同软件运行环境内使用在协作1中详细描述 的相同方法的软件成分(在这种情况下是API2)的情况。因此，在协 作2中，示出设置在应用逻辑59发生到某个其他有用软件成分(硬件 提取层80的API 2)之间的替换体系对任何一种的实施没有影响。此 外，软件成分70的目的是提供这种功能，软件成分70可以符合通过软 件体系10设置的标识和接口要求。
协作3-6示出内嵌虚拟路由器70的其它用途。用于完成这些变形 的机制与在协作1和2中描述的相同。包括他们是为了示出该设计的有 用性以及涉及DAQ30可获得的期望的其它消息模式。应用逻辑59的本 地事件监听者(3)和远程事件监听者(4)都具有与DAQ引擎30的代 表的互连，该互连不仅提供与本地软件运行环境中的DAQ的连接，还 提供与驻留在远程运行环境中的DAQ的连接。基于DAQ事件的发生 而由DAQ产生的消息可以通过70中可获得的机制传送给本地(6)和 远方(5)。
图15是采用12的体系建立的非典型电器的示意图，该电器包括作 为部件组合的永久节点54，该部件包括根据本发明的图1的软件体系 10。现有技术的内嵌系统是为了提供PCB本地的数据持久性，而根据 本发明的永久节点通过软件体系10的机制和/或内嵌虚拟路由器70提供 暴露给部件16和22的永久服务。
在每个客户机的通过内部网络彼此通信的部件内，示出每个部件 16、电器12和永久节点54上的连接器和协议(RS-232，无线的， WIDE等)的各种示例。总的来说，永久节点54是可被共享网络14、 20或运行时连接的所有部件16发现和使用的逻辑实体。该实体提供读 取、写入和存储信息所需要的服务和协议机制。
如上所讨论的，电器12是“状态”驱动的机器，通常具有用户接 口，用户使用该用户接口可以改变电器12的状态(例如将洗衣机从空 闲状态变为“洗衣”状态)。由于开发了需要与电器12进行外部通信的应 用(例如测试，诊断，远程控制等)，因此存在3种可能的技术来执行 该接口：(1)将外部命令翻译为键按下(参见图16和讨论)；(2)采用 定制软件来执行更改状态的命令(参见图16及讨论)；或者(3)简单 地将键按下翻译为逻辑API(参见图17及讨论)。
图16是现有技术方法的示意图，通过该方法外部命令翻译为键按 下以测试家用电器的功能。在该现有技术方法中，用户通过一个或多个 键按下56以更改电器的状态(该电器在图16中称为“状态机”12)从而 影响电器的功能58来启动电器12。为了测试电器的功能58，用户准备 外部命令60，并且(1)将外部命令60翻译成键按下56；或者(2)准 备定制软件62，该定制软件仿真状态机电器12以尝试复制电器功能 58。这可能很困难和容易出错。
在一种运行和测试电器的新方法中，图17是由用户启动的键按下 56和外部馈入的软件命令60(通常来自客户机)的交互的示意图，该 键按下56和外部馈入的软件命令60都作为变量传递给根据本发明的图 1的软件体系10用于向家用电器12发布命令，以例如测试家用电器的 功能58和/或更改家用电器12的状态(即实际运行)。
参照图17讨论的方法是新颖的，因为不是翻译外部消息，将电器 12作为封闭系统来对待，而是与消息是作为外部键按下还是电器12本 地或远程的软件命令接收无关地暴露电器12的功能。消息(命令)通 过软件体系10的API(现在与现有技术的“封闭”系统相反是开放式系 统)处理，同时给用户保留键按下验证和反馈。
当前，电器控制软件不是建立来验证和执行外部命令。为了弥补这 一点，电器API定义为包括用户功能以及下层机器控制命令。在正常运 行期间，在按下键或者发布外部命令时，该键按下或命令作为共用进入 点而直接映射为用户功能API函数调用(例如，在用户接口[键区]上按 下洗衣键或者发布外部的洗衣命令都会导致立即调用setCycle(WASH) 函数，而不管电器12的状态如何)。所有验证和基于状态的行为都存在 于该函数内部，从而外部命令与键按下56得到相同的对待，而且执行 相同的代码。
该API可以不对电器控制软件进行主要的重新设计就实施。只需要 识别用户接口软件以作为任何命令的进入点而调用API函数，而不是只 是对状态机12内部的键按下进行反应。使用图17的方法使得电器12 的制造商可以分开地测试和诊断键区/用户接口。这节省了在电器开发、 诊断和测试时的事件和精力。这也消除了对复杂机械键区启动装置以及 传统上要用于测试用户接口和电器功能的机械执行硬件的需要。
此外，电器12API含有用于将电器送入诊断或工厂测试模式的命 令。在该模式中，所有基于状态的行为和命令验证代码都无效，以允许 下层API。在该模式中的API命令可以访问和控制电器12的下层部 件，如读取和写入EEPROM、按下键(56)、读取传感器值、写入循环 参数、执行转接和其他执行器等。
参照软件体系10讨论的API接口是面向对象的软件分组，其在一 个对象(电器功能)具有多个需要与该对象交互的客户机(例如键按下 56和外部命令60)是高效的。这是一种新的方法，因为电器目前不包 含面向对象的软件，而且通常被视为是封闭系统并只具有一个客户机： 用户接口键。本发明设想电器12通过引入内部通信总线(即网络14) 和外部连接20而具有多个客户机。这些客户机可以包括网页应用、诊 断工具、测试工具和家庭自动化系统等。
具有在此所述的API软件体系的电器12是“将来验证”的，并且可 用于顾客可能需要的很多高级远程应用。这些应用可以包括能量管理、 改进的维护和诊断工具以及远程控制和监视。此外，由于API是进入所 有电器功能的进入点，顾客可以受益于电器12的改进的自动化开发测 试和工厂测试。
Aa110还设想虚拟装置模型可以觉察物理装置(电器12)的当前功 能。例如，如果炉子在烘烤，则电器时钟不能修改。功能的同步是一种 打算允许虚拟模型基于装置的状态识别装置功能的变化的通用解决方 案。
目前，该目的通过为每个电器12写入的代码实现。包含在软件体 系10中的解决方案用通用的解决方案代替特定于装置的代码。该解决 方案包括附加消息，其中软件体系10广播包含无效命令的当前集合 (API和Op码)。该信息在运行时考虑，从而可以按照用户可能只能修 改可被修改的装置特性的方式来表达用户接口，从而没有给予顾客机会 来修改目前由实际装置指示是不变的装置特征。
Aa110是应用和工具的交叉乘积系统。这些应用有助于增加在产品 开发过程中的质量和投放市场的速度。这通过与存储在电器12内的存 储器中的数据交互来完成。
为了保持灵活性、可配置姓和通用性，应用通过规定需要的数值存 储器位置(地址)来与电器交互。但每次当电器中的软件改变时，存储 器中的这些位置可以移来移去，并具有非常不同的含义。为了解决该问 题，创建了变量映射文件标准和发生器。
变量映射文件发生器提取写入代码的软件名称(文本描述)并将该 名称与该数据的数值地址和大小关联。然后该发生器按照标准文件格式 输出该信息。这在每次改变和编译代码时执行。该标准文件中的信息提 供与编译器和数据位于存储器中什么位置无关的独立性。
然后通过任何希望与基于软件体系10的电器12交互的任何应用读 取变量映射文件。应用是对照数据的有意义的文本名称而不是数据的数 值地址来编码的，这大大简化了应用的开发。
变量映射文件格式和使用过程描述在下面的表格中。
模块 变量名称 地址 大小 appman.h Hour_Timer 0213 1 appman.h Zonel 020e 3 appman.h Zonel.Act_Temp 0210 1 appman.h Zonel.Zone_State_Tmr 020f 1 appman.h Zonel.Zone_State 020e 1
采用变量映射工作的方法示例包括以下步骤。
1.工程师建立对照位于电器控制中的有意义的数据的文本描述名 称而编码的应用。
2.电器控制代码变化，从而导致有意义的应用数据具有新的位 置。
3.工程师编译新的电器代码，这也自动产生关联的变量映射文 件。新的代码和变量映射文件一起部署。
4.当应用是对照新代码运行时，只要该应用具有恰当的变量映射 文件，该应用就不需要改变。
5.如果应用需要新的数据，则可以从变量映射文件中很容易识别 或检索出该数据。
因此如上所述，开发工程师只需要记得上面表格中“变量名称”列， 不需要不断查找在“地址”栏中不断变化的地址值。
现在参照图18，为了举例的目的而示作炉子的家用电器12具有内 部通信总线200，而且该家用电器12可以通过类似于上述网络接口连接 器20的网络接口卡(NIC)204耦合到外部网络202。NIC是用于将计 算机或其他客户机连接到网络的公知装置，任何合适的NIC都可用于电 器12。根据本发明的实施例，NIC204电连接到内部通信总线200，并 将内部通信总线协议适应于标准通信协议，如TCP/IP和GSM，从而电 器12可以通过外部网络202如局域网(LAN)和/或广域网(WAN)与 外部客户机(未示出)通信。因此，外部客户机可以与涉及电器12驻 留在内部网络14上的各种内部部件的软件体系10通信。例如，图18 中的电器12示作包括用户接口(UI)208和传感器-执行器板210，每 一个都包括印刷电路板(PCB)和对应的软件体系10，而且外部客户机 可以通过NIC204与软件体系10通信。
NIC204可以通过任何合适的安装装置安装到电器12的优选从外部 设置的通信总线200上，这在计算机网络领域中是公知的。根据本发明 的实施例，通信总线200位于限定与电器12的器壁齐平的开口214的 凹陷212中，该器壁例如是后壁216，如图18所示。当通信总线200位 于凹陷212中时，通信总线200和NIC204(在安装到通信总线200之 后)受到防止在运输电器12过程中可能发生的损坏的保护。
NIC204可以在制造时与电器12一起提供，或者可以作为附件与电 器12分开购买。因此，顾客可以选择购买没有连接到外部网络202的 功能的电器12，并在以后升级该电器12以添加连接，如果需要的话。
NIC204可以通过有线连接或无线地与外部网络202通信。例如， NIC204可以通过无线红外(IR)通信或其他短程无线装置与外部网络 202通信。在这种情况中，NIC204优选安装在电器12的正面218以推 动稳健的通信。根据本发明的实施例，NIC204可以安装在电器的正面 218上的凹陷220中，如图19针对炉子所示。如果安装到电器的正面 218，则NIC204可以通过设置在线路管道224中的导线连接到电器的背 部222，该线路管道224从正面218的安装凹陷220延伸到电器12的背 部222，在背部电线进入电器12。
有线通信的另一个例子是射频(RF)通信。例如，RF印刷电路板 (PCB)226可以位于电器12内部，这需要RF PCB226和外部安装的 天线之间的连接。可替换的，RF PCB226可以安装在电器12外部，但 是该配置需要RF PCB226和电器控制电路之间的电连接，而且安装者 必须在安装RF PCB226期间打开电器12的内部或内箱228。根据本发 明的实施例，RF PCB226安装在电器12内部，而且热和电的不良导 体-非金属保险隔板作为电器内箱228的一部分提供。示例性的保险隔 板230是塑料窗，如Plexiglas窗，与电器内箱228集成在一起，如图 20为说明目的针对炉子形式的电器12所示。保险隔板230允许RF与 内部安装的RF PCB226通信而无需外部天线，并防止人员接触过多的 热量或触电。
现在参照图21，电器12可以用硬件配置以有助于电器12的维护和 诊断。在一个实施例中，配置适用于可消除地与电器12上的标准通信 总线连接的维护模块232以记录诊断数据，例如通过与内部网络14上 的软件体系10通信。维护模块可以很容易连接到内部网络14。维护模 块232与电器12的连接通过图21的步骤1来代表。接着维护模块232 从电器12去掉并连接到个人计算机234，例如通过USB端口或其他合 适的标准通信总线。维护模块232与计算机234的连接通过图21的步 骤2代表。在维护模块232连接到计算机234之后，维护模块232优选 自动连接到互联网，并将诊断数据加载到远程客户机(未示出)上，如 图21的步骤3所示。远程客户机处理诊断数据以识别电器问题或故 障，并潜在地防止维修电话，如果该问题或故障需要维修电话的话，从 而优化维修电话的效果和效率。可选的，维护模块232可以基于诊断数 据下载定制测试脚本，以便在电器12上运行测试以进一步诊断或消除 该问题或故障。图21中的步骤4表示维护模块232与电器12重新连接 以执行该测试脚本。
维护模块232的示例性体系在图21A中示出。维护模块232包括一 对通信总线，如外部串行总线。根据所示出的实施例，维护模块在一端 包括USB236用于连接到个人计算机，而在对立的一端具有RS- 232(EIA-232)总线238用于连接到电器12，尤其是连接到驻留在电器内 部网络14的各个节点上的软件体系10。维护模块232还包括存储器 240，如闪存，用于存储诊断数据、测试脚本和其他数据。闪存240与 控制维护模块232的运行的维护逻辑242通信。
图22示出用于维护和诊断电器12的替换硬件体系。该体系类似于 图21所示出的体系，只是个人计算机234被电话线244代替，维护模 块232适用于连接到电话线244。由此，图22的替换体系更适于没有个 人计算机或者个人计算机没有连接到互联网的电器用户。用于获得诊断 数据的过程与参照图21所述的相同；但是，不是将维护模块232连接 到个人计算机234，用户将维护模块232连接到标准电话插座246，维 护模块232通过电话线244自动连接到互联网。
下面参照图22A，用于图22的系统的维护模块232类似于图21A 示出的维护模块232，只是USB236被电话线插座248代替，如RJ11 插座，该电话线插座用于将维护模块232的调制解调器250与电话线 244连接以建立与互联网的连接。
上述维护模块232可以在制造时与电器12一起提供，或在电器12 销售期间或售后作为附件销售。其它各种附件模块的类型可以随着电器 12一起提供，或者由顾客以后购买以升级电器12。示例性的附件模块 可以包括可操作地连接到内部网络14和外部网络202而且可以在安装 到电器12上时让用户看到的显示器。显示器可以向用户通报各种数 据，包括但不限于诸如运行状态的数据，涉及电器并通过内部网络14 上的软件体系10获得的数据，或者通过外部网络202从互联网下载的 信息。示例性的附件模块是气象站模块252，其在图23中示出安装在以 冰箱的形式示出的电器12上。除了显示与天气有关的信息或可从外部 网络202下载的其他信息之外，气象站模块252的显示器还可以包括具 有选择区域254的一个或多个触摸板或触摸屏256，用于控制冰箱的各 种操作，如控制冰分配和灯，用于访问冰箱的设置如温度。
图24示出分段消息的优选分组结构。这种分组结构优选通报消息 有效载荷何时大于底层协议的有效载荷。该分段分组结构前面已经在涉 及多有效载荷消息的完整性中描述过；但是在此简要总结如下。在分段 消息中，图4所述的标准分组结构优选用在第一片段中。所有后续片段 优选使用图24所述的分组结构。这些协议之间的区别在于字节2。
为了分段消息的完整性，Frag标志应当置位。MFP标志(更多的 片段)应当置位到分段消息的最后一个片段为止。MID(消息id)为每 个分段消息一个处理程序或id，从而防止分开的分段消息融合。FID (片段id)基于分段消息的每个片段一个处理程序或id，从而允许检测 丢失的片段。更为深入的解释可以在多有效载荷消息的完整性中找到。
图25提供在图24中讨论的分段协议的示例性操作。该协议的解释 可以在多有效载荷消息的完整性中找到。
图26A和26B代表用于查找地址和标识符信息的替换体系，使得 可以建立很好形成的消息并发送给图10的软件体系，从而导致在图5 的DAQ30中产生事件。如前所述，DAQ引擎30要求变量的存储器地 址用于事件注册。图26A示出利用由客户机配置的数据获取机制的例 子，其中客户机(计算机或其它客户机)保存将变量名与其存储器位置 关联的当前存储器映射。除了标识符(API Id和Op码)之外，该存储 器地址也用于构建良好成型的消息，该消息发送给DAQ从而导致DAQ 事件的产生。图26示出使用客户机配置的数据获取机制的示例，其中 客户机(即另一个控制板)不知道期望的事件变量的存储器地址。在这 种情况下，客户机可以利用本发明的内嵌式变量映射功能。由此，客户 机只需要提供API Id和Op码，而且不需要在将要发送给DAQ的良好 成型的消息中包括变量的存储器地址。因为在这种情况下，DAQ的软 件执行获取通过标识符指定的变量的存储器位置的附加任务。一旦获得 该存储器位置，DAQ就使用在图26A的前一种情况中引用的相同的函 数调用来创建包含在DAQ存储器堆中的DAQ的事件结构阵列的事件 结构。
图26A的变量映射信息将变量符号名称与它们在16A的存储器中 的地址关联。图26A将变量标识符(API Id和Op码)与它们在16的 存储器中的地址关联。替换体系的合理性在于它们支持与可能发现用符 号名称(符号名称趋向于有意义，而且传达变量的有用性)工作是有利 的人员的交互，以及与软件体系10的其它实例或一些部件16或22或 可以与软件体系10交互的其它软件成分交互。在基于软件的交互(非 人员交户)中，有利的是不使用符号名称，因为它们的存储器来存储， 更多的带宽来发送，以及更多的计算循环来处理。相反可以用数字标识 符来代替符号名称。Aa110使用数字标识符API ID和Op码作为符号名 称的数字替代符。额外的数字标识可用于API Id的任何有效发生。前 一个数字标识足以为驻留在网络14上的每一个部件16提供唯一的索 引，后一个数字标识，即额外的标识信息可以利用需要前一个数字标识 API Id部分的第二查询来获得。然后组合在一起，API Id和额外的数字 标识(后一个)提供了可以表示在软件体系10内的可能软件成分全体 中唯一的标识。
图27提供了采用内嵌变量映射的由客户机配置的数据获取机制的 使用示例。在此，节点A使用公开知道的API X和Op码Y在节点B 上注册链接到期望的事件变量的事件。接着，节点尝试利用API X和 Op码Y注册相同事件。由于该API ID和Op码对以前曾由节点A注 册过，因此节点C的请求找到拒绝。但是，接着节点C用获得远程变 量数据命令从远程(内嵌的)变量映射请求数据。节点B用信息响应， 包括期望的变量的存储器地址。节点C接着使用该存储器地址注册事 件，但这一次是用不同的API ID和Op码对。
图27还可以被认为是公开了两个涉及在图26B中建议的事件产生 的消息情形。第一情形描述了节点A和节点B之间的消息收发，这两 个节点都通过内部通信网络14通信，节点B与软件体系10兼容。在第 一种情况中，节点B可能同意来自节点A的请求。第二种情形描述了 节点A和节点B之间的消息收发，这两个节点都通过内部通信网络14 通信而且与软件体系10兼容。在这种情况下，节点B无法同意来自节 点C的请求，因为消息3中的API ID和Op码已经由前一个请求分 配。在这种情况下，节点B适当响应，导致来自节点C的查询(5)， 从而导致来自节点B的网络消息(6)，其包含允许节点C重新产生图 33的相同NVOEvent存储器结构所需要的信息，以及节点B的软件体 系10的图33的DynamicMemoryHeap唯一的API ID和Op码。
图28示出由本发明提供的可配置事件通知功能。优选地，事件在 默认触发时只通知外部客户机。但是，可能期望该外部通知在有些时候 “沉默”而实际上不从DAQ引擎30中去掉事件。此外，可能期望在事件 发生时通知软件体系10内的内部应用。由此，本发明提供了这样的功 能。如前所述，可以采用DAQ API内的设置外部事件开/关命令来更改 外部通知。此外，软件体系10优选提供内部功能来打开和关闭内部通 知。图28示出在可能的配置下的事件通知示例。
通过这种方式，本发明可以禁止和重新启动图33的NVOEvent在 内部通信网络14上的实现。此外，还可以禁止和重新启动图33的 NVOEvent实现为发送给软件体系10的相同软件运行环境16A内的软 件成分16B的内部消息。
图29示出本发明中经过确认的事件的功能。在经过确定的事件 中，软件体系等待来自客户机的确认消息一段预定的时间，直到处理下 个事件为止。如果预定的时间段结束，则执行预定次数的重试。优选 地，假定所有事件默认情况下都是未确认。因此，在向客户机发送事件 之后，DAQ引擎30立即处理下个事件。但是，一些应用需要确认这些 事件以保证消息被事件请求者接收。采用该技术，发送者可以在未接收 到确认时重新发送该事件。该确认证明请求者已经接收到该事件。提供 经过确认的事件的选择的优选实施例的优点在于，由请求者根据应用需 要决定是否需要确认。因此，当请求者在与DAQ30连接的接口中采用 由软件体系10提供的机制来产生事件，消息28A包含了提供该事件是 得到确认还是未被确认的进一步分类。如图29中的示例所示，在发生 确认事件时，软件体系阻断所有其他事件，同时等待来自客户机的确 认。如果没有接收到确认，则软件体系10在可配置的时间量之后重新 发送该事件。该重试序列将发生可配置的次数，直到最后软件体系停止 尝试发送该事件并通过失败的回叫功能通知该应用。
图30示出在本发明中提供的安全特征。由于外部节点执行关键功 能可以通过前面描述的协议进行，因此本发明提供了防火墙机制来限制 对命令执行的访问。认为是对安全性很关键的命令可以在编译前表格中 列出，优选在文件SAVariableMap.h中。命令可以具体列出(具有API ID和Op码)或作为全部API(具有具体的API和Op码＝0xFF)列 出。在该表格中列出的命令要求在防火墙之后。如图30所示，发明提 供了3级安全访问：拒绝访问，授权访问，临时授权访问。
优选地，所有节点默认状态下都以拒绝访问的访问级别开始。在该 访问级别中，只允许该节点执行防火墙前面的命令。由此不允许执行防 火墙之后的命令(或者在防火墙表格中列出的)。在成功提交永久密码 (在公布节点反馈消息的有效载荷中)之后，节点被提升至授权访问的 安全级别。在该访问级别中，允许该节点执行防火墙之前以及之后的所 有命令。为了进行防火墙之后的临时访问，节点可以成功地提交临时的 访问密码(在公布节点反馈消息的有效载荷中)。在该访问级别中，节 点访问防火墙之前以及之后的所有命令一段可配置的时间。该时间结束 之后，该节点的访问级别回复到其以前的状态。
具体地说，图30设想两个密码，每个密码代表通过命令防火墙的 逻辑识别的安全级别。当广播DAQ API的消息即公布SA节点消息 时，密码由部件或客户机发送。(参见字节3和4或Op码2)。一个密 码代表对认为是在防火墙之后的所有特殊命令进行永久访问。第二密码 向认为是在防火墙之后的所有特殊命令授予临时访问。无需密码，客户 机可以访问认为是在防火墙之前的所有命令。负责将软件体系10安装 到家用电器12的部件16上的工程师确定哪些命令在图30的防火墙之 前，哪些命令在该防火墙之后。
图31示出由本发明提供并在图30中示出的防火墙安全的运行的示 例。默认的，节点不能访问防火墙之后的命令。由此如图所示，如果不 能访问的节点试图执行受到防护的命令，则遭到拒绝。在提交错误的密 码之后，受到防护的命令还是被拒绝。只有在成功提交密码之后，才允 许该节点执行受到防护的命令。
图32示出软件体系10可以实施的标准公共接口。示出的是 ApplicationSpecificAPI，其还由设计者根据该应用的需要配置的有用的 功能。还示出与软件运行环境的其它软件成分的关联，软件体系10就 与该软件运行环境关联。
图33示出软件体系10的优选实施。示出执行和支持通过图32表 示的功能所需要的内部函数和存储器分配。还示出辅助类(Command Handler，Dynamic Memory Heap，Update Handler，NVOEvent， TimeHandler，WIDECommHandler，MessageParser和 AppSpecificCommandHandler)，其示出所需要的内部函数和存储器分 配的功能分组。还示出辅助类之间的关联。
图34软件体系10的源代码文件的优选组织。
图35示出3个主要状态(COMM_IDLE， COMM_EXPEXTING_ACK和COMM_PENDING)相互之间相关的 状态图的集合，每个状态可能具有多个子状态等。在此所代表的功能涉 及图33所示的协作关联。其调用也在图11中参照为从软件运行系统的 MAIN执行循环调用到软件体系10上的标准接口函数。
软件运行环境6A的MAIN函数(在图33和图11中示出)调用 SA类定义中示出的SA_WideComm()(其中SA及其聚合功能是软件体 系10)。该函数调用的结果在图35中示出。如图11所示，MAIN在软 件运行系统执行时定期调用SA_WideComm()。
图35示出与MAIN的第二次间接交互，这是MAIN对WIDE函数 WIDE_EXE()调用的结果。该协作在图11和图35中示出。在这种情况 下，WIDE_EXE()函数调用内的WIDE软件运行层14A调用 WIDE.BuildData()，后者又调用52中的 SA.WideCommHandler.SA_BuildData()。在图35中，该调用在 COMM_PENDING状态中示出。该执行路径在当前一状态 COMM_IDLE中COMM_IDLE的子状态内的逻辑导致针对WIDE网 络14的未决外发消息时进行。如图33所示，该状态变化通过调用函数 WIDE.QueueMessage()来实现。该调用导致调用图35的 COMM_PENDING状态内包含的逻辑。
图35的COMM_EXPEXTING_ACK状态是最初利用表明所需要 的确认的特殊指示符创建的外发事件的结果。如果正在 COMM_PENDING状态中运行的事件(也称为更新)需要确认，状态 从COMM_PENDING变为COMM_EXPEXTING_ACK。在这种情况 下，通过重新进入COMM_PENDING状态来重新发送该事件，如果暂 停时间结束而又没有接收到期望的确认消息的话。该过程要一直重复到 接收到确认或者超过可配置的重试参数(MAX_EVEVT_RETRY，每次 重新发送事件时该参数都增加)为止。
图36示出相互之间相关的状态图的集合。示出4个主要状态 (READY，TRANSMIT SNAPSHOT，UPDATES_BLOCKED， PROCESS_DAQ_EVENTS)。在此表示的功能涉及图33所示的协作关 联。其调用也在图11中引用为从软件运行环境的MAIN执行循环11调 用到软件体系10上的标准接口函数之一。
图36表示的功能的目的是估计图33的结构(NVOEvent)31，以 确定是否发生了发送事件的条件，收集该条件，并设置合适的标志 (Updates_Pending和Bounded Updates)，从而在35的状态机执行 时，由DAQ30检测到的事件条件实现为到WIDE总线14上的WIDE 分组24.
图37示出两个主要状态(MSG_READY和MSG_PROCESS)。在 此代表的功能涉及图33所示的协作关联，其中WIDE调用 SA.WideCommHandler.SA.AcceptData()。调用这些状态机也在图11中 引用为从软件运行环境的MAIN执行循环11调用到软件体系10上的函 数，其中MAIN调用SA.SA_ProccessIncomingEvents()。这些相互之间 相关的状态机管理到来命令的执行，响应请求，和处理事件。
图38示出执行软件运行环境的图33中的类的消息的有序集合。这 些消息代表针对在图39、40、41和42中标记为“发送WIDE消息”的共 用逻辑集的执行逻辑。从MAIN和WIDE(通过WIDE_WXE())的调 用在图11示出。
图39示出执行软件运行环境的图33中的类的消息的有序集合。这 些消息代表在包含软件体系10的软件运行环境内的交互。来自MAIN 的调用在图11中示出。该图示出向DynamicMemoryHeap添加良好成 型的NVOEvent存储器结构所需要的消息收发。
图40示出软件运行环境的图33中的类的消息的有序集合。这些消 息代表在包含软件体系10的软件运行环境内的交互。该图示出图37的 消息执行。来自MAIN的调用在图11中示出。由该图代表的功能的目 的是估计在DynamicMemoryHeap内获得的NVOEvent存储器结构， 收集这些存储器结构及其事件触发判断标准得到满足的合适的数据值， 并保证为了通知其他客户机16/22满足该触发器判断标准的NVOEvent 和关联的数据值的目的，分组24实现到内部通信网络14上。
图41、42、43为了处理来自网络14的到来命令(NVO)的目的示 出软件运行环境的图33中的类的消息的有序集合。这些消息代表包含 在软件体系10的软件运行环境中的交互。从MAIN和WIDE(通过 WIDE_WXE())的调用在图11示出。在下面各段中单独描述的图代表 用于执行的替换路径的3种情况。
图41示出处理来自客户机22/16的从内部通信网络14到来的消息 所需要的消息收发，该客户机不需要包含有意义数据的响应[Command- NotReponse]，而包含发送到来消息的成功或失败原因的响应(API ID ＝1，Op码＝1的ACK或NAK)。
图42示出处理来自客户机22/16的从WIDE总线14到来的消息所 需要的消息收发，该客户机需要多个包含有意义数据的响应消息 [Commmand-MultipleResponseRequired]以及发送到来消息的成功或失 败原因的响应(API ID＝1，Op码＝1的ACK或NAK)。
图43示出处理来自客户机22/16的从内部通信网络14到来的消息 所需要的消息收发，该客户机需要一个包含有意义数据的响应消息 [Commmand-SingleResponseRequired]以及发送到来消息的成功或失败 原因的响应(API ID＝1，Op码＝1的ACK或NAK)。
分类控制
是用新的控制装置来控制电器的典型现有技术方法是使该新控制装 置的软件部件复制电器控制器的逻辑，使得新的控制装置不会疏忽地请 求电器控制器的软件部件执行不能进行的操作。该现有技术方法还需要 电器和新控制装置之间涉及电器的当前状态的通信。该现有技术方法是 低效的，因为它要求复制新控制和装置和电器控制器上的逻辑。此外， 该现有技术方法要求每次将电器控制器引入新的控制装置中时都必须写 入新软件。
控制分类的目的是要避免要求复制控制装置和受控电器中的两个交 互软件部件之间的软件逻辑(通常称为业务逻辑)。具体地说，这允许 控制装置中的命令发生器很容易控制电器而除了控制分类本身之外不需 要任何关于正在受到控制的电器的信息。这可以实现“通用”控制装置的 引入以控制新的电器，将控制装置适用于新提供的循环或加入电器中的 功能，并让电器在提供不同的运行循环或功能的运行模式之间切换。还 控制电器更容易让用户使用，因为只需要向用户展现当前可由该电器提 供的选择。
本发明使用结构化的分类数据集来有效地告知控制装置控制装置所 需要的信息，以便为电器产生格式良好的(well formed)命令。在此使 用的格式良好的命令是有意义而且可由电器执行的命令。数据集传送的 信息包括执行该格式良好的命令所需要的选项和数据输入的分层结构。 在优选实施例中，还包括语义或上下文信息，用于以文字或图标的形式 通报可获得的选项，从而用户可以理解可获得的选择并输入合适的数 据。这优选通过与任意或非用户友好的标识元素关联的数据集内的标记 来完成。这使得必须解释和处理分类的软件部件的逻辑与分类在用户接 口上的呈现分离(如外语，标签，单位)。
参照图44，其概括性地示出本发明的改进的控制结构和方法，受控 的电器12具有软件部件2 16B，该软件部件包括电器控制器和状态发生 器。用于控制电器的控制装置16、22具有软件部件1 16B，该软件部件 包括命令发生器、选择创建器和状态解释器。控制装置16、22可以是 可编程用户接口如pda、web写字板、小区电话、连接到电器或客户机 装置的LCD。
设置在电器控制器16和逻辑中的分类体系可替换的设置在远程位 置，如设置在控制装置或互联网上。分类体系包括分类发生器、分类引 擎、分类翻译器和分类结构。分类体系产生定义分类能力的分类数据 集，其有助于：通过软件部件1产生格式良好的命令，该命令可以通过 分类引擎和可选的通过分类翻译器转换为由软件部件2执行的其他格式 良好的命令；通过软件部件1产生用户接口内容；在呈现给用户接口之 前验证状态信息。每个部件及其相互关系都在下面详细描述。
分类数据集的产生
分类数据集从电器控制器16的运行功能中产生，该电器控制器16 按照允许软件部件1中的命令发生器解释该数据集以完成几种结果的方 式构成。具体地说，分类引擎有时使用分类结构和状态察觉信息来产生 反映可由电器提供给当前可由电器获得的命令的统一选项的子集的分类 数据集。
例如，分类数据集描述由软件部件16B支持的可获得函数，每个函 数变量，以及数据结构中每个变量的有效值。此外，分类数据集定义反 馈变量的有效值。由于这在数据结构中，因此它可以按照需要发送和重 新发送给客户机16或22。由于运行循环发展和可获得的命令或者该命 令的变量的有效值改变，分类数据集发生改变。此外，当运行循环从 Idle(空闲)开始发展时，额外的命令可以提供出来或者变得无效。
具体地说，选择创建器注册分类管理器以接收给予新分类引擎的通 知。为了响应，分类管理器将对所有已知分类引擎的引用发回选择创建 器。然后选择创建器从每个分类引擎请求分类功能数据集。分类引擎评 估包括软件部件2的控制器逻辑分类结构或可替换地评估用于产生分类 功能数据集的文档。然后选择创建器配备适用于应用结束点(应用结束 点的示例是用于控制或维护或其他中间应用层如能量控制器或家庭自动 化模式如休假或晚安的用户接口)的一组伪命令结构，这些命令是选项 的分层结构，并且将这些结构传递给应用结束点，从而允许应用结束点 得到配置。替换的，选择创建器可以直接配置应用结束点。
数据集的通信和使用
当控制装置与电器联网时，分类管理器在软件部件1和分类体系之 间建立关系，以允许命令发生器查询分类数据集是否存在，向软件体系 1提供对分类数据集的访问，并允许命令发生器和状态解释器定购分类 数据集更新。分类翻译器是可选的部件，如果软件部件1和2没有被设 计为与分类数据集的相同实施例共同使用，则分类翻译器就在软件部件 1和2之间翻译分类数据集。
将分类数据集传送给软件部件2的控制器以及软件部件1的选择创 建器。可选的，分类翻译器将分类数据集翻译为命令发生器的不同的示 意定义。
命令发生器使用分类数据集来建立和填充一组可由用户接口或其它 客户机应用选择的命令结构，包括一组有效命令、该命令的有效变量、 每个变量的有效值。具体地说，命令发生器使用分类数据集建立一个或 多个格式良好的命令，然后可以将该命令发送给控制器。由于分类数据 集可以在不同的时刻由分类引擎复位并发送，或者该数据集可以通过来 自分类引擎的修改而更新，因此软件部件1可以具有当前的命令结构 组，然后该命令结构组可由用户接口或其他客户机应用选择。
由此实际上通过采用分类体系，软件部件2或其代理(分类引擎) 向软件部件1通报可以由软件部件1解释的规则集，从而软件部件1不 请求软件部件2的其自身无法供给的东西，并且不对设置为无效值的状 态变量进行操作。
在应用结束点可以开始执行之前，应用结束点用状态解释器请求或 注册状态更新。这将使得在执行逻辑之前以及在用户接口部件交付之 前，应用结束点可以具有来自状态发生器的有效状态变量。状态解释器 将处理分类正确的状态数据集，并根据分类功能数据集验证这些数据 集。状态解释器通过分类引擎请求或注册来自软件部件2的状态发生器 的状态更新。在接收到分类正确的状态时，状态解释器向应用结束点提 供新的状态值。
应用结束点执行，从而导致软件部件2的当前状态的提交以及可选 择的伪命令结构的提交。每次从伪命令结构中选择时，选择创建器都填 充在分类功能数据集中找到的一组有效的子命令，这组子命令适用于由 应用结束点进一步选择。在结束选择时，包含所有伪命令的结构被传递 给命令发生器。
命令发生器建立分类正确的格式良好的命令并且可选地通过分类翻 译器，通过分类引擎在软件部件2的控制器上调用该命令。
执行
将格式良好的命令传送给电器的控制器并由电器执行。
典型的，该命令将导致软件部件2的有关存储器发生状态变化，该 状态变化会触发由状态发生器创建的状态更新，并导致应用结束点的新 的状态提交。状态的变化导致新的功能分类或者可以替代原始功能分类 的一部分的部分功能分类。新的功能分类导致一组不同的有效选择用于 控制软件部件2的运行循环。
验证
状态解释器使用分类数据集从状态发生器验证由分类引擎或翻译器 发送的状态更新。此外，作为分类数据集的来源的分类结构，允许控制 器根据该结构完全验证到来的命令，而无需数据集之外的附加逻辑。例 如，分类结构可以在概念上认为是一个或多个判决树，分类的每一级形 成不同的判决分支或一组判决分支，每个选项和/或数据输入可以形成不 同的级别。电器的运行循环要求用户在形成格式良好的命令时选择该选 项和/或数据输入。这些选择可以与判决树相比较以确认每个循环、循环 属性或循环选项都在判决树的合适分支内。如果期望的运行循环、属性 和选项没有在该命令中，则表明该命令含有错误。分类结构由此用于向 用户接口填充可用的、针对电器的给定状态的选项和数据输入，而且也 用作验证所产生的命令的逻辑。
分类数据集是作为对象或软件结构的分类结构的数据代表。分类数 据集包含所有针对电器当前状态的可用的命令、选项和设置，以及当前 状态时的所有有效状态值。例如，电器包括通过内部网络互连的多个部 件。每个部件可以具有一个或多个装置。每个装置具有一个或多个功 能，每个功能具有一个或多个设置。所有装置的所有功能都不必在电器 的每个状态时可用。这样，分类数据集包括针对当前可用的所有装置的 所有选项和数据输入。
图45-48示出在微波炉的用户接口16、22的环境中的分类控制的 示例，该分类控制具有表明电器12当前状态下可用的功能的分类数据 集。用户可以从该数据集的参数中选择以形成格式良好的命令，该命令 将被发布以用于控制电器12的操作。
图45示出选项和数据输入的可用分层结构。该分层结构的顶级从 循环100开始，其示出具有煮、解冻、煮马铃薯、蒸煮、自动重新加热 和餐盘作为示例。用户必须从顶级中选择一个选项。
一旦用户从顶级中进行了选择，该分层结构的基于顶级选择的下一 级就呈献给用户。在图46中，用户选择了“煮”选项，用户接口然后以 时间102和功率电平104的形式显示可用于该选项而且是形成格式良好 的命令所需要的数据输入。
图47示出顶级的选择暴露了子集的选项。在图47中，选择解冻， 这呈现出子集类型“肉”106.用户必须选择合适的肉选项来完成格式良好 的命令。数据输入以重量108和解冻电平110的形式呈现，而且必须选 择以完成格式良好的命令。
一旦用户从用户接口可访问的分类数据集中选择了这些选项和数据 输入，命令发生器就形成格式良好的命令并发送给电器的部件上的软件 部件2以便于实行。这仅在格式良好的命令经历了验证过程之后才进 行。软件部件2的控制器和逻辑使用该格式良好的命令控制装置的操作 以实行该格式良好的命令。
分类数据集和格式良好命令的创建证明是有用的。图45的微波炉 的公开了多个烹饪循环的分类数据集的创建是由选择创建器根据分类功 能数据集建立的，该分类功能数据集用XML显示如下：
|
|
|
etc
如果图45的微波炉的用户选择用“转盘打开”在90％功率时“煮”30 秒，分类计划的格式良好命令将可选地传送给分类翻译器和分类。命令 形式为：
分类引擎接着穿越分类结构以便将分类计划的格式良好命令转换为 分组结构28的软件部件2的控制器的格式良好命令。分类结构是分类 功能数据集的超集。对于上述每个可指明的命令要素(即，循环，功 率，持续时间和转盘)，都在分类结构内关联形成有效载荷28A所需要 的附加的关键字和值的集合。这些关键字包括API Id，Op码，以及有 效载荷28A中的位置索引，其中位置索引可以是字节偏移量或位偏移 量。
分类数据集可以建立为直接代表软件体系10的API的可能命令领 域，从而为维修、工厂或实验室工程师或技师提供有用功能。
虽然结合具体的实施例描述了本发明，可以理解这只是举例而不是 限制，所附权利要求的范围应当与现有技术允许的范围一样宽。
相关申请的交叉引用
本申请要求2005年6月9日提交的美国专利申请60/595148的优先 权，在此通过引用合并该申请的公开内容。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 寻呼方法和设备 | 2020-05-14 | 432 |
| 内存读取/写入仲裁方法 | 2020-05-13 | 987 |
| 从第一装置到至少一个第二装置在以太网内传输可预先确定优先分类级的数据包的方法 | 2020-05-15 | 437 |
| 内存读取/写入仲裁方法 | 2020-05-12 | 316 |
| 独立处理多个指令流、软式控制各指令流的处理功能的多程序流程同时处理器 | 2020-05-11 | 812 |
| 在多个无线电话系统中公用的频率 | 2020-05-12 | 464 |
| 具优先权的随机存取方法、资源配置方法及碰撞解决方法 | 2020-05-13 | 991 |
| 从第一装置到至少一个第二装置在以太网内传输可预先确定优先分类级的数据包的方法 | 2020-05-15 | 221 |
| 一种关于财务云平台的成对组合测试用例生成方法 | 2020-05-13 | 837 |
| 无线接入网络系统、及无线接入方法 | 2020-05-11 | 494 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈