网硕互联帮助中心本文基于gPTP协议一致性测试规范（AVnu Alliance Automotive Certification Program Test Plan for Automotive Generalized Precision Time Protocol (gPTP) Version 0.2.0）详细解读后得出，该测试用例的作用为实现部件级器件的互通性，该测试用例的应用背景为车载gPTP背景下对802.1AS2011的协议要求，即不考虑多域的情况以及车载中没有Announce报文和对Pdelay进行储存等，（具体车载gPTP及gPTP可阅读博主TSN专栏的前两篇文章）。
该测试用例一共100条用例，本文为下半部分，介绍后50-100条测试用例。本文将从以下几个维度展开：TestCase Name || Test Condition/Test Items 覆盖什么测试需求或测试项 || Test Purpose
这条测试用例设计目的是什么？|| Test Methods(How) 如何测试，即测试方法是什么？|| Test Level是否适用于部件、系统、部件与系统；|| 备注 || Precondition测试配置 || Test Step测试步骤 || Expect Result 期望结果。 其中对于Expect Result 分为INFO（提供信息） NA （不支持） FALL （失败） PASS （通过） 几个维度展开。
原来的Excel表格中还会附带 Testing Environment（测试依赖，包括测试环境如何，对DUT或SUT有没有要求，设备要求 这一项并配有图解，不过在csdn上无法识别，还是有些美中不足。本文从测试的角度进一步理解gPTP，对于细节点有了更深刻的认识。以下的一些相关测试项格外值得关注：
syncinterval
pdelayinterval
neighborPropDelay
correctiononField
如果本文对你有帮助，请收藏+点赞，感谢，转载请注明出处。表格较宽，可用光标滑动。
| No. | TestCase Name | Test Condition/Test Items 覆盖什么测试需求或测试项 |
Test Purpose 这条测试用例设计目的是什么？ |
Test Methods(How) 如何测试，即测试方法是什么？ |
备注 | Test Level 是否适用于部件、系统、部件与系统； |
Precondition 测试配置 |
Test Step 测试步骤 |
Expect Result | |
| 50 | Test Auto.1AS.com.c.3.1 — Proper syncReceiptTimeout_PartB | DUT的syncReceiptTimeout值为Sync报文周期的3倍 | 测试DUT在不同Sync报文周期时的判定丢失Sync报文的时间差 | TS1开启Pdelay和AED-GM仿真，等待一段时间后，停止TS1的GM仿真，读取DUT的日志记录报告丢失Sync报文的时间，然后改变不同的Sync报文发送周期重复上述过程（LogMessageInterval不变） | Sync报文中的LogMessageInterval = -3 | 1.TS1开启Pdelay和AED-GM仿真（Sync和Follow_Up报文周期为250ms） 2.等待20秒后，停止TS1的GM仿真 3.读取DUT的日志记录报告丢失Sync报文的时间 4.增加报文周期每次125ms，直到日志报告Sync报文丢失或者报文周期超过625ms |
PASS：日志报告Sync报文丢失，且此时周期应该在337.5-562.5ms之间 | |||
| 51 | Test Auto.1AS.com.c.4.1 — ClockSlaveSync: updateSlaveTime occurs properly_PartA | Slave与GM的时间同步偏差应该小于80ns | 测试DUT作为Slave的同步偏差 | TS1开启Pdelay与AED-GM仿真,等待一段时间后，通过1PPS或者1PulsePer125us测量时间同步偏差 | If external access to a signal locked to gPTP time is available (1PPS, 1PulsePer125μs, etc). |
1.TS1开启Pdelay与AED-GM仿真（Sync和Follow_Up报文周期为250ms） 2.等待60秒后，通过1PPS或者1PulsePer125us测量瞬时时间同步偏差 3.重复步骤二300次 |
NA:DUT不能提供PPS信号 PASS:时间同步偏差小于80ns |
|||
| 52 | Test Auto.1AS.com.c.5.1 — ClockMasterSyncSend SM: Sync interval_PartA | DUT发送Sync报文的周期应该在合适的区间 | 测试AED-GM发出的Sync报文周期 | TS1开启Pdelay仿真，接收DUT发出的Sync报文并分析 | 排除周期前5%的数值（AS2011协议规定允许按0.5倍Sync周期发送Sync报文) | Grandmaster-capable | 1.TS1仿真Pdelay 2.监测DUT发送的100个Sync报文，排除前5的周期 3.计算剩余95%的平均值与标准差 |
NA:DUT没有GM能力 INFO:报告观察到的Sync周期数，以及最大值，最小值，平均值，标准差，中位数 PASS：Sync报文周期在112.5到187.5ms之间（0.9-1.5倍） |
||
| 53 | Test Auto.1AS.com.c.6.1 — Verification of Pdelay Turnaround Time_PartA | DUT收到Pdelay_Req的回复时间应该在10±5ms之内 | 测试DUT收到Pdelay_Req的回复时间 | TS1发送Pdelay_Req，随后在TS1收到Pdelay的回复报文，计算两者的时间差 | 传播延迟可以忽略不计 | 1.TS1仿真Pdelay（精度小于40ns），将发送Pdelay_Req的时间记为txTime 2.TS1收到Pdelay_Resp的时间记为rxTime 3.计算rxTime-txTime 4.重复上述过程100次，大约1秒1次 |
INFO：报告计算次数，以及时间差的最大值、最小值、平均数和中位数 PASS：时间差小于15ms |
|||
| 54 | Test Auto.1AS.com.c.6.2 — Flow Control Behavior_PartA | DUT不会发送也不会响应流控请求（Pause或PFC） | 验证DUT接收到Pause帧的行为 | TS1给DUT发送Pause帧，观测DUT的反应 | 1.TS1给DUT发送Pause帧 2.等待2秒后观测DUT的是否停止发送Pdelay_Req |
PASS：DUT持续发送Pdelay_Req报文，不受Pause帧影响 | ||||
| 55 | Test Auto.1AS.com.c.6.2 — Flow Control Behavior_PartB | DUT不会发送也不会响应流控请求（Pause或PFC） | 验证DUT不会发送Pause帧 | TS1向DUT发送满带宽数据流，观测DUT是否发送Pause帧 | gPTP设备应该禁用Pause帧，802.1BA中允许使用PFC，但是PCP不允许是2，3（非SR Classes），6 | 1.TS1向DUT发送目的MAC为非DUT的MAC的满带宽数据流 2.等待2秒，监测DUT的回复 3.向DUT发送为目的MAC为DUT的MAC的满带宽数据流，重复上述过程。 |
PASS:TS1没有监测到DUT回复的Pause帧 | |||
| 56 | Test Auto.1AS.com.c.6.2 — Flow Control Behavior_PartC | DUT不会发送也不会响应流控请求（Pause或PFC） | 验证DUT接收到PFC的行为 | TS1向DUT发送PFC暂停所有优先级的数据流，观测DUT的回复 | gPTP报文不带VLAN Tag,gPTP设备内部将gPTP报文当做优先级为6的数据流 | 1.TS1向DUT发送PFC暂停所有优先级的数据流 2.等待2秒后，观测DUT的Pdelay_Req是否被暂停 |
PASS:TS1持续收到Pdelay_Req，没有中断 | |||
| 57 | Test Auto.1AS.com.c.6.3 — Message format—no Q-tags_PartA | gPTP报文不含VLAN和优先级标签 | 验证DUT作为Slave发出的gPTP报文不含VLAN和优先级标签 | 在TS1仿真Pdelay过程，确认Pdelay_Req, Pdelay_Resp and Pdelay_Resp_Follow_Up报文是否含VLAN和优先级标签 | 1.在TS1仿真Pdelay过程 2.等待16秒，在TS1上确认Pdelay_Req, Pdelay_Resp and Pdelay_Resp_Follow_Up报文是否含VLAN和优先级标签（每种报文至少有3帧） |
PASS:收到的所有Pdelay_Req, Pdelay_Resp and Pdelay_Resp_Follow_Up报文不含VLAN和优先级标签 | ||||
| 58 | Test Auto.1AS.com.c.6.3 — Message format—no Q-tags_PartB | gPTP报文不含VLAN和优先级标签 | 验证DUT作为Master发出的gPTP报文不含VLAN和优先级标签 | TS1仿真Pdelay过程，等待一段时间监测DUT发出的Sync和Follow_Up报文 | Grandmaster-capable | 1.TS1仿真Pdelay过程 2.最多等待16秒，监测DUT发出的至少3次Sync和Follow_Up报文 |
NA:DUT没有GM的能力 PASS：接收到的所有Sync和Follow_Up报文不含Vlan标签和优先级标签 |
|||
| 59 | Test Auto.1AS.com.c.6.4 — Media Dependent: Message format—Ethernet fields and reserved fields_PartA | DUT发出的报文的目的MAC、源MAC、以太网类型和预留位应该正确 | 验证Pdelay_Req的目的MAC、源MAC、以太网类型和预留位的正确性 | TS1接收至少3次Pdelay_Req报文 | 1.在TS1监测至少3帧Pdelay_Req报文 | PASS:目的MAC为01:80:C2:00:00:0E，源MAC为出口的MAC的地址，EtherType为0x88f7，报头和报身的预留位均为0 | ||||
| 60 | Test Auto.1AS.com.c.6.4 — Media Dependent: Message format—Ethernet fields and reserved fields_PartB | DUT发出的报文的目的MAC、源MAC、以太网类型和预留位应该正确 | 验证Pdelay_Resp 和Pdelay_Resp_Follow_Up的目的MAC、源MAC、以太网类型和预留位的正确性 | TS1每秒发送Pdelay_Req，TS1接收至少3次Pdelay_Resp 和Pdelay_Resp_Follow_Up报文 | 1.TS1每秒发送Pdelay_Req 2.TS1接收至少3次Pdelay_Resp 和Pdelay_Resp_Follow_Up报文 |
PASS:目的MAC为01:80:C2:00:00:0E，源MAC为出口的MAC的地址，EtherType为0x88f7，报头和报身的预留位均为0 | ||||
| 61 | Test Auto.1AS.com.c.6.4 — Media Dependent: Message format—Ethernet fields and reserved fields_PartC | DUT发出的报文的目的MAC、源MAC、以太网类型和预留位应该正确 | 验证Sync和Follow_Up的目的MAC、源MAC、以太网类型和预留位的正确性 | TS1接收至少3次Sync和Follow_Up报文 | Grandmaster-capable | 1.TS1接收至少3次Sync和Follow_Up报文 | PASS:目的MAC为01:80:C2:00:00:0E，源MAC为出口的MAC的地址，EtherType为0x88f7，报头和报身的预留位均为0 | |||
| 62 | Test Auto.1AS.com.c.6.5 — Media Dependent: Message format—header_PartA | DUT发出的报文的报头应该正确 | 验证Pdelay_Req的报头的正确性 | TS1接收至少3次Pdelay_Req报文 |
|
1.在TS1监测至少3帧Pdelay_Req报文 | Warn:CF不为0 PASS:transportSpecific为0x1，messageType为0x2，versionPTP为0x2，messageLength为54（0x36），flags field 为0x0008，CF为0，sourcePortIdentity为DUT的端口ID，clockIdentity为OUI（Organizationally Unique Identifier） + 0xFFFE + 3-bytes，control为5，logMessageInterval为0 |
|||
| 63 | Test Auto.1AS.com.c.6.5 — Media Dependent: Message format—header_PartB | DUT发出的报文的报头应该正确 | 验证 Pdelay_Resp和 Pdelay_Resp_Follow_Up的报头的正确性 | TS1每秒发送Pdelay_Req，TS1接收至少3次Pdelay_Resp 和Pdelay_Resp_Follow_Up报文 | 在2020中，计算Pdelay有2中方式： instance-specific peer-to-peer delay mechanism(P2P)和Common Mean Link Delay Service (CMLDS) CMLDS会对链路不对称性进行补偿（delayAsymmetry) |
instance-specific peer-to-peer delay mechanism: majorSdoId为0x1 CMLDS：majorSdoId为0x2 |
1.TS1每秒发送Pdelay_Req 2.TS1接收至少3次Pdelay_Resp 和Pdelay_Resp_Follow_Up报文 |
PASS:transportSpecific为0x1，messageType为0x3 (Pdelay_Resp)或者0xA(Pdelay_Resp_Follow_Up)，versionPTP为0x2，messageLength为54（0x36），flags field 为0x0008，CF为0-65535(0xFFFF)，sourcePortIdentity为DUT的端口ID，clockIdentity为OUI（Organizationally Unique Identifier） + 0xFFFE + 3-bytes，control为5，logMessageInterval为7F(非周期） | ||
| 64 | Test Auto.1AS.com.c.6.5 — Media Dependent: Message format—header_PartC | DUT发出的报文的报头应该正确 | 验证Sync和Follow_Up的报头的正确性 | TS1接收至少3次Sync和Follow_Up报文 | 1.TS1仿真Pdelay过程 2.TS1接收至少3帧Sync和Follow_Up报文 |
NA:DUT没有AED-GM的能力 PASS：transportSpecific为0x1，messageType为0x0 (Sync)或者0x8(Follow_Up)，versionPTP为0x2，messageLength为44（0x2C,Sync）或者76（0x4C，Follow_Up），flags field 为0x0208（Sync）或者0x0008(Follow_Up)，CF为0，sourcePortIdentity为DUT的端口ID，clockIdentity为OUI（Organizationally Unique Identifier） + 0xFFFE + 3-bytes，control为0（Sync）或者2(Follow_Up)，logMessageInterval为-3 |
||||
| 65 | Test Auto.1AS.com.c.7.1— MDSyncReceiveSM:followUpReceiptTimeout verification-Part A | 验证DUT接收Sync和Follow_Up之间不同间隔的影响 | 测试DUT没有收到Follow_Up | TS1先发送Sync 和Follow_Up报文，8秒后，只发Sync不发Follow_Up | 1.TS1发送Sync和Follow_Up 2.TS1只发送Sync |
PASS：DUT显示Sync报文丢失 | ||||
| 66 | Test Auto.1AS.com.c.7.1— MDSyncReceiveSM:followUpReceiptTimeout verification-Part B | 验证DUT接收Sync和Follow_Up之间不同间隔的影响 | Sync和Follow_Up相隔100ms | TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔50ms 8秒后，TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔50ms 8秒后，TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔100ms |
1.TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔50ms 2.8秒后，TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔50ms 3.8秒后，TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔100ms |
PASS：无异常 | ||||
| 67 | Test Auto.1AS.com.c.7.1— MDSyncReceiveSM:followUpReceiptTimeout verification-Part C | 验证DUT接收Sync和Follow_Up之间不同间隔的影响 | Sync和Follow_Up相隔200ms | TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔50ms 8秒后，TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔50ms 8秒后，TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔200ms |
1.TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔50ms 2.8秒后，TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔50ms 3.8秒后，TS1发送Sync 和Follow_Up报文，Sync和Follow_Up相隔200ms |
PASS：200ms时显示Sync丢失 | ||||
| 68 | Test Auto.1AS.com.c.7.2— MDSyncReceiveSM: followUp sequenceID Check | 验证Sync和Follow_Up的序列ID是否一致 | 验证Sync和Follow_Up的序列ID是否一致 | 改变Follow_Up的sequenceld的值 | 1.TS1仿真Pdelay过程 2.8秒后时Follow_Up的序列ID-1 |
PASS：当序列ID不一致时，报错 | ||||
| 69 | Test Auto.1AS.com.c.8.1— MDSyncSendSM: sequenceId | 验证DUT是否正确实现MDSyncSendSM状态机对sequenceId的处理。 | sequenceId增加1，与Pdelay_Req传输无关 | 仿真Pdelay，观察序列ID | 符合要求的gPTP设备在MDSyncSend 状态机[1]中分配Sync和Follow_Up 消息的sequenceId编号。状态机使 用MD实体中名为syncSequenceId 的全局变量分配连续编号 |
DUT with a master port | 1在TS 1开始Pdelay仿真。
2观察来自DUT的第一个Sync和Follow_Up消息的sequenceId。 3观察来自DUT的24个连续Sync/Follow_Up消息对的sequenceId。 |
PASS：DUT的sequenceId编号依次递增1，并在Sync和Follow_Up消息对中匹配 | ||
| 70 | Test Auto.1AS.com.c.8.2 — MDSyncSendSM: correctionField of Follow_Up Messages | 验证修正域的值 | Follow_Up correctionField值 | 进行Pdelay仿真，观察修正域的值 | Grandmaster-capable without a sub-nanosecond accurate clock | 1在TS1开始Pdelay仿真。
2等待最多12秒，让TS1接收3个Follow_Up消息 3观察来自DUT的Follow_Up消息的correctionField。 |
PASS:观察到的Follow_Up correction on字段值为零 | |||
| 71 | Test Auto.1AS.com.c.9.1 — MDPdelayReqSM: DUT reports proper delay.-Part A | 不同长度的链路对等延迟的值偏差 | 短链路对对等延迟的影响 | 进行Pdelay仿真，计算链路延迟与设定之间差值 | 如果DUT支持报告Pdelay的可选能力，则应检查链路的长度 | 1使用具有精确已知延迟的短链路将TS1连接到DUT.TS1。 2在TS1开始Pdelay仿真。 3使用供应商指定的机制，记录短链路的报告延迟。重复三次并计算平均值。 4计算步骤A：3的平均值与已知链路延迟之间的差值的绝对值 |
PASS：通过使用短链路，计算的差值小于或等于100 ns | |||
| 72 | Test Auto.1AS.com.c.9.1 — MDPdelayReqSM: DUT reports proper delay.-Part B | 不同长度的链路对等延迟的值偏差 | 长链路对对等延迟的影响 | 进行Pdelay仿真，计算链路延迟与设定之间差值 | 如果DUT支持报告Pdelay的可选能力，则应检查链路的长度 | 1使用具有精确已知延迟的短链路将TS1连接到DUT.TS1。 2在TS1开始Pdelay仿真。 3使用供应商指定的机制，记录短链路的报告延迟。重复三次并计算平均值。 4计算步骤A：4的平均值与已知链路延迟之间的差值的绝对值 |
PASS：通过使用长链路，计算的差值小于或等于100 ns | |||
| 73 | Test Auto.1AS.com.c.9.2 — MDPdelayReq SM: sequenceId- Part A | 正确分配响应Pdelay及相关报文的序列号 | 随机开始连续加一的Pdelay_Req消息 | 观察连续的多个Pdelay_Req消息的sequenceId。 | 观察从DUT.TS1捕获的第一个Pdelay_Req消息的sequenceId。
观察来自DUT.TS1的接下来20个Pdelay_Req消息的sequenceId。 |
PASS：TS1观察到DUT的sequenceId号在Pdelay_Req消息中连续增加1 | ||||
| 74 | Test Auto.1AS.com.c.9.2 — MDPdelayReq SM: sequenceId- Part B | 正确分配响应Pdelay及相关报文的序列号 | 响应中的sequenceId错误 | 对从TS 1收到的所有Pdelay_Req消息提供有效响应。调整序列号观察错误日志报告。 | 1.对从TS 1收到的所有Pdelay_Req消息提供有效响应。 2.40s后将序列号调至1000， 3.40s后将序列号调至有效， 4.40s后将序列号调至1000， |
PASS:DUT在无效的序列ID时观察到延迟时报告超时 | ||||
| 75 | Test Auto.1AS.com.c.9.3 — MDPdelayReq SM: Lost and Late responses – Part A | 验证当DUT的Pdelay_Reqs响应丢失或延迟时，DUT是否正确响应。 | 丢失超过3个连续的Pdelay_Resp消息 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;但是，不要对接收到的下N个Pdelay_Req消息进行响应。 | gPTP设备必须记录对Pdelay_Req帧的连续丢失响应的计数,应被认为是任何延迟（包括缺席）或无效的Pdelay_Resp或Pdelay_Resp_Follow_Up | 1.对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应 2;但是，不要对接收到的下N个Pdelay_Req消息进行响应。 3.N不断+1 |
PASS:当N为3或4时，DUT观察到logaPdelay响应超时事件。 | |||
| 76 | Test Auto.1AS.com.c.9.3 — MDPdelayReq SM: Lost and Late responses – Part B | 验证当DUT的Pdelay_Reqs响应丢失或延迟时，DUT是否正确响应。 | 丢失超过3个连续的Pdelay_Resp_Follow_Up消息。 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;但是，不要对接收到的下N个Pdelay_Req消息进行响应。在每种情况下，发送有效的Pdelay_Resp但不发送Pdelay_Resp_Follow_Up | 1.对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应 2;但是，不要对接收到的下N个Pdelay_Req消息进行响应。 3.在每种情况下，发送有效的Pdelay_Resp但不发送Pdelay_Resp_Follow_Up 4.N不断+1 |
PASS:当N为3或4时，DUT观察到logaPdelay响应超时事件。 | ||||
| 77 | Test Auto.1AS.com.c.9.3 — MDPdelayReq SM: Lost and Late responses – Part C | 验证当DUT的Pdelay_Reqs响应丢失或延迟时，DUT是否正确响应。 | 连续丢失Pdelay_Resp和Pdelay_Resp_Follow_Up消息的混合 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;但是，不要对接收到的下N个Pdelay_Req消息进行响应。在每种情况下交替的不发送任何响应消息;以及发送有效的Pdelay_Resp但不发送Pdelay_Resp_Follow_Up。 | 1.对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应 2;但是，不要对接收到的下N个Pdelay_Req消息进行响应。 3.在每种情况下，交替的不发送任何响应消息;以及发送有效的Pdelay_Resp但不发送Pdelay_Resp_Follow_Up。 4.N不断+1 |
PASS:当N为3或4时，DUT观察到logaPdelay响应超时事件。 | ||||
| 78 | Test Auto.1AS.com.c.9.3 — MDPdelayReq SM: Lost and Late responses – Part D | 验证当DUT的Pdelay_Reqs响应丢失或延迟时，DUT是否正确响应。 | 延迟但未丢失的连续Pdelay_Resp消息：N个响应大于10 ms小于500 ms。 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;但是，不要对接收到的下N个Pdelay_Req消息进行响应。在每种情况下，在等待超过300 ms但小于500 ms后发送有效的Pdelay_Resp。在Pdelay_Resp消息的100 ms内发送有效的Pdelay_Resp_Follow_Up。N最初为一，因此实际上每隔一个Pdelay_Req消息将被正确响应。 | 该测试还在D部分中验证在PdelayReqInerval过期之前接收到的响应不被视为丢失 | 1.对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应 2;但是，不要对接收到的下N个Pdelay_Req消息进行响应。 3.在每种情况下，在等待超过300 ms但小于500 ms后发送有效的Pdelay_Resp。在Pdelay_Resp消息的100 ms内发送有效的Pdelay_Resp_Follow_Up。 4.N不断+1 |
PASS:最多4个召唤延迟（但未丢失）Pdelay_Resp消息不会导致：DUT记录Pdelay响应超时： | |||
| 79 | Test Auto.1AS.com.c.9.3 — MDPdelayReq SM: Lost and Late responses – Part E | 验证当DUT的Pdelay_Reqs响应丢失或延迟时，DUT是否正确响应。 | 延迟但未丢失的连续Pdelay_Resp消息：所有响应延迟 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;在每种情况下，在等待超过300 ms但小于500 ms后发送有效的Pdelay_Resp。在Pdelay_Resp消息的100 ms内发送有效的Pdelay_Resp_Follow_Up | 如果收到的响应晚于10ms，确实要求Pdelay周转时间为10ms或更少。尽管没有进一步的标准要求行为，如果超过这个周转时间，晚于10ms但小于PdelayReqInterval的Pdelay_Resp可能导致某些实现的问题。响应消息是否由实现提供。 | 1对从DUT.TS1收到的所有Pdelay_Req消息提供有效响应。 2等待10秒钟。 3对从DUT.TS1收到的所有Pdelay_Req消息提供延迟响应。在每种情况下，在等待超过300 ms但小于500 ms后发送有效的Pdelay_Resp。在Pdelay_Resp消息的100 ms内发送有效的Pdelay_Resp_Follow_Up。 |
INFO:通过是否有错误报告，来判断DUT是否容许多个连续的延迟响应 | |||
| 80 | Test Auto.1AS.com.c.9.4 — MDPdelayReq SM: Invalid responses – Part A |
验证当DUT的Pdelay_Reqs响应无效时，DUT是否正确响应。 | 由于无效的请求clockIdentity，丢失Pdelay_Resp消息 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;但是，不要对接收到的下N个Pdelay_Req消息进行响应。并进行以下更改：使Pdelay_Resp消息的requestingPortIdentity.clockIdentity不等于DUT的clockIdentity. 。N最初为一 | The Pdelay_Resp’s requesting clock is not the DUT. The Pdelay_Resp’s requesting port number is not DUT.TS1’s port number. The Pdelay_Resp’s sequenceId differs from that of the DUT’s Pdelay_Req. The Pdelay_Resp_Follow_Up’s sequenceId differs from that of the DUT’s Pdelay_Req. The Pdelay_Resp_Follow_Up’s sourcePortIdentity differs from that of the Pdelay_Resp. |
1对从DUT.TS1接收到的Pdelay_Req消息提供有效响应; 2对于发送的每个有效响应集，对接收到的接下来N个Pdelay_Req消息进行响应，并进行以下更改：使Pdelay_Resp消息的requestingPortIdentity.clockIdentity不等于DUT的clockIdentity. 3 N最初为一，因此实际上将正确响应每隔一个Pdelay_Req消息。 |
PASS:当N为3或4时，DUT观察到logaPdelay响应超时事件。 | |||
| 81 | Test Auto.1AS.com.c.9.4 — MDPdelayReq SM: Invalid responses – Part B |
验证当DUT的Pdelay_Reqs响应无效时，DUT是否正确响应。 | 由于无效的请求端口号，丢失Pdelay_Resp消息。 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;但是，不要对接收到的下N个Pdelay_Req消息进行响应。并进行以下更改：使Pdelay_Resp消息的requestingPortIdentity.portNumber不等于DUT的portNumber 。N最初为一 | 1对从DUT.TS1接收到的Pdelay_Req消息提供有效响应; 2对于发送的每个有效响应集，对接收到的接下来N个Pdelay_Req消息进行响应，并进行以下更改：：使Pdelay_Resp消息的requestingPortIdentity.portNumber不等于DUT的portNumber 。 3 N最初为一，因此实际上将正确响应每隔一个Pdelay_Req消息。 |
PASS:当N为3或4时，DUT观察到logaPdelay响应超时事件。 | ||||
| 82 | Test Auto.1AS.com.c.9.4 — MDPdelayReq SM: Invalid responses – Part C |
验证当DUT的Pdelay_Reqs响应无效时，DUT是否正确响应。 | 由于序列ID无效，丢失Pdelay_Resp消息 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;但是，不要对接收到的下N个Pdelay_Req消息进行响应。并进行以下更改：使Pdelay_Resp消息的sequenceId不等于Pdelay_Req的sequenceId。N最初为一 | 1对从DUT.TS1接收到的Pdelay_Req消息提供有效响应; 2对于发送的每个有效响应集，对接收到的接下来N个Pdelay_Req消息进行响应，并进行以下更改：使Pdelay_Resp消息的sequenceId不等于Pdelay_Req的sequenceId。 3 N最初为一，因此实际上将正确响应每隔一个Pdelay_Req消息。 |
PASS:当N为3或4时，DUT观察到logaPdelay响应超时事件。 | ||||
| 83 | Test Auto.1AS.com.c.9.4 — MDPdelayReq SM: Invalid responses – Part D |
验证当DUT的Pdelay_Reqs响应无效时，DUT是否正确响应。 | 由于序列ID无效，丢失Pdelay_Resp_Follow_Up消息。 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;但是，不要对接收到的下N个Pdelay_Req消息进行响应。并进行以下更改：使Pdelay_Resp_Follow_Up消息的sequenceId不等于Pdelay_Req的sequenceId。N最初为一 | 1对从DUT.TS1接收到的Pdelay_Req消息提供有效响应; 2对于发送的每个有效响应集，对接收到的接下来N个Pdelay_Req消息进行响应，并进行以下更改：使Pdelay_Resp_Follow_Up消息的sequenceId不等于Pdelay_Req的sequenceId。 3 N最初为一，因此实际上将正确响应每隔一个Pdelay_Req消息。 |
PASS:当N为3或4时，DUT观察到logaPdelay响应超时事件。 | ||||
| 84 | Test Auto.1AS.com.c.9.4 — MDPdelayReq SM: Invalid responses – Part E |
验证当DUT的Pdelay_Reqs响应无效时，DUT是否正确响应。 | 由于sourcePortIdentity无效，丢失Pdelay_Resp_Follow_Up消息 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;但是，不要对接收到的下N个Pdelay_Req消息进行响应。并进行以下更改使Pdelay_Resp_Follow_Up消息的sourcePortIdentity与Pdelay_Resp的sourcePortIdentity不同。N最初为一 | 1对从DUT.TS1接收到的Pdelay_Req消息提供有效响应; 2对于发送的每个有效响应集，对接收到的接下来N个Pdelay_Req消息进行响应，并进行以下更改：并进行以下更改使Pdelay_Resp_Follow_Up消息的sourcePortIdentity与Pdelay_Resp的sourcePortIdentity不同。 3 N最初为一，因此实际上将正确响应每隔一个Pdelay_Req消息。 |
PASS:当N为3或4时，DUT观察到logaPdelay响应超时事件。 | ||||
| 85 | Test Auto.1AS.com.c.9.4 — MDPdelayReq SM: Invalid responses – Part F |
验证当DUT的Pdelay_Reqs响应无效时，DUT是否正确响应。 | 由于各种原因，连续丢失Pdelay_Resp和Pdelay_Resp_Follow_Up消息的混合 | 对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应;连续响应多个有误的Pdelay_Resp或Pdelay_Resp_Follow_Up消息 | 1对从DUT. TS 1接收到的Pdelay_Req消息提供有效响应 2响应8个连续的Pdelay_Req消息，响应模式与之前的有效模式相似，但以下更改除外： a）无Pdelay_Resp且无Pdelay_Resp_Follow_Up b）有效的Pdelay_Resp但具有无效序列ID的Pdelay_Resp_Follow_Up c）具有无效请求PortIdentity.clockIdentity的Pdelay_Resp;有效Pdelay_Resp_Follow_Up d）有效Pdelay_Resp但Pdelay_Resp_Follow_Up具有无效sourcePortIdentity e）具有无效requestingPortIdentity portNumber的Pdelay_Resp;有效Pdelay_Resp_Follow_Up f）有效Pdelay_Resp但无Pdelay_Resp_Follow_Up g）具有无效sequenceId的Pdelay_Resp;有效Pdelay_Resp_Follow_Up h）有效Pdelay_Resp但Pdelay_Resp_Follow_Up具有无效sourcePortIdentity |
PASS:当N为3或4时，DUT观察到logaPdelay响应超时事件。 | ||||
| 86 | Test Auto.1AS.com.c.9.5 — MDPdelayReq SM: Automotive – no sourcePortIdentity checking | 验证DUT不检查sourcePortIdentity对于收到的Pdelay_resp消息 | 每个Pdelay_Resp都使用DUT的clockIdentity | 在TS1开始Pdelay仿真。 当clockIdentiy不同时不响应 |
在接收到对其Pdelay_Req消息的响应之后，在非汽车环境中，端口仅在满足以下五个条件时才变为asCapable： （1）端口正在与其邻居交换对等延迟消息; （2）邻居PropDelay不是太大; （3）端口没有接收到响应于单个Pdelay_Req消息的多个Pdelay_Resp或Pdelay_Resp_Follow_Up消息; （4）Pdelay_Resp不是来自DUT （5）neighborRateRatio有效。 该测试检查第四个条件。它通过发送Pdelay_Resp消息来实现，其中sourcePortIdentity.clockIdentity等于DUT的clockIdentity[3] |
1在TS1开始Pdelay仿真。 2继续响应，但Pdelay_Resp消息的sourcePortIdentity.clockIdentity设置为DUT的portDS. clockIdentity除外。 3 等待40s |
PASS:DUT日志不显示响应超时 | |||
| 87 | Test Auto.1AS.com.c.9.6 — MDPdelayReq SM: Pdelay_Req interval -Part A |
验证DUT在不同响应的情况下是否以适当的间隔发送Pdelay_Req消息 | 无响应的Pdelay_Req间隔 | 确保所有DUT端口均按照测试设置中所述进行链接。观察DUT的Pdelay_Req间期至少10个间期 | gPTP设备必须以一秒为周期定期发送Pdelay_Req消息。无论响应模式如何，即有或没有丢失响应，该间隔都必须一致。 部分B测试没有丢失响应。部分A和C测试有丢失响应。 请注意，虽然默认的initialLogPdelayReqInterval为0（1秒），但由于消息的软件生成性质，AVnu Alliance允许该间隔的变化为+50%和-10%。 |
1确保所有DUT端口均按照测试设置中所述进行链接。
2观察DUT的Pdelay_Req间期至少10个间期 |
FALL:观察到的Pdelay_Req间期的平均值±样本标准差小于0.9 s或大于1.5 s。 PASS:Pdelay_Req间隔在0.9s-1.5s内 |
|||
| 88 | Test Auto.1AS.com.c.9.6 — MDPdelayReq SM: Pdelay_Req interval -Part B |
验证DUT在不同响应的情况下是否以适当的间隔发送Pdelay_Req消息 | Pdelay_Req间隔，无丢失响应 | 确保所有DUT端口均按照测试设置中所述进行链接。从TS1向DUT.TS1发送的所有Pdelay_Req消息发送有效响应。观察DUT的Pdelay_Req间期至少100个间期。 | 1确保所有DUT端口均按照测试设置中所述进行链接。 2从TS1向DUT.TS1发送的所有Pdelay_Req消息发送有效响应。 3观察DUT的Pdelay_Req间期至少100个间期。 |
INFO:报告观察到的Pdelay_Req间期数量、最大值、最小值、平均值、样本标准差和中位数。 FALL:观察到的Pdelay_Req间期的平均值±样本标准差小于0.9 s或大于1.5 s。 PASS:Pdelay_Req间隔在0.9s-1.5s内 |
||||
| 89 | Test Auto.1AS.com.c.9.6 — MDPdelayReq SM: Pdelay_Req interval -Part C |
验证DUT在不同响应的情况下是否以适当的间隔发送Pdelay_Req消息 | Pdelay_Req间隔，偶尔丢失响应 | 确保所有DUT端口均按照测试设置中所述进行链接。从TS1向DUT.TS1发送的每隔一个Pdelay_Req消息发送有效响应。观察DUT的Pdelay_Req间期至少10个间期 | 1确保所有DUT端口均按照测试设置中所述进行链接。 2从TS1向DUT.TS1发送的每隔一个Pdelay_Req消息发送有效响应。 3观察DUT的Pdelay_Req间期至少10个间期 |
FALL:观察到的Pdelay_Req间期的平均值±样本标准差小于0.9 s或大于1.5 s。 PASS:Pdelay_Req间隔在0.9s-1.5s内 |
||||
| 90 | Test Auto.1AS.com.c.10.1 — MDPdelayResp SM: field values | 验证DUT是否正确实现MDPdelayResp状态机的setPdelayResp（）和setPdelayRespFollowUp（）函数值。 | setPdelayResp（）和setPdelayRespFollowUp（）字段值是否匹配 | 从TS1，每秒发送Pdelay_Req消息。 等待10秒，观察DUT发送的Pdelay_Resp和Pdelay_Resp_Follow_Up消息。 |
setPdelayResp（）和setPdelayRespFollowUp（）函数设置的大多数字段都在单独的测试Media Dependent：Message format-header中进行检查。 | 1从TS1，每秒发送Pdelay_Req消息。
2等待10秒，观察DUT发送的Pdelay_Resp和Pdelay_Resp_Follow_Up消息。 |
FALL:任一DUT消息中的sequenceId不等于TS1Pdelay_Req消息中的sequenceId。 FALL:任一DUT消息中的sequenceId不等于TS1Pdelay_Req消息中的sequenceId。 FALL:回应区间大于1秒 PASS:DUT的Pdelay_Resp和Pdelay_Resp_Follow_Up消息中观察到的字段正确。 |
|||
| 91 | Test Auto.1AS.com.c.11.1 — Signaling message DA, EtherType and reserved fields | 验证DUT信令消息中的目的地址、以太网类型和保留字段 | 监控来自DUT的信令消息 | 在TS 1处开始Pdelay仿真。TS 1，模拟AED-GM。 发送logMessageInterval为-3（125 ms间隔）的Sync消息B）以该125 ms间隔发送有效的Sync和Follow_Up消息。 捕获并观察至少3个在TS 1收到的信令消息。 |
所有保留字段设置为零。 | DUT sends Signaling Messages | 1在TS 1处开始Pdelay仿真。 2从TS 1，模拟AED-GM。 3发送logMessageInterval为-3（125 ms间隔）的Sync消息B）以该125 ms间隔发送有效的Sync和Follow_Up消息。 4捕获并观察至少3个在TS 1收到的信令消息。 .等待时间不超过120秒 |
INFO：报告从DUT观察到的信令消息的数量。 FAIL：任何观察到的信令消息地址不是01：80：C2：00：00：0E FAIL：任何观察到的信令消息的EtherType不是0x 88 F7。 FAIL：任何观察到的信令消息的五个保留字段中的任何一个都不为零。 PASS：每个观察到的信令消息都有正确的地址描述符，正确的以太网类型，保留字段为零。 |
||
| 92 | Test Auto.1AS.com.c.11.2 — Signaling message header, body and TLV | 验证被测设备信令消息中的报头、正文和消息间隔请求TLV | 监测来自DUT的信令消息 | 在TS 1处开始Pdelay仿真。TS 1，模拟AED-GM。 发送logMessageInterval为-3（125 ms间隔）的Sync消息B）以该125 ms间隔发送有效的Sync和Follow_Up消息。 捕获并观察至少3个在TS 1收到的信令消息。 |
测试验证DUT的clockIdentity在信令消息中显示为sourcePortIdentity字段的前八个八位字节。如果它的前三个八位字节是制造商的组织唯一标识符（OUI），并且下面的两个八位字节是0xFFFE，则它是有效的。请注意，Automotive for Signaling消息中的使用限制了linkDelayInterval和announceInterval字段的使用，这些字段应设置为127。 | DUT sends Signaling Messages | 1在TS 1处开始Pdelay仿真。 2从TS 1，模拟AED-GM。 3发送logMessageInterval为-3（125 ms间隔）的Sync消息B）以该125 ms间隔发送有效的Sync和Follow_Up消息。 4捕获并观察至少3个在TS 1收到的信令消息。 .等待时间不超过121秒 |
INFO报告从DUT观察到的信令消息数量。 FALL传输特定的半字节不是0x1。 FALL消息类型半字节不是0xC。 FALL失败版本PTP半字节不是0x2。 FAIL messageLength不等于60。 FAIL domainNumber不为0。 FAIL标志值为0x0008 FAIL correctiononField不为0。 FALL源端口标识符不是DUT的端口标识符 FAIL时钟标识符无效，即它不是以OUI + 0xFFFE开始开始。 FAIL控件不是0x5。 FAIL logMessageInterval不是7F。 FALLtargetPortIdenityis not 0xFF. FAIL tlvType不是0x3。 FAIL长度字段不是12（0xC）。 FAIL验证码ID不是0x0080C2。 FAIL FAILURE onSubType不是0x2。 FAIL flag（TLV）不是0x3。 PASS:DUT的信令消息使用正确的报头和主体字段值 |
||
| 93 | Test Auto.1AS.com.c.11.3 — Signaling message sequenceId | 验证DUT信令消息中的序列号 | 监测来自DUT的信令消息中的sequenceID | 在TS 1处开始Pdelay仿真。TS 1，模拟AED-GM。 发送logMessageInterval为-3（125 ms间隔）的Sync消息B）以该125 ms间隔发送有效的Sync和Follow_Up消息。 观察来自DUT的10个连续信令消息的sequenceId。 |
此测试确保DUT传输的信令消息具有有效的sequenceId字段。参考文献[1]规定每个端口必须为信令消息维护自己的序列号池。标准没有规定初始sequenceId应该是什么，但它规定每个后续ID必须比从端口发出的前一个信令消息的ID大1 | DUT sends Signaling Messages | 1在TS 1处开始Pdelay仿真。TS 1，模拟AED-GM。 2发送logMessageInterval为-3（125 ms间隔）的Sync消息B）以该125 ms间隔发送有效的Sync和Follow_Up消息。 3观察来自DUT的10个连续信令消息的sequenceId。 4等待时间不超过120秒。 |
PASS如果从DUT观察到两个或更多的信令消息，并且连续的sequenceId号增加1。 | ||
| 94 | Test Auto.1AS.com.c.12.1 — AVnuSpecific: Std.Dev of Pdelay_Resp and Pdelay_Resp_Follow_Up T2 & T3 values |
验证DUT的Pdelay_Resp和Pdelay_Resp_Follow_Up消息中发送的（T4-T1）-（T3-T2）值的标准差是否在可接受的公差范围内。/链路延迟 | 验证T2和T3时间戳的标准差。 | 1从TS 1，每秒发送Pdelay_Req消息。 2记录DUT观察到的T2（在Pdelay_Resp消息中）和T3（在Pdelay_Resp_Follow_Up消息中）值的300个观察值，并计算每个观察值的（T4-T1）-（T3-T2），记为往返延迟。 3计算往返延迟数据集的标准差，记为σDUT。 4计算σDUT – σ校准的绝对值。 |
在测试站和DUT之间观察到的标准偏差不能超过两个测试站之间观察到的标准偏差100 ns。 | 校准步骤：1.连接TS 1和TS 2 2.从TS 2，每秒发送Pdelay_Req消息。 3.记录300个从DUT观察到的T2（在Pdelay_Resp消息中）和T3（在Pdelay_Resp_Follow_Up消息中）值的观察结果，并计算每个观察结果的（T4-T1）-（T3-T2），记为往返延迟。 4.计算往返延迟数据集的标准差，记为σ校准。 |
1从TS 1，每秒发送Pdelay_Req消息。 2记录DUT观察到的T2（在Pdelay_Resp消息中）和T3（在Pdelay_Resp_Follow_Up消息中）值的300个观察值，并计算每个观察值的（T4-T1）-（T3-T2），记为往返延迟。 3计算往返延迟数据集的标准差，记为σDUT。 4计算σDUT – σ校准的绝对值。 |
PASS 通过计算值小于或等于100ns | ||
| 95 | Test Auto.1AS.br.c.13.1 — SiteSyncSync: Not GM: Tx Sync not changed when Rx Sync on non-Slave Port | 验证网桥是否继续发送正确编码的同步消息，即使网桥的非从端口未正确接收同步消息，也不进行更改。 | DUT正确忽略从非从机端口接收的PortSyncSync数据 | 从TS 1，每隔125 ms发送一次Sync消息，每个消息后面都有一个Follow_Up消息。 从TS 2，每64 ms发送一次Sync消息，每个消息后面都有一个Follow_Up消息。发送这些消息时，logMessageInterval为-4，并且源地址、sourcePortIdentity、preciseOriginTimestamp、followUpCorrectionField、gmTimeBaseIndicator、lastGmPhaseChange和lastGmFreqChange与TS 1不同。 等待至少2秒，捕获在TS 3接收到的所有同步和跟进消息 |
1从TS 1，每隔125 ms发送一次Sync消息，每个消息后面都有一个Follow_Up消息。 2从TS 2，每64 ms发送一次Sync消息，每个消息后面都有一个Follow_Up消息。发送这些消息时，logMessageInterval为-4，并且源地址、sourcePortIdentity、preciseOriginTimestamp、followUpCorrectionField、gmTimeBaseIndicator、lastGmPhaseChange和lastGmFreqChange与TS 1不同。 3等待至少2秒，捕获在TS 3接收到的所有同步和跟进消息 |
PASS：DUT.TS3发送的Sync和Follow_Up消息中的字段preciseOriginTimestamp、gmTimeBaseIndicator、lastGmPhaseChange和lastGmFreqChange与TS1发送的值匹配 | ||||
| 96 | Test Auto.1AS.br.c.14.1 — PortSyncSyncSend SM: Sync interval after syncReceiptTimeoutTime | 验证在syncReceivtTimeoutTime之前未收到Sync消息的情况下，DUT是否以适当的间隔发送Sync消息。 | Bridge Sync Tx and Interval when no Sync Rx | 将TS1连接至xAED-B从端口。将TS2连接至xAED-B主端口。 在TS 1和TS 2处开始Pdelay仿真。 在TS1正常发送Sync和不发送Sync的情况下观察TS2处的所有流量。 |
已停止接收Sync消息的网桥必须继续以适当的间隔发送有效的Sync和Follow_Up消息，直到SyncReceivtTimeoutTime出现。
本测试验证网桥是否继续使用保存在SEND_MD_SYNC状态中的lastPreciseOriginTimestamp和其他信息发送所需的Sync和Follow_Up消息， |
1将TS1连接至xAED-B从端口。将TS2连接至xAED-B主端口。 2在TS 1和TS 2处开始Pdelay仿真。 3从TS1，每隔125 ms发送一次Sync消息，每个消息后面都有一个Follow_Up消息 4等待两秒钟，让TS2从DUT接收同步消息。注意相关的Follow_Up消息，检查preciseOriginTimestamp是否与TS1发送的消息匹配。 5等待2秒钟。 6停止来自TS1的同步和Follow_Up传输，注意发送的最后一个Follow_Up消息的preciseOriginTimestamp。 7等待2秒钟，观察TS2处的所有流量。 |
FAIL同步间隔大于187.5毫秒。 FAIL所有观察到的Sync消息的序列号从先前观察到的Sync消息增加1。 FAIL最后两个（至少）Follow_Up消息的preciseOriginTimestamp不是精确的。 FAIL最后一条Follow_Up消息的correctiononField增加的量小于最后两条Sync消息发送的增量（在ScaledNS中）。 PASS同步间隔在可接受的容差内，当没有收到Sync或Follow_Up消息时，网桥会正确连接以发送Sync和Follow_Up消息，除非发生同步接收。 |
|||
| 97 | Test Auto.1AS.br.c.15.1 — Message format—no Q-tags from Bridge | 验证DUT未在带有Q-tags的以太网帧中发送gPTP消息 | 检查来自DUT的同步和后续消息 | 在TS1和TS2处开始Pdelay仿真 从TS1，每隔125 ms发送一次Sync消息，每个消息后面都有一个Follow_Up消息。 等待5秒钟，观察TS1和TS2处的所有gPTP消息 停止从TS1发送同步和后续消息。 |
在全双工点对点链路上发送的gPTP消息必须既没有VLAN标签也没有优先级标签。[1]此测试检查通过DUT的Sync和Follow_Up以太网帧是否有此类标签。 | Bridge | 1在TS1和TS2处开始Pdelay仿真 2从TS1，每隔125 ms发送一次Sync消息，每个消息后面都有一个Follow_Up消息。 3等待5秒钟，观察TS1和TS2处的所有gPTP消息 4停止从TS1发送同步和后续消息。 5等待60秒，观察TS1和TS2处的所有gPTP消息 |
FAIL未收到同步消息，或观察窗口中看到的最后一条Follow_Up消息不是来自TS1。 PASS观察到的gPTP帧中没有一个包含VLAN标签或优先级标签。 |
||
| 98 | Test Auto.1AS.br.c.16.1 — MDSyncSendSM: correctionField of Follow_Up Messages for Bridges -Part A |
验证网桥发送的Follow_Up消息的Correction字段是否正确计算 | 观察Follow_Up correctionField值 | 使用具有精确已知延迟的短链路将TS1连接到DUT.TS1。将使用两条链路（指定为短链路和长链路），延迟差异约为300 ns或更大。 在TS1和TS2处开始Pdelay仿真 5从TS1，每125毫秒发送一次有效的Sync和Follow_Up消息。Follow_Up消息的correctionField值（xxxx）最初为3000（0xBB8），累积ScaledRateOffset值（YYYY）为0 等待1秒。 捕获来自TS1并由DUT.TS2在公共时基上发送的所有Sync和Follow_Up消息 修改xxxx的值 |
a）计算ZZZZ作为同步消息穿过网桥所花费的驻留时间。从TS 1发送的第一个同步消息到DUT. TS 2发送的第一个同步消息的时间，并以这种方式继续用于每个后续的同步消息集。信息性地报告观察到的驻留时间[8] B）将80 ns可能的流量监视器时间戳错误添加到ZZZZ。
c）将TS 1和DUT之间的链路的已知链路延迟添加到ZZZZ。TS 1 d）由于DUT的Pdelay测量中的允许误差，将100 ns添加到ZZZZ。 e）乘以最差情况下允许的相邻比率（1.0002001（200.1ppm））。 f）转换为ScaledNS（将ZZZZ乘以2 16）。 g）在TS 1发送的Follow_Up消息中添加值xxxx（最初为0xBB 8）。 h）将该值（ZZZZ）与在来自端口DUT.TS2的Follow_Up消息中发送的correctionField值进行比较。 i）对至少3组Sync和Follow_Up消息进行此计算。 |
双链路精密全双工在线流量监视器，能够以低于40 ns的粒度，以相同的时基对两个不同端口上接收到的帧进行时间戳标记（如果两个测试站共享一个公共时基，则可以等效地实现功能 | 使用具有精确已知延迟的短链路将TS1连接到DUT.TS1。将使用两条链路（指定为短链路和长链路），延迟差异约为300 ns或更大。 在TS1和TS2处开始Pdelay仿真 5从TS1，每125毫秒发送一次有效的Sync和Follow_Up消息。Follow_Up消息的correctionField值（xxxx）最初为3000（0xBB8），累积ScaledRateOffset值（YYYY）为0 等待1秒。 捕获来自TS1并由DUT.TS2在公共时基上发送的所有Sync和Follow_Up消息 Repeat steps A:5 through A:8, where: a) XXXX is now 0x 0000 0001 0000 0000 (4294967296) 32bit scaledns boundary b) XXXX is now 0x 0001 0000 0000 0000 (281474976710656) 48bit scaledns boundary (32-bit seconds boundary) c) XXXX is now 0x 0010 0000 0000 0000 (4503599627370496) 52bit scaledns boundary (68.719seconds) d) XXXX is now 0x 1000 0000 0000 0000 (1152921504606846976) 60bit scaledns boundary (293.203minutes) e) XXXX is now 0x 7FE0 0000 0000 0000 (9214364837600034816) Bits 53-63 set, 64th is sign bit (39 hours) |
FAIL任何观察到的Follow_Up消息的correctiononField值不得超过步骤A：8中计算的ZZZZ值。
INFO观察居留时间[8]报告。 PASS所有观察到的Follow_Up消息的correctonField值不超过观察到的限制。 |
||
| 99 | Test Auto.1AS.br.c.16.1 — MDSyncSendSM: correctionField of Follow_Up Messages for Bridges -Part B |
验证网桥发送的Follow_Up消息的Correction字段是否正确计算 | 延迟Pdelay响应重复 | 使用具有精确已知延迟的短链路将TS1连接到DUT.TS1。 开始Pdelay仿真在TS1和TS2 从TS1开始，修改每隔三次从TS1发送的Pdelay_Resp的定时，以响应DUT. TS1的Pdelay_Req消息。将Pdelay_Resp消息延迟300 ms以上但500 ms以下。因此，对于每三次Pdelay交换，第三次将包括延迟Pdelay_Resp。 等待2秒，继续观察Sync和Follow_Up消息。注意Sync或Follow_Up消息传输是否停止或间隙增加超过50%。 使用在步骤B：9期间捕获的至少三个连续同步和随访消息重复步骤A：8的计算 |
1使用具有精确已知延迟的短链路将TS1连接到DUT.TS1。 2开始Pdelay仿真在TS1和TS2 3从TS1开始，修改每隔三次从TS1发送的Pdelay_Resp的定时，以响应DUT. TS1的Pdelay_Req消息。将Pdelay_Resp消息延迟300 ms以上但500 ms以下。因此，对于每三次Pdelay交换，第三次将包括延迟Pdelay_Resp。 4等待2秒，继续观察Sync和Follow_Up消息。注意Sync或Follow_Up消息传输是否停止或间隙增加超过50%。 5使用在步骤B：9期间捕获的至少三个连续同步和随访消息重复步骤A：8的计算 |
FALL观察到Sync消息或Follow_Up消息之间的间隔增加，增加50%或更多;或者，DUT.TS2的Sync和/或Follow_Up消息传输完全停止。 FAIL任何观察到的Follow_Up消息的correctionOnField值超过A部分A：8中观察到的值一个数量级。（B部分B：10 > 10 x（A部分A：8）。注意：10 x被选择作为由于延迟到达Pdelay_Resp帧而导致的Pdelay计算中溢出的合理指示符。 PASS通过所有观察到的Follow_Up消息的correctiononField值均在A部分A：8（B部分B：10 ≤ 10 x（A部分A：8））中观察到的值的一个数量级内。 |
||||
| 100 | Test Auto.1AS.br.c.17.1 — AVnuSpecific: Bridge impact on End-Station Accuracy | 验证通过桥接器连接时，参考从机是否在1μs内正确锁定到参考主机 | 观察时间同步输出的增量 | 测试设置：参见附录A：默认测试设置。将精密脉冲监视器连接到TS1和TS2的时间基准（1PPS或1PulsePer125μs）。 测试前TS1和TS2校准：1.如有必要，将TS1配置为GM。 2.直接连接TS1和TS2（无需通过桥接器连接）。 3.等待30秒。 4.使用精密脉冲监视器，测量TS1的时间同步输出脉冲（作为参考）与TS2（从机）的时间同步输出脉冲之间的时间增量，并将该值记录为CalibrationDelta 5.继续测量并记录300个CalibrationDelta值。 6.计算CalibrationDelta的平均值和标准差以及最大观测CalibrationDelta的绝对值。 7.重复该校准2次。 8.如果平均值变化超过10 ns，则重复此校准程序，使观察到的CalibrationDelta值的数量加倍;或者，选择不同的TS 1和TS 2器件并重复此校准程序，直到收集到稳定的平均值。 |
本测试仅验证DUT不会降低两个选定测试站保持同步的能力。首先评估两个测试站直接连接在一起的情况，并观察它们的行为超过300次观察。记录从站与主站的最大绝对偏差。然后引入桥接器并重复测量。如果从站与主站的偏差如果增加超过80 ns，则确定DUT出现故障。 | 1使用精密脉冲监视器，测量TS1的时间同步输出脉冲（作为参考）与TS2（从机）的时间同步2输出脉冲之间的时间差。将此值称为ObservedDelta。 重复步骤A：4 300次。 3计算ObservedDelta的平均值和标准差以及最大ObservedDelta的绝对值。 4将BridgeImpact值计算为ObservedDelta值平均值减去CalibrationDelta值平均值的绝对值 |
INFO报告ObservedDelta值和CalibravedonDelta值的平均值、标准差和绝对最大值。 FALL BridgeImpact值超过以下总和：80 ns（桥接影响容差）+80 ns（工具误差：2 40 ns-精确测量）+CalibrationDelta数据的标准差。 PASSDUT不会降低被缓存的从终端Stadion保持在GM的适当锁定内的能力。 |
评论前必须登录！
注册