硬件平台：mdc610 SDK: 1.99.101程序样例： dds_event_async_server_sample，dds_event_async_client_sample具体描述：  在做多进程间传输视频数据项目，视频yuv420数据一帧1920x1200 3M多，cm dds通信中的rawData默认是ara::core::Vector<UInt8>向量，传输效率低，延迟大，想配置dds mbuf 共享内存通信，零拷贝,提高效率，但客户端没收到服务端数据。dds_event_async_server_sample服务端发送数据配置如下：void ServerActivity::Act() { static int32_t sendCount = 1; // 分配Event内存 auto sampleCameraImage = skeleton_->CameraImageAsyncEvent.Allocate(); uint64_t ulTimestamp = 0,ulEndTimestamp=0; HMEV_GET_TIMESTAMP_US(ulTimestamp); // 填值 sampleCameraImage->frameType = sendCount; // 借用frameType传输数据包的index(1..100) sampleCameraImage->dataSize = 1024; // 1024仅作为示例，无实际意义 sampleCameraImage->imageFormat = "yuv_instance1"; // 右侧字符串仅作为示例，无实际意义 sampleCameraImage->width = 100; // 100仅作为示例，无实际意义 sampleCameraImage->height = 100; // 100仅作为示例，无实际意义 sampleCameraImage->header.stampHigh = 33; // 33仅作为示例，无实际意义 sampleCameraImage->header.stampLow = 44; // 44仅作为示例，无实际意义 sampleCameraImage->header.frameId = "test"; // 右侧字符串仅作为示例，无实际意义 sampleCameraImage->timestamp = ulTimestamp; int ret=halMbufAlloc(1024, &m_pMbuf); if(ret==0){ uint8_t *pData=nullptr; uint64_t len=0; if (halMbufGetDataPtr(m_pMbuf, reinterpret_cast<void **>(&pData), &len) != 0) { LOG_ERROR("camera_mviz halMbufGetDataPtr failed!"); } else { for(int i=0;i<5;i++) { if(pData) pData[i]=i; } } } else { LOG_ERROR("halMbufAlloc failed!"); } sampleCameraImage->rawData = reinterpret_cast<Mbuf*>(m_pMbuf); // 发送Event数据包 skeleton_->CameraImageAsyncEvent.Send(std::move(sampleCameraImage)); HMEV_GET_TIMESTAMP_US(ulEndTimestamp); int send_case_ms=(ulTimestamp-ulEndTimestamp)/1000; log_.LogInfo() << "CameraImageAsyncEvent send count: " << sendCount<<",send case(ms):"<<send_case_ms; if(m_pMbuf) halBuffFree(m_pMbuf); sendCount++; }dds_event_async_client_sample客户端接收回调数据配置如下void ClientActivity::CameraImageCallback() { log_.LogInfo() << "CameraImage event received."; proxy_->CameraImageAsyncEvent.GetNewSamples([this](ara::com::SamplePtr<EventAsyncImage const> ptr) { auto sample = ptr.Get(); uint64_t ulTimestamp = 0,ulEndTimestamp=0; HMEV_GET_TIMESTAMP_US(ulTimestamp); log_.LogInfo() << "receive data is: " << sample->frameType<<",case:"<<(ulTimestamp-sample->timestamp)/1000; // 提取Mbuf数据包 Mbuf *pMbuf = reinterpret_cast<Mbuf *>(sample->rawData); uint8_t *pData=nullptr; uint64_t len=0; if (halMbufGetDataPtr(pMbuf, reinterpret_cast<void **>(&pData), &len) != 0) { LOG_INFO("camera_mviz halMbufGetDataPtr failed!"); return; } halMbufGetDataLen(pMbuf, &len); if(pData) { LOG_INFO("recv data:%d %d %d %d",pData[0],pData[1],pData[2],pData[3]); } m_nMsgCnt++; HMEV_GET_TIMESTAMP_US(ulEndTimestamp); int time_case=(ulEndTimestamp-sample->timestamp)/1000; LOG_INFO("got data size:%d,case(ms):%d",sample->dataSize,time_case); }); }EventAsyncImage 结构体rawData定义为rawBuffer*类型struct EventAsyncImage { ::Int32 frameType{ 0 }; ::Int32 height{ 0 }; ::Int32 width{ 0 }; ::Int32 dataSize{ 0 }; ::rawBuffer *rawData{ nullptr }; ::String imageFormat; ::EventAsyncImageHeader header; ::UInt64 timestamp{ 0U }; /// };rm_share_group.yaml文件放在/opt/usr/app/1/gea/conf/rm下，其内容如下DEFAULT_MEM_GROUP:  dds_event_async_server_sample : arw  dds_event_async_client_sample : arw是否mbuf配置有问题？在main函数中都调用了ara::rm::RegisterHisiResource()和aclInit()

一、业务背景我们项目中收支记录、账本数据需高频并发写入系统 。此前，用户记账操作成功率低至 70%，大量用户因记账失败、体验差而流失，严重阻碍业务发展 二、原因分析 全量数据一次性提交，超出系统承载能力当用户批量录入多条记账记录（如导入账单、批量补记）时，前端未做分批处理，直接将所有数据（可能达数百条）通过单次请求提交至后端。后果：单条请求数据量过大（如 100 条记录的 JSON 体积超过 1MB），导致网络传输超时（尤其弱网环境下）；后端接口可能因 “单次请求数据量超限” 直接拒绝（如网关层设置请求体大小限制），或处理时内存占用激增，触发超时熔断未适配设备性能差异，固定逻辑引发低端机崩溃不同设备（如高端旗舰机 vs 入门级手机）的 CPU、内存、网络能力差异显著，但前端采用统一的处理逻辑缺乏操作进度反馈，用户误判失败批量记账时，前端未展示实时进度（如 “已完成 30%”），用户在等待过程中因 “无响应” 误以为操作失败：可能手动刷新页面或重复提交，导致重复请求冲突（如同一笔记录被提交两次），后端因 “数据重复” 返回失败；长时间无反馈触发用户焦虑，直接关闭页面，导致未完成的操作中断三、解决思路动态分批处理：针对全量数据一次性提交超出系统承载的问题，采用 “按需拆分、动态调整” 策略进度可视化与交互反馈：针对用户因无反馈而误判失败的问题，通过 “实时感知、明确反馈” 增强操作透明度异常处理与重试机制：针对网络波动、系统异常导致的写入失败，通过 “容错兜底、自动重试” 降低失败概率四、解决方案4.1 数据分批处理（基础分批逻辑）当用户触发大量记账数据录入操作时，利用 ArkTS 的异步任务调度能力，将数据按固定批次拆分。通过迭代数据数组，每次截取指定数量（初始 20 条）的数据作为一批，调用封装的写入方法逐批处理，避免一次性加载全量数据导致内存溢出或 UI 阻塞// 写入方法async function batchWriteAccountingData(data: AccountingDataItem[]): Promise<void> { const batchSize = 20; for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchData(batch); // 异步写入，避免阻塞主线程 }}// 记账明细interface AccountingDataItem { id: string; amount: number; type: 'income' | 'expense';}4.2 动态分批调整（结合设备状态）借助鸿蒙系统提供的 hidebug 模块获取设备内存占用信息，实时判断设备内存状态。定义内存阈值（需结合实际设备测试确定），动态调整每批数据量：内存充裕时增大批次（如 30 条）以加快处理；内存紧张时减小批次（如 15 条）import { hidebug } from '@ohos.hidebug';async function getDynamicBatchSize(): Promise<number> { const memoryUsage = hidebug.getNativeHeapAllocatedSize(); // 根据实际设备性能测试调整 const lowMemoryThreshold = 1024 * 1024 * 200; // 200MB const highMemoryThreshold = 1024 * 1024 * 500; // 500MB if (memoryUsage < lowMemoryThreshold) { return 30; } else if (memoryUsage > highMemoryThreshold) { return 15; } return 20;}async function dynamicBatchWrite(data: AccountingDataItem[]): Promise<void> { const batchSize = await getDynamicBatchSize(); for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchData(batch); }}4.3 进度可视化与交互反馈（UI 组件集成）在记账操作页面，使用 ArkTS 的 Progress 组件实时展示写入进度。通过计算已处理数据量与总数据量的比例，动态更新进度条数值。同时，结合 Toast 或弹窗反馈关键状态（“数据写入中”“写入完成”“网络异常重试” ），增强用户对操作流程的感知@Entry@Componentstruct AccountingWritePage { @State progressValue: number = 0; @State isWriting: boolean = false; private totalDataCount: number = 0; build() { Column() { Text('记账数据写入中') .fontSize(20) .margin({ bottom: 10 }); Progress({ value: this.progressValue, total: 100 }) .width(300) .height(20) .margin({ bottom: 20 }); if (this.isWriting) { Text(`已完成 ${this.progressValue.toFixed(1)}%`) .fontSize(14) .color(Color.Grey); } else { Button('开始写入') .onClick(async () => { this.isWriting = true; const data = await fetchAccountingData(); this.totalDataCount = data.length; await this.batchWriteWithProgress(data); this.isWriting = false; // 写入完成反馈 Toast.show({ message: '记账数据写入完成！' }); }); } } .padding(20) .width('100%') .height('100%') .justifyContent(FlexAlign.Center); } private async batchWriteWithProgress(data: AccountingDataItem[]): Promise<void> { const batchSize = await getDynamicBatchSize(); const totalBatches = Math.ceil(data.length / batchSize); let processedCount = 0; for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchData(batch); processedCount += batch.length; this.progressValue = (processedCount / this.totalDataCount) * 100; // 业务逻辑 await new Promise(resolve => {}); } }}4.4 异常处理与重试机制在分批写入过程中，捕获网络请求异常、系统写入失败等错误。通过设置重试次数（如 3 次），针对失败批次自动重试；若重试仍失败，记录失败数据并反馈给用户，支持手动触发重试或跳过失败项const MAX_RETRY_COUNT = 3;async function writeBatchDataWithRetry(batch: AccountingDataItem[], retryCount: number = 0): Promise<boolean> { try { await writeBatchData(batch); // 写入 return true; } catch (error) { if (retryCount < MAX_RETRY_COUNT) { // 重试 return writeBatchDataWithRetry(batch, retryCount + 1); } else { // 记录失败数据，可存入本地缓存待后续处理 saveFailedBatch(batch); console.error('写入失败，已达最大重试次数：', error); return false; } }}// 在分批写入循环中替换为带重试的方法async function dynamicBatchWrite(data: AccountingDataItem[]): Promise<void> { const batchSize = await getDynamicBatchSize(); for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchDataWithRetry(batch); }}五、方案总结本方案通过以下核心技术解决性能问题：动态分批处理技术，通过结合设备状态动态调整数据分批大小，形成一套灵活、高效的动态分批处理机制，可复用至其他需批量数据处理的业务场景，优化数据写

最近拜读了https://bbs.huaweicloud.com/blogs/450734这篇文章，里面讲解将ALL-reduce和GEMM融合的分块方式只切分M轴。因为通信任务调用的Hccl API要求分块数据内存连续，若按N轴切分，则每行数据都被切断，导致通信数据的内存不连续，不满足通信要求；若按M轴切分，则每行数据都是内存连续的，满足通信要求。看完后有两个疑问想请教下：文章里提到只对M轴切分，是否可以认为只对左矩阵切分，每个GPU拿到部分左矩阵数据，而右矩阵不切分，每个GPU拿到完整的右矩阵数据若只对M轴切分，则多卡通信汇聚数据的时候，理论上不需要将多卡的数据进行求和，这里为啥需要使用all-reduce而不是all-gather（我知道目前也是支持all-gather与gemm融合的，只不过all-reduce的这个分块方式令我有些困惑）由于我刚接触该融合特性，如果上面的理解有不到位的地方还请指正，多谢！

如题，我想通过AT指令来做SLE通讯，但是关于ws63 SLE AT指令，开发手册里所有SLE AT指令的响应都只有OK或ERROR，对于查询指令我该怎么获取查询后的数据 

我司自主研发的短信平台，从事于电信增值业务其中包含：行业通知类短信，验证码，视频彩信，5G消息，语音短信，在短信终端、数据传输等电信增值业务领域属同行业领先。三网短信服务，包括：验证码（发送速度3-5秒）、会员营销（提供多条备用通道）、通知（到达率99.9%）、消费（价格优惠）、订单（提拱及时状态）、祝福（提拱成功计费）、视频彩信，5G消息，语音短信等。截止目前，渠道代理商和技术合作伙伴达到30余家，产品覆盖全国100余个城市的20余个行业，超过5万家商企客户。其中包括：税务单位、医院、学校、教育局、12345、水务单位、供暖公司、大型软件公司等。实力雄厚，价格优惠，期待与您的合作！联系人：张经理    联系电话：17301310195

您好，使用环境为：AR502H + iCUBE-PLC100 + PLC-IS-1，以下是我从STA上导出的日志，多个头端均设定白名单，想请教如下几个问题:PLC STA日志：2025-02-03 01:07:15 Info[tman]:set sys time 2025-02-03 01:07:151970-01-01 00:00:00 Info[dev]:version: V200R021C10SPC100B1302024-07-24 23:59:59 Info[fanm]:start soft tf, set started2024-07-24 23:59:59 Notice[fanm]:plcmgr init successfully2024-07-25 00:00:00 Notice[fanm]:failed to get RF MAC address: 12024-07-25 00:00:00 Notice[fanm]:Without RF channel2024-07-25 00:00:06 Notice[fanm]:PLC connect2024-07-25 00:00:07 Info[fanm]:stop soft tf, set unstarted2024-07-25 00:00:07 Info[fanm]:set mac profile type by beacon success, type=12024-07-25 00:00:07 Notice[fanm]:PLC connect2025-02-03 04:28:23 Info[fanm]:recover net config successfully: host=fe80::02a4:00ff:fe07:28412025-02-03 04:28:23 Notice[fanm]:PLC authentication passed and online2025-02-03 04:28:24 Info[AUTH]:The 4-thread auth server has been created1970-01-01 00:00:00 Info[dev]:version: V200R021C10SPC100B1302024-07-24 23:59:59 Info[fanm]:start soft tf, set started2024-07-24 23:59:59 Notice[fanm]:plcmgr init successfully2024-07-25 00:00:00 Notice[fanm]:failed to get RF MAC address: 12024-07-25 00:00:00 Notice[fanm]:Without RF channel2024-07-25 00:00:32 Err[fanm]:sta association failed: nid=0xbf588a, freq=15, reason=1, cco mac=00:a4:00:11:53:412024-07-25 00:00:37 Err[fanm]:sta association failed: nid=0x857442, freq=15, reason=1, cco mac=00:a4:00:07:12:412024-07-25 00:01:00 Err[fanm]:sta association failed: nid=0x7ee2aa, freq=15, reason=1, cco mac=00:a4:00:07:27:412024-07-25 00:01:10 Err[fanm]:sta association failed: nid=0x65c7d5, freq=15, reason=1, cco mac=00:a4:00:07:18:412024-07-25 00:01:26 Err[fanm]:sta association failed: nid=0x8ac2c8, freq=15, reason=1, cco mac=00:a4:00:11:25:412024-07-25 00:02:07 Err[fanm]:sta association failed: nid=0xa91664, freq=15, reason=1, cco mac=00:a4:00:11:54:412024-07-25 00:03:00 Err[fanm]:sta association failed: nid=0x3f99a3, freq=15, reason=1, cco mac=00:a4:00:11:76:412024-07-25 00:09:36 Err[fanm]:sta association failed: nid=0x723f20, freq=15, reason=1, cco mac=00:a4:00:11:56:412024-07-25 00:14:36 Err[fanm]:sta association failed: nid=0xc5323e, freq=15, reason=1, cco mac=00:a4:00:11:60:412024-07-25 00:16:57 Err[fanm]:sta association failed: nid=0xee125e, freq=15, reason=1, cco mac=00:a4:00:10:90:412024-07-25 00:27:13 Err[fanm]:sta association failed: nid=0x3, freq=1, reason=1, cco mac=00:a4:00:07:12:412024-07-25 00:39:58 Err[fanm]:sta association failed: nid=0x3, freq=1, reason=1, cco mac=00:a4:00:07:24:412024-07-25 00:40:33 Err[fanm]:sta association failed: nid=0xd, freq=1, reason=1, cco mac=00:a4:00:07:05:412024-07-25 00:40:41 Err[fanm]:sta association failed: nid=0x3, freq=1, reason=1, cco mac=00:a4:00:11:60:412024-07-25 00:53:11 Notice[fanm]:PLC connect2024-07-25 00:53:12 Notice[fanm]:PLC connect2024-07-25 00:53:16 Info[fanm]:stop soft tf, set unstarted2024-07-25 00:53:16 Info[fanm]:set mac profile type by beacon success, type=12025-02-03 07:22:23 Info[fanm]:recover net config successfully: host=fe80::02a4:00ff:fe07:28412025-02-03 07:22:24 Notice[fanm]:PLC authentication passed and online2025-02-03 07:22:24 Info[AUTH]:The 4-thread auth server has been created[admin@huawei internal_storage]$ 问题1：在相同的环境下，且多个CCO均设定白名单，为什么STA第一次入网和第二次入网时，STA两次接入申请请求CCO节点会有这么大的差别，以至于第二次入网上线时间晚40分钟呢？问题2：在第二次入网中，STA在00:00:37申请接入【cco mac=00:a4:00:07:12:41】后，因CCO设定白名单接入时被拒绝，请问为什么在00:27:13还能再次申请呢？STA申请接入CCO的运行规则是怎样的呢？问题3：请问nid字段代表什么意思呢，为什么nid=0x3会有3个相同的呢？问题4：请问freq字段代表什么意思呢，freq=15和freq=1有什么差别呢？freq取值范围多大？内部是如何选择的呢？

深度数据包检测 (DPI) 技术是一种能够深入分析和控制网络流量的技术，其检测粒度达到应用层，可以识别和控制各种应用协议，如HTTP、FTP、DNS等。DPI技术广泛应用于网络安全、网络优化、业务运营等领域，能够帮助企业提高网络性能、保障网络安全、提升用户体验。 DPI技术的工作原理是对网络流量进行深入的分析和控制。当网络流量经过DPI设备时，设备会对流量进行深度分析，识别出流量的应用协议，然后根据预设的策略对流量进行控制，如允许、限制或阻断等。  例如，在网络安全方面，通过对网络流量进行深度分析，DPI可以实时检测和防范各种网络攻击，如DDoS攻击、网络钓鱼等。在网络优化方面，DPI可以识别和控制各种应用层协议，有效优化网络资源，提高网络性能。   DPI技术的应用对于企业和个人都有着重要的意义。对于企业来说，DPI技术可以帮助他们提高网络性能、保障网络安全、提升用户体验，从而提高企业的运营效率和竞争力。对于个人来说，DPI技术可以保护他们的网络安全，避免网络攻击和网络钓鱼等安全威胁，提高他们的网络使用体验。  DPI技术还可以用于构建用户画像。在当今这个信息爆炸的时代，品牌了解自己的用户变得越来越重要。用户画像中包含了用户的年龄、性别、地域、社交关系、兴趣偏好、触媒习惯、行为特征、消费习惯等信息，可以帮助品牌深入了解目标用户群体，洞察用户真正的动机和行为。这对于品牌来说，具有重要的营销和产品设计意义。  

使用c语言ebpf和int _sockops(struct bpf_sock_ops *ctx)函数，map随意我是初学者，死活写不出来，求教大佬们。

您好，我们想通过容器内的APP程序查询获取到通信链路的中继等级、衰减和信噪比等参数，实现对通信链路状态的监控，但查阅了《边缘计算网关二次开发指南（AR502H-CN）》，未找到相关方法，请专家提供技术指导，感谢

1.Q: CPE下挂的PC DHCP拿不到地址？A：CPE关联的AP的上行交换机接口，检查放通的vlan，不可以放通cpe-tunnel的vlan2.Q: CPE关联上之后，在AC上display station all查看发现协商速率只有几兆？A: 需要关闭BSS COLOR，因为我们AP和CPE支持的bss color值不一致，可关闭该功能规避。3.Q: CPE下挂STA 上行链路不稳定，ping上层网关时通时不通？A： 检查CPE-TUNNEL中的vlan配置，双发选收配置下2.4G和5G的cpe-tunnel的pvid vlan不可以一样，frer vlan必须一样。​4.Q：CPE关联成功后，过一段时间就掉线重新关联？A: 检查CPE的iconnect开关，环境里没有iconnect服务器的话，需要关闭该功能才能正常使用。5.Q:CPE和AC/AP建隧道，跑极限性能掉坑或者跑流性能低？A:需要配置MTU 1700，在AP系统模板、AP的capwap vlan和CPE的service-vlan都要配置MTU 17006.Q: CPE与AP建隧道，静止状态下，下挂终端ping上层服务器，ping一晚上，ping包40000，丢包2-20？A: 根据丢包具体时间查看AC是否有该CPE的掉线记录(dis station offline-record all)。查看AC是否开启调优(dis wlan calibrate global configuration / dis channel switch-record all)查看信道是否改变。如果时间一致，就是调优的时候信道切换导致CPE掉线，关闭调优功能可以解决。7.Q: CPE与AP建隧道，AC上执行dis cpe-tunnel remote-station all查看下挂终端设备数量与真实数量不一致?A:AP上查询的终端表项是实时的，但是AC需要等AP同步过来（大概5min），所以AC上的查询结果可能与实际不一致。8.Q:R19C10版本AP，对接九联CPE，CPE关联psk信号失败？A:R19版本AP有问题，升级可解。9.Q:CPE测试极限性能，跑流只有几十兆，无法达到规格？A:如果是用的转接头测试，建议更换转接头尝试，或者更换电脑和网线。10.Q:CPE下挂STA可以ping通百度的ip地址，但是打不开百度网页？     A:1.检查DNS服务器是否可达，配置是否正确。2.检查该电脑的其他网卡配置，如果不用可以先禁用其他网卡。11.Q:CPE下挂STA和上层服务器通讯，网络中一直存在丢包？     A:检查下CPE是否开启漫游，并且漫游阈值设置不合理，导致CPE一直在AP间反复漫游。如果实际使用不需要漫游可以关闭漫游开关，如果需要漫游可以根据现场情况调整漫游阈值。

0 引言隐私计算作为一种助力实现“数据可用不可见”的关键技术，在近几年受到了越来越多的关注，相关技术产品百花齐放、行业生态建设如火如荼。从技术发展的角度看，隐私计算之所以如此火热，主要在于它改变了传统的数据流通形态，增强了数据流通的可控性，在一定程度上回避了数据权属与安全保护争议，为数据要素流通提供了新模式[1]。在推广隐私计算落地应用的过程中，不同技术厂商提供的产品和解决方案在设计原理和功能实现之间存在较大差异，使得部署不同技术平台的数据流通参与方之间无法跨平台完成同一个计算任务。为实现多个合作方之间的数据融合，用户往往要付出极高的沟通成本以协调产品选型方案，甚至不得不部署多套产品以逐一适配，造成重复建设。作为促进跨机构间数据共享融合的关键技术，隐私计算有望成为支撑数据流通产业的基础设施，但高额的应用成本不利于隐私计算技术的推广应用，解决不同产品之间的技术壁垒，实现隐私计算跨平台间的互联互通已成为产业内的迫切需求。推进隐私计算的跨平台互联互通需要关注哪些问题和要点?本文拟从以下六个方面展开讨论。1 隐私计算跨平台互联互通的需求数据资源只有经过“流通”，脱离了原有使用场景，从数据产生端转移至数据应用端，并在生产经营活动中产生效益，才能真正释放其作为生产要素的市场价值[2-3]。在数据权属界定规则缺失、安全合规风险加剧的当下，众多数据从业者选择隐私计算作为探索数据流通新模式、新形态的突破口。隐私计算已经成为了当前数据流通领域最火热的一类技术，但在技术推广的过程中，不同隐私计算技术平台之间无法互联互通成为了制约产品落地应用的一个关键阻碍。1.1 助力多方数据融合降本增效的市场用户需求作为一类助力数据流通的工具，产品的可用性、易用性、好用性决定着隐私计算技术价值发挥的范围和程度。在此前几年的时间里，国内技术提供者们已经在提升产品的可用性和易用性方面取得了一定的进展。根据中国信息通信研究院云计算与大数据研究所和隐私计算联盟工作中的调研交流和产品评测结果[2]，可以发现在算法、算力、硬件的协同优化之下，行业内整体的技术产品性能已可以满足用户业务的基本需求，并且还将持续优化以促进隐私计算在更多需求场景中可用；同时，越来越多的技术厂商可以提供多版本、轻量化等方式来提升用户部署的便捷性，并配合模块自定义、组件拖拉拽等设计来满足用户的个性化需求，提高产品的易用性。进一步地,在如何提升产品好用性、促使产品与用户实际业务场景友好适配这个层面，隐私计算技术平台之间的互联互通就成为了关键话题。目前，市场上已经发布了近百款隐私计算产品，且仍有许多企业和机构正在研究和开发。而不同产品均有各自特定的算法原理和系统设计，产品之间（甚至同一产品的不同版本之间）的技术差异使得彼此很难兼容、无法互通。因此，参与联合计算的用户只能在部署相同产品的情况下才能实现多方数据合作。为了满足这一条件，单一用户往往要部署多套产品以满足不同合作方的需求，这极大地增加了用户的使用成本，也阻碍了隐私计算技术的推广落地。1.2 打造数据流通基础设施关键底座的产业需求跨行业、跨机构的数据融合在金融、电信、医疗、政务、广告营销、智慧城市等诸多场景都有着广泛的需求。但由于国内对于数据流通使用的监管要求趋严，且尚未出台具有指导性的实施细节指引，相关企业和机构参与数据流通时既有顾虑也有困惑，无疑阻碍了数据资源的充分流通，不利于数据要素市场的培育。而隐私计算技术正在以一种不交互原始数据，只流通数据使用价值的方式，推动着传统数据流通模式和流程的变革，有望成为全社会数据流通网络的支撑型基础设施。但是现阶段，隐私计算整体的技术能力和应用模式还不成熟，实现目标仍有距离。以当前在金融场景的应用模式为例，金融机构往往都需要依靠多方来源的外部数据来支撑其对于诸多业务的风险控制，这些外部数据可能包括专业数据服务商提供的公共市场信息、政府公共部门提供的客户基础信息、征信机构提供的客户征信数据以及运营商、互联网平台、电商平台等提供的更多替代数据等。参与其中的银行、运营商等大型机构很多已经部署或开始试点各自的隐私计算平台，面对多机构之间的数据资源合作需求，往往会在反复沟通后由相对强势的机构要求使用特定的隐私计算平台进行合作。以此类推，如果在各个应用场景中，合作机构之间都要就使用特定技术产品达成共识，长此以往，市场就会衍生出一个个基于相同的隐私计算平台捆绑形成的小生态，而各个生态之间仍旧相互孤立。那么，隐私计算在破除机构间“数据孤岛”问题后，将催生一个个新的“数据群岛”，与技术本身促进数据流通的使命相背离，无法支撑建立面向全社会的数据流通网络。因此，隐私计算平台之间的互联互通已成为技术产业进一步发展中亟需解决的问题。2 隐私计算跨平台互联互通的内涵解决隐私计算跨平台互联互通问题的核心基础，是理解它的概念内涵。（1）什么是“互联互通”? 这个概念最早是美国电信领域在1934年提出的，本意是两个通信网络之间是否能够兼容，而在当下这一概念逐渐演变为不同组织、不同场景、不同系统之间在平台“互操作”与数据“可携带”等方面的问题。（2）互联互通的客观对象是什么? 隐私计算跨平台互联互通的最根本需求来自于部署了不同产品的用户，这里的“不同产品”既可能是不同技术厂商提供的多个产品，也可能是相同厂商相同产品的不同版本。进一步地，与其说是不同产品间互联互通，不如说是用户部署不同技术产品后的一个个平台实例。（3）互联互通的目标形态是什么? 用户的最终诉求是希望在部署不同产品后，仍可以实现各自持有的数据在不同底层技术平台之前间仍可以流畅传输、交互、融合，协同完成计算任务。因此，隐私计算跨平台互联互通的目标形态是具有不同系统架构或功能实现方案的隐私计算技术平台（包括同一平台的不同版本）之间通过统一规范的接口、交互协议等实现跨平台的数据、算法、算力的互动与协同，以支持部署不同技术平台产品的用户共同完成同一隐私计算任务。相比之下，实践中部分针对多个不同产品之间部署于统一大平台以支持用户灵活选择任一产品执行任务的探索，更贴近于对于不同提供方隐私计算能力模块的集成，而非真正的跨平台互联互通。3 隐私计算跨平台互联互通的难点隐私计算技术原理本就复杂，而异构隐私计算平台间的互联互联不仅要能够实现复杂的隐私计算原理，保证平台原有功能的实现，还要提供足够的包容性，考虑到不同平台设计的复杂差异。3.1 不同隐私计算核心技术路线之间存在天然壁垒隐私计算并非一项单一技术，而是一个包含多种技术的复杂体系。例如，以密码学为核心原理的多方安全计算类产品、以安全硬件为核心原理的可信执行计算类产品和以“数据不同模型动”为核心思想的联邦学习类产品之间，技术实现的最底层思路就有着天壤之别，这种技术上的差异性为现阶段讨论隐私计算互联互通带来巨大挑战[4]。3.2 算法的实现方案复杂多样隐私计算最核心和最关键的就是算法，但每个算法在从设计到实现上经过多个环节，涉及诸多细节。在基础原理上，即使是同一算法从实现原理上也可能有多种不同的实现方案。例如，基于不经意传输和基于同态加密的方案都是从密码学原理出发的，但实现方案却无法兼容。在工程优化上，对于同一密码学协议下的相同算法，不同的设计者也可以选择不同的加速器进行优化，差异依然明显。进一步地，在不同的计算架构设计下，计算方数量也会不同，是否由中间协调方参与、计算方和数据方之间是否独立也会对算法执行产生不同影响。3.3 不同技术提供者在平台应用管理的设计各不相同除了核心算法之外，一套完整的隐私计算平台还包含资源授权、任务管理、任务编排、流程调度等相关的控制管理功能，且不同平台整体的系统架构也是结合各自的研发思路和应用侧重来设计实现的，跨平台任务的执行需要适应不同平台的这些设计。因此，基于不同隐私计算平台共同完成同一计算任务，就必须要解决基础功能和算法实现如何在不同平台上兼容和适配的问题。3.4 技术提供者之间相互适应的驱动力不足除了技术产品设计本身的复杂性之外，技术提供者们的驱动力不足也会对实现互联互通产生障碍。无论是技术路线的选择、核心算法的设计和基础功能的实现，都是各个隐私计算技术提供者最核心的设计思想和知识产权，实现互联互通的过程中势必会存在一定的相互迁就与妥协，损失产品原有的个性化。现阶段，在隐私计算的应用探索仍在推进，用户增量不断，因此在进入存量竞争之前，跨平台互联互通对于技术厂商而言并非“刚需”。因此，已有的探索实践大多是用户侧推动的。4 隐私计算跨平台互联互通的实现路径4.1 隐私计算跨平台互联互通应满足的特性考虑到现有隐私计算技术产品之间存在较大的差异性和商业驱动力的现状，若要实现不同技术产品间的协同，就不能要求所有产品同质化、统一化，必须尊重各平台本身的设计思路和理念，在保证各隐私计算技术平台的独立性、完整性和安全性的基础上对实现互联互通的最基础环节求同存异。因此，隐私计算跨平台互联互通的实现方案应该满足以下特性。一是互通性。即不同技术平台间应支持通用、规范的通信接口和互联协议，能够进行跨平台的通信、数据交换、互联操作和状态同步。二是平台自治性。即各平台均应为自治系统，保留对各自平台设计的独立性和个性化，自主管理平台内部的任务协同与资源配置，在参与跨平台互联互通任务时，无需暴露内部的私有协议、模块设置和架构细节。三是正确性。即跨平台互联互通完成的隐私计算任务与各平台独立完成的隐私计算任务结果保持一致，或偏差在不影响应用的范围内。这是隐私计算技术产品的最基础的功能要求。四是安全性。即不同平台间的交互和协同应通过统一的安全通信机制、认证与授权机制、安全模型假设等保障跨平台互联互通的通信安全、应用安全、算法协议安全。这是隐私计算技术产品的最关键的应用要求。五是易扩展性。即不同平台间的互联互通应支持较为灵活的加入或退出，可以随着技术发展适配更多新的隐私计算功能实现方案，实现有机扩展。这要求互联互通方案能够包容和应对未来技术发展带来的挑战。4.2 隐私计算跨平台互联互通的实现思路而具体如何实现互联互通，可以对其他技术或行业应用场景中的互联互通经验进行参考和借鉴。比如互联网数据传输场景中的TCP/IP协议、银联银行卡跨行交易的通用报文协议、国内外物联网的跨平台接入协议等都是通过制定系列标准化的协议，约定不同的设备如何组织和接入同一网络并进行数据交互。其中，互联网通过多层次的协议设计连接多设备、多网络的成功经验可以为通过隐私计算串联起的数据流通网络提供较多参考，隐私计算跨平台的互联互通也可以拆解成底层的通信、逐步上升到传输交互和顶层应用，通过逐层定义共识性的技术标准，最终实现规范流畅的跨平台协作。以相关经验为参考，隐私计算跨平台互联互通的实现路径可以从“底层通信—中间层交互—顶层应用”的思路出发进行设计。通信层需对平台间选择的通信框架、通信接口、数据格式、传输机制等内容进行规范；交互层可以从节点、资源和算法执行三个维度进一步约定在跨平台交互过程中在发现、认证、申请、授权、连接调用、信息和状态同步等环节的规范流程和要求；而应用层则是在规范通信要求和互联协议栈的基础上定义跨平台隐私计算任务实现过程中的协同管理要求和具体场景的实现流程，既包括对跨平台任务编排、调度、执行、监控和存证等方面的统一规则，也包括不同类型计算任务的实现流程的约定。5 隐私计算跨平台互联互通的探索进展自2021年开始，很多隐私计算技术提供者和应用侧都开始推进跨平台互联互通的尝试，提出了不同的思路和方案，也取得了一定的进展。中国电信翼支付的隐私计算技术团队通过引入中间件和区块链智能合约的方式实现了自研Priv Torrent隐私计算平台和FATE开源框架的对接[5]。基于中间件对交互过程中报文的转换实现异构平台节点识别、算法数据报文重构、任务事件转发和任务状态同步；基于区块链的智能合约实现两个平台间底层通信、交互标准以及报文分类和内容（包括过程数据、任务状态和执行结果）的统一。这个方案提供了一种相对低耦合、易扩展的解决思路，中间件可以灵活部署在任意节点,而区块链可以进一步地支持对任务的审计溯源。但是这一方案也存在局限性，一是平台的原生内核限定在FATE框架，二是需要以隐私计算与区块链的耦合作为前提。富数科技和微众银行在2021年4月宣布突破了隐私计算跨平台、跨架构的互联互通难题，双方团队按照认证、管控、计算三个主要流程，抽象出节点、数据、算法组件、计算任务、存证、认证六大对象模型，提出了从节点互相发现、资源互相共享到算法组件跨平台迁移部署再到计算任务跨平台执行的三阶段思路。类似于这一思路，洞见科技、锘崴科技和蚂蚁集团共享智能部在2021年8月宣布联合攻关完成了具体互通协议流程的架构设计和落地实现。在第一层次统一了节点发现、业务流程对接、资源信息定义和管理的规则之上，进一步实现了三个平台各自独立设计和开发的算法插件可以直接在另两方的平台上运行，并与其他参与方协同完成计算任务的执行和结果输出。这类方案无需引入中间件或其他系统，可以较大程度地保留各自平台算法功能的独立设计，与本文讨论的实现路径基本一致，但是除了算法功能之外，各个技术提供者对于底层通信框架、上层工程化方案的设计仍有诸多坚持，若要取得大范围的行业共识仍有较大难度。除了以上实施案例之外，华控清交与星云Clustar、矩阵元、冲量在线等技术厂商也宣布建立战略合作探索隐私计算跨平台互联互通。参考互联网中自治系统、边界网关协议和TCP/IP协议的设计思路，华控清交提出了一种定义跨域数据交换（Inter-Domain Data Exchange，IDDE）协议实现互联互通的思路。将不同的隐私计算平台视为独立的自治系统（AS），并参照TCP、UDP和IP协议向上可满足多类应用、向下可兼容多种底层物理通信机制的思路，来规范IDDE中的核心协议。其中，IDDE协议包含控制面、数据面两部分，控制面对节点、资源的信息和任务调度、存证等内容进行规范；数据执行层则负责规范在各隐私计算平台中执行已编排的计算过程。6 隐私计算跨平台互联互通的未来推进思路当前，从标准体系层面对利用隐私计算跨平台互联互通的具体方案进行规范势在必行，包括中国信息通信研究院云计算与大数据研究所牵头的隐私计算联盟、大数据技术标准推进委员会（TC601）、全国信息安全标准化技术委员会（TC260）、京金融科技产业联盟等在内的标准化组织和研究机构都在推进相关技术标准的研讨和编写。但是，隐私计算的跨平台互联互通不只需要在技术层面进行攻关，更需要在商业层面继续突破。因此，相关标准规范体系不能只停留在标准文稿制定层面，等待由统一的规则指导实施，还必须从实践中汲取经验，推广运营事实标准，由正式标准在原则要求层面对事实标准进行引导，由事实标准从实际业务场景中对正式标准进行细化完善，双管齐下，最终在技术方案选择、跨平台协同和具体应用实施的各个环节给出具有普遍共识的、可落地执行的细节指引。7 结束语现阶段，隐私计算技术发展尚未完全成熟，对于如何将复杂的技术原理转化为商业化的产品实现已经是百家争鸣，而对于如何将不同技术方案串联起来协同应用于数据互联互通的实际场景，仍有众多观点在持续探讨。在技术发展过程中，只要行业保持对于各类观点思路的开放包容，并坚持通过广泛交流和探索来挖掘最佳实践，相信隐私计算的跨平台互联互通难题也能尽快得到突破。参考文献[1] 李凤华, 李晖, 贾焰, 等. 隐私计算研究范畴及发展趋势[J]. 通信学报, 2016,37(4):1-11.[2] 王思源, 闫树. 隐私计算面临的挑战与发展趋势浅析[J]. 通信世界, 2022(2):19-21. DOI:10.13571/j.cnki.cww.2022.02.007.[3] 闫树, 吕艾临. 隐私计算发展综述[J]. 信息通信技术与政策, 2021,47(6):1-11.[4] 徐葳, 王云河, 靳晨, 等. 基于隐私计算的数据流通平台互联互通思考[J]. 金融电子化, 2021(9):72-73.[5] 徐潜, 章庆, 喻博, 等. 基于中间件与区块链的异构隐私计算平台互通系统研究[J]. 信息通信技术与政策, 2021,47(6):38-49.文章转自中国信通院CAICT公众号：文章链接

类似安装在windows操作系统的KEPSERVER这款软件。有兴趣的大拿们，可以留个言。支持原创国产化、支持工业化Teams software LTD,C&江苏特姆斯软件

笔记本连接到小熊派了以后，可以使用QCOM和小熊派进行正常的AT指令通讯，但是使用HUAWEI-LiteOS-Studio的串口调试就没有办法接收到信息了麻烦帮我看下，是什么问题，会不会影响到后面的开发

本文主要介绍说明XQ6657Z35-EVM评估板Cameralink回环例程的功能、使用步骤以及各个例程的运行效果。（基于TI KeyStone架构C6000系列TMS320C6657双核C66x 定点/浮点DSP以及Xilinx Zynq-7000系列SoC处理器XC7Z035-2FFG676I设计的异构多核评估板，由核心板与评估底板组成。评估板CameraLink功能支持2路Base输入、或者2路Base输出、或者1路Full 输入或输出）ZYNQ7035 PL Cameralink回环例程1.1.1 例程位置ZYNQ例程保存在资料盘中的Demo\ZYNQ\PL\base_cameralink_loop\prj文件夹下。1.1.2 功能简介Cameralink回环例程将J3、J4当作两个独立的Base Cameralink接口使用，一个接收，另一个发送。Cameralink接收端，利用Xilinx ISERDESE2原语进行串/并转换，将LVDS串行数据转换成28bit的cameralink并行数据。解串后的并行数据通过ila进行在线分析和查看，并实时检测并行数据是否有误码。Cameralink发送端，利用Xilinx OSERDESE2原语进行并/串转换，将本地28bit cameralink并行数据串行化为LVDS数据发送出去。1.1.3 Cameralink接口时序说明1.1.3.1 Cameralink三种配置模式Base模式：只需一根Cameralink线缆；4对差分数据、1对差分时钟；Medium模式：需要两根Cameralink线缆；8对差分数据、2对差分时钟；Full模式：需要两根Cameralink线缆；12对差分数据、3对差分时钟。各种模式下，统一都包含一组控制口和一组串口。控制口有4根信号，用于图像采集端对相机的IO控制；串口用于图像采集端对相机参数的配置。1.1.3.2 单路差分数据与时钟之间时序关系单路Cameralink差分数据与随路的差分像素时钟之间的时序关系如下图所示：一个时钟周期内传输7bits串行数据，首先传输串行数据的最高位，最后传输串行数据的最低位。7bits数据起始于像素时钟高电平的中间位置，即数据的最高位在Clock高电平的中间时刻开始传输。Clock高电平时间比Clock低电平时间多一个bit位。1.1.3.3 通道传输数据与图像数据映射关系1路差分数据通道上，一个Clock像素时钟周期传输7bits串行数据，那么4路差分数据通道总共就是4*7bits=28bits，我们称这28bits数据为并行数据，为了方便描述，这28bits数据记为TX/RX27~0。Cameralink Base模式下，这28bits数据与图像行/场同步/数据有效标记、图像数据的映射关系如下图所示：TX/RX24映射为行同步标记LVAL，TX/RX25映射为场同步标记FVAL，TX/RX26映射为图像数据有效标记DVAL，TX/RX23未使用，其余位对应图像数据。1.1.3.4 28位并行数据与4路差分数据传输通道之间的映射关系上述28位并行数据是如何通过4路差分数据传输通道进行传输的呢？28位并行数据映射到4路差分数据传输通道各个时刻点的位置关系如下图所示：1.1.4 管脚约束ZYNQ PL工程管脚约束如下图所示：1.1.5 例程使用1.1.5.1 连接Cameralink线缆使用Cameralink线缆将J3、J4两个接口连接在一起：1.1.5.2 加载运行ZYNQ程序1.1.5.2.1 打开Vivado工程打开Vivado示例工程：工程打开后界面如下图所示：1.1.5.2.2 下载ZYNQ PL程序下载bit流文件base_cameralink_loop.bit，并且配套base_cameralink_loop.ltx调试文件，如下图下载界面所示：1.1.5.3 运行结果说明ZYNQ PL端提供的ILA调试窗口，可以实时抓取采集Cameralink并行信号以及错误检测信号的时序波形。hw_ila_1调试界面抓取Cameralink并行发送数据，是一个28bits的累加数：hw_ila_2调试界面抓取Cameralink并行接收数据、接收误码统计以及接收误码实时标识信号，如下图所示：cameralink_rx_err_num显示有数值，则说明Cameralink接收过程中存在误码。可能在开始通信初始化期间存在误码现象，导致cameralink_rx_err_num误码统计累加。待程序下载完毕后，如果Cameralink通信正常的话，cameralink_rx_err_num误码统计应该不会再累加。如果cameralink_rx_err_num误码统计继续不断累加，则通过触发camera_rx_error信号可以捕捉到误码具体发生时刻。1.1.5.4  退出实验Vivado调试界面Hardware Manager窗口，右键单击localhost(1)，在弹出的菜单中点击Close Server，断开ZYNQ JTAG仿真器与板卡的连接：最后，关闭板卡电源，结束。

 下面是 方法void onEvtLoginFailed(int userId, TsdkServiceAccountType serviceAccountType, TsdkLoginFailedInfo loginFailedInfo);中TsdkLoginFailedInfo的信息。TsdkLoginFailedInfo{reasonCode=50331748, reasonDescription='[TSDK_E_CALL_ERR_REASON_CODE_PAYMENTREQUIRED]:Indicates 402 payment required', lockInterval=0, residualRetryTimes=0}出现的场景是有多个账号，在华为的HW CouldLink登录了一个，我的二开软件登录另一个账号就报这个错误