一种通知事件的路由方法和半导体工艺设备与流程

1.本发明涉及半导体装备技术领域，特别是涉及一种通知事件的路由方法和半导体工艺设备。


背景技术：

2.随着信息技术的不断发展，集合多个界面的系统在多个领域得到广泛应用。对于系统中不同界面之间事件的传递，目前通常是将事件处理机制独立出来，形成事件处理的注册和收发模块，当模块需要监听事件时注册事件并处理，其它模块发送消息后，注册事件的模块会收到该消息，从而实现事件的处理。这种事件消息机制是基于容器实现的一种通用消息机制，可以实现消息的注册、发送与接收。
3.但是，这种方案无法灵活控制通知事件的传播和处理过程，而且，消息通知事件在接收消息的数据承载容器里的接收顺序也是无序的，即会导致紧邻的父页面没有更新数据，而其它关系不密切的页面先更新数据显示。


技术实现要素：

4.本发明实施例所要解决的技术问题是目前无法高效管理通知事件的传播及处理。
5.为了解决上述问题，本发明实施例公开了一种通知事件的路由方法，所述方法包括：
6.通过n级数据承载容器监测目标系统中变量的变量状态，所述n为大于1的整数；
7.在检测到所述变量状态满足预设条件的情况下，触发通知事件；
8.将所述通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理所述通知事件；所述n-1级数据承载容器对应至少一个n级数据承载容器；
9.在所述n-1级数据承载容器完成对所述通知事件的处理的情况下，将所述通知事件逐级传递至一级数据承载容器；
10.通过所述一级数据承载容器对每个所述数据承载容器广播所述通知事件。
11.本发明实施例公开了一种半导体工艺设备，半导体工艺设备还包括：
12.控制器，用于通过n级数据承载容器监测目标系统中变量的变量状态，所述n为大于1的整数；
13.在检测到所述变量状态满足预设条件的情况下，触发通知事件；
14.将所述通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理所述通知事件；所述n-1级数据承载容器对应至少一个n级数据承载容器；
15.在所述n-1级数据承载容器完成对所述通知事件的处理的情况下，将所述通知事件逐级传递至一级数据承载容器；
16.通过所述一级数据承载容器对每个所述数据承载容器广播所述通知事件。
17.根据本发明的实施例，通过n级数据承载容器监测目标系统中变量的变量状态，在检测到变量状态满足预设条件的情况下，触发通知事件，将通知事件传递至n-1级数据承载
容器，由n-1级数据承载容器处理通知事件；n-1级数据承载容器对应至少一个n级数据承载容器。这里，n-1级数据承载容器可以统一的处理至少一个n级数据承载容器传递来的通知事件，减少了代码重复率，降低系统中不同页面的耦合度。在n-1级数据承载容器完成对通知事件的处理的情况下，将通知事件逐级传递至一级数据承载容器；通过一级数据承载容器对每个数据承载容器广播通知事件，可以快速高效地将通知事件传达至对全系统的数据承载容器。
附图说明
18.图1示出了本实施例提供的一种数据容器的结构示意图；
19.图2示出了本实施例提供的一种兄弟关系的通知事件传递示意图；
20.图3示出了本实施例提供的一种父子关系的通知事件传递示意图；
21.图4示出了本实施例提供的一种基于数据承载容器的事件机制示意图；
22.图5示出了本实施例提供的一种通知事件的路由方法的流程图；
23.图6示出了本实施例提供的一种通知事件的处理流程示意图；
24.图7示出了本实施例提供的一种通知事件的传递流程示意图；
25.图8示出了本实施例提供的一种实现通知事件的路由方法的流程图；
26.图9示出了本实施例提供的一种半导体工艺设备结构示意图。
具体实施方式
27.下面将详细描述本发明的各个方面的特征和示例性实施例，为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本发明进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本发明，并不被配置为限定本发明。对于本领域技术人员来说，本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明更好的理解。
28.需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
29.首先，对于本发明实施例涉及的技术术语进行介绍。
30.基于windows的用户界面框架(windows presentation foundation，wpf)，它提供了统一的编程模型、语言和框架，为用户界面、2维/3维图形、文档和媒体提供了一致的描述和操作方法。
31.下面对路由事件(route event)进行说明，wpf以可扩展应用程序标记语言(extensible application markup language，xaml)文件的方式将用户界面(user interface，ui)元素以树状结构组合到一起，形成的ui元素树构建起整体界面。ui元素之间
通过事件的方式相互之间传递消息，以实现ui元素的渲染。wpf有两种事件模型：一种是公共语言运行库(common language runtime，clr)事件，另一种是wpf时代的路由事件。其中，路由事件(route event)是wpf下特有的消息传递机制。
32.一方面，传统的clr事件机制中，事件发起者与接收者是紧密关联，不容易解耦。如果利用事件传递消息，必须分级定义事件逐级嵌套传递，比较繁琐，也不容易管理。另一方面，路由事件机制中，路由事件是一种可以针对元素树中的多个侦听器(而不是仅针对引发该事件的对象)调用处理程序的事件。常用的路由策略是冒泡(bubble)路由策略，从事件触发位置沿ui元素树向父元素传播，每个元素均可对接收到的事件进行处理。
33.路由事件机制解决了crl事件机制的发起者与接收者是紧密关联的问题和消息传递过程中冗余的事件嵌套问题。同时，路由事件还有其它优势：
34.能够记录路由事件从触发点到事件处理节点的路由顺序，能够实现事件传播追踪功能；而且，能够灵活控制消息传播过程，当事件被某ui元素节点处理后，该节点可决定事件是否继续传播并由其它节点是否继续处理。当然，无论是crl事件机制还是路由事件机制，事件机制与ui元素节点关系紧密，也导致ui元素上的事件处理的业务逻辑存在耦合度高的问题，为了实现ui界面与业务逻辑解耦，引入了mvvm(model-view-viewmodel)设计模式。
35.下面对mvvm进行说明，mvvm是微软wpf技术下的产物，它是由mvp(model-view-presenter)模式与wpf结合后演变过来的一种新型架构框架。mvvm将页面渲染容器(view)中的状态和行为抽象化，将界面ui与业务逻辑分开，从而实现了基于数据驱动的架构理念。
36.mvvm模式结构如图2所示，其中，页面渲染容器(view)，用于渲染ui控件元素界面，对应文件类型为xaml，提供元素布局，用于数据渲染。
37.其中，数据承载容器(viewmodel)，负责数据逻辑加载，view与viewmodel通过数据绑定(databinding)机制对页面元素与viewmodel公开属性进行直接绑定，view属性变化直接传到到viewmodel，viewmodel变量自身变化通过属性通知(property notification)来确定view的数据变化，更新ui元素，从而实现数据的双向绑定。
38.view中事件通过wpf的命令绑定(commandbinding)机制转化为viewmodel中继承指令(icommand)接口的公开属性对象，将view事件业务逻辑转移到viewmodel中实现事件逻辑与ui分离。实现底层业务逻辑的过程中，由viewmodel直接调用。
39.下面说明ui组件间事件消息传递与订阅，当采用mvvm设计模式实现ui系统时，需要实现多个view组合关系的消息传递，以便消息可以在各个view或者子页面渲染容器(subview)中进行传播，以实现不同ui区域的控件元素渲染。
40.有两种场景的视图组合，需要实现view间事件消息传递：
41.一种，多视图view组合，组合形成系统功能页面，如图2所示，示出了兄弟组合页面消息的通知事件消息间传递的过程。另一种，子视图与父视图的通知事件消息间传递的过程，如图3所示，示出了父子组合页面消息。
42.本发明实施例提供的通知事件的路由方法至少可以应用于下述应用场景中，下面进行说明。
43.为了实现ui界面与业务逻辑的完全分离，采用mvvm设计模式来实现数据驱动机制，通过数据变化激活viewmodel层事件处理，其它view的viewmodel通过订阅事件的方式
实现通知消息在viewmodel层传播，进而更改每个view的可视元素的显示更新。目前的技术方案通常是将事件处理机制独立出来，形成事件处理的注册和收发模块，使得事件处理模块与其它模块解耦，当模块需要监听事件时注册事件处理，其它模块发送消息后，注册事件的模块会收到该消息，从而实现事件的处理。这种事件消息机制是基于容器(通过字典或哈希表实现)实现的一种通用消息机制，可以实现基于viewmodel的消息注册，发送与接收。在mvvm设计模式下，通过数据变化驱动事件的触发过程，通知事件在注册事件的viewmodel集合内进行传播，收到消息的viewmodel检查是否存在该事件的处理，如果存在激活自身处理函数，处理事件。
44.目前的技术方案中的事件的注册处理机制，具体包括：接收注册消息；基于接收的实体、消息令牌和消息类型等信息注册消息；判断字典是否存在该消息类型；若是，则基于该消息类型，查找消息处理队列，并获取该队列；若否，则基于该消息类型创建消息处理队列，并获取该队列；最后，将该消息接收者的实例，消息令牌，消息处理函数保存到该消息类型的处理队列中，消息注册存储于字典或哈希表。
45.目前的技术方案中的事件的发送以及接收处理机制，具体包括：发送消息；基于消息类型或者消息目标接收者类型发送消息；检查注册存储中是否存在该消息类型；若是，则获取该类型消息处理队列；若否，则结束；然后，从处理队列中检查是否需要判断直接接收消息的接收者类型；若是，则基于接受者类型获取消息处理队列以及执行消息处理；若否，则获取该消息类型对应的所有消息处理函数以及执行消息处理。
46.由此，目前的技术方案，首先，不能实现消息在视图树中传播和处理过程的灵活控制；其次，不能获取消息发送过程消息路由节点路径信息；最后，消息通知事件在接收消息的viewmodel容器里的接收顺序也是无序的，可能导致其它页面先得到消息，而紧邻相关页面后得到消息。某些场景会导致消息传递的延迟，引起紧邻的父页面没有更新数据，而其它关系不密切的页面先更新数据显示。
47.基于上述应用场景，结合图4，首先对本发明实施例提供的基于路由策略的viewmodel事件机制进行说明，通过将view和子视图的嵌套关系完全映射到了viewmodel与子viewmodel的嵌套关系，通过数据驱动机制，在数据变化的情况下，viewmodel1.1.1激活通知事件，同时viewmodel1.1.1决定是否处理，并决定是否向viewmodel1.1传播，通知事件沿着viewmodel树向上传播，同时系统记录通知事件途径的路由节点。
48.这里，基于mvvm设计模式，view与viewmodel存在一一对应的关系，view通过组合嵌套的方式最终形成用户界面，wpf技术的路由消息事件采用冒泡路由策略，即通过view1.1.1(如图4所示)触发事件，向父view1.1传播(甚至更高父视图层级传播)，更高父级接收到消息事件后，确定自己视图是否需要响应该消息事件，以便重新渲染自己界面内的其它界面元素，依次像冒泡一样向更高节点传播。
49.由此，基于wpf的路由消息机制实现原理，将view对应的viewmodel也通过组合的设计理念，将viewmodel形成树状结构，这样可以将wpf的路由消息事件的冒泡路由策略移植到viewmodel数据层，进而实现消息事件在viewmodel下的传播，从而实现业务逻辑与ui的分离。
50.基于上述应用场景，下面对本发明实施例提供的通知事件的路由方法进行详细说明。
51.图5为本发明实施例提供的一种通知事件的路由方法的流程图。
52.如图5所示，该通知事件的路由方法可以包括步骤510-步骤550，该方法应用于数据处理装置，具体如下所示：
53.步骤510，通过n级数据承载容器监测目标系统中变量的变量状态，n为大于1的整数。
54.步骤520，在检测到变量状态满足预设条件的情况下，触发通知事件。
55.步骤530，将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件；n-1级数据承载容器对应至少一个n级数据承载容器。
56.步骤540，在n-1级数据承载容器完成对通知事件的处理的情况下，将通知事件逐级传递至一级数据承载容器。
57.步骤550，通过一级数据承载容器对每个数据承载容器广播通知事件。
58.本发明提供的通知事件的路由方法中，通过n级数据承载容器监测目标系统中变量的变量状态，在检测到变量状态满足预设条件的情况下，触发通知事件，将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件；n-1级数据承载容器对应至少一个n级数据承载容器。这里，n-1级数据承载容器可以统一的处理至少一个n级数据承载容器传递来的通知事件，减少了代码重复率，降低系统中不同页面的耦合度。在n-1级数据承载容器完成对通知事件的处理的情况下，将通知事件逐级传递至一级数据承载容器；通过一级数据承载容器对每个数据承载容器广播通知事件，可以快速高效地将通知事件传达至对全系统的数据承载容器。
59.下面，对步骤510-步骤550的内容分别进行描述：
60.涉及步骤510。
61.步骤510，通过n级数据承载容器监测目标系统中变量的变量状态，n为大于1的整数。
62.n级数据承载容器为目标系统中的子数据承载容器，n为大于1的整数，即n为2、3，
……
，等。n级数据承载容器是n-1级数据承载容器的父级，n-1级数据承载容器是n级数据承载容器的子级。
63.在一种可能的实施例中，在步骤510之前，方法还包括：
64.构建目标系统中对于通知事件的路由机制。
65.构件路由事件机制的过程是基于路由策略在父viewmodel创建子viewmodel过程中完成的。
66.通知事件的路由机制，即通知事件的发送与接收处理主要包括两个方面：一方面，冒泡策略的消息传递和事件接收处理；另一方面，在viewmodel树root节点进行通知事件的广播，使消息在整棵树中的节点传播，并允许每个节点做出响应。
67.其中，上述涉及到的构建目标系统中对于通知事件的路由机制的步骤中，具体可以包括以下步骤：
68.对应于用户界面中的一级视图层至n级视图层的视图层结构，依次创建由一级数据承载容器至n级数据承载容器的各级数据承载容器，一级数据承载容器至n-1级数据承载容器中的各级数据承载容器对应至少一个下一级数据承载容器；
69.使各级数据承载容器订阅下一级数据承载容器传递的通知事件，形成通知事件的
路由机制。
70.对应于用户界面中的一级视图层至n级视图层的视图层结构，依次创建由一级数据承载容器至n级数据承载容器的各级数据承载容器，创建通知事件路由，父viewmodel(n-1级数据承载容器)创建子viewmodel(n级数据承载容器)，增加子viewmodel到父的viewmodels集合内，如此循环创建，直至完成路由通知事件机制设计，由此，一级数据承载容器至n-1级数据承载容器中的各级数据承载容器对应至少一个下一级数据承载容器。
71.使各级数据承载容器订阅下一级数据承载容器传递的通知事件，即父viewmodel订阅子viewmoel的传播通知的事件，形成通知事件的路由机制。由此，通过父子嵌套关联形成viewmodel树的创建循环，完成父节点订阅子节点消息通知事件，从而形成事件的冒泡策略。
72.涉及步骤520。
73.步骤520，在检测到变量状态满足预设条件的情况下，触发通知事件。
74.在一种可能的实施例中，在步骤520之后，还可以包括以下步骤：
75.判断n级数据承载容器是否需要处理通知事件；
76.若不需要，则执行将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件的步骤；
77.若需要，则由n级数据承载容器处理通知事件，并进一步判断是否需要将通知事件传递至n-1级数据承载容器，在需要时，执行将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件的步骤。
78.响应于检测到变量状态满足预设条件的情况下，触发通知事件，然后n级数据承载容器(子viewmodel)判断是否由自己执行处理通知事件。若子viewmodel确定不需要由自己执行处理，则执行将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件的步骤。如果子viewmodel确定需要由自己执行处理，则由子viewmodel执行处理通知事件，并进一步判断是否需要将通知事件传递至n-1级数据承载容器，在需要时，执行将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件的步骤。由此，可以实现对通知事件的处理过程的灵活控制。
79.其中，预设条件包括第一子预设条件，上述涉及到的由n级数据承载容器处理通知事件，并进一步判断是否需要将通知事件传递至n-1级数据承载容器，包括：
80.在变量状态满足第一子预设条件的情况下，n级数据承载容器确定需要将通知事件传递至n-1级数据承载容器；
81.在变量状态不满足第一子预设条件的情况下，n级数据承载容器确定不需要将通知事件传递至n-1级数据承载容器。
82.示例性地，在检测到变量状态满足预设条件的情况下，三级页面(n级数据承载容器)触发通知事件。然后，三级页面(n级数据承载容器)需要进一步判断是否需要将通知事件传递至n-1级数据承载容器，即在处理过程中通过判断变量状态来决定是否需要将通知事件传递至二级页面(n-1级数据承载容器)。由此，可以实现控制软件子页面随组件状态变量变化，来决定是否发送通知消息，以及是否要求上级页面联动进行ui渲染。
83.其中，变量为工艺参数，变量状态为参数值，预设条件为参数值在预设参数区间内。预设参数区间包括区间上限和区间下限，上述涉及到的由n级数据承载容器处理通知事
件，并进一步判断是否需要将通知事件传递至n-1级数据承载容器的步骤中，分别具体可以包括以下步骤：
84.在参数值小于区间下限的情况下，n级数据承载容器确定需要将通知事件传递至n-1级数据承载容器；在参数值不小于区间下限的情况下，n级数据承载容器确定不需要将通知事件传递至n-1级数据承载容器；或者，
85.在参数值大于区间上限的情况下，n级数据承载容器确定需要将通知事件传递至n-1级数据承载容器；在参数值不大于区间上限的情况下，n级数据承载容器确定不需要将通知事件传递至n-1级数据承载容器；或者，
86.在参数值的变化量大于预设变化阈值的情况下，n级数据承载容器确定需要将通知事件传递至n-1级数据承载容器；在参数值的变化量不大于预设变化阈值，n级数据承载容器确定不需要将通知事件传递至n-1级数据承载容器。
87.示例性地，目标系统可以用于记录工艺腔室晶圆的温度参数，即变量为温度参数，变量状态为温度值，当温度值达到阈值后，抛出消息通知，以提示用户警示。其中，阈值分为警告阈值和错误阈值，警告阈值用户只需要知晓，不需要检查设备；错误阈值需要用户检查设备。
88.如图7所示：现在假设三级页面负责记录温度值，当达到预警值抛出消息。该三级页面的二级页面(含有列表控件)来存放通知消息。如果温度值达到大于预警阈值，三级页面只保存通知消息，该通知消息不需要向上给主页面发送通知；如果温度值大于错误阈值，三级页面保存消息的同时，向上一级数据承载容器发送通知，以便上一级数据承载容器接收消息，并进行处理。
89.涉及步骤530。
90.步骤530，将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件；n-1级数据承载容器对应至少一个n级数据承载容器。
91.父viewmodel将自己作为子viewmodel向其父viewmodel进行传播并进行处理。
92.示例性地，目标系统，如控制系统通常页面采用三级导航模式，从底层两个页面(第三级页面)触发通知事件“消息1”，触发通知事件的页面不做处理，由二级页面统一进行消息处理，同时处理完毕把消息传递到根页面，当消息通知到达根页面(一级数据承载容器对应的页面)后，消息可以采用广播方式对其它页面进行广播，如图6所示：
[0093]“消息1”从两个三级页面触发，三级页面不需要接收并处理消息，抛送消息到二级页面，二级页面使用统一的处理函数接收“消息1”，消息处理函数不需要分布在触发消息的页面进行单独处理，从而减少代码重复率，同时也使消息发送和消息处理从页面级别解耦。
[0094]
需要说明的是，由于view树与viewmodel树是一一对应的关系，本文中使用页面级的view树解释数据级的viewmodel树的消息传递过程，以便更容易理解消息传递过程。
[0095]
这里，两个第三级页面发出相同消息，消息由父级(第二级页面)接收并处理，只需要一个处理过程。实现了更加灵活的ui通知事件传播与事件处理的控制机制。
[0096]
由此，避免事件触发源与处理过程的耦合性，消息可路由到父级，由父级(n-1级数据承载容器)统一负责处理，降低消息处理逻辑代码的重复和分散的问题，提升代码质量。
[0097]
涉及步骤540。
[0098]
步骤540，在n-1级数据承载容器完成对通知事件的处理的情况下，将通知事件逐
级传递至一级数据承载容器。
[0099]
在一种可能的实施例中，步骤540，具体可以包括以下步骤：
[0100]
n级数据承载容器和一级数据承载容器之间的各级数据承载容器依次判断是否需要向上一级数据承载容器传递通知事件，在需要时，才向上一级数据承载容器传递通知事件。
[0101]
示例性地，三级页面发出消息，二级页面(各级数据承载容器)接收到该消息并进行处理，在处理过程中通过判断周边环境变量决定是否将该消息继续向第一级页面(各级数据承载容器的上一级数据承载容器)传播。传播与否完全依据周边当前目标系统的环境参数来动态决定。可以实现控制软件子页面随组件状态变量变化，来决定是否发送通知消息，以及是否要求上级页面联动进行ui渲染。
[0102]
其中，预设条件包括第二子预设条件，上述涉及到的n级数据承载容器至一级数据承载容器中的各级数据承载容器依次判断是否需要向上一级数据承载容器传递通知事件，包括：
[0103]
在变量状态满足第二子预设条件的情况下，各级数据承载容器确定需要向上一级数据承载容器传递通知事件；
[0104]
在变量状态不满足第二子预设条件的情况下，各级数据承载容器确定不需要向上一级数据承载容器传递通知事件。
[0105]
其中，变量为工艺参数，变量状态为参数值，预设条件为参数值在预设参数区间内，预设参数区间包括区间上限和区间下限，上述涉及到的n级数据承载容器和一级数据承载容器之间的各级数据承载容器依次判断是否需要向上一级数据承载容器传递通知事件，在需要时，才向上一级数据承载容器传递通知事件的步骤中，分别具体可以包括以下步骤：
[0106]
在参数值小于区间下限的情况下，各级数据承载容器向上一级数据承载容器传递通知事件；或者，
[0107]
在参数值大于区间上限的情况下，各级数据承载容器向上一级数据承载容器传递通知事件；或者，
[0108]
在参数值的变化量大于预设变化阈值的情况下，各级数据承载容器向上一级数据承载容器传递通知事件。
[0109]
示例性地，目标系统可以用于记录工艺腔室晶圆的加工累计数量，即变量状态为晶圆数量，当数量达到阈值后，抛出消息通知，以提示用户警示或者更换拥有使用寿命的硬件。其中，阈值分为警告阈值和错误阈值，警告阈值用户只需要知晓，不需要更换硬件；错误阈值需要用户更换硬件。
[0110]
如图7所示：现在假设三级页面负责记录晶圆加工累计值，当达到预警值抛出消息。该三级页面的二级页面(含有列表控件)来存放通知消息。如果晶圆累计值大于预警阈值，二级页面只保存通知消息，该通知消息不需要向上给主页面发送通知；如果晶圆累计值大于错误阈值，二级页面保存消息的同时，向一级数据承载容器发送通知，以便一级数据承载容器接收消息，并在一级数据承载容器对应的主页面中的醒目位置提示用户。
[0111]
由此，通过各级数据承载容器依次判断是否需要向上一级数据承载容器传递通知事件，在需要时才向上一级数据承载容器传递通知事件，可灵活动态地控制消息是否向上传播，避免无用消息群发时导致的资源损耗。
[0112]
其中，步骤540，具体可以包括以下步骤：
[0113]
响应于检测到通知事件被传递，记录通知事件被逐级传递至一级数据承载容器的传递路径。
[0114]
具体地，如果从最内部viewmodel触发导航消息事件，那么该消息会从触发的viewmodel传递到更上层viewmodel，最终到达根节点viewmodel。由于viewmodel与view存在对应关系，因此可以获取在view(n级数据承载容器)到根view(一级数据承载容器)的完整传递路径，从而通过viewmodel在数据层实现子页面到父页面的传递路径的记录。基于消息路由机制，可以通过n级数据承载容器对应的子视图发送导航通知消息动态获得从子视图到父视图的完整路径，无需长期占用系统资源。
[0115]
由此，通过响应于检测到通知事件被传递，记录通知事件被逐级传递至一级数据承载容器的传递路径，简化了导航功能的实现逻辑，随着通知事件的传递就可以自动记录下通知事件被逐级传递至一级数据承载容器的传递路径，减少每个导航节点(每个级别的数据承载容器)存储全导航路径占用的内存，节省系统资源。
[0116]
涉及步骤550。
[0117]
步骤550，通过一级数据承载容器对每个数据承载容器广播通知事件。
[0118]
在一种可能的实施例中，步骤550，具体可以包括以下步骤：
[0119]
根据传递路径，确定一级数据承载容器至n级数据承载容器中的各级数据承载容器是否需要处理通知事件，在需要时，各级数据承载容器才处理通知事件。
[0120]
其中，在通过一级数据承载容器对每个数据承载容器广播通知事件的过程中，可以根据传递路径，确定二级数据承载容器和n级数据承载容器之间的至少一个数据承载容器是否要处理通知事件。
[0121]
其中，上述涉及到的根据传递路径，确定一级数据承载容器和n级数据承载容器和之间的各级数据承载容器是否需要处理通知事件的步骤中，具体可以包括以下步骤：
[0122]
对于任一数据承载容器，若该数据承载容器在传递路径中，则不需要处理通知事件；若该数据承载容器不在传播路径中，则需要处理通知事件。
[0123]
对于任一数据承载容器，若该数据承载容器在传递路径中，说明某个节点viewmodel(该数据承载容器)是前期通知事件向根viewmodel传播的途径节点，即如果某个节点viewmodel是前期传递路径中承担传递步骤的任一数据承载容器，那么该viewmodel将不进行事件处理，只向下传播通知事件到子viewmodel，直到广播到每一个子viewmodel，则完成通知事件的广播过程。
[0124]
对于任一数据承载容器，若该数据承载容器不在传递路径中，说明该数据承载容器不是前期通知事件向根viewmodel传播的途径节点，则需要处理通知事件。即如果某个节点viewmodel没有在前期传递路径中承担传递步骤，则该数据承载容器可以选择处理通知事件。
[0125]
综上，在本发明实施例中，通过n级数据承载容器监测目标系统中变量的变量状态，在检测到变量状态满足预设条件的情况下，触发通知事件，将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件；n-1级数据承载容器对应至少一个n级数据承载容器。这里，n-1级数据承载容器可以统一的处理至少一个n级数据承载容器传递来的通知事件，减少了代码重复率，降低系统中不同页面的耦合度。在n-1级数据承载容器完
成对通知事件的处理的情况下，将通知事件逐级传递至一级数据承载容器；通过一级数据承载容器对每个数据承载容器广播通知事件，可以快速高效地将通知事件传达至对全系统的数据承载容器。
[0126]
基于上述图5所示的通知事件的路由方法，本发明还提供了一种实现通知事件的路由方法，图8为本发明实施例提供的一种实现通知事件的路由方法的流程图。
[0127]
其中，详细的通知发送与接收过程如图8所示：
[0128]
步骤810，子viewmodel根据数据变化激活通知事件。
[0129]
步骤820，子viewmodel判断是否自己执行处理过程，如果子viewmodel需要执行处理，则执行处理步骤830；否则执行步骤840。
[0130]
步骤830，子viewmodel执行事件处理，处理完毕后，确定是否继续向父viewmodel传播，如果“是”则执行步骤840。若否，则结束消息处理。
[0131]
步骤840，事件向父viewmodel传播，同时记录传播路由节点。
[0132]
步骤850，父viewmodel将自己作为子viewmodel向其父viewmodel进行传播并进行处理，重复步骤810至步骤840。
[0133]
步骤860，当通知事件传播到根节点viewmodel时，根节点能够发起广播通知事件命令(可选)。
[0134]
步骤870，通过广播方式对viewmodel中每一个节点进行事件广播。
[0135]
判断，通知事件是否是到达冒泡策略中通知事件传递的节点。若是，则执行步骤890；若否，则执行步骤880。
[0136]
步骤880，每个子viewmodel可以选择接收该事件，并进行相应处理。
[0137]
步骤890，如果某个节点viewmodel是前期通知事件向根viewmodel传播的途径节点，那么该viewmodel将不进行事件处理，只向下传播通知事件到子viewmodel。
[0138]
直到广播到每一个子viewmodel，则完成通知事件的广播过程。
[0139]
综上，在本发明实施例中，通过更加贴近wpf的类似消息路由事件的机制，满足半导体控制软件界面状态控制的复杂场景。首先，实现了消息通知传播和处理过程的控制灵活性，减少通知消息的触发源与处理过程的耦合性。消息可路由到父级，由父级统一负责处理，降低消息处理逻辑代码重复和分散问题。其次，解决了消息发送过程路由节点信息的获取问题，同时使得消息的传递按照路由顺序有序传播，避免了消息接受者的无序接收。最后，通过路由消息机制也实现了简化导航功能实现逻辑，减少导航节点存储全部导航路径占用内存的问题，节省了系统资源。由此，不仅完善半导体控制软件在wpf技术下实现ui界面的数据驱动架构，还更有效的集成mvvm设计模式与消息路由机制，提升事件消息处理的灵活性。
[0140]
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
[0141]
参照图9，示出了本发明实施例的一种半导体工艺设备的结构框图，该半导体工艺设备910，包括：
[0142]
控制器911，用于通过n级数据承载容器监测目标系统中变量的变量状态，n为大于1的整数；
[0143]
在变量状态满足预设条件的情况下，触发通知事件；
[0144]
将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件；n-1级数据承载容器对应至少一个n级数据承载容器；
[0145]
在n-1级数据承载容器完成对通知事件的处理的情况下，将通知事件逐级传递至一级数据承载容器；
[0146]
通过一级数据承载容器对每个数据承载容器广播通知事件。
[0147]
在本发明一个可选的实施例中，控制器，还用于：
[0148]
判断n级数据承载容器是否需要处理通知事件；
[0149]
若不需要，则执行将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件的步骤；
[0150]
若需要，则由n级数据承载容器处理通知事件，并进一步判断是否需要将通知事件传递至n-1级数据承载容器，在需要时，执行将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件的步骤。
[0151]
在本发明一个可选的实施例中，控制器，具体用于：
[0152]
n级数据承载容器和一级数据承载容器之间的各级数据承载容器依次判断是否需要向上一级数据承载容器传递通知事件，在需要时，才向上一级数据承载容器传递通知事件。
[0153]
在本发明一个可选的实施例中，控制器，具体用于：
[0154]
响应于检测到通知事件被传递，记录通知事件被逐级传递至一级数据承载容器的传递路径。
[0155]
在本发明一个可选的实施例中，控制器，具体用于：
[0156]
根据传递路径，确定一级数据承载容器至n级数据承载容器中的各级数据承载容器是否需要处理通知事件，在需要时，各级数据承载容器才处理通知事件。
[0157]
在本发明一个可选的实施例中，控制器，具体用于：
[0158]
对于任一数据承载容器，若该数据承载容器在传递路径中，则不需要处理通知事件；若该数据承载容器不在传播路径中，则需要处理通知事件。
[0159]
在本发明一个可选的实施例中，控制器，还用于：
[0160]
构建目标系统中对于通知事件的路由机制。
[0161]
在本发明一个可选的实施例中，控制器，具体用于：
[0162]
对应于用户界面中的一级视图层至n级视图层的视图层结构，依次创建由一级数据承载容器至n级数据承载容器的各级数据承载容器，一级数据承载容器至n-1级数据承载容器中的各级数据承载容器对应至少一个下一级数据承载容器；
[0163]
使各级数据承载容器订阅下一级数据承载容器传递的通知事件，形成通知事件的路由机制。
[0164]
在本发明一个可选的实施例中，控制器，具体用于：
[0165]
在变量状态满足第一子预设条件的情况下，n级数据承载容器确定需要将通知事件传递至n-1级数据承载容器；
[0166]
在变量状态不满足第一子预设条件的情况下，n级数据承载容器确定不需要将通知事件传递至n-1级数据承载容器。
[0167]
在本发明一个可选的实施例中，控制器，具体用于：
[0168]
在变量状态满足第二子预设条件的情况下，各级数据承载容器确定需要向上一级数据承载容器传递通知事件；
[0169]
在变量状态不满足第二子预设条件的情况下，各级数据承载容器确定不需要向上一级数据承载容器传递通知事件。
[0170]
其中，变量为工艺参数，变量状态为参数值，预设条件为参数值在预设参数区间内。
[0171]
综上，在本发明实施例中，通过n级数据承载容器监测目标系统中变量的变量状态，响应于检测到变量状态满足预设条件的情况下，触发通知事件，将通知事件传递至n-1级数据承载容器，由n-1级数据承载容器处理通知事件；n-1级数据承载容器对应至少一个n级数据承载容器。这里，n-1级数据承载容器可以统一的处理至少一个n级数据承载容器传递来的通知事件，减少了代码重复率，降低系统中不同页面的耦合度。在n-1级数据承载容器完成对通知事件的处理的情况下，将通知事件逐级传递至一级数据承载容器；通过一级数据承载容器对每个数据承载容器广播通知事件，可以快速高效地将通知事件传达至对全系统的数据承载容器。
[0172]
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0173]
本发明实施例还提供了一种电子设备，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述一种通知事件的路由方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
[0174]
本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现上述一种通知事件的路由方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
[0175]
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0176]
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
[0177]
本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0178]
本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设
备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0179]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0180]
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0181]
尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
[0182]
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
[0183]
以上对本发明所提供的一种通知事件的路由方法和一种半导体工艺设备，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。