用于提供用于工业车间的基于服务的控制应用的方法与流程
未命名
08-05
阅读:86
评论:0
1.本发明涉及一种用于提供用于工业车间的基于服务的控制应用的方法、该应用的用途、数据处理系统、计算机程序产品和计算机可读介质。
背景技术:
2.目前,用于工业车间的控制应用通常沿着物理过程拓扑或材料流来实现,并且它们被划分成代码块以适合专用硬件(例如plc)的性能,该专用硬件在工业车间上是内置的。这种划分是手动任务,而不管是否使用iec 61131语言来创建具有更精细的粒度自动化功能的单片代码或iec 61499。在任何情况下,专用控制硬件的使用允许高可靠性和短响应时间。然而,例如,当涉及硬件维护、固件和应用更新以及所需的内置硬件能力和可靠性时,该方法也具有缺点。
3.虽然对于一些基于云或基于边缘服务器的解决方案的数据驱动工业,例如作为服务的开放的、部分外部化的边缘计算环境(例如,多访问边缘计算mec,例如5g mec)已经变得更广泛地使用,但是在可靠性和响应时间方面的要求使得在控制工业车间的应用时难以转移到这样的技术。通常,大多数代码块可能包含对于非本地部署它们来说太关键的自动化逻辑。
4.因此,自动化工程师必须考虑到这些要求来决定专用控制硬件的控制代码是否应当在本地运行,并且当有疑问时,必须采取保守的方法。因此,云和边缘服务器能力的优点没有被完全利用。
5.本发明的目的是提供一种减轻至少一些上述缺点的方法。
技术实现要素:
6.该问题由独立权利要求的主题解决。优选实施例在从属权利要求中列出。
7.本发明提供了一种用于提供用于工业车间的基于服务的控制应用的计算机实现的方法。该方法包括将用于工业车间的初始控制代码自动分割成多个代码块,并且自动创建多个服务,每个服务实现多个代码块中的一个或多个代码块的功能。考虑到分配给多个代码块中的每个代码块的关键程度的相似性来执行多个服务的自动创建,使得具有更相似的关键程度的代码块更可能在同一服务内被实现。
8.换句话说,应用,特别是控制代码,可以基于用于相关过程的关键程度被划分或打包为度量(metric)。这允许以后基于最小的性能需求和成本而不是例如基于plc硬件或虚拟容器限制来部署应用。用于将初始代码分段并且将所得到的代码块分组为服务的度量的示例可以包括在正常操作、更新或故障切换期间的计算和通信开销等,这将在下面更详细地解释。
9.通过本公开的方法获得的控制应用可以被称为基于服务的控制应用。
10.本公开的服务还可以被称为毫微服务,并且创建服务可以被称为毫微封装。例如,这种毫微封装还允许代码的精细粒度更新。服务的粒度将取决于手头的初始控制代码,使
得人们可以将服务称为毫微服务(nano-service)或微服务(micro-service)。
11.初始控制代码和控制应用可以各自包括用于控制工业车间的设备的操作的功能,以及可选地,用于监测工厂的设备的操作条件和/或操作的功能。
12.本公开的控制应用例如可以是所创建的服务和一些附加代码的集合,例如胶合代码(glue code),如以下详细描述的。附加代码可以确保服务之间和/或服务内的正确通信。这将在下面更详细地解释。
13.因此,当从代码块创建服务时以及当基于服务创建控制应用时,可以对代码进行改变以确保服务内以及服务之间的代码块彼此间的兼容性和通信。因此,当一起查看整个控制应用和/或整个服务集时,这可能不对应于初始代码。这也在下面进一步详细讨论。
14.应当注意,分段初始控制代码可以以不同的方式执行。例如,初始控制代码可以被分解为非常小的片段,然后被分组回一起,或者它可以在几个步骤中被连续地分解,或者它可以在仅仅一个步骤中立即被带入期望的粒度。
15.此外,为了完整起见,应当注意,在自动创建多个服务的步骤中,除了考虑分配给多个代码块中的每个代码块的关键程度的相似性之外,还可以考虑附加标准,例如开销量等。
16.从上面可以看出,根据本公开,该方法可以将(甚至大的)控制应用分割成多个(优选地小部分)代码块,这些代码块仅具有间接依赖性,例如单个循环。代码块然后可以被分组部署为分布式异构计算环境上的(毫微)服务的部分,例如,包括一个或多个plc、本地边缘集群、5g mec服务提供、和云计划,即,大且多样的连接和计算生态系统。特别地,关于所需的性能水平,服务可以部署在正好适合的节点上。
17.因此,例如,可以分割初始控制应用,并且以以下方式表征这些片段,该方式允许获得具有以下部件的基于服务的控制应用,该部件以最低成本具有充足性能跨异构计算环境在节点上分布。
18.在自动分割初始控制代码中,本公开的方法可以将初始控制代码分割成彼此具有预定独立度的执行单元。独立度可以表示为受控过程中所需的执行qos(可靠性、可接受的故障切换时间)或依赖性/距离。
19.针对服务的分割和/或创建,一些指示符可以从代码(例如,单位、命名约定)和/或从dcs(例如,与信号限制相关的警报关键程度)和/或从工程数据导出。因此,通过集成或重新捕获工程数据并且暴露dcs对象,能够获得用于服务的分割和/或创建的数据。
20.为了完整起见,本公开的方法超出了当前可用标准提供的任何能力,包括但不限于iec 61131、iec 61499或用于模块化过程的vdi/vde/namur 2658。然而,这些标准仍然可以被利用,并且如下面将看到的,本方法也适用于模块化应用。
21.本公开的方法允许开放的、部分外部化的边缘计算环境作为被完全利用的服务(例如5g mec)。此外,使用例如docker/kubernetes的用于应用虚拟化的已知技术是可能的。此外,可以支持连续递送和永续车间,特别是具有应用的无缝更新。还可以改善可伸缩性。
22.在本公开中,执行如自动地分割和/或创建服务的步骤,利用可用数据,例如工程数据、元数据,例如涉及特定服务的哪些过程参数、或机器/车间的拓扑上的数据。
23.例如,服务可以是包括一个或多个代码块的封装代码的实况实例。例如,当在容器
中执行封装代码时,可以获得服务。例如,对于编译的代码,可将其与清单(manifest)一起打包成容器图像。容器图像可以由运行时环境(例如,kubernetes运行时环境)执行。
24.本公开的方法的其它优点在下面呈现。
25.与(仅)基于过程拓扑将代码分组到应用中相比,本公开的方法的优点在于,对于实现工业车间的过程功能(诸如例如加热、混合等)的每个区域、单元、模块或设备,将总是存在用于自动化例如高度关键和非关键过程的不同类别的代码段。当通过过程拓扑仅执行分组时,这意味着通常使相应的代码段运行基于云的环境是不适当的,从而结果是关键和非关键服务两者都将在本地运行,并且不可能很好地利用基于云的解决方案。
26.根据本公开的过程拓扑结构具有各自实现工业车间的过程功能(例如加热、混合和/或填充)的元素。元素可以是例如工业车间的区域、单元、模块或设备。
27.本发明可以仿真用于过程拓扑的专用元素的代码,同时使与该元素相关联的服务的部分在本地运行,而使与硬件模块相关联的服务的其他部分在基于云的环境中运行。
28.本公开的方法允许将代码分解成小片段,可选地甚至分解为单独的循环,并且提供对某些过程(例如控制循环)的关键程度的自动调查。关键程度意味着,例如,如果服务没有正确地执行,则必须多快地作出反应。它可以取决于服务是否与安全和/或产品质量相关。例如,在许多情况下,监测数据收集可能不是特别关键的,因为在监测没有连续和可靠地执行的情况下,产品质量和安全性都不受到影响,或者在不同的条件下,以人工操作员或长期资产管理为目标的观察性监测具有非常高的生存时间。然而,数据被用于干预目的,例如用于关键过程参数的测量数据,以及与所述数据相关的服务可能更加关键。
29.具体地,本公开的方法允许以这样的方式分解代码,即,可以执行分组成不同类别的关键程度,并且可以在本地(例如在传统plc上)执行高度关键的服务,并且作为示例,可以经由云服务执行不太关键的服务。
30.本公开的方法可以允许以最小资源密集的方式封装和部署执行单元。一种执行环境,其能够实现较低的性能并具有较低的成本,并且部署具有对应qos简档的容器。执行环境的功能部分可以按照能力和成本的升序是云、移动边缘、自有边缘和plc。例如,高优先级、低时延的环路可以在一个服务器房间内的本地边缘集群上运行,或者甚至在plc上运行,以提供所需的状态转移/故障切换时间。
31.根据本公开的自动划分消除了工程师分割应用或定义应用最终应该在其上执行的控制器的需要,例如对于使用例如iec 61131或it编程和脚本语言(包括c、c++到python)来编程控制应用的工程师。
32.该方法独立于具体编程语言、二进制/编译代码格式、底层计算机架构,以及用于在特定架构(例如,x86、x64、arm)上的执行环境(例如,kubernetes)上执行作为若干服务的分段(编译)代码的仿真层或运行时引擎。示例是被容器化并随后运行实际应用代码的java虚拟机(jvm)、.net公共语言运行时(clr)、或iec 61131执行引擎的使用。
33.本公开的方法还可以改进可伸缩性(例如,当更新或扩展应用时),并且允许应用组件的更精细粒度(软件定义)可靠性。此外,可以获得更高的整体应用可靠性,同时还以降低的成本采用更多的“不可靠”计算环境。此外,当更新通过本公开的方法获得的应用时,仅必须更新单独的毫微服务,这几乎不需要备用资源或网络负载。
34.本公开的方法还可以允许最小化capex/opex。它还可以改进更新能力,例如,可以
实现轻量级的实时更新,例如用于负载-估计-运行leg(load-evaluate-go)更新。
35.下面提供根据本公开的方法的另外的示例和实施例。
36.本公开的方法可以包括,针对代码块中的每个代码块,自动地确定由代码块控制和/或监测的多个过程中的一个或多个过程的关键程度,并且基于该确定将关键程度自动地分配给代码块。
37.确定关键程度可以考虑与代码块相关联的关键性能指标来执行,特别地,其中关键程度可以由关键性能指标的向量来表示。
38.为了简洁起见,还可以将表示代码块的关键程度的关键性能指标的向量称为代码块的向量。为了简洁起见,代码块可以被描述为具有向量。
39.当关键程度由关键性能指标的向量表示时,相似性可以由距离度量确定,其中两个代码块的相似性可以基于表示每个代码块相对于彼此的关键程度的向量之间的距离来确定。换句话说,相似性可以基于代码块的向量之间相对于彼此的距离来确定。
40.例如,基于预定距离度量,具有相对于彼此在预定间隔内的距离的向量的所有代码块可以被认为是相似的。
41.根据预定距离度量,当代码块的向量之间的距离较低时(例如,比两个其它代码块的向量之间的距离低),代码块被描述为彼此更相似(例如,比两个其它代码块更相似)。
42.考虑到分配给多个代码块中的每个代码块的关键程度的相似性而自动创建多个服务的上述步骤可以包括确定代码块的向量之间相对于彼此的距离。
43.例如,可以在同一服务内仅实现具有下述向量的代码块,所述向量基于预定距离度量具有在预定间隔内的相对于彼此的距离。换句话说,只有基于预定距离度量被认为是相似的代码块可以在同一服务内实现。特别地,基于预定距离度量被认为是相似的所有代码块可以在同一服务内实现。
44.如上所述,在本公开中,在自动创建多个服务的步骤中,除了考虑分配给多个代码块中的每个代码块的关键程度的相似性之外,还可以考虑附加标准。
45.例如,附加标准可以包括代码块的向量相对于参考向量的距离在预定间隔内。例如,即使仅基于相似性代码块将在同一服务内实现,但如果不满足附加标准,例如,如果代码块的向量相对于参考向量的距离不在预定间隔内,则它们可能不在同一服务内实现。
46.这可以避免生成一组代码块的服务,其中每个代码块与它们相应的最近邻居相似,但是对于该组的一个或多个其他代码块并不特别相似。
47.备选地或附加地,例如,附加标准可以包括在同一服务内仅实现具有下述向量的代码块,该向量具有满足预定标准(例如,在预定间隔内)的一个或多个关键性能指标。例如,即使仅基于相似性,代码块将在同一服务内实现,但如果不满足附加标准,例如如果它们的向量的一个或多个关键性能指标不在预定间隔内,则它们也可以不在同一服务内实现。
48.这可以避免生成一组代码块的服务,该组代码块可以是类似的,但包括具有超过关键程度阈值的要求的一些代码块,以及不超过关键程度阈值的代码块。该关键程度阈值可以但不一定对应于确定服务应该在异构计算基础设施的哪个功能部分上运行的阈值。
49.上述间隔和/或阈值可以是预先确定的,例如根据技术要求和/或技术环境根据具体情况来预先确定。
50.在本公开中,每当例如预定的距离度量可以是已知用于确定向量之间的相似性或距离的任何距离度量时。其可以根据技术要求和/或技术环境,根据具体情况预先确定或选择。
51.本公开的关键性能指标可以包括但不限于可用性、可靠性、循环时间、冗余水平、应用生存时间和恢复时间中的至少一个。关键性能指标的测量或量化可以取决于情况,例如取决于技术要求和/或技术环境。
52.可用性和可靠性可以例如根据诸如iec 61907或3gppts 22.261的标准来定义,例如如下。
53.可靠性可以表示如下:r
(t)
=e-λt
=e-(t/m)
,其中r
(t)
是可靠性,λ是故障率,m是平均故障间隔时间(mtbf,mean down time),其中m=1/λ。因此,m=t/log
(n)
(1/r
(t)
)。作为选择,mtbf可以用作可靠性的量度。
54.可用性可以由以下表达式表示:
55.或或其中mtbf是平均故障间隔时间,mdt是平均停机时间(mean down time)。
56.在本公开中,应用循环时间是这样的持续时间:在该持续时间期间,控制回路基于感测输入潜在地对受控过程发出新的致动,即,其包括用于感测和信号处理、传输、控制逻辑计算、传输、输出处理/致动的时间。由此,可以导出服务的通信时延和最坏情况执行时间。成本可以作为每个执行周期的货币给出。
57.下面将提供度量的示例用于说明。假设一对向量v_req用于服务并且v_env用于计算环境。一个基本示例是这样的度量,其中元素v_env-v-reg的成对差异必须是正的或零,其中较高的值是较好的(例如可用性),或者是负的或零,其中较低的值是较好的(例如成本或时延)。这可以表示为(v_end-v_reg)*v_mirr》=0,其中v_mirr包含1,其中较大的值较好,-1,其中较小的值较好。
58.向量的一些元素可能是不可协商的,例如plc的安全认证,其它元素例如可用性可能以低成本进行交易。一个示例是假定计算平台按服务需要以1eur/天提供99.9%的可用性,而另一个以49c/天提供99%的可用性,相同的服务可以在低成本平台上以98c/天启动两次,可用性甚至为99.99%。
59.类似地,当整个应用周期时间是关键决定因素时,通信时延和服务执行时间可能被交换。
60.本公开的方法可以包括自动分解初始控制代码,以便获得多个候选代码块,以用于控制和/或监测由工业车间的一个或多个设备执行的多个过程。此外,本公开的方法可以包括自动确定候选代码块是否将被用作多个代码块。所述确定可以包括:确定所述多个候选代码块是否满足至少一个标准;在确定满足所述标准时,将所述多个候选代码块用作所述多个代码块;以及在确定不满足所述标准时,确定所述多个候选代码块不将被用作所述多个代码块。可选地,所述方法可以包括:在确定所述多个候选代码块不将被用作所述多个代码块时,修改,特别是合并或进一步分解所述多个候选代码块以获得多个经修改的候选代码块。
61.换言之,可以确定候选代码块,然后可以执行判定过程,该判定过程确定这些候选代码块是否将被用作上面进一步提到的多个代码块,即下述代码块:所述代码块被使用以考虑分配给多个代码块中的每个代码块的关键程度的相似性而自动创建多个服务。否则,候选代码块可以被修改。
62.分解初始控制代码以获得候选代码块以及可选地合并候选代码块的步骤可以被看作是将初始控制代码分割成代码块的一部分。
63.当使用多个候选代码块作为多个代码块时,该至少一个标准可以反映控制应用中的预期开销量和/或与代码块相关联的所需可靠性和/或所需可用性,可选地还考虑使用仿真器或运行时引擎来执行实际代码所增加的开销量。确定是否满足标准可以包括确定预期开销量是否保持在预定阈值以下和/或确定可靠性和/或可用性是否满足相似性要求。
64.在本公开中,开销可以指运行候选代码块的特定集合并在它们之间交换(先前内部的)数据的附加存储、计算和通信覆盖区中的至少一个,特别是在匹配给定定时约束时。
65.备选地或附加地,确定是否满足可用于确定候选代码块是否将被使用的标准可以包括:将被包括在每个候选代码块中的关键程度和/或功能相互比较或与其它候选代码块的关键程度和/或功能进行比较。
66.备选地或附加地,确定是否满足标准可以包括:确定候选代码块是否具有合适的大小或者可能需要减小或增大大小。
67.例如,初始控制代码可以被分解以获得多个候选代码块,每个候选代码块表示单个函数和/或单个循环。然后,通过应用预定标准,例如通过确定多个代码块中的几个代码块具有相同或非常相似的关键程度和/或通过确定它们在过程的上下文中具有相同的功能,可以确定它们可以被合并以形成比先前候选代码块更大的一个或多个经修改的候选代码块。备选地或附加地,初始控制代码可以被分解为包括多个函数和/或循环的候选代码块,并且可以确定候选控制块内的函数和/或循环的关键程度被扩展得太多。然后,候选代码块可以被进一步分解以获得比先前候选代码块更小的多个经修改的代码块。
68.候选控制块的创建以及在必要时的修改可以确保用于自动创建多个服务的关键程度可以针对控制块被有效且足够准确地定义。
69.为了说明起见,用于分割代码,特别是用于将代码分解为候选代码块和/或合并候选代码块,以及用于将代码块分组为服务的标准可以重叠,特别是在旨在对在某些特性(例如,关键程度)方面类似的代码块进行分组的标准的情况下。然而,标准通常不是完全一致的。
70.本公开的方法可以包括:针对多个经修改的候选代码块,重复确定候选代码块是否将被用作多个代码块,否则,即,一旦确定多个候选代码块将不被用作多个代码块,则修改,特别是合并或进一步分解多个候选代码块以获得多个经修改的候选代码块。
71.也就是说,从候选代码块获得代码块可以是迭代过程,其包括重复地修改候选控制块直到它们被认为适合于在自动创建服务中使用。这允许获得对于自动创建服务来说尽可能接近理想的代码块。
72.用于确定候选代码块是否将被用作多个代码块的标准对于所有迭代可以不同。例如,一个或多个迭代可以具有与函数相关的标准,而一个或多个其它迭代可以具有与关键程度相关的标准,或者它们可以各自与具有不同相对权重的函数和关键程度相关。
73.分解初始控制代码以便获得多个候选代码块可以包括将代码分解为预定大小的单元,具体地,分解为函数和/或分解为最小可能的单元,诸如实现单个控制循环的代码。
74.这构成了提供候选代码块的非常简单和有效的方式。因此,可以快速和有效地找到用于寻找代码块的起始点,并且通过可选地重复地应用修改候选代码块的步骤,可以以有效和可靠的方式确定代码块。最小可能的单元例如可以是实现单个循环的代码。
75.单个控制回路的代码可以包括:表示测量的过程变量的一个输入变量、影响致动器行为的控制器输出、设定点,该设定点指示相关控制代码应该确保的过程变量的目标值。
76.本公开的方法可以包括,针对多个服务中的一个或多个服务,例如基于由服务实现的一个或多个代码块的关键程度来自动确定服务的总体关键程度,以及基于服务的总体关键程度来自动确定服务应当在分布式异构计算基础设施的运行时环境(诸如本地控制器,边缘节点或云服务器)的哪一功能部分上运行,特别是运行时环境的什么类型或实例,特别是服务是否应当在本地、在边缘节点上或在云中运行。
77.这允许改进每个功能部分的技术优点的利用,并且因此改进整个异构计算基础设施的能力。特别地,它允许根据服务的相应要求和功能部分的能力在基础设施上分发整个控制应用。这可以在不产生过量开销的情况下完成。
78.具体地,如上所述,基础设施的不同功能部分可以具有不同的技术能力,例如在响应时间、可用性等方面。每个服务可以在仅满足该服务的要求的功能部分上运行,即,在仍然满足该要求的同时以最低可能的量超额满足该要求。
79.作为基于一个或多个代码块的关键程度来确定服务的整体关键程度的示例,整体关键程度可以对应于具有最高关键程度的代码块的关键程度。
80.自动确定服务应该在分布式异构计算基础设施的哪个功能部分上运行可以包括将服务分配给功能部分。
81.确定服务应该在哪个功能部分上运行将在根据其功能类别确定基础设施的一部分方面被看到。例如,确定服务应该在哪个功能部分上运行可以,但不一定包括确定特定的单独节点或服务器。例如,可能需要仅确定服务应该在边缘或plc或云服务器上运行,而不分别指定边缘集群的多个可用边缘节点中的哪一个边缘节点或多个可用plc中的哪一个plc或多个可用云服务器中的哪一个云服务器。
82.在本公开中,功能部分可以是例如如上所述的运行时环境的类型或实例。
83.自动确定服务应该在分布式异构计算基础设施的哪个功能部分上运行可以包括访问指定计算基础设施(例如,给定硬件环境)的信息,从该信息确定可用功能部分,并且基于该信息将服务分配给可用功能部分中的一个功能部分。备选地或附加地,确定服务应当在分布式异构计算基础设施的哪个功能部分上运行可以包括确定分布式异构计算基础设施的适当配置,特别地,确定要被包括在分布式异构计算基础设施中的适当功能部分,以及将服务分配给功能部分中的一个功能部分。例如,确定服务应该在分布式异构计算基础设施的哪个功能部分上运行可以包括例如从给定的组件目录确定硬件环境。可以在预定约束(例如功能部分的可用性)内执行确定适当配置。
84.应当注意,本领域技术人员可以例如选择允许执行在分布式异构计算基础设施的不同功能部分上运行的应用的已知架构,以实现在所确定的功能部分上运行不同服务。例如,一些以网络为中心的架构,例如具有abb select i/o的架构,可能已经提供了在连接到
网络的任何专用过程控制器和/或主机上运行应用的可能性。
85.本公开的方法可以包括:针对多个服务中的一个或多个服务中的每一个,以这样的方式存储整体关键程度和/或分布式异构计算基础设施的服务应该在其上运行的功能部分,使得整体关键程度和/或功能部分可以由执行控制应用的计算系统访问。作为示例,执行控制应用的计算系统可以是分布式异构计算基础设施。
86.换句话说,一旦确定了关键程度和/或适当的功能部分,就可以存储它们以供以后使用。因此,在服务被复制以供使用的情况下,所存储的关键程度可以被直接用于确定应该在基础设施的哪个功能部分运行。在一些情况下,所存储的功能部分甚至可以直接用作服务应该在其上运行的功能部分。它可以取决于是否直接使用所存储的功能部分或是否功能部分根据所存储的关键程度被确定的上下文。
87.该存储可以在任何合适的计算机可读存储器上执行,该计算机可读存储器可以是分布式异构计算基础设施的一部分。例如,信息可以被存储在数据库中。
88.确定服务应该在分布式异构计算基础设施的哪个功能部分上运行可以包括:基于预定距离度量,针对分布式异构计算基础设施的每个功能部分,确定服务的需求向量与功能部分的能力向量之间的距离。备选地或附加地,确定服务应该在分布式异构计算基础设施的哪个功能部分上运行可以包括:针对分布式异构计算基础设施的功能部分中的每一个,确定功能部分的能力向量的条目中的一个或多个条目是否等于或大于服务的需求向量中的对应条目。
89.作为示例,确定服务应该在分布式异构计算基础设施的哪个功能部分上运行可以包括:针对服务的需求向量的预定条目集合和每个功能部分的相应能力向量的对应条目集合,确定能力向量的条目是否等于或大于需求向量的条目,并且如果是这种情况,则确定功能部分适合于运行服务。该确定可以包括在适当的功能部分中确定具有相对于需求向量具有最小距离的能力向量的功能部分。该功能部分可以被确定为服务应该在其上运行的功能部分。备选地,顺序可以颠倒。可以应用上述标准的其它组合,以及可选地,附加标准。
90.需求向量可以对应于上述表示关键程度的向量。能力向量的每个条目对应于需求向量中的条目,并且指示功能部分根据需求条目所表达的需求所提供的最大能力。
91.例如,需求向量中的条目可以是表示最小所需可用性的值,而能力向量中的条目可以表示功能部分能够提供的最大可用性。
92.这样,需求和能力向量可以用于例如确定功能部分是否能够执行服务和/或用于选择至少超性能的功能部分。
93.在一些情况下,两个功能部分可以是同样合适的,例如就基于向量的上述评估而言。在这种情况下,可以考虑其它因素。例如,可以存在边界条件,该边界条件产生针对成本的默认或针对在其他方面同样合适的功能部分的情况下的安全决定的默认。
94.应当注意,存在这样的情况,其中,为了获得能够被比较的能力向量和需求向量的条目,功能部分的能力和/或特征和/或服务的需求的转换或变换被执行。
95.本公开的方法可以包括:针对工业车间的过程拓扑的至少一个元素,例如针对工业车间的区域、单元、模块或设备中的至少一个,自动识别在控制和/或监测过程拓扑的元素时所涉及的多个服务的子集;以及将子集组装成元素专用代码包,同时保持服务在代码包中分离。
96.作为示例,与给定元素相关的所有服务可以被标识为元素专用代码包的一部分。其优点在于,当设置具有相同配置的过程拓扑的元素时,这将允许使用与元素特定代码包中的那些服务集相同的服务集。应当理解,保持服务分离意味着在组装之后,控制代码与初始控制代码(即分割之前的控制代码)不同。换句话说,服务保持完整。
97.本公开的方法可以包括自动生成胶合代码,该胶合代码被配置为确保在分割初始代码和创建服务的过程中对初始代码做出的任何改变不会破坏初始代码的功能,特别是被配置为允许服务的完全集成。
98.生成胶合代码可以包括,但不限于,生成附加的i/o变量,例如具有对应的数据大小和/或通信服务质量,如时延或冗余度,以允许交换,特别是先前内部的变量,例如跨越在分割初始控制代码的过程中分离的代码块而交换先前内部的变量。特别地,生成胶合代码可以包括生成附加的i/o变量以及通信qos以传送数据,该数据在分割之后必须在至少两个服务之间共享。
99.应当注意,特别是由于变量的交换通常在初始控制代码中是可跟踪的,本领域技术人员将知道如何实现自动生成。
100.本发明还提供了由本公开的任何方法提供的控制应用的用途,以用于控制和/或车间的操作。
101.特别地,该使用可以包括在分布式计算系统中执行控制应用,该分布式计算系统包括位于工业车间现场的本地计算系统,与工业车间相关联的边缘计算系统和云计算系统中的至少一个。例如,控制应用的不同服务可以在计算系统的不同功能部分上运行。
102.执行控制应用可以包括在本地计算系统上执行服务的第一子集,以及在边缘计算系统上执行服务的第二子集和在云计算系统上执行服务的第三子集中的至少一项。可以如以上在本公开的方法的上下文中所描述的那样执行确定应当在哪个功能部分上执行服务的相应子集。
103.本发明还提供了一种数据处理系统,包括用于执行本公开的计算机实现的方法的装置。数据处理系统可以实现为分布式系统或集中式计算系统,例如计算机。数据处理系统可以至少包括处理器,并且可选地包括存储器单元。
104.本发明还提供了一种包括指令的计算机程序产品,当所述程序由计算机执行时,所述指令使所述计算机执行本公开的任何方法。
105.本发明还提供了一种包括指令的计算机可读介质,所述指令在由计算机执行时使得所述计算机执行本公开的任何方法。
106.以上在方法的上下文中概述的特征和优点类似地适用于本文所述的用途、数据处理系统、计算机程序产品和计算机可读介质。
107.通过参考附图的详细描述、其它特征、示例和优点将变得显而易见。
附图说明
108.在附图中,
109.图1示出了数据处理系统以及工业车间和分布式计算系统的示意图;
110.图2是示出根据本公开的方法的流程图;
111.图3是示出根据本公开的另一方法的流程图;
112.图4是工业车间的至少一部分的示意性的、不按比例的表示;
113.图5示出了用于工业车间的控制代码分割的概念。
具体实施方式
114.图1示出了根据本公开的数据处理系统1,其包括用于执行本公开的方法(例如下述方法之一)的装置(例如处理器1a)。
115.如图1所示,根据本发明的系统可以可选地进一步包括工业设备2,该工业设备2包括多个设备2a、2b和2c。此外,如图1所示,该系统可以可选地包括分布式异构计算系统3,该分布式异构计算系统3仅作为示例包括三个功能部分3a至3c,即,位于工业车间现场的本地计算系统3a、与工业车间相关联的边缘计算系统3b、以及云计算系统3c。可选地,可以提供数据连接4a和4b,用于在分布式计算系统和数据处理系统1之间和/或在工业车间和分布式计算系统3之间交换数据。
116.图2是示出根据本公开的方法的流程图。
117.该方法包括步骤s1和步骤s2,步骤s1将工业车间的初始控制代码自动分割为多个代码块,步骤s2自动创建多个服务,每个服务实现多个代码块中的一个或多个代码块的功能。根据本公开,多个服务的自动创建在考虑分配给多个代码块中的每一个的关键程度的相似性的情况下执行,使得具有更相似的关键程度的代码块更可能在同一服务内实现。
118.将初始控制代码分割成多个代码块通常可以以不同的方式执行。作为非限制性示例,分割可以包括可选的步骤s11至s13。备选地,这些步骤中的至少一些可以在分割初始控制代码之前执行。
119.在可选步骤s11中,初始控制代码被自动分解以便获得多个候选代码块。例如,它可以被分解成功能和/或最小可能的单元,如单个循环。
120.随后,在步骤s12中,自动确定多个候选代码块是否满足至少一个标准。例如,当使用多个候选代码块作为多个代码块时,该标准可以反映控制应用中的预期开销量。
121.如果是这种情况,则在步骤s13中,在确定满足标准时,使用多个候选代码块作为多个代码块,并且该方法直接地或经由下述的可选步骤s15和s16进行到步骤s2。
122.否则,在步骤s14中,在确定不满足标准时,合并或进一步分解多个候选代码块以获得多个经修改的候选代码块,并且该方法前进到步骤s12。因此,候选代码块被修改直到它们满足该标准,然后在步骤s2中被用作代码块。
123.在可选步骤s15中,针对代码块中的每个代码块,在本示例中由代码块控制和/或监测的多个过程中的一个或多个过程的关键性能指标的向量表示的关键程度被自动确定。在可选步骤s16中,关键程度被自动分配给代码块。
124.在可选步骤s21中,自动生成胶合代码以确保在分割初始代码和创建服务的过程中对初始代码作出的任何改变不会破坏初始代码的功能。具体而言,胶合代码可以生成附加的i/o变量,例如以允许在分割初始控制代码的过程中分离的代码块之间交换先前的内部变量。在可选步骤s21a中,可以将胶合代码与服务组合以共同形成控制应用。
125.如果该方法不包括步骤s21,则在步骤s2a中可以组合多个服务以共同形成控制应用。
126.在可选步骤s22中,例如基于由服务实现的一个或多个代码块的关键程度,针对服
务中的每个服务,自动确定服务的整体关键程度。
127.在可选步骤s23中,基于服务的整体关键程度,自动确定服务应该在分布式异构计算基础设施的哪个功能部分上运行。例如,在该步骤中,可以确定该服务是否应当在本地、在边缘节点上或在云中运行。作为示例,可以做出决定以便选择具有最低能力的功能部分,该功能部分仍然满足服务在关键程度方面的要求。
128.在可选步骤s24中,以执行控制应用的计算系统能够访问该信息的方式存储关键程度和/或该服务应该在其上运行的功能部分。因此,该信息稍后可以在实际运行控制应用时被使用。
129.应当注意,步骤s22至s24可以不必是用于提供用于工业车间的基于服务的控制应用的方法的一部分。相反,这些步骤中的一些或全部可以是使用根据本公开的控制应用的方法的一部分。这意味着在创建控制应用时不必一定已经确定了服务将如何根据关键程度来评估和/或服务将在哪些功能部分上运行。在一些情况下,为了适配控制应用,该步骤可以(至少也)在给定地点和给定时间使用控制应用时执行,例如基于手头的特定基础设施。
130.在创建服务之后,可以执行可选的步骤s25,其中多个服务中的涉及控制和/或监测车间的设备的子集被自动标识并且被组装到该件设备所特有的代码包中,同时仍然维持个体服务。
131.图3是示出使用通过根据本公开的方法获得的控制应用的方法的流程图。具体地,控制应用用于控制和/或监测工业车间的运行,例如图1的上下文中描述的工业车间或任何其他工业车间。
132.该方法包括在分布式异构计算系统中执行控制应用,该分布式异构计算系统包括作为功能部分的位于工业车间现场的本地计算系统,以及与工业车间相关联的边缘计算系统和云计算系统中的至少一个。作为示例,分布式计算系统可以是如上在图1的上下文中描述的计算系统。
133.执行控制应用包括在本地计算系统上执行服务的第一子集的步骤s32,在边缘计算系统上执行服务的第二子集的步骤s33,以及在云计算系统上执行服务的第三子集的步骤s34。
134.该方法可选地包括,在执行控制应用之前,步骤s31,获得关于相应服务应该在哪里执行的信息。该信息可以根据本公开的任何方法来确定,例如在图2的上下文中描述的方法。
135.为了说明,下面提供根据本公开的方法的另一示例的方法步骤。
136.在第一步骤中,初始控制代码(例如初始控制应用)被分割成多个代码块。例如,可以将其分解或划分成更小的执行单元,例如甚至划分成最小可能的执行单元,例如单独的循环。从应用的角度来看,保持了片段的完整性。在该方法应用于模块化工程车间的情况下,划分可以在模块水平上定义一次,然后再利用。
137.在第二步骤中,可以通过相似性来聚合执行单元,例如根据所需的可靠性、可接受的故障切换时间、过程中的依赖性/距离、qos等,以便平衡容器化开销,例如优化资源使用。换句话说,执行单元被封装到容器中,这里也称为代码块。换句话说,如果从技术观点来看认为是合适的,则也可以再次合并一些较小的执行单元。
138.从上面可以看出,分解和可选地合并将导致多个代码块。
139.分割和聚合的信息例如可以从现有的cad和自动化工程数据中获得。
140.在第三步骤中,可以通过将代码块分组来获得服务,并且在第四步骤中,可以将服务部署在异构计算环境中,优选地利用确定性的容器间和/或进程间通信来传送状态。
141.对于部署,可以为每个服务定义所需的鲁棒性,例如在可用性、可靠性和/或恢复时间方面的鲁棒性,以例如导出实例、恢复机制和/或通信资源的冗余水平。例如,对于一些服务,所需的恢复时间可以是1秒,而对于其它服务,所需的恢复时间可以是大约仅10ms的数量级。
142.在本公开中,具体地在上述第一步骤至第三步骤中,可以执行以下步骤中的至少一些,例如,以标识初始控制代码中的执行单元及其性能特性,以获得代码块,和/或获得服务:
143.捕获例如来自p&id图的环路;
144.识别用于监测的特定开环;
145.分析环路之间或环路级联中的信号流或进程依赖性;
146.解释物理量,例如温度和/或压力等,并且将它们与预定义的可用性和定时简档相关联;
147.评估显式信号更新速率。
148.为了避免在步骤1和/或步骤2中破坏代码,可以执行以下步骤中的一个或多个:
149.抽取逻辑;
150.识别所交换的内部信号;
151.创建用于协议栈的外部i/o信号配置;
152.在逻辑和栈之间生成胶合代码;
153.将逻辑、胶合代码和栈封装到例如虚拟容器中;
154.添加内容标识符,例如环路名称。
155.可选地,在自动生成代码块和/或服务及其特征之后,可以由人(例如工程师)验证和批准结果。
156.在本公开中,具体地在上述第一步骤至第三步骤的上下文中,可以确定用于执行单元和/或代码块的相似性度量。例如,可以基于过程中的受控点(例如i/o)来确定相似性。具体地,例如,可以基于过程中执行单元的空间距离(直线)和/或通过使用过程中的中间过程单元或模块的数量(例如,遵循材料流)来确定例如从cad或p&id数据导出的关于过程的相似性。例如,两个相邻储罐的液位控制将具有距离"1"。备选地或附加地,相似性可以根据代码执行特性来确定,例如,根据定时配置、指示物理量的单元、用于安全或互锁的命名约定、所使用的信号的警报关键程度等。所考虑的因素可以是时延或往返时间(rtt)、循环的关键程度(criticality)中的一个或多个,例如取决于物理量的变化速度(例如,量化为℃/s或m3/s2)。例如,就关键程度而言,可以将循环标记为与产品质量相关、与安全相关或仅用于监测(例如,没有闭环)。
157.在本公开中,具体地在上述第一步骤至第三步骤中,可以如下执行执行单元的聚合或通过相似性对代码块进行分组。
158.可以聚合足够相似(例如,具有相同或足够相似的qos简档)的执行单元。例如,可以合并代码单元,或者可以选择性地回溯分划分。因此,获得代码块,并且可以基于代码块
的特征将类似的代码块分组为服务。
159.如上所述,聚合代码单元允许优化存储、cpu、通信和容器的管理开销。例如,利用冗余,在任何情况下都需要传送状态,但是在网络上具有较少的报头开销。类似地,来自单个远程i/o的数据优选地不应被许多容器解密以每次仅提取一个信号。除了该过程的性能需求之外,可以考虑i/o映射用于聚合。
160.在本公开中,具体地在上述第四步骤中,可以如下执行异构环境中的服务部署的自动定义。针对每个服务,可以确定满足所需的执行速度、可靠性/故障切换时间和内部信号交换速度的节点集群,并且还可以确定到其它节点集群的通信是否满足外部信号交换速度和可靠性要求(针对每个成对的集群,这样的特性必须能够从通信基础设施获得)。换言之,为了选择节点,可以考虑节点能力和节点网络内的通信能力。根据计算环境,选择仅满足要求的节点可能是有利的。
161.作为示例,安全码可以在专用且可认证的控制器上运行,具有5ms或更少rtt的循环可以在本地边缘集群上运行,例如,利用千兆tsn以太网,较慢的循环可以在5g移动边缘上运行,并且数据分析可以在云上通过因特网运行。后者可能具有高时延,但通常也具有最低成本。应当注意,在某些情况下,例如纯粹的监测信号,信号可能不具有任何相关联的计算,但是在任何情况下可能需要在本地操作者图形上被示出,并且因此可能潜在地不通过5g mec或云。
162.下面将概述本公开的一些其它方面和示例。
163.就冗余和状态转移而言,本公开的服务可以以给定的可用性度量或明确的冗余水平开始。为此,除了i/o信号之外,毫微服务(nano-service)可以暴露要与其冗余实例同步的内部状态变量。用于配置和执行状态转移的机制可以与用于i/o信号的机制相同(例如,所需的带宽和时延以及用于数据传输的网络可用性/冗余测量)。
164.就利用本公开的服务来应用负载-评估-执行leg更新而言,可以部署被标记为评估候选的多个服务。候选代码的行为可以例如与常规leg一样被评估。可以执行新代码的同步激活和旧代码的禁用。
165.以网络为中心的架构可用于通过循环的共同关键程度而不是来自fieldbus段的i/o信号的空间协同来将代码聚合到控制器硬件上。因此,可以防止浪费的冗余。
166.可以提供用于容器的网络故障容忍应用层。可以提供扩展的容器网络/连接功能以使用可配置时间点的最后良好值。可以发出关于丢失新值的警报,但是服务可以继续运行直到在“i/o状态”转到“坏状态”之前时间结束。
167.优选地,当为本公开的控制应用准备新的代码片段时,例如,当编写代码时,特别是当利用模块化工程时,本公开的用于提供(基于服务的)控制应用的方法可能已经被考虑或至少部分地在设计时执行。在这种情况下,执行特性可能已经被存储在代码旁边以供将来使用。新代码可以作为本机毫微服务或基于具有附加特性的iec 61499编写。
168.在图4和图5中示出了本公开的方法的另一具体示例。该实施例涉及用于上游油气车间的分离器方法。在该示例中的分离器是被配置为分离水、气体和油的三相分离器,但是备选地,它也可以被配置为仅分离两相,例如仅分离油和水。图4分别用虚线矩形、六边形和圆形示出了过程和突出显示,相应地部分表示非关键功能、部分表示过程关键功能、以及部分表示安全关键功能。
169.通过元素bv10,井口的输出流入容器。将容器设定在压力下以分离水、气体和油。气体通过顶部管道流出,水和油通过底部管道流出。可以存在另外的分离器级,例如,可以存在总数为四个的分离器级,其具有用于最佳分离的不同压力水平。这些级可以以串行方式连接。图5示出了根据本公开,在初始控制代码的分割之后,代码块可以遵循功能性和关键程度,而不是物理设备和/或过程拓扑的元素。
170.关于该示例,表1示出了用于相应类(即功能的监测、过程关键和安全关键)的类特定kpi。
171.假设运行时生态系统是分布式异构计算基础设施的形式,具有专用的本地硬件,例如plc,内部部署边缘集群,5gmec,以及可选地,云,不同的部署通常可用于每一类。当按照关键程度来分发时,例如,安全关键代码可以仅在(安全)plc上运行,过程关键代码可以部署在自有的内部部署的边缘集群上,并且与监测相关的代码可以部署在自有的或租用的边缘集群上,这在capex/opex结构或5gmec中可能不同。如上所述,根据本公开的方法,可以执行部署使得仅满足要求。例如,可以在5g mec上执行监测,在内部部署边缘集群上执行处理关键功能,以及在专用本地硬件上执行安全关键功能。
[0172][0173]
表1针对图1的曲线示例(数值仅供说明)
[0174]
虽然已经在附图和前面的描述中详细说明和描述了本发明,但是这样的说明和描述应当被认为是示例性的而不是限制性的。本发明不限于所公开的实施例。考虑到前面的描述和附图,对于本领域技术人员来说显而易见的是,在由权利要求限定的本发明的范围内可以进行各种修改。
技术特征:
1.一种用于提供用于工业车间(2)的基于服务的控制应用的计算机实现的方法,所述方法包括:将用于所述工业车间的初始控制代码自动分割成多个代码块;以及自动创建多个服务,每个服务实现所述多个代码块中的一个或多个代码块的功能,其中,所述多个服务的自动创建是在考虑分配给所述多个代码块中的每个代码块的关键程度的相似性的情况下执行的,以使得具有更相似的关键程度的代码块更可能在同一服务内被实现。2.根据权利要求1所述的方法,包括:针对所述代码块中的每个代码块,自动确定由所述代码块控制和/或监测的多个过程中的一个或多个过程的关键程度,并且基于所述确定来将所述关键程度自动分配给所述代码块。3.根据权利要求2所述的方法,其中确定所述关键程度是在考虑与所述代码块相关联的关键性能指标的情况下执行的,所述关键性能指标诸如循环时间、所需冗余水平、生存时间和/或故障切换时间,特别地,其中所述关键程度由关键性能指标的向量表达和/或其中所述关键性能指标是通过分析信号标签名称以标识受控物理量的类型和/或通过分析与信号相关联的警报和/或事件的严重性等来导出的。4.根据前述权利要求中任一项所述的方法,包括自动分解所述初始控制代码以便获得多个候选代码块,以用于控制和/或监测由所述工业车间(2)的一个或多个设备(2a、2b、2c)执行的多个过程;以及自动确定所述候选代码块是否将被用作所述多个代码块,所述确定包括:确定所述多个候选代码块是否满足至少一个标准,在确定满足所述标准时,确定所述多个候选代码块将被用作所述多个代码块,以及在确定不满足所述标准时,确定所述多个候选代码块将不被用作所述多个代码块,可选地,所述方法还包括:在确定所述多个候选代码块将不被用作所述多个代码块时,修改所述多个候选代码块以获得多个经修改的候选代码块,特别地,合并或进一步分解所述多个候选代码块以获得多个经修改的候选代码块。5.根据权利要求4所述的方法,还包括:针对所述多个经修改的候选代码块,重复以下操作:确定所述候选代码块是否将被用作所述多个代码块,以及否则修改所述多个候选代码块,特别地,合并或进一步分解所述多个候选代码块。6.根据权利要求4或5所述的方法,其中所述至少一个标准反映以下项:当将所述多个候选代码块用作所述多个代码块时的所述控制应用中的预期开销量,和/或与所述代码块相关联的所需可靠性和/或所需可用性。7.根据权利要求4至6中任一项所述的方法,其中分解所述初始控制代码以便获得多个候选代码块包括:将所述代码分解为预定大小的单元,具体地,将所述代码分解为函数和/或分解为最小可能的单元,诸如实现单个控制循环的代码。8.根据前述权利要求中任一项所述的方法,还包括,针对所述多个服务中的一个或多个服务:自动确定所述服务的整体关键程度,特别地基于由所述服务实现的一个或多个所述代码块的关键程度来自动确定所述服务的整体关键程度;以及基于所述服务的所述整体关键程度,自动确定所述服务应该在分布式异构计算基础设
施(3)的哪个功能部分(3a、3b、3c)上运行,特别地自动确定所述服务应该在运行时环境的什么类型或实例上运行,所述运行时环境诸如本地控制器、边缘节点或云服务器,特别地自动确定所述服务是否应该在本地、在边缘节点上或在云中运行。9.根据前述权利要求中任一项所述的方法,还包括:针对所述多个服务中的一个或多个服务中的每个服务,以以下方式存储所述整体关键程度和/或所述分布式异构计算基础设施(3)的所述服务应该在其上运行的功能部分(3a、3b、3c):所述整体关键程度和/或所述功能部分(3a、3b、3c)能够由执行所述控制应用的计算系统访问。10.根据权利要求8或9所述的方法,其中确定所述服务应该在分布式异构计算基础设施(3)的哪个功能部分(3a、3b、3c)上运行包括:基于预定距离度量,针对所述分布式异构计算基础设施(3)的所述功能部分(3a、3b、3c)中的每个功能部分,确定所述服务的需求向量与所述功能部分(3a、3b、3c)的能力向量之间的距离;和/或针对所述分布式异构计算基础设施(3)的所述功能部分(3a、3b、3c)中的每个功能部分,确定所述功能部分的能力向量的条目中的一个或多个条目是否等于或大于所述服务的需求向量中的对应条目。11.根据前述权利要求中任一项所述的方法,包括:针对所述工业车间的过程拓扑的至少一个元素,例如针对所述工业车间(2)的区域、单元、模块中的至少一个或设备(2a、2b、2c)中的至少一个,自动识别所述多个服务中的在控制和/或监测所述过程拓扑的所述元素时所涉及的子集,并且将所述子集组装成元素专用代码包,同时保持所述服务在所述代码包中分离。12.根据前述权利要求中任一项所述的方法,还包括自动生成胶合代码,所述胶合代码被配置为确保在分割所述初始代码和创建服务的过程中、对所述初始代码作出的任何改变不会破坏所述初始代码的功能,特别地,所述胶合代码被配置为允许所述服务的完全集成,特别地,其中自动生成胶合代码包括生成附加的i/o变量,特别地自动生成胶合代码包括生成附加的i/o变量和通信qos,所述通信qos用于传送在所述分割之后必须在至少两个服务之间共享的数据。13.根据前述权利要求中任一项所述的方法,其中,针对所述服务的所述分割和/或所述创建,指标从所述初始控制代码和/或从所述dcs和/或从工程数据被导出,例如所述指标从与信号限制相关的警报关键程度被导出。14.一种将由权利要求1至13中任一项所述的方法提供的所述控制应用用于控制和/或监测工业车间(2)的运行的用途,特别地,所述用途包括在分布式计算系统(3)中执行所述控制应用,所述分布式计算系统(3)包括位于所述工业车间的现场的本地计算系统(3a),以及与所述工业车间(3)相关联的边缘计算系统(3b)和云计算系统(3c)中的至少一者,特别地,其中执行所述控制应用包括在所述本地计算系统(3a)上执行所述服务的第一子集,以及在所述边缘计算系统(3b)上执行所述服务的第二子集和在所述云计算系统(3c)上执行所述服务的第三子集中的至少一者。15.一种数据处理系统(1),包括用于执行根据权利要求1至13中任一项所述的方法的装置。
16.一种计算机程序产品,包括指令,当所述程序由计算机执行时,所述指令使所述计算机执行根据权利要求1至13中任一项所述的方法,或一种计算机可读介质,包括指令,所述指令在由计算机执行时使所述计算机执行根据权利要求1至13中任一项所述的方法。
技术总结
本公开的一个或多个实施例涉及用于提供用于工业车间的基于服务的控制应用的方法。本发明提供了一种用于提供用于工业车间的基于服务的控制应用的计算机实现的方法。该方法包括将工业车间的初始控制代码自动分割成多个代码块,并且自动创建多个服务,每个服务实现多个代码块中的一个或多个代码块的功能。考虑到分配给多个代码块中的每个代码块的关键程度的相似性来执行多个服务的自动创建,使得具有更相似的关键程度的代码块更可能在同一服务内实现。务内实现。务内实现。
技术研发人员:迪尔克
受保护的技术使用者:ABB瑞士股份有限公司
技术研发日:2023.02.01
技术公布日:2023/8/4
版权声明
本文仅代表作者观点,不代表航空之家立场。
本文系作者授权航家号发表,未经原创作者书面授权,任何单位或个人不得引用、复制、转载、摘编、链接或以其他任何方式复制发表。任何单位或个人在获得书面授权使用航空之家内容时,须注明作者及来源 “航空之家”。如非法使用航空之家的部分或全部内容的,航空之家将依法追究其法律责任。(航空之家官方QQ:2926969996)
飞行汽车 https://www.autovtol.com/
