1.基础准备下载并解压软件包本地环境下载文件服务器安装包，云上环境使用本地虚拟机下载后scp[root@k8s-master-node1 ~]# wget http://172.128.10.10/KubeEdge/KubeEdge1.11.zip [root@k8s-master-node1 ~]# unzip KubeEdge1.11.zip解压并安装keadm[root@k8s-master-node1 ~]# cd KubeEdge1.11/ [root@k8s-master-node1 KubeEdge1.11]# tar xf keadm-v1.11.1-linux-amd64.tar.gz [root@k8s-master-node1 KubeEdge1.11]# cp keadm-v1.11.1-linux-amd64/keadm/keadm /usr/local/bin/加载部署镜像[root@k8s-master-node1 ~]# cd /root/KubeEdge1.11 [root@k8s-master-node1 KubeEdge1.11]# docker load -i cloudcore.tar [root@k8s-master-node1 KubeEdge1.11]# docker load -i installation.tar [root@k8s-master-node1 KubeEdge1.11]# docker load -i kubeedge_pause.tar [root@k8s-master-node1 KubeEdge1.11]# docker load -i pause.tar [root@k8s-master-node1 KubeEdge1.11]# docker load -i mosquitto.tar 拷贝离线部署文件keadm快速部署需要将文件拷贝到对应路径下[root@k8s-master-node1 KubeEdge1.11]# mkdir /etc/kubeedge [root@k8s-master-node1 KubeEdge1.11]# tar xf kubeedge-1.11.1.tar.gz [root@k8s-master-node1 KubeEdge1.11]# cp kubeedge-v1.11.1-linux-amd64.tar.gz /etc/kubeedge/ [root@k8s-master-node1 KubeEdge1.11]# cp -rpf kubeedge-1.11.1/build/crds /etc/kubeedge/ [root@k8s-master-node1 KubeEdge1.11]# cp checksum_kubeedge-v1.11.1-linux-amd64.tar.gz.txt /etc/kubeedge2.部署云端节点--advertise-address 应当为公网地址(非公网环境则为可以互通的地址)使用keadm命令安装云端节点拷贝离线安装文件至配置目录，keadm会联网检测文件的完整性后即可开始离线安装报错连接超时可以多次尝试[root@k8s-master-node1 KubeEdge1.11]# keadm deprecated init --kubeedge-version 1.11.1 --advertise-address 49.234.105.98 --tarballpath /etc/kubeedge/ 3.证书配置配置双端Stream以支持查看边缘node监控指标与Pod日志生成cloudStream证书私网环境请替换IP[root@k8s-master-node1 KubeEdge1.11]# CLOUDCOREIPS=49.234.105.98 ./kubeedge-1.11.1/build/tools/certgen.sh stream 4.启动云端节点修改配置文件以开启对应组件[root@k8s-master-node1 KubeEdge1.11]# vim /etc/kubeedge/config/cloudcore.yaml 43 cloudStream: 44 enable: true 105 router: 107 enable: true启动服务停止服务以便systemmd管理[root@k8s-master-node1 KubeEdge1.11]# pkill cloudcore [root@k8s-master-node1 KubeEdge1.11]# kill -9 50337配置systemd管理cloudcore[root@k8s-master-node1 KubeEdge1.11]# cp /etc/kubeedge/cloudcore.service /etc/systemd/system/ [root@k8s-master-node1 KubeEdge1.11]# systemctl enable cloudcore --now检查服务状态[root@k8s-master-node1 KubeEdge1.11]# systemctl status cloudcore.service7.边缘节点部署以下操作在边缘节点进行1.获取云端token获取token以加入边缘节点[root@k8s-master-node1 ~]# keadm gettoken2.基础准备从云端拷贝命令ubuntu@node-1:~$ sudo scp root@49.234.105.98:/usr/local/bin/keadm /usr/local/bin/3.docker安装一键式安装docker可以参考华为云文档中Ubuntu安装docker# 用户提权 ubuntu@node-1:~$ sudo -i root@node-1:/etc/kubeedge# curl -sSL https://get.daocloud.io/docker | sh启动dockerroot@node-1:/etc/kubeedge# systemctl enable --now docker加载镜像(离线环境)镜像从云端节点拷贝联网环境可以不使用root@node-1:~# docker load -i kubeedge_pause.tar root@node-1:~# docker load -i installation.tar root@node-1:~# docker load -i mosquitto.tar后续安装需要用到仓库名称,所以我们这里统一tag名称root@node-1:~# docker tag eclipse-mosquitto:1.6.15 kubeedge/eclipse-mosquitto:1.6.15 4.关闭防火墙关闭防火墙以加入云端节点root@node-1:~# systemctl disable --now ufw5.加入节点root@node-1:~# keadm join --cloudcore-ipport=49.234.105.98:10000 --token=5f1face87297274b29e264537fa0110699d51fd5004090f3d56ed723f4ba7ecf.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2ODI2ODMzNTJ9.t2oPE13kEDfzhYJS_IzF0Ih2Ic3CgXJpXDuOrSG0HMo --image-repository kubeedge --kubeedge-version v1.11.16.配置边端支持监控此时我们发现节点的 CPU 内存信息无法统计，需要开启 KubeSphere Metrics_Server 并在 Edge 端开启 EdgeStreamroot@node-1:~# vim /etc/kubeedge/config/edgecore.yaml 36 edgeStream: 37 enable: true重启服务root@node-1:~# systemctl restart edgecore此时可以在云端查询到节点的负载情况7.云端查看节点列表以下操作在云端节点进行查看到新加入节点即可[root@k8s-master-node1 KubeEdge1.11]# kubectl get nodes8.其他操作操作错误后清除环境的做法云端节点和边缘节点都可以这样操作root@node-2:~# rm -fr /etc/kubeedge/ # 如果已经初始化完成后可以执行 root@node-2:~# keadm reset --force

【赛题任务】边缘计算是在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的分布式开放平台，就近提供边缘智能服务，满足行业数字化在敏捷联接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求。它可以作为连接物理和数字世界的桥梁，使能智能资产、智能网关、智能系统和智能服务。华为AR502H系列边缘计算网关具备强大的边缘计算能力，提供丰富的物联网接口，可扩展IP化PLC通信，积木式按需组合，广泛应用于各种物联网场景，比如智慧用能，智慧路灯，智能配电房等领域。请各个参赛团队基于华为边缘计算网关（AR502H）自行设计开发一款物联网行业应用。完成高性能，高可靠性，安全的系统实现。【案例参考】现有的体征监测仪器大多是接触式的。它们需要附着在患者身上才能进行测量和监测。 这对于需要长时间连续监测的患者来说不是很方便。非接触式生命体征监测设备会变得更加重要，因为它将有助于最大程度地减少通过接触点和接触者造成的病毒传播，更好地确保医疗保健人员的安全。随着雷达技术的发展，已能实现无接触式的人体行为、姿态、体征的感知。基于毫米波雷达的生命体征监测系统，无需佩戴任何设备，无隐私侵犯，实现无感远程监护、实时告警、连续监测等能力。【参赛支持】边缘计算网关二次开发指南（AR502H系列）即EC-IoT开发者云社区：cid:link_0技术人员在线支持     参赛并选择华为数通的参赛队伍请加入华为数通的线上答疑QQ群，边缘计算网关的专家将在QQ群及时做技术解答，并不定期进行线上培训。群号：794109174（3）硬件支持：参赛团队可与工作人员联系购买（有优惠）。序号型号厂家1毫米波雷达浙江智尔2边缘计算网关（AR502H）华为（4）工作人员：马老师 18600655781、常老师 13126863800

随着人工智能的发展，不是把数据交给算法，而是算法去处理数据，从而实现一个全新的洞察力水平。 如今，人工智能 (AI) 无处不在，使组织能够预测系统中断的可能性，推动自动驾驶汽车，并为聊天机器人或虚拟助手提供语言功能。 这些类型的人工智能用例主要依赖于集中式、基于云的人工智能，其中存储着大量的训练数据集。 然而，人们越来越倾向于让人工智能更接近源头或更接近边缘。 边缘计算在世界范围内部署了一系列网络和设备，并且数据在更接近数据生成的地方进行处理，在人工智能的支持下变得可操作。由于物联网 (IoT) 积累的海量数据，从源头就非常需要这种类型的智能。 物联网设备(例如传感器、设备或可穿戴设备)通过互联网收集和交换数据，并且通常嵌入到其他物联网设备中以提供通信网络。 例如，仓库员工佩戴的物联网设备可以在跌倒时通知管理层，并向 911 发出警报。冰箱上的物联网设备可以在牛奶不足时提醒房主，或者在搅拌器需要维护时向生物技术科学家发出信号。在这些和其他场景中，边缘人工智能在利用所有数据来开发可行的见解、采取纠正措施或提供安全方面发挥着重要作用。 边缘人工智能允许在靠近实际收集数据的地方进行计算，而不是在集中式云计算设施或异地数据中心进行计算。 当紧迫性和时机至关重要时，边缘人工智能会挑战云的能力。 例如，在自动驾驶汽车中，数据是实时捕获的，但汽车却以每小时 65 英里的速度行驶。 没有时间将数据发送到云端然后返回决策。 必须立即做出决定。边缘优势比比皆是考虑以下一些主要好处：实时决策：边缘人工智能可以帮助设备做出关键决策，而不会产生与基于云的处理相关的延迟。 例如，自动驾驶汽车可以对不断变化的路况做出快速反应，确保乘客安全。隐私和安全：边缘计算还提供安全优势。 从位置传输到云的数据可以在位置之间被黑客攻击，但是当数据在边缘本地处理时，数据不需要通过网络移动。 这在视频监控摄像头等用户隐私至关重要的应用中尤其重要。有限连接：在偏远地区或互联网连接不可靠的地方，边缘人工智能可以独立运行，提供不间断的服务。 这对于农业地区是有益的，配备边缘人工智能的无人机可以监控连接有限的地区的农作物和牲畜。降低成本：边缘人工智能减少了对大规模且昂贵的云基础设施的需求。 企业可以节省数据传输成本并立即访问数据，从而提高效率。可扩展性：边缘人工智能具有高度可扩展性，允许将其他设备轻松添加到边缘计算网络，而不会导致中央云服务器过载。可靠性：通过将人工智能分布在多个设备或节点上，边缘人工智能更具弹性。 即使一台设备发生故障，其他设备也可以继续独立运行，从而降低系统范围内发生故障的风险。安全性：除了上述可穿戴物联网设备的安全优势之外，边缘人工智能还避免了分析师手动收集数据的人身安全隐患。 例如，有人被派去分析受自然灾害影响的建筑物的结构完整性。 当检查过程自主完成时，他们能够在世界另一端办公室的安全范围内实时分析数据。生活在边缘的挑战尽管将人工智能扩展到边缘有很多好处，但它也并非没有局限性。 其中一项挑战是其有限的计算资源。 与数据中心相比，边缘设备的计算能力有限。 这可能会对需要在其上运行的人工智能模型的复杂性造成限制。此外，边缘设备通常由电池供电，而人工智能模型通常需要大量电量，并且会很快耗尽电池寿命。 然而，研究人员正在开发针对边缘设备优化的轻量级人工智能模型和算法。 这些模型在准确性和资源消耗之间取得了平衡，使边缘人工智能更加可行。另一个挑战是，虽然边缘人工智能降低了数据泄露的风险，但它可能会引起本地层面的数据隐私问题，并被视为侵入性的。尽管面临挑战，边缘人工智能仍有望实现显着增长和创新。 事实上，根据 Future Market Insights (FMI) 的数据，边缘人工智能市场预计在 2022 年至 2023 年期间将以 20.8% 的复合年增长率扩张。最新一代无线网络连接 5G 网络的推出将有助于边缘人工智能的兴起，为边缘设备提供更快、更可靠的连接。 此类用例之一是仓库或工业环境，这些环境通常依赖 Wi-Fi。他们现在能够建立一个专用的本地5G网络，连接分布在整个站点的许多设备和物联网传感器。边缘人工智能为数据收集和分析方式提供了另一种选择。 其减少的延迟、数据隐私和成本效率使许多行业的智能达到了新的水平。 不是把数据交给算法，而是算法去处理数据，从而实现一个全新的洞察力。转载自：cid:link_0

1、感觉IEF和IoT edge的功能上差别不大，都是软件对物联设备的管理，是不是有差别？貌似IoT edge专业版兼容IEF2、两者在部署的时候是部署在虚拟机上，还是Docker上？对资源的消耗有差别吗？3、这两个都能在客户处部署吗？边端自治和边边协同能做到吗？

近日有报道称，长沙县在春运期间实行城乡公交“一人一座一带”安全规定，即每位乘客均需有座且系好安全带才能参与运输，此举引发广泛关注。部分乘客表示，这个规定只到3月5日，难道3月5日之后就没有安全隐患了吗？很多老人只能在公交站苦苦等待，甚至等上一两个小时。笔者认为，虽然这一举措体现了对公共交通安全的高度重视，但若因为安全而限制了乘客的数量，公交车的优势不就不复存在了？时下位于物联网技术前沿的边缘计算处理能否提升公交的运营和服务？物联网技术通过将各种传感器、智能设备与互联网连接，实现数据实时采集、传输和处理，对于提升公交系统的安全性具有显著效果。车路协同驾驶：通过将车载智能终端、路侧单元和各类传感器收集的数据回传给边缘计算平台，可以实现车路协同。边缘计算平台利用其强大的运算能力，可以快速处理这些数据，为公交车辆提供实时的运行线路信息，从而提高行车安全性和效率。算力下沉、离线优先：边缘计算节点通常部署在网络的边缘，靠近数据源。这意味着可以在数据产生的地点就近分析处理数据，而不是将所有数据上传到云端。这样做可以减少传输延迟，提高数据处理的时效性，同时也降低了传输和存储成本。在公交车运营中，这种实时的数据处理能力对于确保乘客安全至关重要。车载传感器监控：在公交座椅上安装传感器，精确统计座位使用情况，并将数据实时传送到调度中心和乘客手机APP，乘客能准确了解即将到站车辆是否有空余座位，从而合理规划出行时间和路线。安全带监控与报警系统：物联网技术支持的安全带检测装置可以自动识别乘客是否正确佩戴安全带，并在必要时通过语音提示或驾驶室警示，确保每一位乘客遵守“一带”的规定，降低交通事故中乘客受伤的风险。实时信息分析：随着机动车数量的增长，交通压力也随之增大。边缘计算能够通过实时信息的快速分析，为交通管理带来效率的提升。在公交车运营中，这意味着可以实时监控交通状况，及时调整路线和车速，以避免拥堵和事故发生，从而保障乘客的安全。预测性维护：边缘计算还可以帮助实现公交车的预测性维护。通过对车辆状态的实时监控和分析，可以预测潜在的故障和维护需求，从而在问题发生之前进行维修，减少意外停运的风险，确保乘客的行程安全。物联网边缘计算通过提供快速的数据处理和实时响应能力，能够提升公交车的运营效率，在很大程度上增强乘客的安全性。通过融合盈电物联网边缘技术进行精细化管理和智能化服务，更能平衡安全与便利的关系，使广大居民享受到更为安全、高效、舒适的公共交通服务。未来，随着更多智慧交通项目的落地，一个更加人性化、智能化的公共交通体系在长沙县乃至全国范围内逐步成形。

      边缘计算是什么呢?简单点讲，就是把本来属于中心节点做的计算下放到边缘节点来做。那么在本来，对于数据进行处理、计算，这都是平台层所做的事情，但是现在，网关可以进行一部分不是特别重要的数据的计算，并且将这些计算过的数据及时地反馈给终端设备来达到低时延的效果。这么做，一定程度上有效地保护了用户的边缘隐私，也达到了降低成本的目的。因为对于中心节点来讲，并不是所有收集到的数据都是有用的，有些没有必要的数据就可以交给边缘节点来处理，相当于边缘节点给中心节点分担了一部分压力，这祥做可以达到降低成本的效果。      过去数据处理的方式与上图相同，数据从设备产生，并且上传到网关，但是网关没有计算能力，就只能充当一个传输的作用，之后再把数据上传到云端来进行处理。但是现在不一样了，当网关具备了计算能力之后，它可以先把要求低的一些数据先帮远端处理了，但是要注意的是处理完了之后还是要向中心节点反馈“数据已经处理过了”的一个信息。      边缘计算就是一个结合了网络、计算、存储、应用的开放平台。同时它的架构分层可以和物联网的架构分层来做一个类比，它被分为了设备域、网络域、数据域和应用域。虽然说边缘计算的位置是位于感知层和网络层之间的，但是边缘层所具备的能力可以使他分成这样四层的架构提供和物联网四层架构模型相同的能力。      边缘计算的架构分层其实就是将设备和网关中间的这一段内容进行了分层，将原来属于物联网架构中两层的架构进行了细分，分成了四层。在边缘计算架构中，设备域与感知层相同，上面的网络域所指代的是底下的设备到网关之间的这一段网络。同时在往上的数据域指代的就是网关可以像物联网平台一样处理数据，以及向上的应用域指代的就是边缘计算当中的各种应用。

【中国，东莞，2023年11月19日】今天，以“创想无限”为主题的2023华为开发者大赛全球总决赛及颁奖典礼在华为松山湖基地圆满落幕。本届大赛开设云底座和产业两大赛道，覆盖中国以及亚太、拉美、欧洲、土耳其等区域，吸引了来自全球30多个国家和地区的19000多名开发者、3000多支团队报名参赛。 在颁奖典礼上，华为颁发了3个金奖、6个银奖、9个铜奖、7个创新奖等超过25个奖项。全球总决赛大合照本届大赛自启动报名以来，备受全球各领域开发者关注，涌现了众多具有丰富想象力和创造力的优秀作品，包括应用华为云盘古大模型和IoT等能力的智慧工地管控平台、基于华为云AI开发生产线ModelArts和端云协同开发的新一代主动式外骨骼康复产品、将华为昇腾和AI技术应用于为特殊人士打造的无障碍智能交流应用、通过华为昇思MindSpore和AI能力打造的阻塞性睡眠呼吸暂停综合征解决方案、以及通过AI技术实现原声语音自动翻译的语言转译系统等。参赛作品由评委团从技术领先性、方案创新性、商业前景等维度进行综合评审，最终评选出获奖作品。在中国赛区的企业赛道，“天图万境”团队凭借“人工智能AI感知视听空间计算技术”作品一举夺魁，荣获银奖的队伍为“深圳前海粤十信息技术有限公司”和“北京聚力维度科技有限公司”，荣获铜奖的队伍为“国蓝中天”“Motphys”“耕耘逐梦”，荣获创新奖的队伍是“万商云集”和 “云天励飞”。中国赛区企业赛道金奖在中国赛区的学生赛道，“IoT智慧铝电解”团队凭借“基于华为云IoT的铝电解能耗监测管理系统”作品荣获金奖，荣获银奖的队伍为“质感队”和 “卓越脑康”，荣获铜奖的队伍为 “一把火”“融创眼援”“智睡芯安”，荣获创新奖的队伍是“郁云守护”和 “郑信智眼队”。中国赛区学生赛道金奖在亚太赛区，“nozama”队伍凭借“Magik（虚实游戏玩具）”作品荣获金奖，荣获银奖的队伍为“DecentraRating”和“Netizen”，荣获铜奖的队伍为 “HeyHi”“SmartAM”“IC”，荣获创新奖的队伍是“Soca.AI”“Aye-Aye”“CyberWhiz”。亚太赛区金奖华为云全球生态部总裁康宁、华为云CTO张宇昕、华为公司战略与产业发展副总裁肖然等嘉宾出席了总决赛颁奖典礼并为获奖队伍颁奖。康宁在致辞中表示：“全球数字经济蓬勃发展，以云为底座的创新生态，以大模型为代表的创新技术，正在加快重塑千行万业。开发者作为创新技术生态体系的核心力量，也迎来了高速发展的新机遇。华为将在多元算力领域、AI领域、云原生核心软件领域持续突破，构筑核心技术新生态，与开发者一路同行，引领数字未来。”张宇昕表示：“开发者是用代码改变世界的人，每个开发者都在引领数字时代，开创智能世界，每个开发者都了不起！华为公司希望提供连接开发者、连接企业、连接投资人的舞台，让更多开发者投入到软件开发、投入到创造新世界的洪流当中；让更多企业开发者创新产品、创造价值、加速企业发展；让更多的资金发现创新机会，创造商业价值。华为云希望和开发者一起，用创新的技术和产品来推动世界进步，创造更加美好的智能世界！”肖然在致辞中阐述了华为在根技术领域的研发投入成果，以及全面助力开发者成功的决心和行动。他表示：“未来，华为将持续加大技术投入和创新，并通过在供应链、标准和人才等领域开放合作、包容发展，与客户、伙伴、标准组织和开发者一起推动整个产业的进步，为各行各业的数字化转型提供技术保障和价值驱动，以推动数字经济的高质量发展。”作为华为ICT领域的顶级赛事，华为开发者大赛旨在面向全球开发者全面开放华为各产业领域的技术成果，鼓励开发者发挥想象力和创新精神，用ICT技术解决实际问题、创造无限价值，与华为一起引领数字未来、共建智能世界。本届大赛总奖金达500万元，除了丰厚的奖金外，华为云同步为每支参赛队伍提供的无门槛云资源券，提供优质课程、沙箱实验等丰富的学习资源扶持和华为云开发者认证券，并通过华为云学堂持续培养和赋能开发者。同时，优秀参赛者还能获得华为云云商店KooGallery、沃土云创计划、初创计划等提供的商业成功扶持。此外，大赛额外设置人才招聘绿色通道，如华为人才市场岗位库，人才双选会门票等资源。一直以来，华为云致力于构建以开发者为核心的、开放共赢的生态体系。目前，华为云全球开发者数量已超过500万人，合作伙伴42000多家，云商店SaaS应用已达10000多个，与全国110多所高校合作培养数万名专业人才，产、学、研、用深度融合，让核心技术生态行稳致远。面向飞速发展的大模型时代，在开发者方面，华为云提供盘古大模型研发工程套件，打造开放模型社区、大模型云学堂，帮助开发者更快实现大模型的开发落地。华为云希望广大开发者基于华为的根技术，利用云上的澎湃算力和盘古大模型的强大能力，共同构建起“百模千态”的繁荣生态。面向未来，华为将加快软、硬、边、端、云等全面融合，协同华为云、鲲鹏、昇腾、鸿蒙等开发生态，持续加大投入研发创新，与全球各领域开发者一起用技术推动世界进步。

作者：华为云云原生团队▎边缘计算安全防护的实践与洞察随着开源软件安全漏洞持续引起世界各地政府和企业的关注，越来越多的组织、开发人员、研究人员和安全专家投入到开源安全工作中，在各方力量的推动下，开源安全目前已初步形成体系化的生态大网，覆盖了国际化的软件工程行业标准、安全评估体系、安全工具链与整体解决方案等，并逐步撬动整个业界开源软件安全行业的生态产业链。在2020年Linux基金会与多家硬件和软件厂商合作创立了开源软件安全基金会OpenSSF（Open Source Security Foundation），这是一个跨行业的合作组织，汇集了行业领军企业与机构，涵盖世界上最重要的软件供应链安全计划、开源开放的工具链、安全指南、培训等，旨在提高开源软件（OSS）的安全性。作为业界首个云原生边缘计算项目，KubeEdge社区致力于提升KubeEdge在云原生边缘计算场景下的安全性，将安全视为社区发展的重要指导原则。社区充分结合了业界的开源安全经验，于2022年7月完成了对KubeEdge项目的安全威胁模型分析。尽管云原生边缘计算的安全问题备受用户关注，但业界目前缺乏相关的安全威胁模型分析，这使得用户难以有效地加固其边缘系统。因此，KubeEdge社区发布了安全威胁模型及分析白皮书，为用户和厂商提供了重要的安全实践指导。下文将着重介绍Kubeedge在安全防护方面的实践，并介绍OpenSSF在开源软件安全方面的计划与目标。▎KubeEdge安全防护安全防护背景KubeEdge在边端云协同领域正在加速布局，已在智慧交通、智慧城市、智慧园区、智慧能源、智慧工厂、智慧银行、智慧工地、CDN等行业提供一体化的边端云协同解决方案。随着越来越多的用户将KubeEdge项目用于生产环境中， KubeEdge社区把安全问题放在优先地位，并成立Sig- Security 和安全团队 ，负责KubeEdge的系统安全设计，并快速响应和处理安全漏洞。为了对KubeEdge项目进行更加全面的安全评估，KubeEdge社区联合ADA LOGICS公司、OSTIF及云原生计算基金会（CNCF）对KubeEdge项目进行安全评估并输出安全评估报告，分析和总结KubeEdge项目的安全威胁模型及相关安全问题。该评估对KubeEdge项目的安全防护有重要的指导意义，感谢ADA LOGICS公司的专家Adam Korczynski和David Korczynski在该项工作中的巨大贡献，同时，感谢OSTIF的Amir Montazery和Derek Zimmer以及CNCF基金会，他们对这次评估提供了很大帮助。对于安全报告中发现的安全问题，KubeEdge社区已根据社区的漏洞处理策略第一时间完成修复，并针对v1.11、v1.10、v1.9三个版本发布了安全补丁，版本号分别为v1.11.1、v1.10.2和v1.9.4，漏洞公告已发布在cid:link_4。接下来将通过解读KubeEdge威胁模型，为边缘计算领域提供更多的安全防护经验，并在开源软件供应链安全加固工作上为更多的开源社区提供参考。威胁模型分析KubeEdge的安全审计报告指出，该系统可能受到外部攻击、内部操作人员的不当操作和供应链攻击等三种潜在攻击类型的影响。本章节使用STRIDE威胁建模方法，结合安全审计报告对KubeEdge进行了系统的安全分析，包括上述三个方面。目的是帮助开发者和用户了解系统中的潜在安全威胁、明确风险并列举出目前KubeEdge社区已有的消减机制和安全加固建议。以下人群使用KubeEdge过程中，了解KubeEdge的威胁模型分析和可能的缓解措施将对他们的工作有所帮助：• KubeEdge的贡献者：一个通用的威胁模型对KubeEdge贡献者很有用，他们可以从整体角度考虑并加固他们的系统。• 部署KubeEdge的组织：对于在集群中使用KubeEdge的组织来说，了解常见的攻击和可能的弱点是很有用的，这样他们就可以检查和评估自己的配置。• 安全评估员：负责评估KubeEdge及所属Kubernetes集群的安全性。通过了解该威胁模型，让安全评估员可以对系统的安全风险进行更加全面的评估。• KubeEdge的用户及其开发人员：需要了解KubeEdge的更新和攻击，以主动避免未来可能发生的安全风险。外部攻击分析根据STRIDE威胁建模方法对KubeEdge潜在的外部攻击进行分析，对应的数据流图如下。如数据流图所示，当数据流穿越不同的信任级别（区域）时，就存在信任边界，已在图中用红框标出。下面将详细分析KubeEdge系统架构中的信任边界（引用自KubeEdge第三方安全报告）、社区已有的消减措施并给出安全加固建议。威胁一：云端CloudCore组件与EdgeCore组件之间的连接描述：该威胁涉及边缘EdgeCore与云端CloudCore之间的连接。在这个数据流中，较低信任级别组件EdgeCore向较高信任级别组件CloudCore发起访问。由于EdgeCore在系统中拥有独立的权限级别，攻击者控制EdgeCore后，不应该能够对其他边缘节点造成负面影响，例如通过攻击和操控CloudCore来攻击其他节点（该漏洞描述引用自安全评估报告）。影响：攻击者恶意修改CloudCore与EdgeCore组件之间的请求和应答报文，导致通信过程存在仿冒和篡改的威胁风险。消减措施：• CloudCore与EdgeCore之间的通信通过数字签名证书加密和服务端/客户端双向认证的方式保障信息交互的机密性和完整性，安全加密协议使用TLS 1.2，且指定加密算法套件白名单，防止客户端使用不在白名单中的不安全算法进行通信造成安全风险；• 证书默认有效期为一年，过期后失效，防止证书被攻击者利用。用户基于KubeEdge项目已有的证书轮转机制，可以实现证书过期自动更换，保障业务连续性。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 1和2）。威胁二：边缘组件ServiceBus在本机范围内提供HTTP服务描述：边缘组件ServiceBus监听本地local host端口并在本机范围内提供HTTP服务。该数据流中，较低信任级别的用户应用进程向较高信任级别组件ServiceBus发起访问。如果发起攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：ServiceBus组件收到的数据往往是不受管理面控制的，攻击者能够对ServiceBus组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。ServiceBus组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• ServiceBus组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• 服务端接收客户端连接时记录连接访问的日志，可作为审计日志，可以让管理员及时发现攻击的发生，并及时停止ServiceBus服务，阻止攻击继续进行；• ServiceBus服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。威胁三：边缘端Device通过MQTT Broker连接到EdgeCore描述：边缘device设备通过MQTT Broker（集成在EventBus组件中）连接到EdgeCore。该数据流中，较低信任级别的用户device设备向较高信任级别组件EdgeCore发起访问（该漏洞描述引用自安全评估报告）。影响：EdgeCore组件收到的数据往往是不受管理面控制的，攻击者能够对MQTT Broker发起恶意报文攻击，存在仿冒和篡改的威胁风险。如果发起攻击导致EventBus组件异常，异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MQTT Broker仅监听在本机端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；同时，EventBus组件可作为客户端，对接外置第三方MQTT Broker，如果用户使用第三方MQTT Broker，详细的消减措施请参考对应第三方MQTT Broker服务提供厂商的安全文档。• EventBus仅对MQTT Broker中的特定Topic进行处理，用户无法通过该通道对EdgeCore任意访问。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、5和6）。威胁四：Edged管理和监控Pods及其他K8s资源描述：Edged管理和监控Pods及其他K8s资源。该数据流中，较低信任级别的应用容器与较高信任级别组件EdgeCore之间进行数据交互。如果主动发起连接时，被恶意服务器攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：如果Edged访问的CRI插件被攻击者恶意伪造，则存在CRI插件仿冒和篡改的威胁风险，导致本地业务异常。消减措施：• Edged与CRI插件通信时，只在本地访问受信任路径，由管理员控制访问路径，最小化Unix domain sockets文件描述符的权限，避免被仿冒者恶意替换。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3和7）。威胁五：MetaServer在边缘节点提供HTTP服务描述：MetaServer作为边缘“api-server”，对边缘插件提供HTTP服务。该数据流中，较低信任级别的用户应用插件向较高信任级别组件MetaServer发起访问（该漏洞描述引用自安全评估报告）。影响：MetaServer组件收到的数据往往是不受管理面控制的，攻击者能够对MetaServer组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。MetaServer组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MetaServer组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• MetaServer服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。内部攻击分析对于内部管理员或操作人员，可能的风险主要包括管理员或操作人员错误操作将恶意软件部署至集群中、在高风险场景中执行高风险配置等。消减措施：• KubeEdge用户手册中已提供各个组件的详细功能描述及配置使用指导文档 ，指导系统管理员或操作人员正确操作，减少人为误操作或误配置导致的安全风险。由于KubeEdge的持续迭代，该文档也将持续更新并完善。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、8和9）。供应链攻击分析攻击可能发生在典型软件供应链的每一个环节，而且在当今环境中，这些类型的攻击越来越公开，破坏性和代价高昂。攻击方向包括源代码完整性、构建完整性和构建产物的可用性。消减措施：• 社区联合安全公司对KubeEdge软件供应链流程已进行SLSA等级评估，并引入SLSA软件供应链安全评估框架，包括对源代码、构建流程、依赖库等进行安全评估，防止针对软件供应链的攻击，从源头上保障软件供应链的安全。值得一提的是，在2023年1月18日发布的v1.13.0版本中，KubeEdge项目已达到SLSA L3等级（包括二进制和容器镜像构件），成为CNCF社区首个达到SLSA L3等级的项目，并加入Sigstore生态系统，实现更高等级的安全标准。• KubeEdge仓库CI/CD流水线中已开启dependence bot第三方依赖库检查功能，及时发现第三方依赖库的安全漏洞并在KubeEdge版本中同步更新，降低被攻击的风险；• KubeEdge security team已具备完整漏洞处理机制，包括漏洞发现、漏洞上报、漏洞分析处理、漏洞披露和发布整个流程，可以及时处理和修复安全漏洞。详细漏洞处理及披露策略请见https://github.com/kubeedge/community/blob/master/security-team/SECURITY.md。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 10和11）。安全加固建议列表Recommendation ID描述1使用安全长度的私钥加密，并加密保存私钥。建议用户生成至少为2048位私钥，且在本地加密存储私钥，存储私钥的文件设置最小化的访问权限，仅属主可读。2使用可信来源的CA证书。从可信的CA获取数字证书，不使用自签名证书。3严格限制边缘节点的本机权限，限制外部用户的用户登录权限，减少非必要的授权。4严格限制边缘节点应用部署的权限，只有系统服务和管理员才能拥有部署特权容器的权限。5在边缘节点部署应用时，严格校验应用镜像的合法性，防止部署恶意应用。6对于接入边缘节点的Device设备进行严格审核，避免非必要设备接入。7严格审查CRI插件的配置，使用CRI对应插件的官方推荐配置。8严格划分系统中各个角色权限，通过RBAC、OPA等方式实现系统角色权限的细粒度控制。9社区发现漏洞后将在最近的3个minor release版本中合入解决，用户可以关注社区security advisory 获取漏洞披露信息，及时跟进并更新KubeEdge版本。10用户使用社区发布的二进制文件前，应该根据社区发布的校验文件进行严格校验，防止二进制被仿冒和篡改。社区release软件包发布地址cid:link_6。11用户或vendors在使用源代码构建过程中，应该参考SLSA软件供应链安全评估框架，对源代码、构建流程、依赖库等进行安全加固。开源安全洞察本章节通过对OpenSSF社区的战略规划、OpenSSF工作组内容及开放源代码软件安全动员10个TOP计划进行介绍，为相关从业人员、开源生态产业提供参考。1) OpenSSF介绍社区工作组为了更好的提升开源软件安全，OpenSSF目前已成立了8个工作组，主要负责开源软件开发最佳实践、软件代码安全、用户、安全工具链、开源项目安全威胁识别、软件供应链完整性、保护关键开源项目、漏洞披露。相关项目1. OpenSSF最佳实践徽章（OpenSSF Best Practices Badge Program）开源软件开发的最佳实践目的是提供开源开发者安全相关行业标准、框架、安全指导、课程、开源安全评估体系、包括工具支持开发人员日常开发过程的软件安全检测。开源项目可以通过OpenSSF最佳实践徽章项目进行最佳实践评估，该项目是自由/开源软件（FLOSS）项目展示其遵循最佳实践的一种方式。可以通过使用这个网站来解释他们如何遵循每个最佳实践，从而自愿地进行自我认证，认证分为通过、银、金三个级别，不需要任何费用。该项目是基于核心基础设施倡议（CII）项目发展而来。2. 积分卡（Scorecards）通过Scorecards积分卡项目可以实现自动化地对开源项目相关安全指标进行评估，以加强项目的安全状况，根据项目的评估结果给出0-10分数，帮助项目maintainer改进项目安全。3. 安全知识框架（Security Knowledge Framework）SKF是一个完全开源的Python-Flask / Angular网络应用程序，它使用许多其他的开源项目来训练你和你的团队通过设计来构建安全的应用程序。其涵盖了整个软件开发生命周期如构建、测试、需求、设计、代码开发、度量、培训等环节。4. 安全开发指南提供安全开发、安全评估的详细指导步骤，以开发者使用视角将上面的项目全部串接起来，已完整覆盖了OpenChain Security Assurance Specification、SLSA、工具如 GitHub's dependabot、GitLab dependency scanning、Scorecards check等。5. 教育与培训课程提供开发人员免费的安全开发课程，完成学习后可以发放证书有效期2年。6. 软件构建供应链级别（SLSA）软件构建的供应链级别SLSA由Google贡献给OpenSSF，是软件供应链完整性的安全标准准则，以帮助企业和开源生态确保软件开发生命周期的安全，ScoreCards是SLSA度量的工具组成部分。7. 令牌分发项目Great Multi-Factor Authentication (MFA) 分发项目。致力于将硬件 MFA 令牌分发给关键的 100+开源软件项目，目标是防止开源软件开发凭据薄弱或受损的供应链攻击。8. 包管理最佳实践提供业界主流的构建框架、包管理器的最佳实践如 maven、gradle、npm、pip、RubyGems，重点介绍其依赖管理、可重复构建、发布、基于包管理的漏洞披露等。当前文档还不完善，只重点介绍了npm，其它的包管理器待建设中。9. C/C++编译选项制定 C/C++场景的编译选项规则，避免潜在的安全风险和被攻击的风险。当前在孵化阶段。10. 开源社区安全教育SIG当前在孵化阶段，主要致力于提供行业标准的安全软件开发相关的培训材料，提供网络和应用程序安全方面的最佳实践辅导开发人员安全地创建、编写、部署和维护软件。OpenSSF安全工具链安全领域涉及面广，规则规范多，开发人员甚至从事资深安全工作的专家人工识别冗余遗漏。安全工具链用于快速识别安全风险，使开发人员专注于功能特性开发。覆盖范围：涵盖整个DevSecOps的各环节工具链，并支撑开源软件开发的最佳实践章节，如：linters(cleanCode), SAST, SCA, DAST, Fuzzers, Hard Coded Secrets Detectors, and SBOM generators。提供方：部分来自公司捐赠，部分来自OpenSSF基金会自主规划，部分在规划阶段待建设。2) 开源软件安全动员计划及目标2022 年 1 月，美国政府专家、 OSS 基金会、相关企业在白宫举行会议讨论，制定如下三个动员计划的总体目标：• 保护 OSS 生产：首先是专注于防止安全缺陷、代码和开源包漏洞• 改进漏洞识别和修复：改进缺陷识别过程、漏洞修复• 缩短补丁响应时间：缩短漏洞披露和修复时间在2022年5月第二届开源软件安全峰会上，Linux基金会、OpenSSF及各行业安全专家，就提高开源软件安全性计划达成共识，将集中在以下10个方向进行投资和安全改善，项目投资1.5亿美元，分为两年规划。备注：动员计划和OpenSSF工作组是相辅相成的，其动员计划的能力会融入到工作组中。投资方向描述安全培训向所有人提供基础安全软件开发培训和认证。风险评估为前 10,000 个（或更多）OSS 组件建立一个公开的、供应商中立的、客观的、基于指标的风险评估仪表板。数字签名加快在软件版本上采用数字签名。内存安全通过替换非内存安全语言来消除大多数漏洞的根本原因。事件响应建立一个由安全专家组成的 OpenSSF 事件响应团队，以协助开源项目加快对新发现漏洞的响应速度。安全扫描通过高级安全工具和专家指导，加快维护人员和专家发现新漏洞的速度。代码审计每年对200+个最关键的OSS组件进行一次第三方代码审查（以及任何必要的补救工作）。数据共享协调全行业的数据共享，以改善研究，帮助确定最关键的开放源码软件组件。SBOMs改进SBOM工具和培训，以推动采用。提升软件供应链安全用更好的供应链安全工具和最佳实践来增强10个关键的开放源码软件构建系统、软件包管理器和分发系统。▎总结本文通过从外部攻击面、内部攻击面及软件供应链三个维度对KubeEdge项目进行安全威胁建模，实现对KubeEdge项目的系统性安全评估，帮助社区maintainer及时发现和修复安全风险。同时，对业界OpenSSF社区开源安全策略及相关项目进行洞察，通过洞察分析可以看出，越来越多的组织、开发人员、研究人员和安全专家将加大投入资源来加强开源安全，并已逐步形成业界开源安全行业的生态产业链，在开源安全上占据标准高地可以为后续的商业扩展提供有力地位。KubeEdge社区结合业界安全理念，将能够推动社区持续巩固和演进项目的安全。▎附录相关链接• 社区漏洞处理机制: cid:link_5• 安全审计报告: cid:link_1• 社区security advisory链接: cid:link_4• KubeEdge威胁模型及安全防护分析（本文档）: cid:link_0• 社区用户文档链接: https://kubeedge.io/en/docs• SLSA软件供应链安全框架: https://slsa.dev/spec/v0.1/#supply-chain-threats• KubeEdge实现SLSA L3分析: https://kubeedge.io/en/blog/reach-slsa-l3/• Release版本发布链接: cid:link_6• 开源软件安全动员计划：https://cta-redirect.hubspot.com/cta/redirect/8112310/3b79d59d-e8d3-4c69-a67b-6b87b325313c• OpenSSF最佳时间徽章：https ://bestpractices.coreinfrastructure.org/en• 最佳实践项目：https://github.com/ossf/wg-best-practices-os-developers添加小助手微信k8s2222，进入云原生交流群

基于STM32的油井数据采集与处理cid:link_2本文介绍了油井数据采集与传输的流程，并给出了相应的Python代码示例。通过实时采集油井数据，并将其传输到服务器，从而实现对油井状态的监测和维护。可作为平时训练的例子。 开天平台+鸿蒙OS小熊派打造智能大棚温控报警cid:link_0本文把华为的众多生态结合在一起运用，对于想要了解华为云iot生态的用户具有非常好的借鉴意义IoTDA设备接入服务和边缘计算的结合：构建高效的边缘物联网方案cid:link_1本文介绍了边缘计算的概念，并且提供了一些python版本的demo，可以为入门的iot的新手提供一些边缘计算方面的的帮助。STC89C52+HX711完成电子秤设计cid:link_3此文介绍了C52制作一个电子秤，可以作为学习C52单片机的入门项目，丰富嵌入式开发的经验和了解电路的整体设计。IoTDA平台OTA升级与设备远程控制：华为云物联网平台的能力介绍cid:link_3

在边缘计算的浪潮中，AI是边缘云乃至分布式云中最重要的应用。随着边缘设备的广泛使用和性能提升，将人工智能相关的部分任务部署到边缘设备已经成为必然趋势。KubeEdge-Ianvs 子项目，作为业界首个分布式协同AI基准测试平台，基于 KubeEdge-Sedna 为算法及服务开发者提供全场景可扩展的分布式协同AI基准测试，以研发、衡量和优化分布式协同AI系统。然而在边缘设备中部署静态的AI模型往往不足以应对复杂多变的真实世界环境，因此终身学习能力对于边缘AI模型来说变得越来越重要。为了方便边缘AI算法研究者开发及测试终身学习算法在真实世界环境中的效果，KubeEdge-Ianvs 在新版本的更新中发布了支持终身学习范式的相关算法的研发与测试功能。本篇文章为大家阐释相关背景和Ianvs终身学习架构，并以 Ianvs 云机器人终身学习测试为例对 Ianvs 终身学习的特性进行介绍。欢迎关注 Ianvs 项目，持续获得第一手独家公开数据集与完善基准测试配套。开源项目GitHub地址：cid:link_4  一、背景  ▍1.1 终身学习能力对边缘模型越来越重要边缘设备所处的环境通常是不稳定的，环境变化会导致数据分布的大幅变化，即数据漂移。数据漂移会显著降低模型准确性。为了解决数据漂移问题，边缘设备需要具备动态更新模型的能力，以适应环境变化。下图展示了一个典型的终身学习算法流程框架。在该框架中，终身学习任务被定义为：已处理 N 个任务，将陆续处理 M 个任务。如何维护知识库并利用其中的模型处理这些任务是关键。终身学习的流程分为四步，首先根据之前已处理的 N 个任务初始化云端的知识库中的已知任务处理模型；然后在遇到新的任务时，从云端知识库中选取合适的模型部署到边缘端处理任务，如果新任务是已知的任务则更新原来的模型，如果遇到了未知任务则重新训练新的模型用于处理该任务；在边缘端处理好该任务后，对云端知识库进行更新；最后遇到新任务时重复前两步操作。通过以上流程可以确保边缘部署的模型具备终身学习的能力，从而可以应对数据漂移等问题带来的影响。▍1.2 业界缺少合适的终身学习测试工具目前终身学习算法相关测试工具发展较慢，目前比较成熟的测试工具只有 ContinualAI 推出的 Avalanche。Avalanche 支持的特性如下：Avalanche 支持的特性非常丰富，但是对于终身学习算法开发者来说 Avalanche 还存在一些局限性：未能覆盖终身学习全生命周期算法：支持的场景主要局限于增量学习等场景，而终身学习中任务定义、分配以及未知任务识别等流程无法体现在该 benchmark中。缺乏配套真实世界数据集：配套的数据集主要包括 Split-MNIST、Cifar10 等学术界常用的玩具测试集，缺乏适用的真实世界数据集及配套算法。研发算法难以落地：Avalanche更多面向终身学习算法的测试实验，并没有考虑未来将算法落地部署的需求。因此目前业界亟需一个更好的终身学习测试 benchmarking 工具，Ianvs 发布的非结构化终身学习新特性可以很好的解决上述问题。  二、lanvs 终身学习架构  ▍2.1 Ianvs 终身学习优势终身学习近年来得到了越来越多的关注，越来越多的边缘智能从业者认识到了终身学习的重要性。但是终身学习相比其他 AI 算法来说有着更高的研究门槛，经过我们的调研发现终身学习研发存在模型训练流程复杂、算法效果难以衡量和算法落地应用困难三大挑战。第一个挑战是终身学习模型训练流程较为复杂，比如对于一个刚入门终身学习的同学来说，可能对终身学习算法流程中的未知任务识别模块比较感兴趣，但是要想完整实现终身学习还需要填补任务定义、任务分配等模块，而这对于刚入门的同学不太友好，想复现别人的工作还需要去额外完成其他终身学习模块。针对这一挑战，KubeEdge-Ianvs 中对终身学习全生命周期的各个模块都进行了设计，包括并不限于任务定义、任务分配、未知任务识别和未知任务处理等多个终身学习核心算法模块，各个模块之间是解耦合的，用户可以只研究自己感兴趣的模块，其他模块采用默认配置即可跑通终身学习实验。第二个挑战是终身学习算法效果衡量困难，不同论文中的终身学习算法由于其测试流程不一样难以比较其工作的优劣。同时大部分论文的工作都是在 MNIST、CIFAR10 这些非真实数据集上进行的实验，由于缺乏在真实世界数据集上的测试，算法在现实世界中的实际应用效果往往要大打折扣。针对这一挑战，KubeEdge-Ianvs 中对终身学习的测试流程进行了统一，提供 BWT、FWT 等公认的终身学习系统指标，方便衡量算法效果。同时 KubeEdge-Ianvs 开源了 Cloud-Robotics 等真实世界终身学习数据集，并配套了对应的运行样例，用户可以直接开箱使用该真实世界数据集测试自己提出的算法的效果。第三个挑战是终身学习算法落地较为困难，算法研发与实际部署之间存在一定鸿沟。用户训练好的模型需要进一步封装才能实际在生产环境上使用。针对这一挑战，KubeEdge-Ianvs 在开发时就考虑到了和其姊妹项目 KubeEdge-Sedna 开源服务平台是配套兼容关系，因此在 KubeEdge-Ianvs上研发的终身学习算法可以直接迁移到 KubeEdge-Sedna平台上实现落地部署，解决了从研发到落地最后一公里的问题。总而言之，Ianvs 终身学习优势包括：覆盖终身学习全生命周期，包括任务定义、任务分配、未知任务识别和未知任务处理等多个模块，各个模块是解耦合的；统一化的测试流程，系统内置权威的终身学习测试指标，并且支持测试结果的可视化；并提供真实世界数据集用于终身学习测试，能更好测试终身学习算法在真实环境的效果；和 KubeEdge-Sedna 终身学习相兼容，研发算法可以快捷迁移到 Sedna 上实现落地部署。▍ 2.2 Ianvs 终身学习新特性Ianvs 在去年发布的 0.1.0 版本中已具备支持单任务学习范式和增量学习范式的算法研发与测试，在新版的 Ianvs 中增加了支持对终身学习范式的相关算法的研发与测试的功能，同时也为终身学习算法测试提供了新的开源数据集。主要新特性如下：特性一：覆盖终身学习全生命周期Ianvs 终身学习具体架构如下图所示，主要包括任务定义、任务分配、未知任务识别和未知任务处理等模块，覆盖终身学习全生命周期。对于已处理任务，Ianvs 通过任务定义模块，将已知任务抽象成若干个模型存储进云端知识库中。在遇到新任务时，Ianvs 首先通过未知任务识别模块判断推理样本属于未知任务还是已知任务。若是已知任务，则从云端知识库中调度对应模型部署在边侧处理该任务，同时基于已知任务样本对模型进行增量更新。若是未知任务，则 Ianvs 通过未知任务处理模块处理该任务，利用外部系统标注并重新训练新的模型用于处理该任务。处理完成后，新的任务模型或是更新后的已知任务模型再重新整合至云端知识库中。为了方便初学者使用 Ianvs，在 Ianvs 仓库中的 examples/robot/ 文件夹下提供了一个可以直接运行的样例cid:link_1 ， 详细的教程在第三节。特性二：统一化的测试流程和真实世界数据集Ianvs 对终身学习测试流程进行了统一，主要参考了 NIPS2017 的论文 “Gradient Episodic Memory for Continual Learning”，复现了其中提出的 BWT 和 FWT 指标，用于评价终身学习算法的抗遗忘能力和未知任务泛化能力。Ianvs 还开源了 Cloud-Robotics 等真实世界数据集，并提供了配套的可以开箱即用的实验代码，帮助用户快速上手 Ianvs 终身学习。数据集官网链接：cid:link_5特性三：支持快捷落地部署如下图所示，Ianvs 中终身学习算法实现的组件与 Sedna 上终身学习算法实现的组件是相兼容的，因此在 Ianvs 上研发测试的算法可以无障碍迁移部署到 Sedna 上，方便相关从业人员实地部署算法。  三、lanvs 终身学习快速教程  在这章中我们通过运行 Ianvs 终身学习的 cloud-robotics 样例向大家讲解 Ianvs 终身学习的基本流程。Ianvs 安装流程以及终身学习更详细的介绍可以参考：Ianvs-lifelong-learning-tutorial相关链接：cid:link_31）首先我们需要配置好 Cloud-Robotics 的数据集，先创建数据集的文件夹，注意如果你把数据集放到别的位置，本教程中的部分路径配置也要一并修改。mkdir /datacd /datamkdir datasetscd datasetsCloud-Robotics 数据集可以根据该数据集专属网站的指示操作获得，链接：cid:link_22）下载完成后解压数据集：unzip cloud-robotics.zip3)配置好数据集后，我们可以准备运行示例代码了。Cloud-Robotics 示例运行的代码放在 /ianvs/project/ianvs/examples/robot/lifelong_learning_bench/ 下，我们首先要配置 python 路径（这里如果 Ianvs 安装位置不一样的话需要更改路径）：export PYTHONPATH=$PYTHONPATH:/ianvs/project/ianvs/examples/robot/lifelong_learning_bench/testalgorithms/rfnet/RFNet4）然后我们检查一下 yaml 文件的信息：5）上图 benchmarkjob.yaml 中 workplace 是存放模型训练输出的路径，可以改成你需要的路径。6）上图 testenv-robot.yaml 中 train_url 和 test_url 是数据集索引的路径，如果你的数据集存放位置和教程不一样，则需要修改 train_url 和 test_url 的路径。7）在上图 rfnet_algorithm.yaml 中可以根据你的需求添加测试的终身学习算法，比如任务定义、任务分配等算法。本样例中提供了一个简单的示例。8）其他的配置文件暂时没有需要调整的。接下来我们就可以运行示例代码了：cd /ianvs/project/ianvs ianvs -f examples/robot/lifelong_learning_bench/benchmarkingjob.yaml 在模型终身学习任务结束后你可以看到以下内容，包括 BWT、FWT 等终身学习系统衡量指标：9）出现以上显示结果，则成功跑通了一个 Ianvs 终身学习样例！如果读者对于本次版本发布的更多细节感兴趣，欢迎查阅 Ianvs v0.2 Release Note：cid:link_0后续 KubeEdge SIG AI 将发布系列文章，陆续具体介绍终身学习全面升级的特性，欢迎各位读者继续关注社区动态。▍相关链接[1] 开源项目GitHub地址：cid:link_4[2] 数据集官网链接：cid:link_5[3] Ianvs 安装流程以及终身学习更详细的介绍链接：cid:link_3[4] Cloud-Robotics 数据集：cid:link_2[5] Ianvs v0.2 Release Note：cid:link_0

北京时间2023年10月13日，KubeEdge 发布 v1.15.0 版本。新版本新增多个增强功能，在边缘节点管理、边缘应用管理、边缘设备管理等方面均有大幅提升。KubeEdge v1.15.0 新增特性：支持 Windows 边缘节点基于物模型的新版本设备管理 API v1beta1发布承载 DMI 数据面的 Mapper 自定义开发框架 Mapper-Framework 发布支持边缘节点运行静态 Pod支持更多的 Kubernetes 原生插件运行在边缘节点 新特性概览 ▍支持 Windows 边缘节点随着边缘计算应用场景的不断拓展，涉及到的设备类型也越来越多，其中包括很多基于Windows 操作系统的传感器、摄像头和工控设备等，因此新版本的KubeEdge 支持在 Windows 上运行边缘节点，覆盖更多的使用场景。在 v1.15.0 版本中，KubeEdge 支持边缘节点运行在 Windows Server 2019，并且支持 Windows 容器运行在边缘节点上，将 KubeEdge 的使用场景成功拓展到 Windows 生态。Windows 版本的 EdgeCore 配置新增了 windowsPriorityClass 字段，默认为NORMAL_PRIORITY_CLASS。用户可以在 Windows 边缘主机上下载 Windows 版本的 EdgeCore 安装包[1]，解压后执行如下命令即可完成 Windows 边缘节点的注册与接入，用户可以通过在云端执行 kubectl get nodes 确认边缘节点的状态，并管理边缘 Windows 应用。edgecore.exe --defaultconfig > edgecore.yaml edgecore.exe --config edgecore.yaml更多信息可参考：cid:link_3cid:link_4▍基于物模型的新版本设备管理 API v1beta1 发布v1.15.0 版本中，基于物模型的设备管理 API，包括 Device Model 与 Device Instance，从 v1alpha2 升级到了 v1beta1，新增了边缘设备数据处理相关等的配置，北向设备 API 结合南向的 DMI 接口，实现设备数据处理，API 的主要更新包括：Device Model 中按物模型标准新增了设备属性描述、设备属性类型、设备属性取值范围、设备属性单位等字段。// ModelProperty describes an individual device property / attribute like temperature / humidity etc. type ModelProperty struct { // Required: The device property name. Name string `json:"name,omitempty"` // The device property description. // +optional Description string `json:"description,omitempty"` // Required: Type of device property, ENUM: INT,FLOAT,DOUBLE,STRING,BOOLEAN,BYTES Type PropertyType `json:"type,omitempty"` // Required: Access mode of property, ReadWrite or ReadOnly. AccessMode PropertyAccessMode `json:"accessMode,omitempty"` // +optional Minimum string `json:"minimum,omitempty"` // +optional Maximum string `json:"maximum,omitempty"` // The unit of the property // +optional Unit string `json:"unit,omitempty"` }Device Instance 中内置的协议配置全部移除，包括 Modbus、Opc-UA、Bluetooth 等。用户可以通过可扩展的 Protocol 配置来设置自己的协议，以实现任何协议的设备接入。Modbus、Opc-UA、Bluetooth 等内置协议的 Mapper 不会从 mappers-go 仓库移除，并且会更新到对应的最新版本，且一直维护。type ProtocolConfig struct { // Unique protocol name // Required. ProtocolName string `json:"protocolName,omitempty"` // Any config data // +optional // +kubebuilder:validation:XPreserveUnknownFields ConfigData *CustomizedValue `json:"configData,omitempty"` } type CustomizedValue struct { Data map[string]interface{} `json:"-"` } 在 Device Instance 的设备属性中增加了数据处理的相关配置，包括设备上报频率、收集数据频率、属性是否上报云端、推送到边缘数据库等字段，数据的处理将在 Mapper 中进行。type DeviceProperty struct { ...... // Define how frequent mapper will report the value. // +optional ReportCycle int64 `json:"reportCycle,omitempty"` // Define how frequent mapper will collect from device. // +optional CollectCycle int64 `json:"collectCycle,omitempty"` // whether be reported to the cloud ReportToCloud bool `json:"reportToCloud,omitempty"` // PushMethod represents the protocol used to push data, // please ensure that the mapper can access the destination address. // +optional PushMethod *PushMethod `json:"pushMethod,omitempty"` }更多信息可参考：cid:link_5cid:link_6▍承载 DMI 数据面的 Mapper 自定义开发框架 Mapper-Framework 发布v1.15.0 版本中，对 DMI 数据面部分提供了支持，主要承载在南向的 Mapper 开发框架 Mapper-Framework中。Mapper-Framework 提供了全新的 Mapper 自动生成框架，框架中集成了 DMI 设备数据管理（数据面）能力，允许设备在边缘端或云端处理数据，提升了设备数据管理的灵活性。Mapper-Framework 能够自动生成用户的 Mapper 工程，简化用户设计实现 Mapper 的复杂度，提升 Mapper 的开发效率。DMI 设备数据面管理能力支持v1.15.0 版本 DMI 提供了数据面能力的支持，增强边缘端处理设备数据的能力。设备数据在边缘端可以按配置直接被推送至用户数据库或者用户应用，也可以通过云边通道上报至云端，用户也可以通过 API 主动拉取设备数据。设备数据管理方式更加多样化，解决了 Mapper 频繁向云端上报设备数据，易造成云边通信阻塞的问题，能够减轻云边通信的数据量，降低云边通信阻塞的风险。DMI 数据面系统架构如下图所示：Mapper 自动生成框架 Mapper-Frameworkv1.15.0 版本提出全新的 Mapper 自动生成框架 Mapper-Framework。框架中已经集成 Mapper 向云端注册、云端向 Mapper 下发 Device Model 与 Device Instance 配置信息、设备数据传输上报等功能，大大简化用户设计实现 Mapper 的开发工作，便于用户体验 KubeEdge 边缘计算平台带来的云原生设备管理体验。更多信息可参考：cid:link_7▍支持边缘节点运行 Kubernetes 静态 Pod新版本的 KubeEdge 支持了 Kubernetes 原生静态 Pod 能力，与 Kubernetes 中操作方式一致，用户可以在边缘主机的指定目录中，以 JSON 或者 YAML 的形式写入 Pod 的 Manifests 文件，Edged 会监控这个目录下的文件来创建/删除边缘静态 Pod，并在集群中创建镜像 Pod。静态 Pod 默认目录是 /etc/kubeedge/manifests，您也可以通过修改 EdgeCore 配置的 staticPodPath 字段来指定目录。更多信息可参考：cid:link_8▍支持更多的 Kubernetes 原生插件运行在边缘节点v1.15.0 版本的 KubeEdge 支持更多原生插件在边缘节点上运行。KubeEdge 提供了高扩展性的 Kubernetes 原生非资源类 API 透传框架，满足了原生插件对此类 API 的依赖。插件可以从边缘节点的 MetaServer 中获取集群 version 等信息，MetaServer 将对请求进行数据缓存，保证边缘节点网络中断时仍能正常服务。当前框架下，社区开发者将更容易的开放更多非资源类 API。开发者只需关注插件依赖的 API，而不需要考虑请求如何传递至边缘节点。更多信息可参考：cid:link_9▍升级 Kubernetes 依赖到 v1.26新版本将依赖的 Kubernetes 版本升级到 v1.26.7，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_10 升级注意事项 新版本 v1beta1 的 Device API不兼容 v1alpha1 版本，如果您需要在 KubeEdge v1.15.0 中使用设备管理特性，您需要更新 Device API 的 yaml 配置。如果您使用 containerd 作为边缘容器运行时，您需要将 containerd 版本升级到 v1.6.0 或者更高版本，KubeEdge v1.15.0 不再支持 containerd 1.5 以及更早的版本。参考：https://kubernetes.io/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal在 KubeEdge v1.14 中，EdgeCore 已经移除了对 dockershim 的支持，边缘运行时仅支持 remote 类型，并且使用 containerd 作为默认运行时。如果您想要继续使用 docker 作为边缘运行时，您需要安装 cri-dockerd，并且在启动 EdgeCore 过程中，设置 runtimeType=remote 以及 remote-runtime-endpoint=unix:///var/run/cri-dockerd.sock。参考：cid:link_2▍致谢感谢 KubeEdge 社区技术指导委员会( TSC )、各 SIG 成员对 v1.15.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接[1] Windows 版本 EdgeCore 安装包:cid:link_0[2] Release Notes：cid:link_11/blob/master/CHANGELOG/CHANGELOG-1.15.md  加入KubeEdge社区 KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 : https://kubeedge.ioGitHub地址 : cid:link_11Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/扫码回复“KubeEdge”进入技术交流群

在公路隧道、城市地下通道等隧道场景下，隧道内路况车况复杂，机电设备哑终端多，运行状态监测难，实时性差，联动处置慢，复杂机电场景依赖传统PLC，监测运维能力弱，事故发生处理不及时产生次生事故。华为面向复杂机电监测场景，安全运营、智能联动需求，打造智能化、高可靠的隧道监测站产品组合方案，降低安全隐患，秒级实时联动，提高运维效率，全站可视运维，大幅度提升隧道运营安全。详细链接：https://e.huawei.com/cn/solutions/digital-site/tunnel-monitoring-site