标签: 网络性能

IP 语音（VoIP）网络依赖于 SIP（会话启动协议）和 RTP（实时传输协议）等实时通信协议，因此必须保持高可用性和低延迟。一旦出现问题，就必须迅速查明并解决，以防止服务中断。 一个常见的问题是不兼容问题，目前有 100 多份与 SIP 相关的征求意见稿（RFC），其中有大量 “应该”（SHOULD）而非 “必须”（MUST）的声明。这通常会导致用户无法拨出或拨入电话。 本文将介绍一种使用 IOTA 的故障排除方法，IOTA 是一种实时流量捕获和分析工具，可简化复杂 VoIP 网络问题的根本原因识别。文章将重点介绍 IOTA 如何帮助高效地排除网络故障、识别异常并解决传统日志分析和基本流量捕获可能会遗漏的问题。 一、问题描述 VoIP 网络容易受到各种问题的影响，从而影响服务质量。典型的用户投诉可能涉及无法向外部号码拨出电话，这可能会迅速升级为高优先级支持问题。在这种情况下，必须高效地排除故障，尽快恢复服务。VoIP 管理员通常首先查看日志或通过 SPAN 端口执行基本的数据包捕获，然后进行手动分析，但这些方法不一定总能提供迅速解决问题所需的清晰度。 用户视角 从用户的角度来看，问题很明显：用户无法拨出外部号码。这让用户感到疑惑，并可能导致创建高优先级的支持票单。支持团队必须快速有效地做出响应，以避免进一步的中断。 日志视角 图 1：有 403 禁止但无详细 TCP 信息的日志视图 首次发现问题时，VoIP 管理员通常会首先查看受影响客户端的日志。在本例中，日志显示了从 PBX 到软电话的 SIP 403 “禁止 ”响应代码。此外，日志还暗示出现了身份验证错误，这促使管理员调查与 SIP 注册和身份验证相关的潜在原因。 在进一步调查后，管理员可能会发现注册数据似乎是正确的。但是，即使在验证注册过程正常运行后，403 响应仍然存在，这就促使他们进行更深入的调查。此时，管理员通常会捕获受影响呼叫期间的网络流量，以获得更多信息。 网络视角 网络级故障排除涉及捕获网络中相关点的流量，以观察 SIP 信令和 RTP 传输。此时，问题往往会变得更加复杂。VoIP 网络由多个相互连接的组件组成，包括 PBX、软电话、SBC（会话边界控制器）和 ITSP（互联网电话服务提供商）。 下一个挑战来自于 SIP 信令中的数据流与 RTP 流中的语音数据可能不同。为了有效捕获相关流量，管理员需要确保在正确的网络点进行捕获，包括软电话和 PBX、PBX 和 SBC 以及 SBC 和 ITSP 之间。 使用网络交换机 SPAN 端口的传统数据包捕获方法可能会成为瓶颈，影响捕获数据的准确性。具有在线捕获功能的 TAP 或捕获设备可以消除这一问题。不过，即使使用了正确的捕获工具，确定 SIP 403 消息的根本原因也可能既费时又复杂。 二、故障排除焦点：IOTA 如何改进 VoIP 根源分析 使用 IOTA 捕获流量 IOTA 解决了网络管理员在排除 VoIP 问题时面临的许多难题。通过提供实时流量捕获和分析，IOTA 允许管理员在受影响的呼叫期间高效地收集数据。它可在线部署在多个网段上，包括：软电话（softphone）和 PBX 之间；PBX 和 SBC 之间；SBC 和 ITSP 之间。 图2：用于排除故障的 IOTA 位置。 IOTA 能够捕获所有呼叫段（内部、DMZ 和外部）的流量，必要时甚至可以捕获 SPAN 端口的流量，从而确保全面覆盖整个通信流，帮助管理员找出问题所在。 分析 SIP 403 错误 捕获流量后，IOTA 的 VoIP 面板会提供 SIP 响应代码的详细概览。在 SIP 403 错误的情况下，管理员可以立即发现问题发生时这些响应代码频率的增加。通过将这些数据与之前呼出电话正常运行时的基线数据进行比较，管理员可以观察到信令模式中的任何显著差异，尤其是在呼叫失败前后。 图3：VoIP 面板 IOTA 的用户友好界面允许使用简单的下拉列表，根据发件人或收件人头中的 SIP URI 以及 VoIP/SIP Call-ID 或用户代理进行过滤。SIP 注册具有相同的发件人和收件人 URI，因此可以通过这种模式进行过滤。在我们的示例中，我们发现 SBC 在注册请求中发送的 VOIP_FROM_URI 没有后缀“;user=phone”，而在邀请请求中发送的 VOIP_FROM_URI 有后缀“;user=phone”，这在呼出呼叫中使用，因此我们可以在筛选器中区分它们。 图 4：通过 VOIP_FROM_URI 过滤器根据发件人中的 SIP URI 进行过滤。 之后，我们缩小了受影响电话的范围，从而更容易关注与 403 响应相关的具体问题。 图 5：按 VoIP 呼叫 ID 过滤。 深度数据包检测和 TCP 分析 对 VoIP 问题进行故障诊断的一个重要方面是检查捕获数据包的详细信息。在本例中，如果管理员查看 “概览 ”仪表板中的流量列表，就能发现 SIP 注册和 INVITE 请求使用 TCP 作为传输协议。这在 “协议栈 ”列中可见。 图 6：概览仪表板上有受影响调用的流量列表。 TCP 分析仪表板有助于更深入地检查 TCP 流量。乍一看，一切似乎都运行正常，因为所有 TCP 套接字都完成了 3 次握手，iRTT 也没有问题。 图 7：TCP 分析仪表板上的注册请求 TCP 流量。 图 8：TCP 分析仪表板上受影响通话的 TCP 流量。 随后，我们比较了来自 SIP 注册和 SIP 邀请的 TCP 流量。如图 7 和图 8 所示，IOTA 发现注册和呼叫设置请求（邀请）使用了不同的 TCP 源端口。进一步调查后发现，ITSP 拒绝未重复使用 TCP 会话的呼叫，这符合其特定的接口要求。这一发现对于诊断为什么会返回 403 响应至关重要。 三、利用可视化数据简化故障排除 传统的故障排除方法通常要求管理员筛选大量日志数据，寻找线索和不一致之处。IOTA 通过在其仪表板上提供可视化数据简化了这一过程，使管理员能够快速查看问题发生的位置以及需要进一步调查的内容。 例如，通过使用 IOTA 的 SIP 响应代码分析，管理员可以看到特定时间的 403 响应峰值，从而更容易找出根本原因。TCP 分析仪表板可帮助确定套接字的具体细节，如握手状态、iRTT 或源端口和目标端口。这种可视化方法能让用户更快地做出决策，并最大限度地减少故障排除所花费的时间。 四、使用 IOTA 进行 VoIP 故障排除的主要优势 提高采集的准确性 ：在网络的多个点高精度地采集数据有助于收集所有所需的数据，并确保不会忽略任何关键细节。在线和 SPAN 选项可在多种情况下提供帮助。如果在没有知识工作者的远程站点捕获流量，只需简单的硬件 “点击 ”即可启动，而无需任何知识。 更快、更高效的分析 ：IOTA 的实时和详细分析仪表板使管理员和分析人员能够快速发现问题，减少停机时间和服务中断。通过深度包检测和数据关联（如本例中的 SIP 和 TCP 流），IOTA 可帮助找出 SIP 403 响应等问题的根本原因，如错误配置的 TCP 流处理或身份验证不匹配。 基线分析 ：通过捕获流量模式使用 IOTA 进行基线分析，管理员和分析师可以将失败的流量模式与 “已知良好 ”的情况进行比较，从而发现问题。 结论 对 VoIP 网络问题进行故障排除是一项复杂而又耗时的任务，尤其是当用户因 SIP 403 错误而无法拨出电话时。通过将 IOTA 集成到故障排除流程中，网络管理员可以显著提高快速、准确地找出问题根源的能力。IOTA 能够捕获实时流量、分析 SIP 响应代码并检查 TCP 流量，为诊断 VoIP 问题提供了一种全面而有效的方法。最终，IOTA 可帮助简化故障诊断流程，减少停机时间，并确保 VoIP 服务保持正常运行，最大限度地减少中断。

网络流量中的微突发问题常常难以察觉，但它们可能对网络性能产生显著影响。这篇文章深入探讨了如何利用IOTA来捕捉和分析微突发，帮助您快速有效地解决网络中的突发流量问题。 什么是微突发（Microburst）流量？ 微突发是指接口在极短时间（毫秒级别）内收到大量突发流量，以至于瞬时速率达到平均速率的数十倍、数百倍，甚至超过接口带宽的现象。网络流量通常使用链路的平均利用率来衡量，即5分钟的输入或输出率，单位为Mbps或Gbps。5分钟平均值，甚至1秒钟平均值通常都很平滑，显示了网络的稳定状态。如果以更细的粒度（如每毫秒）查看网络中的实际流量，则会发现突发流量要大得多。这些突发非常细微，以至于标准监控工具经常会忽略它们。微突发就是网络流量中的这些短时间峰值。 问题描述 网络中的短期过载（即所谓的 Microburst）会影响应用程序的服务质量。传统方法（如交换机和路由器上的接口统计数据以及SNMP数据）很难或根本无法检测到这种情况。这是因为这些方法通常只能评估较长的时间间隔。因此，微突发分析给IT经理的故障排除工作带来了真正的挑战。 入门 下面的示例逐步概述了如何使用IOTA进行微突发分析。 第一步，我们需要配置物理接口。为此，我们导航到左侧菜单树中的捕获菜单，然后导航到接口配置部分。在所示配置中，接口配置为10/100/1000 Mbit/s自动协商的内联模式，这意味着物理接口可以直接从内联链路看到并捕获要分析的流量。如果要将IOTA设置为带外捕获，以接收来自TAP或SPAN端口的流量，则必须取消勾选内联模式框，并单击保存按钮。 图1 物理接口的配置。在本例中，10/100/1000 Mbit/s自动协商为内联模式。 IOTA的放置 为进行微突发错误模式分析，应通过IOTA的集成端口或使用TAP内联部署IOTA。 为了获得真实的场景，IOTA应尽可能靠近发生错误的地点。但是，如果大量客户出现瓶颈，首先必须确定他们使用哪些组件和接口进行通信，以确定适当的点。这通常是向提供商的广域网过渡。 图2 IOTA的位置，用于数据包平均和随后的微突发分析。 开始捕获 放置好IOTA并准备好物理接口后，我们连接到适当的电缆，然后导航到捕获控制部分并单击屏幕底部的开始捕获按钮，开始捕获过程。 图3 使用“捕获控制”部分的“开始捕获”按钮开始捕获。 微突发分析 当用户报告性能问题时，我们首先会询问发生的时间。这通常只是一个非常粗略的时间：例如2023年5月20日，18:50至19:00。在后续工作中，我们首先将时间间隔限制在这个范围内。为此，我们使用时间范围的相对或绝对规格，或“向下钻取”。然后，我们使用导航菜单切换到Microburst仪表板。 图4 使用屏幕右上角的导航菜单切换到Microburst仪表板。 在该仪表板上，可以对负载范围进行下钻，以缩小时间范围。 如图5所示，微突发仪表板根据很短的时间间隔显示微突发。IOTA会自动选择适当的接口，并在右下方窗格中显示以Mb/s为单位的最大入站和出站微突发，以及上方时间间隔内传输的字节数和数据包数。在图表中，传出流量显示为红色，传入流量显示为蓝色。 向下钻取到相应的时间范围后，我们可以看到以200毫秒为时间间隔的微突发发显示。我们检测到1 Gbit/s连接的利用率为998 Mbit/s，相当于满负荷。这一瓶颈导致了性能问题。 图5 以200毫秒的时间间隔钻取后的Microburst仪表板。 不过，我们仍然需要分析是哪个网络流“拖慢”了应用程序。为此，我们需要通过导航菜单切换到应用程序概览仪表板。 图6 应用程序概览仪表板，其中指出了造成被检查微突发的根本原因。 在应用程序概览仪表板上，我们可以看到IOTA识别的应用程序。IOTA使用深度数据包检测来识别使用过的应用程序。如图6所示，Google共享服务的流量导致了微突发。因此，我们回到问题开始的客户端，查看此刻使用了哪些Google服务。我们看到，此时正在运行备份到Google Drive的服务，占用了整个链接容量。如果应用程序概览仪表板无法识别应用程序，IOTA可以选择在Microburst仪表板中导出相应的时间段。我们可以回到该仪表板，单击导航菜单左侧的下载按钮，这样就可以在需要时使用Wireshark等其他工具分析PCAP。 图7 从Microburst面板直接下载相应时间间隔的数据。 在Microburst面板的底部，我们还可以看到相应的PCAP文件，其中包含时间范围、持续时间和文件大小。我们可以复制这些文件名来下载我们需要的文件。 图8 微突发选定时间间隔内记录的PCAPNG文件列表。 在此基础上，我们导航到捕获文件页面，如图9所示。 图9 导航至“捕获的文件”页面。 在PCAPNG文件列表中，我们选择之前记下的文件名，然后点击下载按钮。 图10 选择和下载PCAPNG文件 IOTA的优势 由于测量时间间隔较短，IOTA可以检测活动网络组件上的普通接口工作负载无法捕获的临时瓶颈。此外，它还能通过应用识别对这些数据进行相应分析，或将其提供给进一步分析。因此，IOTA为我们分析瓶颈提供了更多可见性。

在企业网络和供应商环境中，通过 IP 协议传输语音面临着各种挑战。首先，对可用性的要求非常高。作为一种实时服务，用户也会立即发现服务质量方面的问题。丢包、抖动和延迟等网络质量参数会严重影响实时传输协议（RTP）的语音质量。 请注意，在 VoIP 环境中，不同的数据流是有区别的。信令是第一个数据流。信令是用于设置和清除下行数据流及其变化的通信。在当今的 VoIP 网络中，通常使用会话启动协议（SIP）来完成。第二个数据流是语音传输。因此，在发生错误时，必须能够记录这两个数据流并对其进行有效分析。 IOTA简介：IOTA 是一款功能强大的网络捕获和分析解决方案，适用于边缘和核心网络。IOTA 系列包括便携式 EDGE 型号、高速 CORE 型号和 IOTA CM 集中设备管理系统。IOTA 解决方案可为分支机构、中小企业和核心网络（如数据中心）提供快速高效的网络分析和故障排除功能。 开始 下面的示例逐步概述了如何使用IOTA 分析降低的 VoIP 质量。它涉及呼叫设置错误和语音质量错误。 第一步是配置物理接口。 为此，我们使用左侧菜单树导航到 “捕获 ”页面，然后导航到 “接口配置 ”部分。如下图所示，接口配置为 SPAN（带外），具有 10/100/1000 Mbit/s 自动协商功能，这意味着两个物理接口都可以接收来自 SPAN 端口或 TAP 的待分析流量。如果要将 IOTA 内联到数据流中，则必须勾选内联模式旁边的复选框并点击保存按钮。 图1 物理接口配置。本例中为 SPAN 模式下的 10/100/1000 Mbit/s 自动协商 准备好物理接口并定位好 IOTA 后，我们连接到相应的电缆，然后在捕获控制页面上单击页面底部的开始捕获按钮启动捕获过程。或者，我们也可以按下 IOTA 设备上的物理 “开始捕捉 ”按钮来启动捕捉过程。这将加快整个过程，未经培训或没有权限的人员也可以进行操作。 图2 使用 “Capture Control（捕捉控制）”子菜单中的 “Start Capture（开始捕捉）”按钮开始录制 故障排除仪表板 要排除网络电话的故障，我们首先要使用网络电话仪表板。 图3 导航至 VoIP 控制面板 会话过滤 在 VoIP 仪表板上，我们可以看到 VoIP 会话的列表。在这里，我们可以看到源 URI 和目标 URI、用户代理和会话持续时间。使用 VoIP 会话表的 “选择 ”列过滤特定会话，如图 4 中的示例，我们过滤了与 “sip:23@192.168.178.1;user=phone ”相关的会话。 对所需 VoIP 会话应用筛选器后，我们会在右侧边缘看到 VoIP 流程图，通过该图可以大致了解 VoIP 会话中涉及的端点。此外，还可将过滤器设置为上部区域的 VoIP 通话 ID。因此，仪表板下部区域的所有面板都会过滤为该呼叫。 图4 VoIP 仪表板，SIP 会话从号码 *29 转到号码 23 RTP 分析 再往下看，您可以看到与传输语音的实时传输协议相关的丢包和抖动等质量参数。高抖动会导致机器人声音，而丢包会导致对话无声。图 5 显示了网络电话会话中的高丢包率和高抖动率。我们还可以看到由此产生的抖动和丢包的方向。在示例中，这是由于所使用的软电话的 WiFi 连接不佳造成的。 图5 VoIP 仪表板中的 RTP 抖动和数据包丢失 该仪表板还可以查看所谓的平均意见分（MOS），即用户的主观通话质量（取决于通信方向）。图 6 举例说明了这一点。不过，这也取决于所使用的编解码器。常用的 G.711 编解码器的最大 MOS 约为 4.4。 图6 VoIP 面板中的计算 MOS 图 如图 7 所示，根据对 VoIP 呼叫 ID 的过滤，还可显示相应语音数据流（RTP 流）的信息。除了客户端和服务器 IP 和端口外，我们还可以看到呼叫持续时间。此外，还可以下载包含 RTP 流的 PCAPNG 文件。例如，我们可以在 Wireshark 中使用支持的编解码器监听语音数据，并听到语音传输中的任何错误。如果用户报告在通话过程中出现噪音，则可以快速、轻松地检查网络中的潜在错误。 图7 VoIP 面板中的 RTP 流列表 信令分析 除了语音质量差的评估外，信令中也可能存在错误，如呼叫设置或拆分。要对单个呼叫进行评估，我们需要在 VoIP 会话中选择所需的呼叫，如上所述。然后，我们可以在 SIP 响应类型部分看到对 SIP 请求的响应。如果有许多信息带有 4xx（客户端错误）、5xx（服务器端错误）或 6xx（全局错误），则应对这些信息进行更仔细的分析。 图8 SIP 响应类型图与各响应类型的编号 不过，建议特别注意 4xx，因为如果 SIP 使用了身份验证，注册和邀请的 407 和 401 消息是完全正常的。要查看确切的应答和通话过程中的时间，我们可以在 VoIP 面板中查看 SIP 流详情评估。在右侧窗格中，SIP 流程图显示了呼叫流程。在这种情况下，我们可以看到使用了身份验证，但收到的回复是 407，在这种情况下，4xx 回复是正常的，而不是错误。 图9 带有详细呼叫信令流程的 SIP 流程详情 如果在建立呼叫时出现性能问题，建议从上述 VoIP 会话表中下载 VoIP 呼叫的 PCAPNG。这样，对 SIP 请求的响应延迟过大就可能是性能问题的原因。 IOTA 的优势 VoIP 故障排除过程往往像大海捞针。IOTA 通过易于使用的过滤选项（如选择单个呼叫），简化了对根本原因的搜索。 可以根据 SIP 流程图检测信令错误，并下载为 PCAPNG 进行更深入的分析，例如查看单个报头。 RTP 抖动和损耗图形可以很好地概括语音质量。在 RTP 流中，IOTA 还提供下载带有 RTP 数据的 PCAPNG 的选项，以便在 Wireshark 的 RTP 播放器中收听语音数据。

控制器局域网（CAN）属于现场总线的范畴，是一种有效支持分布式控制系统的串行通信网络。它是由德国博世公司在20世纪80年代专门为汽车行业开发的一种串行通信总线。由于其通信速率高、工作可靠、调试方便、使用灵活和性价比高等优点，己经在汽车业、航空业、工业控制、安全防护等领域中得到了广泛应用，被公认为几种最有前途的总线之一，其协议也发展为重要的国际标准。 随着CAN总线在各个行业和领域的广泛应用，其通信性能也越来越受到人们的关注。目前，已有很多学者对CAN总线通信性能进行分析研究。文中在分析CAN总线通信控制协议的基础上，在MATLAB/Sinulink软件Stateflow仿真环境下，利用有限状态机理论对CAN总线通信系统进行了形式化建模。通过此仿真模型，分析了CAN总线通信系统中负载率的变化对网络吞吐量、平均信息时延、通信冲突率、网络利用率、网络效率以及负载完成率的影响。 1 CAN总线通信控制协议 根据ISO11898(1993)标准，CAN从结构上分为物理层和数据链路层，数据链路层又包括逻辑链路层控制子层（LLC）和介质访问控制子层（MAC）。在CAN总线系统中，节点间通过公共传输介质传输数据，因而数据链路层是总线的核心部分。CAN总线数据链路层的通信介质访问控制方式为事件触发，采用CSMA/CD。只要总线空闲，网络上任意节点均可在任意时刻主动地向网络上其他节点发送信息，而不分主从，节点在请求发送信息时，首先侦听总线状态，若总线空闲（或等待至总线空闲）则开始发送。当多个节点同时发送产生冲突时，采用非破坏性位仲裁机制，即借助ID标识符及逐位仲裁规则，低优先级节点主动停止发送，高优先级节点不受影响继续发送，从而避免总线冲突，避免信息和时间发生损失。在发送过程中，发送节点对发送信息进行校验，完成发送后释放总线。CAN总线系统通过使用这种非破坏性的逐位线仲裁技术来处理多个节点同时访问网络的冲突，最后优先级最高的节点能够立即发送数据，满足了高优先级节点实时性的相关需要。 2 CAN总线系统仿真模型 文章在Matlab/Simulink软件Stateflow仿真环境中建立了16节点的CAN总线通信系统仿真模型。节点1—16的结构是相同的，节点模块如图1所示。 图1 节点模块 节点模块包括发送、缓存、数据采集3个部分。因为本次仿真主要研究CAN总线的通信性能，所以建立节点模型时，只考虑了其通信活动所涉及的部分，没有加入节点计算控制活动部分和数据接收部分。数据采集用于采集Simulink中输入的数据，数据长度服从随机平均分布，在状态“有数据”中，数据被组装成CAN标准短帧。在实际系统中，数据可能是节点本身采集的现场检测数据，或是节点控制器输出的数据。“缓存”代表节点的缓冲器，这里假设容量为1。包括两个状态：“空”和“非空”。数据被采集并组装成CAN标准短帧后，触发由“空”到“非空”的转换，将节点信息放在等待发送的缓冲器中，发送完成后，返回“空”状态，等待下一次触发。“发送”代表节点发送部分，当缓冲器有数据等待传输时，触发由“停止”到“等待”的转换，进入等待状态；当总线仲裁允许本节点发送时，触发由“等待”到“传送”的转换，开始发送数据；当缓冲器的数据传送完成时，触发由“传送”到“停止”的转换，等待下一次发送。 图2 通信调度模块 通信调度模块，如图2所示。包括总线活动模块fieldbus和仲裁判断函数compete。fieldbus模块包括3个状态：“空闲”、“忙碌”、“帧间隔”。开始总线在“空闲”状态下，当有节点要发送信息时，用compete函数对待发节点进行仲裁，并触发由“空闲”到“忙碌”的转换；节点发送数据完成后，以“返回”事件触发由“忙碌”到“帧间隔”的转换；经过一个“帧间隔”后，回到“空闲”状态，等待下一次传输。compete函数对各节点的仲裁符合CAN仲裁机制，通过比较各待发节点的优先级，实现“线与”功能，将发送权给优先级最高的节点。 以上所述的仿真平台简洁直观地解释了CAN网络的控制机理，并能动态地仿真其通信活动。 3 网络性能 3.1 性能指标 我们先介绍总线网络相关性能指标的相关定义。 网络负载率：单位时间内发出访问网络的节点数（需要传送的报文数）与网络最大容量的比率。 吞吐量：单位时间内系统成功发送信息数量的均值。 平均信息时延：从信息发出传输请求到被成功地传输到目的节点所需要的平均时间。 通信冲突率：节点遭受通信冲突的概率。 网络利用率：单位时间内通道传送信息号的时间比率，即是通道处于忙碌状态的概率，它反映了通道被利用的情况。 网络效率：单位时间内通道成功传送的信息与通道发送信息的时间比率，即吞吐量与通道利用率两者间的比率。 负载完成率：所有节点运行完成后成功向总线上发送的报文帧的总个数与所有节点请求发送的报文帧的总个数的比率。 3.2 性能分析 仿真设定CAN总线传输速率为200kbit/s，总的运行时间为T=2s，并假设每一帧报文的数据长度为100bit，可以得知，CAN总线满负载时传输4000帧数据，表示为N=4000帧，即满负载时传输的数据帧的总长度为400kbit，表示为S=400kbit。通过设定各节点的发送周期，来调整负载率的大小。 CAN总线仿真模型中，输出参数含义分别为：u代表通道处于忙碌状态的总时间；thout代表所有节点发送的所有数据帧的总长度；fz代表所有节点产生的所有数据帧的总长度；b1—b16分别代表第1—16个节点每次运行完成后成功向总线上发送的数据帧的个数；p1—p16分别代表第1—16节点每次请求发送的数据帧的个数。 所以，吞吐量的计算公式为： 平均信息时延的计算公式为： 式中i表示节点编号（I=1～16）。 通信冲突率的计算公式为： 网络利用率的计算公式为： 网络效率的计算公式为： 负载完成率的计算公式为： 式中i表示节点编号（1~16）。 经过运行仿真模型，得到系统在负载分别为16%、33%、50%、81.5%、100%、125%、150%、175%、200%、230%、250%、280%、310%时的一系列仿真结果。 依据公式（1）—（6），我们分析了负载率从0.02到3.1的情况下，CAN总线通信系统中负载率的变化对网络吞吐量、平均信息时延、通信冲突率、网络利用率、网络效率以及负载完成率的影响。结果如图3—8中所示。 图3—8的变化趋势都是由CAN总线通信控制协议决定的，即总线空闲时，任一节点都有发起通信的权力，当多个节点同时发送产生冲突时，采用非破坏性位仲裁机制，低优先级节点停止发送，高优先级节点不受影响继续发送，从而可以避免总线冲突。 图3中，由于当负载率较低时，低优先级的信息可以竞争到总线权得以发送，随着负载率的增加，网络利用率提高，所以，吞吐量也随之增加，当负载率增加到一定程度时，只有高优先级的信息得以发送，此时吞吐量趋于饱和。 图3 吞吐量与负载率的关系 图4中，由于随着负载率的增加，信道主要用来发送高优先级的信息，而低优先级的信息却被长时间延迟甚至造成数据丢失，所以平均信息时延随着负载率的增加几乎呈线性增加。 图4 平均信息时延与负载率的关系 图5中，由于随着负载率增加，吞吐量增加，即单位时间内需要处理的信息量增加，信息发生冲突的机会也增加。而且随着负载率的增加，当吞吐量增加到趋于饱和后，信息发生冲突的机会也增加的较为缓和，即通信吞吐率增加的较为缓和。 图5 通信冲突率与负载率的关系 图6中，由于随着负载率增加，吞吐量随之增加，则单位时间内需要处理的信息量增加，从而使得通道的利用率增加。同时，通道由“忙碌”到“空闲”状态所用的帧间隔时间也增加，使得通道不可能连续不断地传输信号，这样随着吞吐量增加并趋于饱和时，网络利用率也随之增加并趋于1，但不会达到1。 图6 网络利用率与负载率的关系 图7中，由于随着负载率的而增加，吞吐量增加，而通道处于“忙碌”状态的总时间也在增加，并且在吞吐量达到饱和时，通道处于“忙碌”状态的时间也趋于稳定，所以，单位时间内通道成功传送的信息与通道发送信息的时间比率几乎不随着负载率变化而变化，基本在一个恒值附近微小变化。 图7 网络效率与负载率的关系 图8中，由于在负载率较低时，各优先级的信息都可以竞争到总线权得以发送，所有节点成功向总线上发送的数据帧的个数与请求发送的数据帧的个数相等或相差很小，但是随着负载率的增加，低优先级信息得不到发送，只有高优先级信息才得以发送，导致所有节点成功向总线上发送的数据帧的个数远小于请求发送的数据帧的个数。所以，负载完成率随着负载率的增加而减小，并且在负载较小时，负载完成率很大，几乎接近于1。 图8 负载完成率与负载率的关系 总之，以上分析结果验证了CAN总线通信控制协议的特点。 4 结束语 运用MATLAB软件中Stateflow工具箱来对CAN总线通信系统建模仿真切实可行，是现场总线协议分析与研究的又一途径。仿真模型能够完全描述协议的复杂逻辑关系，而且形象直观贴近实际系统，易于理解，也便于修改调试。