标签: 数据处理

一、前言 作为一名 高校的科研工作者 ，在高校的科研工作中，经常需要处理各种复杂的数据流，尤其是 视频采集和处理 的工作，对数据的实时性和精度要求非常高，我首次试用ADTF时，主要负责开发一个 集成FFmpeg的Filter组件 ，处理摄像头采集的raw数据，并对其进行H264编解和解码。在这个试用的过程中，我对ADTF的初步体验是它的设计 非常便捷 ，尤其是对于 图像和视频数据的处理。 通过这次开发，我对 ADTF的模块化设计、流数据传输机制以及其便捷的开发环境 有了更加深刻的认识。接下来，我将从多个角度详细分享我的试用体验，内容涵盖 ADTF的优势、工作流程中的亮点 ，以及 未来展望 等方面。 二、ADTF的用户界面与灵活性 在打开ADTF时，我觉得其 直观的GUI设计 非常的友好。作为一名高校科研工作者，我们通常需要频繁的调整实验配置、切换不同的开发场景，而ADTF的界面布局使得这些操作变得十分便捷。 其工具栏、Component、Sessions管理以及快捷命令栏 的存在，极大的 优化了工作的流程 。能够在搭建工作流时，迅速的找到所需要的工具和组件，并轻松的管理多个实验配置，这在需要进行多项实验的科研工作中尤其重要。 ADTF的模块化设计 使我能够快速自由的组合各种组件，构建适合 具体科研需求 的工作流。例如，我能够通过ADTF提供的Store模块，轻松地管理不同的数据流和实验配置。这种灵活性对于需要 快速迭代实验和算法验证 的科研工作来说非常有利。 三、便捷的组件开发 我在ADTF中开发的Filter组件，集成了FFmpeg进行H264图像数据编解码，这使得我能够处理摄像头采集的raw数据。ADTF提供了 标准的图像数据流定义 ，使我可以快速上手，并通过 自定义的数据流类型进行数据的高速传输。 让我印象深刻的是，ADTF允许我创建自定义的流类型，并将编码后的视频数据发送至下一个Filter进行解码。这种模块化的设计对于处理复杂的多步数据流非常有帮助，尤其是在 处理视频和音频等 连续数据时。 ADTF的流数据传输机制非常稳健 ，特别是在 高速数据吞吐 情况下，它依然能够保证数据的完整性和及时性。例如，当我处理大规模视频数据时，ADTF通过其文件的流数据传输体系很好地管理了数据流的传输，确保没有出现数据丢失的现象。这一点在要求 高精度 的场景下， ADTF的表现非常好 。 此外，ADTF的组件开发过程也充分展示了其 灵活性 。在开发Filter组件时，ADTF中可以自定义流类型，不仅能与标准化的数据流兼容，还能针对特定需求自己定义。通过这种方式，我可以轻松的将编码后的视频数据 传输至下一个 解码或者处理视频数据的组件，实现多步数据流处理。在整个开发过程中，我清晰地感受到了ADTF模块化设计所带来的便利，它允许我 根据不同的实验需求进行自由组合和扩展。 四、丰富的工具箱和组件 ADTF还有一个非常好的亮点是它 丰富的工具箱 。我在开发组件的过程中直接使用了ADTF自带的Windows摄像头驱动采集数据，避免了繁琐的硬件配置。此外，ADTF还提供了Qt以及foxglove等显示组件，使我能够实时监控摄像头捕获的视频流，很大程度上方便了我的开发和测试。这种 预制组件的存在大幅度缩短了开发时间 ，我可以把更多的精力集中在数据处理的核心逻辑上。 在科研项目中，快速的验证新算法和新想法是我们的日常工作。 ADTF通过大量现成的组件，帮助我们在短时间内可以搭建一个完整的测试环境 。例如：我可以迅速继承已有的摄像头采集组件，并通过简单的操作和配置就可以完成视频流的显示和存储。这种集成工具的便利性是在科研工作中快速迭代优化的重要支撑。 五、外部库与ADTF完美结合 在科研项目中，大部分的功能需要 依赖外部库 ，比如OpenCV、FFmpeg…，在这次的开发过程中，我通过FFmpeg对摄像头采集的raw数据进行H264编解码。 ADTF的开放性和模块化 使得FFmpeg的集成过程十分顺畅，通过Filer组件可以轻松调用FFmpeg的功能，将raw数据进行编码，并在解码阶段还原数据进行显示。 FFmpeg强大的视频处理能力与ADTF的稳定数据流传输机制相结合，使我能够达到项目中要求的实时数据处理。通过把FFmpeg集成到ADTF中，我能够以较低的系统资源消耗完成高效的视频编码和解码，还可以在我设计不同的试验方案时，快速的帮我搭建适合试验方案要求的工作流。 ADTF与FFmpeg的结合组件展现了非常出色的扩展性和稳定性。 六、未来展望 通过对ADTF的使用，我认为ADTF为高校的科研人员提供了一个强大的数据处理和开发平台，A DTF在处理大规模数据流、视频数据编解码等领域具有极大的潜力。 这种模块化设计使我们能够轻松定制复杂的工作流程，特别是在处理多个传感器数据和视频流时，ADTF提供了极高的灵活性。 在未来对ADTF的使用中，我将会进一步探索ADTF在 自动驾驶、智能交通系统等领域 的应用，并希望能够看到它在数据处理和算法开发中的更多突破。

在上期 数据隐私和匿名化系列 文章中，我们主要分享了 《中国个人信息保护法》（PIPL） 和 《欧盟通用数据保护条例》（GDPR） 在 涵盖范围、定义、敏感信息 等方面的异同点，今天，我们将重点分析PIPL与GDPR在 数据处理行为及其基础合法性 方面的异同，旨在帮助车企更准确地把握数据隐私保护法规的要求，有效应对相关挑战，推动自动驾驶行业健康发展。 一、PIPL和GDPR的异同点 1、数据处理行为定义 两部法规（PIPL和GDPR）均明确界定了 不同的数据处理行为 ，这些行为将触发各自法规的管理范畴。此处所提及的信息， 已不再局限于敏感信息 ，而是涵盖了两部法规所规定的 所有相关信息 。 在 英文版的PIPL 中，数据处理行为被表述为“ Handling ”，而 GDPR 则使用 “Processing” 一词，两者在本质上并无区别。然而，在 数据处理行为的定义上，两部法规却存在些许差异 。 PIPL中的“Handling”涵盖了 收集、存储、使用、加工、传输、披露以及删除个人信息 等一系列行为。相较于PIPL， GDPR 关于数据处理行为的定义则 更为详尽 ，除了包含上述相同的行为外，还涉及到了 个人数据的检索、咨询 等多个方面。 但实际上，当我们深入探讨PIPL中定义的数据处理行为时，相关法律专家指出： “在中国境内处理个人信息时，GDPR所涵盖的任何数据行为都需要被纳入考虑范围，即使PIPL并未完全列举出所有要点。” 由此可见，在各自司法管辖区域内处理相关数据时，任何数据处理行为都将受到该区域法律条例的约束。 2、数据处理基础合法性 为了进一步对比数据处理行为的异同，我们在此列举了中国的《个人信息保护法》（PIPL）与欧盟的《通用数据保护条例》（GDPR）在 数据处理基础合法性 方面的相关规定。 “同意”（Consent） 是指数据主体明确授权或表示同意其个人数据被处理的行为。这种同意必须是建立在充分知情的基础上，且必须是明确且自愿给出的。 除了“同意”这一点外，我们重点关注两部法律在 合法利益（Legitimate Interest）和公共利益（政府任务）（Public Interest/Government Task） 方面的差异。实际上，PIPL在这两点上并未作出明确规定，这主要归因于中国和欧洲在法律及监管环境上的差异。 首先在 合法利益 这一点上，GDPR作为欧洲地区的人权保护框架，旨在平衡企业与个人之间的权益，为企业提供一定的 灵活性 ，允许其在没有明确同意的情况下处理个人数据，从而在一定程度上增强了企业的自主权。相比之下， PIPL更加强调对个人信息的严格控制。 在处理个人数据时，PIPL要求必须获得明确的授权或依据法律规定进行，更倾向于通过明确同意或法律规定来实施严格监管。 其次在 公共利益 方面，两部法律对公共事务和政府职责的界定存在差异。 GDPR 在确保公共机构履行任务时赋予了更大的 灵活性 ，而PIPL则通过其他法律条款来规范政府的处理权限，更加侧重于 信息透明性和数据主体的保护 。 二、信息跨境处理注意事项 在 跨境处理信息 的过程中，除了需遵循《个人信息保护法》（PIPL）和《通用数据保护条例》（GDPR）这两部基础法律的规定外，还需执行一系列严格的 安全评估措施。 以中国车企为例，若需将欧盟境内的数据传输回中国进行处理，必须确保该跨境数据传输完全符合GDPR的严格要求。 GDPR对向欧盟外传输数据有着明确的规范，要求必须依赖 标准合同条款（SCCs）或充分性决定（Adequacy Decision） 来确保数据的合法传输。特别是当涉及敏感个人信息处理时，如位置数据、行为数据以及测绘数据等，企业可能还需进行 数据保护影响评估（DPIA） ，以全面评估数据处理的合法性、必要性和风险性。 值得注意的是，由于欧盟目前尚未对中国作出充分性决定，因此中国企业在向欧盟外传输数据时，可能需要与相关方签订 标准合同条款（SCCs） 来确保数据传输的合法性。 总之，在跨境传输过程中，为降低数据泄露或不当使用的风险，企业需对敏感数据进行加密或匿名化处理。

自动驾驶技术的快速发展伴随着数据隐私保护的严峻挑战。 中国《个人信息保护法》（PIPL）与欧盟《通用数据保护条例》（GDPR） 为自动驾驶数据合规设立了高标准。本篇文章将带大家深入探讨PIPL与GDPR的异同点，期望能够帮助车企更好地理解并应对数据隐私保护法规的挑战，推动自动驾驶行业健康发展。 一、自动驾驶数据合规挑战 2021年8月20日， 中国 发布了一项重要的 数据保护法 ，即《个人信息保护法》(Personal Information Protection Law, PIPL)。围绕数据隐私，将零碎的立法统一并加强为一套完整的规范，包含数据的收集、处理和保护等规则。 与 欧盟的通用数据保护条例 （General Data Protection Regulation,GDPR）类似，PIPL在众多方面对于数据隐私做出了相应的限制。 图1 部分国家和地区的数据隐私法规 数据隐私保护法规的相关限制对自动驾驶行业无疑是一项 重大挑战 。这是因为近年来在自动驾驶行业，众多新能源车企已经将眼光从逐渐饱和的中国市场转向欧洲市场，而 数据采集作为自动驾驶数据闭环的开始 ，在中国地区和欧洲地区之间的数据转移必须要符合相应地区的隐私保护法规，否则可能会和Google一样， 因涉嫌侵犯用户的隐私而面临巨额罚款。 目前GDPR相关的罚款总额现已达到近50亿欧元。 图2 累计罚款总额（来源：GDPR Enforcement Tracker ） 在中欧地区之间进行自动驾驶行业的 数据转移 时，为帮助车企避免违规受罚，本文接下来将从多个方面讨论 中国和欧盟隐私保护法规的异同之处。 二、PIPL和GDPR的异同点 1、覆盖范围 PIPL的范围： （1）中国境内的个人信息的处理；（2）在海外处理中国境内个人信息：a.必须为中国提供产品或相关服务;b.中国公民的行为或是活动的数据分析处理必须在中国境内进行。 在 覆盖范围 这一层面上，GDPR（欧盟通用数据保护条例）与PIPL（中国个人信息保护法）呈现出相似性。就PIPL而言，它明确保障了在中国境内居住公民的个人信息安全。而对于在境外处理涉及中国公民个人信息的数据活动，PIPL同样设定了条件，即这种处理必须旨在向中国境内的消费者提供商品或服务，简而言之，其服务对象必须限定为中国公民。 一个可能的 差异点 在于，PIPL在执行过程中明确指出了可能 会援引其他法律或行政法规的情况 ，这一特点使得PIPL的适用范围相较于GDPR更为广泛。但在处理数据的过程中，企业也需要更加全面地考虑各种可能的法律限制和约束。 2、个人信息定义 PIPL规定了个人信息是指由电子类设备或是其他方式记录，与已识别或可识别的自然人相关的信息，并指出不包括匿名化处理后的数据。 GDPR则在这一基础上进一步 细化了可识别自然人的定义 ，明确了无论是直接还是间接方式能够识别出的个体均属于此范畴，并列举了诸如姓名、身份证号码、居住地址，以及自然人的物理、生理等特征作为具体示例，以更直观地说明其定义。 图3模糊匿名化后的数据 3、敏感数据 在 敏感数据处理 方面，PIPL与GDPR也存在异同之处。比如，PIPL与CCPA类似，直接使用了“敏感数据”（Sensitive Data）这一术语，而GDPR则称之为“特殊类别信息”（Special Category Information）。这一称呼上的差异也反映了两者在敏感数据定义上的不同。 GDPR通过明确列出一种具体的信息清单，将符合该清单的数据归类为“特殊类别信息”，并为其提供专门的保护。这种方式使得GDPR在敏感数据的识别上更加 直接和具体。 相比之下，PIPL在敏感数据的定义上采取了 更为宽泛 的视角。它不仅包括了生物计量学特征、低于14岁公民个人信息等明确列出的内容，还支持对清单外数据内容提出争议的权利。这意味着，在PIPL的框架下，敏感数据的范围可能更加广泛。 未完待续，我们将分享更多数据隐私和匿名化的相关内容。

在 ADTF(Automotive Data and Time-Triggered Framework) 中， 过滤器（Filter） 扮演着数据处理的核心角色。过滤器是处理数据流的基本单元，它们接收、处理并发送数据。接下来，将 分享ADTF中创建和使用过滤器 ，包括设置输入输出针脚（Pins）、配置触发器（Triggers）以及处理数据样本（Samples）。 一、过滤器基础 过滤器是ADTF中用于数据处理和转换的小型处理单元，可以通过特定的接口接收和发送数据，如图1所示。 图1 Filter 过滤器核心能力如下： 1.数据接收： 通过输入引脚（In Pins）和对应的样本读取器（Sample Reader）接收数据。 2.数据发送： 通过输出引脚（Out Pins）和对应的样本写入器（Sample Writer）发送数据。 3.数据处理： 在运行器（Runners）（也称为触发上下文、可运行对象或可调用对象）的上下文中处理数据。 在进行过滤器的设计，考虑将数据传输与运行时行为分离。因此引入了触发机制，包括数据触发和时间触发。 1.数据触发： 功能在传入数据事件上运行。 2.时间触发： 功能在传入时间事件上运行。 通过这种设计支持构建一个强大且可适应的系统，使用过滤器可以轻松集成和定制。比如在数采系统中，通过不同的时间触发设计，以适应不同频率的传感器数据采集。或者利用cDataTriggerHint类来确保当车辆传感器数据（如摄像头图像）到达时，触发相应的数据处理算法运行，从而实现实时数据流的高效响应和处理。 二、创建过滤器 通常，在ADTF中滤波器会被打包成一个插件。通过ADTF 的插件机制使其能够在 ADTF 的运行时加载。在滤波器中，可以通过可以创建输出引脚或输入引脚，这里我们以输出引脚为例。引脚传输出去的数据，在ADTF中称为样本（Sample）。其代码案例如下，创建一个滤波器并添加一个输出引脚及样本数据。 三、 样本（Sample） 样本（Sample）是 ADTF中用于数据传输的基本单元。它们不仅包含数据本身，还包含与数据流相关的元信息，如图2所示。 图2 Sample 一般来说，样本通过 streaming::ISample 接口进行操作。其样本组成包含以下内容： 1.时间戳（Timestamp）： 为每个数据提供时间关联。 2.样本缓冲区（SampleBuffer）： 通常是一个内存块的引用，包含用户数据。 3.样本信息（Sample Info）（可选）： 提供额外的元数据。 4.子流 ID（Substream Id）（可选）： 用于标识特定的数据子流。 比如我们可以轻易实现将内存缓冲区内容复制到样本中，实现数据传输。 四、过滤器应用 ADTF过滤器的应用场景广泛，它们不仅能够处理和转换数据，还能够根据特定的需求定制功能。在图3所示，在人脸识别算法工程中，过滤器被用于处理从摄像头捕获的视频流。 首先，一个过滤器用于解码视频流，将原始数据转换为图像帧。接下来，通过一个复杂的过滤器（OpenCV Face Detector Filter）实现人脸识别算法，识别并跟踪视频中的人脸。通过这些过滤器的协同工作，系统能够实时处理视频数据，并提供有用的输出，如安全监控或人流量统计。 图3 人脸识别算法工程 此外，过滤器可用于多种用途，包括但不限于： 1.解码来自CAN、MOST或FlexRay等设备的流源数据。 2.预处理传入数据，为算法实现做准备。 3.通过复杂的算法实现重新计算和合并传入数据。 4.实现循环控制器。 5.接收传入数据并进行数据可视化。 五、总结 ADTF过滤器提供了一个灵活且强大的平台，用于构建和集成数据处理流程。无论是在汽车、工业自动化等领域，过滤器都能够提供定制化的解决方案，满足特定的技术需求。通过合理设计和配置过滤器，可以大大提高数据处理的效率和可靠性。

应用背景 块或分段内存平均模式常用于在不同应用当中，移除信号中不相干的噪声。不管是哪家的数字化仪制造商，几乎所有基于FPGA实现的块平均模式都会受到块或者段内存大小的限。该限制一般取决于FPGA的容量，最大样品量通常在32k到500k之间。 本白皮书将展示如何使用德思特TS-M4i系列数字化仪的高速PCIe流模式来在软件中实现块平均处理，从而突破FPGA的限制。 我们用了TS-M4i.2230（1通道，5 GS/s，8位垂直分辨率，1.5 GHz带宽）作为例子，对比硬件和软件进行块平均处理的效果。 什么是块平均？ 块平均模式可以用来移除随机噪声成分，提高重复信号的保真度。该模式允许对多次单段采集进行处理、累积和平均。 这个过程减少了随机噪声，提高了重复信号的可见性，平均后的信号具有增强的测量分辨率和更高的信噪比（SNR） 。 块平均模式可用于改善雷达测试、天文学、质谱学、医学成像、超声波测试、光纤测试和激光测距等各种不同应用中的测量。 下面截图显示了一个较低电平的信号（大约2mV），完全被随机噪声覆盖的情形，以及使用不同平均因子获得的信号质量改进。虽然在原始单次采集中源信号基本无法看到，但10x平均时，能显示出实际上有5个信号峰。执行1000x的块平均可以进一步改善信号质量，揭示出带有二次最大值和最小值峰的完整信号形状。 通过块平均改善噪声问题，该示例使用了一个500MS/s采样率（每个采样点2ns）和14位分辨率的数字化仪制作 系统配置 为了兼顾更多老旧设备的性能状况，测试系统选用了一台德思特公司内的旧办公电脑，大致配置如下： ● 主板：技嘉GA-H77-D3H ● CPU：Intel i7-3770，4核3.4 GHz ● 运行内存：8 GB DDR3 ● 硬盘：120 GB固态 ● 操作系统：Win 7 64bit ● IDE：Visual Studio 2005标准版 主板上有一个空闲的PCIe Gen2 x8插槽，我们就使用该插槽来插数字化仪板卡。此时，德思特的TS-M4i板卡的流式传输可以达到满速，约3.4 GB/s（不考虑数据处理的情况下）。 软件实现 测试软件使用纯C++编写，并基于德思特流式传输示例。数字化仪板卡通过外部触发采集，板卡会自动在每个触发事件后获取一段数据。数据会先存储在板载内存中，然后通过分散聚集式式DMA直接传输到PC的运行内存，并在运行内存中进行累积，进而执行块平均操作。我们针对不同的配置方式和优化策略进行了测试，来看看分别能达到什么样的性能水平。 摘录出来的一小段源代码显示了多线程版本的主求和循环，这正是软件处理的关键部分，也是决定速度的部分。 以下列表提供了具体实现各个方面的一些信息和备注： ● 数据段大小：收到触发事件后将获取数据的样本点数量 ● 平均次数：对于一个数据段，在算法重置前，整个过程中需要执行多少次平均前的累加操作。 ● 通知大小：硬件生成中断所需的数据量。该参数决定了整个平均循环的速度。如果通知大小大于数据段大小，则会在一次中断中传输多个数据段的内容，这将减少线程通信和中断处理的额外开销。 ● 缓冲区大小：DMA传输的目标缓冲区整体大小。在我们的实验中，这个缓冲区固定等于通知大小的16倍。 ● 触发速率：作为外部触发的信号发生器的信号重复频率。在结果表格中，我们给出的是在不填满（溢出）缓冲区的情况下可以达到的最大触发速率。 ● 线程数：为了加快求和过程，我们对该任务进行并行化优化，将其分割成多个不同的软件线程。如果线程为1，则表示求和过程不使用额外线程，而是直接在主循环中直接执行。 ● CPU负载：由于平均过程是用软件完成的，具体来说就是CPU进行了所有的工作。幸好现代CPU往往包含多个内核，我们实际上可以轻松地在它们之间共享工作任务。 ● SSE/SSE2指令：乍一看，这些命令似乎非常适合并行化求和过程，并似乎可以在不需要任何线程编程的情况下加快软件的速度。但不幸的是，SSE命令集都是基于相同类型的数据的，而由于获取的数据是8bit宽度，而平均缓冲区是32位宽，因此在本例中无法利用该指令集进行加速。 效果和比较 所有的测量都是使用一个采样率高达5GS/s、垂直分辨率为8位，并且带有外部触发通道的数字化仪进行的。我们在表格中还列出了不同的程序配置以对比效果差异。 通过普通（性能偏低的）PC在时域上进行块平均的性能对比 新方法：使用CUDA进行平均运算 2018年11月， 德思特推出了一些使用SCAPP（通过CUDA访问数据和并行处理）选项进行块平均的示例，适用于非常高速的数据处理。 其基本概念与前文所述相同，即数据由数字化仪采集并通过PCIe总线连续传输。不同之处在于，平均值的计算操作不是由CPU完成，而是在GPU中完成。GPU解决方案的一个主要优点在于， GPU本身就是为并行计算而设计，这使GPU成为各种类型的块平均运算的理想选择 。 在实现上，SCAPP允许用户直接将数据传送到GPU，这使用了RDMA（远程直接内存存取）技术，然后可以在GPU上执行高速时域和频域信号的平均，并突破通常在CPU和FPGA中出现的数据长度或算力限制。 比如， TS-M4i.2220数字化仪可以以2.5 GS/s的速度连续采样信号，我们可以做到在不丢失样品点的情况下，进行长达数秒的平均运算 。类似地，我们还有14位垂直分辨率的TS-M4i.4451数字化仪可以以450 MS/s的速度同时对四个通道的信号进行同一功能的采样。数字化仪板卡还提供了灵活的触发、捕获和读出模式设置，从而使它们能够在触发速率极高的情况采回原始信号，进而做平均处理。相比之下，FPGA方案需要最高性能级别的FPGA来同时满足数据拉取和平均运算，而GPU方案则可以轻松跑满数字化仪的全速，即使是使用入门级GPU也不会成为瓶颈。 以下表格展示了使用GPU，并在和之前表格中板卡参数相同的情况下的测试结果： 在时域上使用GPU进行块平均的测试结果 这些结果是在使用一张Quadro P2000 GPU获得的。如表所示，数据段大小和通知大小并未限制性能，我们遇到唯一限制的瓶颈是GPU内存（显存）。 使用GPU进行频域平均 在需要进行频域平均的情况下，也建议使用GPU，因为GPU允许比FPGA方案更大的平均块大小。频域的平均运算过程包含两个步骤，一个是针对块数据的FFT运算，另一个是对FFT结果求和（然后取平均）。其中FFT计算在处理能力方面要求非常高，因此对于频率域平均而言，除了FPGA外，GPU是唯一的可行方案，CPU并不适合在高速下进行FFT转换。 以下表格显示了使用最大采样率为500 MS/s的TS-M4i.4451数字化仪（4通道，14位垂直分辨率）的一些测试结果。最终表明该方案能高效地实现无间隙数据采集，将每个块中的原始数据转换为对应电压值，然后再转换至频率域做平均。 使用GPU进行频率域块平均的测试结果 结论 如上述结果所示，只要重复率不算太高，得益于PCIe总线的高速数据传输率，使用基于CPU的软件在进行块平均时，可以实现比FPGA更大的总数据段大小，从而平均更长时间的样本；而使用GPU时，更是可以达到PCIe总线传输所限制的上限速度。对于需要处理更高重复触发率的情况，会对总线传输速度提出更高的要求，此时基于FPGA硬件的块平均仍将是最佳选择。 上述测试程序也可以提供给您，以便您自己进行重复测试，或者作为实现其他软件程序的基础。其中GPU示例是SCAPP软件选项的一部分，在选购后，德思特的客户可按照NDA协议使用。 总的来说，通知大小设为1 MByte时，可获得最佳性能。具体执行的平均次数对测试性能并没有明显的影响。因为复制结果段和清除结果缓冲所需的时间相对于样本求和运算而言微不足道。 由于在同时采集多个通道时，整个的数据处理和求和过程并没有本质区别，因此只需等价成一个把所有数据都合并到一起的新通道即可（等效采样率= 每通道采样率 × 通道数）。以下设置对应的最大触发速率完全相同： ● 1通道5 GS/s @ 数据段大小S1 ● 2通道2.5 GS/s @ 数据段大小S1/2 ● 4通道1.25 GS/s @ 数据段大小S1/4 将采样速度降低到2.5 GS/s时，可以在理论上使软件针对1个通道执行平均运算的速度最大化。对于1 M样本点的数据段大小，外加死区长度为160个样本点时，理论上的最大触发速率为：(2.5 GS/s) / (1 MS+ 160 S) = 2.38 kHz。 注意，这确实会明显低于单纯采集时的最大触发速率：2.9 kHz @ 5 GS/s。 关于德思特 ：德思特是虹科的一家姐妹公司，基于超过10年的业务沉淀，德思特公司专注提供电子测试/测量解决方案。主要业务范围涵盖：汽车电子仿真及测试、射频微波及无线通信测试、无线频谱监测与规划、无线通信（包括智能网联汽车无线通信、轨道交通、卫星通信、室内无线通信）、半导体测试、PNT解决方案、大物理和光电测试等。更多资讯请关注tesight.com或公众号德思特测试测量