近日，国家安全部微信公众号发布新闻提醒，随着窃密手段不断迭代，看似可靠的碎纸机，正成为泄密风险的隐秘源头。有公开报道显示，有专业技术能通过扫描碎纸颗粒的图案、颜色，并运用相关软件恢复关键内容，甚至可还原约70%的碎纸内容！因此，正确使用碎纸机，不仅是办公的好习惯，更是一项重要的保密责任。   面对这些隐患，物联网技术正成为全新的“安全加固”方案。首先，它让粉碎“达标”可监控。单纯“能碎纸”已不够，符合保密等级的粉碎规格才是关键。盈电智控物联网碎纸机可集成传感器，实时检测并记录每一次粉碎的纸屑尺寸、密度，一旦未达预设标准便自动告警并锁定，从根源上杜绝“机型不达标”的敷衍。   其次，它实现了流程“闭环”可追溯。从文件放入、粉碎到碎屑封装清运，全过程可被加密记录并上传。操作人员、时间、文件类型自动生成不可篡改的日志，解决了“缺登记、难追溯”的管理难题。设备状态异常（如中途卡纸、非授权开启）会实时向管理员报警，避免因人员离开现场而产生的风险盲区。   此外，智能识别技术的结合，能对文件“分类”做初审。通过简单识别文件页眉、密级标识或特定颜色，设备可提示或要求操作者对涉密文件进行单独处理，有效减少“混合粉碎”带来的交叉风险。物联网的介入，将碎纸机从一台孤立执行的机器，转变为保密销毁链中一个智能、可控、可追溯的关键节点。它用技术弥补了人为疏忽与制度空隙，让“彻底销毁”不再依赖自觉，而成为一道被严密守护的标准程序。在信息保卫战中，这样的“锁”正变得不可或缺。

香港宏福苑大火吞噬151条生命的悲剧仍在刺痛社会神经。当调查直指不合格阻燃围网与发泡胶板是罪魁祸首时，我们不禁要问：物联网能否在装修材料入场的瞬间就识破危险？这场血泪教训揭示了一个残酷现实——传统消防系统已无法应对现代建筑复杂风险，而物联网技术正从三大维度重构楼宇防火体系。  传感器织就的"电子围栏"在宏福苑事件中，若存在温湿度-气体-图像的多维传感网络，系统能在发泡胶板释放有害气体时就触发预警。盈电智控物联网传感器可实现：材料入场时红外光谱扫描识别易燃物；施工期间24小时监测氧气/挥发性有机物浓度；电梯井等重点区位部署热成像摄像头。某实验数据显示，智能传感器组合使初期火灾识别速度提升47倍，远超传统烟雾探测器3-5分钟的响应延迟。  数据中台构筑"防火墙"涉案人员混用合格与劣质围网的行为，暴露了人工监管的致命缺陷。盈电智控物联网云平台通过建立材料电子档案库，每个进场建材都需扫码验证防火认证，与香港消防处数据库实时比对。更关键的是机器学习模型能识别施工异常模式——例如当监测到某楼层突然出现与报备材料不符的隔热系数波动时，系统会自动冻结电梯运行并推送告警。这种动态风险评估机制，正是预防"台风后偷换劣质网"等钻空子行为的核心技术。  应急响应的"神经末梢"革命传统消防系统最大的软肋在于信息孤岛。物联网构建的分布式架构能让喷淋系统、排烟窗、应急照明等设备形成协同网络。当某区域温度异常时，相邻单元的传感器会自主启动交叉验证，防止单一传感器误报。香港华懋大厦火灾后涉案人员的"应付式整改"，在物联网系统中将无处遁形——所有检修记录、检测数据均上链存证，任何人为篡改都会触发审计警报。  这场悲剧警示我们：防火不是简单的设备堆砌，而是需要重构"感知-决策-执行"的全链条智能。当物联网技术将建材溯源、环境监测、应急处置融为有机整体时，楼宇才能真正拥有会思考的"防火大脑"。香港正在开展的全面安全排查，或许该优先考虑为每栋大楼装上这套数字神经系统——因为预防下一次悲剧的技术条件，其实已经成熟。

本地判题器能正常运行，前几天线上提交也能正常得分，今天提交后无法正常运行，得分为0，负责人说更新了对异常指令的判定，但在本地检查没有发现异常指令，希望能发一下最新的判题器

 如题，异地联培，加完发现只能加学校所在地赛区

一、1800侧配置设备和上级视图管理平台对接时使用的鉴权方式，需要和上级视图管理平台的鉴权方式保持一致。上级视图管理平台支持的鉴权方式，请咨询上级视图管理平台的设备提供商。鉴权方式默认为Digest_SHA256。其中仅“EnableMD5_N_Onvif”设置为“1”的场景下，“ONVIF鉴权方式”才可以选择Digest_MD5/Digest_SHA256、Digest_MD5或者Digest_MD5/WSSE。具体操作如下：选择“系统管理 > 高级配置”。选择“模块名称”为“OCG”，单击“搜索”。设置“EnableMD5_N_Onvif”参数值为“1”，打开ONVIF对接启用MD5算法功能。​选择“对接管理 > ONVIF对接”。启用ONVIF功能。选择对应的鉴权方式和onvif传输协议类型​配置ONVIF密码。该密码为第三方平台通过onvif协议添加1800的onvif密码。​当遇到第三方平台无法通过onvif添加1800时，通常建议使用Onvif Device Manager工具（简称ODM工具）或者ONVIF Device Test Tool 工具进行测试。二、ODM工具测试以1800版本10.0.0SPC500为例，使用ODM工具测试运行ODM工具，点击左下角“Add”​把URL中的IP地址改成对应的1800设备IP、onvif端口号（80），点击“Apply。选中上一步添加的设备，输入1800的onvif的用户名和密码，点击“log in”。如果设备可以连接上，点击“Live video”就可以看到设备的实时视频，该实时视频就是通过onvif获取，说明IVS1800的onvif协议正常。如果通过ODM工具链接不上设备，那么可以排查如下部分查找原因：·请检查ODM工具到设备网络是否正常；·设备支持onvif协议，但需要在网页开启onvif功能·ODM对接1800如果对接报错鉴权错误（如下图），请将IVS1800网页端onvif鉴权方式修改成Digest_MD5/WSSE、WSSE或者NONE。·设备支持onvif协议，但需要在网页端配置onvif用户才可以。另外，如果ODM报错提示“基础连接已经关闭：连接被意外关闭”，原因是密码错误导致触发OCG模块黑名单功能，连接关闭。解决方案：重启或者等待5min后重新输入正确密码。三、ODT工具测试打开ONVIF Device Test Tool测试工具，建议设备网络和电脑在同一局域网。按照如下1-5步骤进行操作。注：使用该工具时，1800网页界面onvif鉴权方式选择Digest_MD5、Digest_MD5/WSSE或者None，否则鉴权失败。2.点击“Check”之后验证通过会显示设备的参数信息3.视频测试（需要切换到局域网环境下）·切换到“Debug”选项卡---点击“Media”---“get”Media URL---“get”Media Profile---选择“main stream（Profile_1）”---自动获取Video和Adudio的先关参数---点击下方Play Video，播放通道视频

ief中边缘侧的应用和另一个边缘侧应用应该如何通讯，是否需要借助云端做桥连还是可以直接进行通讯，请给一个示例说明一下

ief应该如何处理边缘自治的应用，是否有指导案例和规范

IEF中的消息路由应该如何使用，比传统http访问又有什么优势

我使用IEF下发应用之后让设备上报数据应该使用消息路由还是我直接在边缘设备访问云端接口进行上报

Hi3519DV500内置双核A55，提供高效、丰富和灵活的CPU资源，以满足客户计算和控制需求。 Hi3519DV500集成了高效的神经网络推理引擎，最高2.5Tops NN算力，支持业界主流的神经网络框架。神经网络支持完整的 API 和工具链，易于客户开发，升级 IVE 算子，支持特征点检测、周界、光流及多种计算机形态学算子；升级 DPU 算法实现双目深度图加速单元，最大分辨率 2048 x 2048，最大视差 224，处理性能 720p@30fps。Hi3519DV500芯片搭载了高性能的ISP引擎和处理器，能够实时处理高清、超高清甚至4K级别的图像数据。它支持多种图像处理算法和技术，如自动白平衡、自动曝光、降噪、边缘增强等，可以实现图像的清晰度、色彩还原度和对比度的优化。Hi3519DV500芯片采用了高度集成的设计，将多个核心组件融合在一起，减少了电路板的复杂度和体积。同时，芯片还采用了低功耗设计，在保证性能的同时，降低了能耗和发热量。这使得Hi3519DV500芯片适用于多种嵌入式图像处理应用等；

场景在购买可信智能计算服务TICS之前，客户可能自行准备了一台虚拟机/物理机，对于这种方式TICS推荐使用IEF边缘模式部署可信计算节点。为了保护自有的节点网络安全，往往需要在这台机器上配置代理及端口转发。TICS针对这种场景也提供了相关的功能支持。步骤安装squid代理首先，用户需要在机器上安装代理软件。TICS推荐使用的代理软件是squid 4或者5版本（http://www.squid-cache.org/）。注意：使用其他代理服务器需支持代理Grpc,Http2请求。增加代理配置安装完squid软件后，需要编辑代理配置文件放通30000~30016的ssl连接转发能力，默认路径为/etc/squid/squid.conf使用文本编辑器打开该文件后，粘贴如下内容：acl SSL_ports port 30000-30016再执行命令重启squid服务systemctl restart squid购买TICS计算节点在购买计算节点的“部署配置”——“proxy配置”部分填写squid代理服务的ip和端口即可，在部署完成后与计算节点通信的请求都会访问到用户填写的ip和端口

制卡失败，失败原因为qemu is broken or the version of qemu is not compatible我已经按照华为官方文档的要求安装了相应的依赖软件，为什么还会出现qemu broken的错误

分类文档链接备注路标信息cid:link_4　特性清单cid:link_1　原子APIcid:link_3　FAQcid:link_2　华为云在线课程（免费）华为云智能边缘解决方案介绍cid:link_0本课程主要介绍边云协同应用场景，华为智能边缘平台方案及方案设计华为云开发者网智能边缘平台IEF开放能力cid:link_5　

各位大佬好 ：经过一周爬坑  已经将官方的demo 跑通  但是替换自己的模型时出差  提示信息也很少  不知道是哪里出问题环境  yolov5-6.0  +  docker 镜像直接使用的 nvcr.io/nvidia/caffe  省的自己重新搭建caffe环境yolov5.yaml 文件另外就是将models下common.py文件按照网上的教程做了修改  如下只修改了3处   主要是将nn.silu()变为nn.relu() 其他未做处理。训练50轮后  得到pt模型执行python3 export.py  --include onnx  --device '0'  --weights best.ptpython3 -m onnxsim  best.onnx yolo.onnx下载了官方推荐的caffetoonnx项目   https://github.com/xxradon/ONNXToCaffe   opset记得设置为9执行 python3 convertCaffe.py yolo.onnx  yolov5s.prototxt yolov5s.caffemodel全程无任务报错  顺利生成模型重点！！！   将成功转换后的模型执行后直接报错： 网上找了好久也没有类似的问题   纠结了一天也不知道从哪里下手 

Atlas200(RC模式)PCIE通过PCIE桥扩展两路PCIE，分别连接FPGA(EP)和Atlas200(EP模式)，这样需要在Atlas200(RC模式)里安装Atlas200（EP模式）驱动，可以安装吗？