数据定义:数字化控制系统技术分析-4
数字化控制系统中任何设备都可能故障,即使在同一台算力设备中,作为进程或线程运行的软件功能模块也有可能故障,这些故障各不相同,且故障出现的时机也是随机的,当代数字化系统仅做到了“高内聚、松耦合”,并没有做到完全解耦的无耦合,一个功能模块故障可能会引起一系列的连锁反应,这给故障监测、故障定位、故障隔离带来了极大的复杂性,当代系统设计只能作出折衷取舍,通过冗余系统来解决一些致命故障,忽略非致命性故障检测
3、当代数字化控制系统之工业信息化下的数据处理
我们认为工业信息化的结果是多样场景且繁杂,对应的是数据也是多样且繁杂,有很多数据是可用的、可信的,但在实际应用场景中,有价值的数据非常有限,主要原因:
(1)没有统一数据标准;
(2)因工业工作流程问题造成数据关联度长且复杂,建模难度大,价值挖掘较难。
(3)数据量庞大;
(4)缺乏数据安全合理策略。
这种原因导致企图使用第三方服务平台来存储这些数据本身就是一个极大的挑战。
对于工业设备设施来说,历史数据资源为设计闭环、仿真训练、事故鉴定、健康管理等各个方面起到非常重要的作用,数据资源本身也是一种资产,其数据安全是一项十分重要的课题。云计算即使是私有云,对于单平台设备来说,仍然是第三方平台,难以做到绝对的安全防范。
只有将计算放在“根”(设备内部或设备拥有方指定的位置),并且在特定的硬件中才能做到最高程度的安全防范,即开放什么,他人才能访问与控制什么,这些访问和控制内容与设备本身的运行环境使用中间存储来进行隔离,当出现第三方非法控制时能够手动或自主切断第三方控制,并通过预留的安全通道进行有效控制:
(1)“根”负责过程计算与存储:根计算、根存储保证数据与控制的安全性,且容易做到按需配置,也易于扩展;
(2)“云”负责历史数据使用:利用云计算的大数据处理优势易于构建预测系统、健康管理等功能。
当代系统设计企图将云计算、云存储等互连网技术应用到工业控制平台产品的设计,以虚拟化、容器化、面向服务等技术来实现平台内、平台间系统解耦的技术路线是本质上的误区,在工业领域,云技术、云存储应以工业产品的“私有特性”,重新分配其功能,以“数据信息地址”为对象管理分布式历史数据,以“面向智能化计算模块”为对象管理平台内某项功能的计算。云计算技术、云存储技术应服从平台功能设计技术和数据管理技术,而不是将现有云计算技术、云存储技术应用于工业产品的设计。

图14 具备隔离功能的云根协同系统
4、数字化控制系统的群协同发展分析
多模态、多平台、跨域间的群协同是实际运用的一个结果和需求。
我们目前的在数字化控制系统的群协同研究和开发主要集中协同算法、任务控制、通信网络等方面。而在面对跨平台、跨领域、跨载荷、跨周期的应用中,互连互通、互操作是一个重要的部分:(1)互连互通是手段;
(2)互操作是目的。
但至于如何达到上述两种目的,至目前在面向不同场景、不同领域时,国内没有一个标准的或是精确的定义。
一般公认互操作内涵:
(1)一种是IEEE定义的“互操作是两个或多个系统或组成部分之间交换信息以及使用已交换信息的能力”;
(2)一种是美国国防部定义的“互操作是系统、单元或军队其它系统之间提供或接受服务,并一起高效合作的能力”。
目前的群协同的技术路线主要体现在无人系统、有人系统、任务载荷系统等互连互通互操作,实现数据、信息、服务等资源共享。除此之外,还体现在指挥控制系统一方面能够采用同一控制单元分时或同时控制、监测多个不同类型的无人系统及其任务载荷,另一方面是一个无人平台及其载荷能够被不同指挥控制单元控制或监测。
互操作体系架构的内涵还主要体现在网络通信分层架构。
在系统总体架构、软件体系架构、协同系统架构方面,由于跨领域平台涉及到机载、车载、舰载、任务载荷等各类异构系统的差异性,往往都是从网络互连、开放式软件框架等系统架构(SA,System Architecture)方面,对于跨领域或领域融合的体系架构(SoSA,System of Systems Architecture)还处于探索中,缺乏相应的理论支持和工程验证实践。
正因为互操作内涵的技术导向,当代系统对群协同的组成单元仅划分到单个平台,将群协同当作是一个跨领域、跨平台巨系统。
由于群协同往往针对某一共识目标而装载的单独任务系统设备,因此往往又会要求跨任务载荷,这是从载具(单平台)和任务系统的角度来看待群协同,但究其本质,运载工具的移动能力本身也是一项任务,而任务载荷的设备如信号发射机、传感器、武器等与运载工具本身的感知或执行设备在本质上是一致的,都是数据字化系统感知-决策-执行环节中的设备设施。
群协同巨系统中,由于网络的异构、平台功能的异构、操作系统的异构、编程语言的异构等各个方面,导致系统设计时无法做到完全的硬件抽象,功能模型始终与“连接逻辑”处于耦合状态,即使采用了通信中间件来实现软件与硬件的解耦,功能模块又与中间件的数据服务模块产生连接逻辑。各个平台之间由于缺乏统一的步进时钟触发,在各自的步进周期中,所交换的数据又与“时序、时刻”处于紧耦合状态。只能通过将一些通用的技术封装为“服务”,通过服务为功能模块提供数据来做到松耦合。
在单平台内部,每一个分/子系统实际上也是一个独立的数字化控制系统,即使是同一算力设备中的每一个功能模块单元,仍然还是一个数字化控制系统,如果从数据处理的角度来看待最小颗粒度的功能模型、分/子系统、单平台直至多平台群协同,它们具有共同的特性:输入数据-决策计算-输出数据,唯一不同的是数据源的多少。因此,如果以“面向数据”的视角来看,从平台内单个设备中的功能模型微观单元一直到以平台为单位的宏观单元,其本质是完全一样的:

图15 面向数据的体系级一致性:万物协同
以“面向数据”的理念来看待整个系统设计,就能够将系统划分的颗粒度最小化到单个功能模块,通过硬件抽象和软件抽象来忽略异构连接,使单平台内部微观环境直至海陆空天宏观环境具备相同的特性。从最小化单个功能模型à分/子系统à单平台,仅仅是系统的规模不同,多平台协同的本质也仅仅是单平台具备了“多源数据”处理的能力,能够在不同场景下生产或消费不同的数据源。
将网络互连互通和步进时钟调度从任务计算的功能模块中剥离出来,并以平台的方式来支撑不同规模的计算过程,不难发现,从单个功能模型直至群协同巨系统,每一个组成单元都有其“整体性”和“独立性”,差别仅在于颗粒度大小不同,而“群协同”只是单平台增加了一项功能:

图16 万物协同的统一解决方案
不难看出,相对于上一代的单平台,支持群协同的系统设计有以下特点:
(1)数据源、数据量增加:能够接收到其它平台的感知信息或决策控制数据,也能将自身的感知信息或决策控制数据发送给其它平台;
(2)协同算法增加:协同算法在系统设计中只是一个任务功能,需要的是算力资源、存储资源硬件提升,但不会因为有协同算法导致软系统架构发生改变;
(3)无线网络增加:平台间无法使用有线网络,往往采用数据链、无线自组网、5G等网络接口,对于单个平台来说,只是增加了异构网络端口,本身也不会改变平台内异构、导步分布式系统的本质。
群协同的本质是单平台包括算法、网络、算力、存储等综合能力的提升,只是当代单平台的软硬件架构是一个“决定与被决定”的关系,采用的“面向服务的集中式计算架构”限制了电子电气平台的伸缩性,平台承载能力难以扩展。即使在当代的软硬件系统架构上实现了群协同,紧接着又会而临现有产品的改造与集成,将付出更高的成本和研发时间。
七、异构、异步分布式系统设计面临的挑战
分布式的概念不仅在物理节点之间,也延伸到算力设备内部软件模型之间。
当代数字化控制系统及其未来都是异构、异步分布式系统的体现。这种异构、异步相对于集中式计算而言,系统设计需要更复杂的交叉协调、功能构建、维护管理,同时也意味着应用软件系统的根源问题更难以发现。
复杂系统设计时,应用层系统设计将遇到以下挑战:
1、时间处理是系统设计最大的难点
单机内功能模型协同、单平台内多机协同、多平台机间协同,这些紧密且相互依赖(因果关系)需要对功能模型产生的“执行动作”具有时间上的共识,即单一全局时钟,而全局时钟又必须通过网络的通信动作才能到达各个分布式功能模块,这使得全局时钟在各个分布式节点直至分布式功能模块的准确性受到极大的限制,即使物理硬件达到微秒级,到功能模块时受操作系统本身的影响可能已达到毫秒级甚至十几或几十毫秒级。当代数字化控制系统受限于这种特性不得已采用更高实时性的操作系统、更高性能的网络硬件、更高性能的算力设备。但即使采用这种策略,全局时钟在分布式节点间的同步过程受数据交换(时钟同步帧与数据帧在传输时产生链路竞争)的影响产生不确定的抖动,这种影响是物理网络本身无法解决的;
2、异构性导致更大的劳动强度
在过去近50年里,工业网络、总线的协议超过2000多种,而近年来还会有各种网络、总线在不断推出,系统设计时需要将这些异构网络/总线在多种算力平台、多种操作系统、多种编程语言实现。在当代越来越复杂的数字化系统中,系统所分解的功能模块也越来越多,功能模块之间的应用层数据交互协议也在剧增,系统设计的复杂度、发现问题的难度、设计修改时大规模重复性测试工作量等各个方面都在剧增,这些问题又会导致管理的复杂度和难度;
3、故障独立性难以实现
数字化控制系统中任何设备都可能故障,即使在同一台算力设备中,作为进程或线程运行的软件功能模块也有可能故障,这些故障各不相同,且故障出现的时机也是随机的,当代数字化系统仅做到了“高内聚、松耦合”,并没有做到完全解耦的无耦合,一个功能模块故障可能会引起一系列的连锁反应,这给故障监测、故障定位、故障隔离带来了极大的复杂性,当代系统设计只能作出折衷取舍,通过冗余系统来解决一些致命故障,忽略非致命性故障检测、定位与隔离;
4、数据一致性难以实现
数据分散在不同的分布式节点或分布式功能模块中,通过网络通信动作复制到各个节点或各个功能模块。当代智能化算法对数据集中(整体性、全局性)要求越来越高,即某个节点或某些节点可能需要所有的数据才能完成功能算法,最典型的是“全机数据监控”、“全机数据存储”(尽管目前全球性未做到),这些数据在网络中交叉反复传输才能做到。应用层系统设计时往往设计为步进同步模式,而且对同步精度要求非常高,但正因为这种高精度同步模式,有可能导致众多设备在同一时刻出现“并发竞争”关系(如当代飞机试飞测试时的测试设备通过GPS将时钟同步到纳秒级,各个测试设备在同一时刻向网络交换机发送数据),交换机由于机内存储(片上存储)较少,即使只使用10%的带宽,也会发生大量的丢包现象,数据一致性、完整性难以保障。即使在网络平台上保证了数据的一致性,应用层软件功能模型在消费数据时也受线程运行周期影响,所使用的数据也可能出现不一致性;
5、可伸缩性难以实现
系统可伸缩性不仅表现在最终的产品级功能增加、减少(平台承载能力),也体现在设计验证过程中从单模块直至整机联调联试,还会体现在功能模块在设计完成后在平台内算力设备群中的功能迁移,甚至还体现在平台运行时节点故障后的功能重构等环节。当代系统设计观念还只关注到平台设备级的可扩展性,对设备内功能模型的可扩展性未关注到。
上述比较典型问题导致当代系统设计的高技术壁垒和高额研发成本,而未来更高复杂度的多功能单平台(如海际空多栖平台)、多平台群协同(海陆空天巨系统)的分布式控制系统的设计面临更多的问题和更高的技术壁垒。从单模块设计-单设备设计-单平台设计-多平台协同任何一个环节其实都面临众多问题,这些问题又覆盖了平台的全寿命周期从方案论证à设计验证à测试验收à仿真训练à维修诊断à退役处理各个阶段、各个领域。
如果没有一个体系级的全面需求牵引来规划未来数字化控制系统的各个层级功能分配、性能分配,做到“跨领域、跨平台、跨任务载荷、跨全寿命周期”统一解决方案,未来的系统设计必然面临“高技术壁垒、高成本、高劳动强度”三大弊病,特别是在“领域融合、多功能可组合、多功能可重构”等未来产品设计上带来更大的障碍。
更多推荐



所有评论(0)