习近平总书记在中国科协第十次全国代表大会上的讲话中提到:“以信息技术、人工智能为代表的新兴科技快速发展,大大拓展了时间、空间和人们认知范围,人类正在进入一个人机物三元融合的万物智能互联时代”。如图1所示,随着人类社会、信息系统、物理空间(人机物)的不断融合,一种新的计算范型—泛在计算[1]也逐渐显现。泛在计算的发展预示着人机物融合不断向更大范围和更高层次发展,最终在万物互联的基础上并通过“软件定义”的途径实现面向用户需求和应用场景的人机物资源的按需汇聚、统一编程和敏捷协同,从而形成一种跨越人机物三元空间的超级自动化(Hyperautomation)。由此形成的人机物融合系统也将具有广义的“云化”特性并在此基础上形成开发运维一体化(DevOps)。

图1.人机物融合

本文将围绕人机物融合泛在计算阐述三个方面的问题:不同层次上的人机物融合以及泛在计算的出现;基于人机物融合泛在计算所形成的面向万物互联的超级自动化;人机物融合系统的开发运维一体化。

从人机物融合到泛在计算

人机物融合可以在多个不同的层次上存在,如图2所示。任何具备信息物理融合系统(即CPS)特性的设备,例如智能汽车、无人机/无人车、机器人,都可以被认为是一种人机物融合系统,因为其中融合了物理组件(如动力及刹车装置、机械臂等)与软件组件(如感知和控制算法),有时还会以人机交互的方式融入人的行为(如智能汽车中的驾驶员)。在更高的层次上,一定区域内的人机物资源可以在更大范围内以物理时空为基础和背景进行融合,并逐层复合形成更大的人机物融合系统。

图2. 不同层次上的人机物融合

随着层次的提高,所涉及的人机物资源粒度及参与融合的人机物资源规模越来越大,但人机物耦合程度越来越低。例如,在单设备(如单台智能汽车)上,所涉及的物理资源是车上的传感和控制单元,信息资源包括车上负责感知、决策和控制等功能的软件模块,相互之间的耦合度及实时性要求都比较高,而其中的人(例如驾驶员或乘客)的感知和操控行为与车载系统也有很深的耦合。在更高层的区域管理(如一个区域内的车路云一体化系统)中,所涉及的物理资源则包括所接入并管理的大量有人/无人车辆、无人机等设备,人力资源包括接受管理的保安及其他各类工作人员,信息资源则包括更大规模的管理和调度软件。这个层次上经常需要以一种云化的方式管理同类资源的多个实例(如同一型号的无人车),资源之间的耦合程度以及相应的实时性要求相对都比较低。

事实上,各个层次上的人机物融合系统都体现了泛在计算的特性,即计算无缝融入物理环境,无处不在、无迹可寻,同时具有软件定义一切、万物均需互联、一切皆可编程、人机物自然交互等基本特征[1]。只是在单设备(如单台智能汽车)上,系统所管理的资源数量比较有限,计算融入物理环境的方式具有鲜明的自动控制特征,且实时性要求较高。在更高的层次上以及更大范围内的人机物融合系统(如一个区域内的车路云一体化系统)中,系统所管理的资源数量较多且同类资源经常存在多个实例(如同一型号的无人车),计算融入物理环境的方式表现为更大粒度上的资源调度(如无人车调度)和跨界的服务编排(如人员、车辆和商业服务的混和编排)。

这种人机物融合泛在计算模式带来了全方位的挑战:既需要面临“云-管-边-端-物”乃至“人”的海量异构资源尤其是各种泛在化的“端”资源的有效管理,也需要进行各种多样化的新型应用的共性凝练,还需要支持和适应场景动态多变的复杂泛在计算环境,应对开放环境带来的安全可信挑战[1]。为了支持人机物泛在资源的管理和调度以及泛在应用的开发运行,我们需要新型系统软件的支撑,即泛在操作系统。泛在操作系统在“广义”上可以用于指代基于单机操作系统(节点操作系统)、面向网络环境与场景的新型“中间件”层系统软件[1]。按照这一定义,单设备上的人机物融合系统支撑软件更像是一种节点操作系统,而更高层次上的人机物融合系统支撑软件具有更鲜明的泛在操作系统特征。例如,当前智能汽车正在从分布式架构、域集中式架构向车辆集中式架构发展,最终将实现集中式硬件和算力基础上的统一虚拟化和节点操作系统(如Linux)部署。而在更高层次上的车路云一体化系统通过新一代信息与通信技术将人、车、路、云的物理空间、信息空间融合为一体,基于系统协同感知、决策与控制,实现智能网联汽车交通系统安全、节能、舒适及高效运行[3]。这种车路云一体化系统背后的支撑软件具有更加鲜明的泛在操作系统特征。

面向万物互联的超级自动化

泛在计算要求硬件资源、数据资源、软件平台、应用软件具有柔性灵活的软件定义能力、动态适配能力、泛在互联能力和自然交互能力[1]。其中,软件定义能力是人机物融合泛在计算系统的重要基础。软件在人机物融合系统中扮演着万能集成器的角色,各种人机物资源以软件实体的形式实现状态和能力等方面的封装,向上提供软件编程能力。对于人力和物理资源而言,实现软件定义能力的前提是物理世界的数字化:人力资源可以借助移动设备实现状态报告(如实时位置)和任务分配(如通过移动设备下达指令);而物理资源则需要借助各种传感器和控制器实现状态报告(如停车位是否可用)和控制命令(如停车位开放使用)。对于软件和信息资源而言,实现软件定义能力的关键是打破原有系统边界、解构原有系统能力并通过多种方式开放相关API。

事实上,基于各种传感器、控制器和智能设备所实现的面向万物互联的新型数字化已经推动了很多人机物融合应用的涌现,如图3所示。这些应用以一种特定(ad hoc)的方式实现,普通用户难以根据自己的需求和偏好进行定制和扩展。同时,这种应用所覆盖的人机物融合场景比较碎片化,难以以人为中心形成持续的智能化服务。例如,一个用户在家中享受智能家居服务,从家里出门后进入一辆智能汽车,到达单位所在的写字楼停车场停好车后通过电梯进入办公场所,在这整个过程中智能化服务并不总是能够覆盖而且不同的智能化系统(如智能家居系统、智能汽车系统、智能停车场系统、智能楼宇系统)之间也往往是割裂的。

图3. 物理世界的数字化

理想的人机物融合泛在计算系统应当实现面向万物互联的超级自动化(Hyperautomation)[2]。超级自动化连续三年被Gartner列为战略级技术趋势之一,其目标是利用RPA(Robotic Process Automation,机器人流程自动化)以及其他AI技术打破企业组织壁垒和资源孤岛(业务、应用、数据)、打通不同部门以及不同系统之间的协作流、执行流、数据流,从而实现高度的流程自动化,并进一步实现数据驱动的全局业务优化和创新。与之相似,人机物融合泛在计算系统以软件定义为手段打破人机物三元空间之间的界限以及原有的软件及信息化系统边界,实现人机物资源的按需汇聚、统一编程和敏捷协同。

一个人机物融合应用编程的实例如图4所示,其中实现了一个智慧办公中的VIP来访接待应用。在此应用中,VIP客户来访触发迎宾机器人播报欢迎词和咖啡机开始制作咖啡,然后迎宾机器人根据所查询和确定的会议室引导VIP客户到会议室,而送餐机器人则根据控制指令在咖啡制作好之后取咖啡(在机械臂的协助下)并送到相应会议室。这一应用建立在办公场所的数字化模型基础上,同时通过融合感知实现人机物融合空间中相关事件(如VIP来访、咖啡制作完成)等抽取以及对象属性(如会议室是否空闲、咖啡机工作状态)的更新。其中的物理资源(如咖啡机、不同型号机器人)以软件定义的方式实现控制命令,例如迎宾机器人的语音播报(播报内容作为参数)、引领访客(来访人、引领目的地为参数)能力的软件接口封装。此外,当应用运行时,系统需要基于时空约束实现资源实例的绑定,例如根据位置、距离和空闲状态调度某台送餐机器人去去送咖啡。

图4. 人机物融合应用编程

在人机物资源能力软件定义的基础上,我们还可以利用大模型(如GPT-4)实现人机物融合应用程序的自动生成。例如,在之前的分享《动动嘴就能喝上咖啡,ChatGPT做到了》中,我们机器人软件工程研究组在咖啡机、机械臂和送餐机器人基本能力封装(如make_coffee、get_cup、put_cup、dispatch)的基础上实现了机器人送咖啡场景的程序自动生成;在另一个分享《基于GPT-4的人机物融合应用构造实践》中,我们人机物融合系统研究组在办公楼环境数字化表示(如实验室、会议室、走廊以及温度、人数等属性)以及设备能力封装(如开关灯、开关空调等)的基础上实现了一系列TAP(Trigger-Action Programming)程序的自动生成。

云原生与开发运维一体化

与互联网以及企业IT系统中软件架构及开发过程的演化趋势类似,人机物融合泛在计算系统也会逐渐从软件化(IT化)向云化和云原生化的方向发展,如图5所示。这里的云化和云原生化有以下两层含义。

  • 计算资源层面:随着KubeEdge等云原生边缘计算系统的应用,Kubernetes等容器编排框架的能力向边缘延伸,从而使人机物融合应用软件可以以容器化的方式在中心云和边缘节点上部署并实现容器资源的弹性伸缩和优化调度。

  • 泛化的人机物资源层面:系统中以软件定义的方式接入并管理的人力资源(如保安)和物理设备资源(如无人车、咖啡机)在经过能力抽象后可以以类似于云计算资源的方式进行调度和管理并支撑上层的人机物融合应用。

图5. 人机物融合泛在计算与云原生和开发运维一体化

需要注意的是,虽然在抽象层面上都具有“云化资源”属性,但计算资源和泛化的人机物资源在管理和调度方法上存在着很大的区别。首先,人力和物理资源都存在于现实物理世界中,需要考虑位置、速度、电量等方面的物理规律及约束。例如,调度机器人完成特定任务时需要考虑机器人是否能在一定时间内从当前位置到达指定位置,并有足够的电量来支撑其完成任务。其次,人力和物理资源在接入稳定性以及资源可用性上存在较大的不确定性。例如,无人车在不断移动的过程中其网络连接也一直处于不稳定的状态,而人力资源则更是由于自身心理和生理状态的变化而具有较大的不确定性。最后,人力和物理资源具有显著的领域特征和业务特性,其管理和调度方法需要考虑这些因素。例如,封闭园区中的无人车与开放道路上的乘用车在管理和调度方法上具有显著的差异。

互联网以及企业IT系统的云原生化支撑了开发运维一体化(DevOps),甚至很多人认为DevOps本身就是云原生的基本内涵之一。DevOps打通了软件开发与运维,将敏捷开发所倡导的持续交付、快速反馈、敏捷迭代的思想发挥到了极致:软件开发更新通过自动化的持续集成和持续部署流水线快速部署上线,运维阶段良好的可观测性确保可以及时获得更新后的软件运行反馈并推动后续的软件开发迭代。云原生软件架构及相应的云基础设施为DevOps的实现提供了有力的支持,例如云原生基础设施对于系统的可观测性提供了有力的支持,而松耦合、支持独立发布和部署的微服务架构为软件的持续更新和可用性保障打下了基础。在此基础上,BizDevOps进一步将业务目标和业务价值融入开发和运维的反馈环路中。

人机物融合泛在计算系统在快速反馈和敏捷迭代等方面具有与互联网以及企业IT系统类似的需求,并且这类系统由于天然与业务和应用场景融为一体因此对于业务、开发、运维之间的快速反馈(即BizDevOps)具有更加显著的需求。软件定义和云原生化是人机物融合泛在计算系统实现开发运维一体化的基础支撑。如图6所示,人力/物理资源及感知资源通过软件化的资源孪生和相应的管理调度机制接入人机物融合应用,使得应用可以以一种与资源实例无关的方式进行开发,例如应用逻辑中包含对于无人车配送的请求但并不关心平台调度哪一辆无人车来满足请求(就像微服务系统中的服务动态发现与实例绑定)。

人机物融合泛在计算系统的开发运维一体化有赖于可观测性体系的建立以及不同层面上软件的持续迭代更新。

  • 可观测性:通过各种物理和软硬件监测手段收集各种可观测性数据(如日志、链路、指标等),在此基础上计算人机物融合应用服务完成率、满意度、用户体验等多方面的观测结果作为反馈信息。

  • 应用逻辑更新:针对人机物融合应用层的各种应用服务(包括一般软件服务以及深度学习模型的AI服务)实现动态更新,在云边融合云原生基础平台的支持下实现服务动态更新的同时保持系统的高可用性。

  • 资源调度策略更新:人力/物理资源以及感知资源的调度本身与特定领域业务密切相关,其自身也可能需要进行动态更新,由于这部分本身是软件化的实现因此可以在容器平台的支持下持续进行更新。

图6. 人机物融合泛在计算系统框架结构

结束语

人机物融合泛在计算将云计算的思想拓展到人机物三元空间,实现多元资源的虚拟化,按需融合信息、物理、人力资源及服务,实现各种现实世界需求和应用场景。人机物融合泛在计算通过软件定义方法及智能化技术实现面向万物互联的超级自动化,为此需要在资源抽象和虚拟化的基础上建立人机物融合应用平台及相应的低代码“编程”体系,同时通过云原生边缘计算支持各种设备接入和管理以及多种算力保障(如AI算力)。在此基础上,可以进一步建立面向人机物融合应用的“开发运维一体化”,实现快速反馈、敏捷适应、持续演进等方面的目标。

参考文献

[1] 梅宏, 曹东刚, 谢涛. 泛在操作系统:面向人机物融合泛在计算的新蓝海. 中国科学院院刊, 2022, 37(1): 30-37. DOI: 10.16418/j.issn.1000-3045.20211117009

[2] 精鲲张欣:iPaaS解码超能力 从集成走向超级自动化的组合式创新 WISE2022 “解码超能力”超自动化峰会. https://mp.weixin.qq.com/s/dBWG2O3xEgijpvNiFc4nwQ.

[3] 中国智能网联汽车产业创新联盟. 车路云一体化系统白皮书. 2023年1月.

作者简介

彭鑫,复旦大学计算机科学技术学院副院长、教授,中国计算机学会(CCF)杰出会员、软件工程专委会副主任、开源发展委员会常务委员,IEEE高级会员,《Journal of Software: Evolution and Process》联合主编,《ACM Transactions on Software Engineering and Methodology》编委,《软件学报》编委,《Empirical Software Engineering》编委。主要研究方向包括软件智能化开发与运维、人机物融合泛在计算、机器人软件工程等。

声明:本文来自CodeWisdom,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。