jasonj333

检查method echoUINT8Array8BitLength的参数当长度字段为8bit时的序列化和反序列化长度字段的标准长度为32bit，如果设置为8bit，对序列化和反序列化都会引发错误。

检查当method echoUINT8Array16BitLength的参数中长度字段为16bit时，SOME/IP协议层是否能对参数进行序列化和反序列化。对于可变长度的数组而言，必须用长度字段表示数组长度。否则接收方无法判断有效数据。SOMEIP_ETS_028: echoUINT8Array测试用例中，长度字段的长度为4个字节，32bit。如果我们把长度字段的长度改为16bit，对于接收方而言，还是按照32bit作为长度字段，用它的值判断数组长度，这样肯定对不上号。这就是这条测试用例的目的。

检查method方法echoUINT8的参数及其顺序能够被顺利地发送和接收说白了就是检查UINT8数据类型参数在SOME/IP协议层的序列化与反序列化是否正常。UINT8相比于测试用例SOMEIP_ETS_021: echoINT8中的SINT8数据类型来说，属于无符号整数，也就是只有正数没有负数。

检查method方法echoINT8的参数及其顺序能够被顺利地发送和接收各种数据类型的参数要按照一定的规则编码成字节数据作为SOME/IP有效载荷传输到目标主机。目标主机收到SOME/JIP报文后，再按照相同的规则解码成正确的数据类型的参数。这就是SOME/IP协议中数据的序列化和反序列化。！！！这就是我们为什么要在TC8 SOME/IP测试用例中包含序列化和反序列化测试的原因。

检查枚举类型的参数及其顺序能够被顺利地发送和接收。

SOMEIP_ETS_007: echoBitfields目的检查位字段是否能够被顺利地发送和接收。

在TC8一致性测试用例中，物理层的测试用例分为两个部分：IOP和PMA。其中IOP中对PHY芯片的Link-up时间的测试，又包含三个测试用例。这三条case从名称就能够判断出它们的不同。OABR_LINKUP_01是给DUT的对手件上电唤醒，OABR_LINKUP_02是DUT上电唤醒，OABR_LINKUP_03是DUT报文唤醒。

它可以用来表示Unicode标准中的任何字符，而且其编码中的第一个字节仍与ASCII相容，使得原来处理ASCII字符的软件无须或只进行少部分修改后，便可继续使用。像上面"AbCd"这种英文字母可以用一个字节编码，就用ASCII码表示，而"€"无法用ASCII码表示，在UTF-8中用三个字节的数字表示。为什么需要传入这些参数？网卡表示ping报文使用的源IP地址，目标IP地址表示发给哪个主机，payload数据表示携带的有效数据。传入的参数包括：网卡名称、目标IP地址、payload数据。

检查DUT是否可以在短时间内处理突发请求并返回所有请求的响应。

当Tester发送的SOME/IP消息中，payload数据是序列化的数组时，数组的长度比SOME/IP长度允许的要长时，DUT回复SOME/IP Error消息如果DUT忽略SOME/IP Request消息，这条测试也是Pass的，结果也能接受。

对于method通信中的request/response消息，如果request消息中的Message ID错误，ECU回复SOME/IP Error消息。Error消息应复制SOME/IP Request消息中报头的字段（即Message ID、Request ID 和Interface Version），但不复制payload。此外，必须将Message Type和Return Code设置为适当的值。这条case检查Message ID。

Field的setter属于request/response调用。request消息的payload中放入期望值，response消息的payload中放入设置值如果设置Field值正确，request和response的payload值应该相同。

检查Type 1 Entry（Offer Service）的“Instance ID”字段。

Flag字段中的未定义位应静态设置为0。

Subscribe Eventgroup Negative Acknowledgment entry type应用于指示订阅事件组条目未被接受。Subscribe Eventgroup Negative Ack entries应按以下方式设置Entry字段： Type应设置为0x07 (SubscribeEventgroupAck)。Service ID、Instance ID、Major Version、Eventgroup ID 和Reserved与正在回答的订阅中的值相同。

IPv4 Endpoint Option的Reserved字段应静态设置为0x00这是第二个Reserved字段。

在FINWAIT-2状态下的TCP，接收到SEQ号超出窗口范围或ACK号不可接受的传入段时，返回一个带有正确SEQ和ACK号的ACK消息，并保持在FINWAIT-2状态。

检查Type 2 Entry（SubscribeEventgroupAck）的"Major Version"字段。

IPv4 Multicast Option的Reserved字段应静态设置为0x00这里指的是第二个Reserved字段。

TCP能够处理SYN+ACK报文段中MSS选项的长度非法，而不会崩溃可以正常地响应，就是不崩溃，这里指的应该是DUT发送ACK。

定时器的初始设置是重组等待时间的下限。这是因为如果到达片段中的生存时间（TTL）大于当前计时器值，则等待时间将增加。（注意：这里我们假设初始计时器设置为15秒）其实也很好理解，TTL表示报文在网络中的最大生存时间，所以虽然主机有一个默认的重组等待时间，但是也要考虑虽然重组等待时间超时，但是分片包还在网络途中未到达而已所以这个重组的Timer定时器，要取默认重组等待时间和TTL这两个值中，最大的那个。

在LISTEN状态下的TCP接收到携带一个不可接受的ACK号的段，发送RST并且保持在相同的状态在LISTEN状态下的TCP，只能接收到SYN消息，不能有ACK标志位和ACK号，如果有，就是不可接受的。

处于CLOSED状态下的TCP在主动open调用下发送SYN消息什么是active OPEN call？主动打开调用，客户端创建socket后调用connect函数。

TCP从FINWAIT-2状态到TIME-WAIT状态后，等待2MSL时间后，移动到CLOSED状态关于为什么要等待2MSL时间，我的文章中讲过太多次了，这里就不提了。

验证DUT发送的UDP报文的Total Length字段的正确性。

主机回复ICMP Echo Response报文的Identifier字段和Sequence Number字段和接收到的ICMP Echo Request报文相同。这条case的目的很简单，主机接收到的ICMP Echo Request报文里的数据，必须放入ICMP Echo Response报文中发送回来。4, Tester：验证接收到的ICMP参数问题消息包含Unused字段为0并且数据字段包含完全相同的IP报头和发送到DUT的64 位原始数据。在请求消息中接收到的数据必须在应答消息中返回。

检查DUT能接收Length字段设置为最大值的UDP报文UDP头部里的Length字段是2字节，最大值为65535。那么是不是表示Length字段可以取最大值65535来使用呢？并不是为什么？UDP头部+data，作为网络层的payload，它的大小需要由网络层的Total Length的大小决定。

主机收到IP Header中协议字段不支持的IP数据包时，回复ICMP目的不可达报文（未知协议）

确保DUT不会重组没有分片包首片的IPv4数据包。

主机收到ICMP时间戳请求后，需要把里面的时间戳数据与附加的时间戳一起通过ICMP时间戳响应发送出去。

如果在连接建立时没有收到MSS选项，TCP必须假定默认发送MSS为536。

在SYN-SENT状态的TCP，接收到一个既没有SYN也没有RST标志位的传入段后，必须丢弃这个包并保持在SYN-SENT状态。

当flg为0时，表示仅时间戳，存储在连续的32位bit中。

如果Overflow计数本身溢出，则认为原始数据报有错误并被丢弃。

所有主机都必须准备好接受最多576个字节的数据报我们知道最大传输单元MTU通常是1500个字节，也就是说一条IP数据报的Header+payload最大1500，那为什么这条测试用例又要求主机准备好接受最多576个字节的IP数据报呢。

SOME/IP-SD Header的Reboot Flag应在重新启动后为所有消息设置为1，直到SOME/IP-Header中的Session-ID循环回来并再次以1开始。在循环回来后Reboot标志设置为0。

在CLOSED，LISTEN，SYN-SENT状态下的TCP，不处理FIN消息。

在FIN-WAIT-2状态下的TCP，允许接收操作。

在CLOSE-WAIT状态下的TCP，接收到任意SEQ号超出窗口范围的报文段，必须发送ACK号为它期望对面发送的下一个传入段的SEQ号的ACK消息，并保持在相同的状态CLOSE-WAIT状态。

对于携带错误的SOME/IP消息（return code 0x01 - 0x1f），不应该用SOME/IP Error消息回答。