干巴巴的干活，帮助广大同行少做重复性工作。 |
上述“主-从”式电源管理，比较low，效率低下，不符合行业技术发展趋势，也很难玩出什么花样来。
如上述跳转图，ANM测试的主要目的就是测试各个状态调整的条件和时间参数。
就全行业而言，ANM测试的先驱应该是北汽，其是较早投入ANM路线的车企。
虽然，现在，几乎所有的车企都有自己的AutoSAR NM体系，都能在理论上把它阐述得头头是道，但是真正拥有全面测试能力的车企，并不多。
车辆技术联合业内优秀开发商，发布了基于Python的全自动ANM测试系统，源代码交付，助力贵司严格检验供应商交付质量，助力贵司建立起这个领域的开发能力、升级完善能力。
该方案为合作伙伴的商业方案，得好几万，所以不做私人交流哈~
敲黑板，接下来我们详细讲解，AutoSAR网络管理测试，都测什么，怎么测？
此外，上图还展示了0~17，共17个状态迁移动作，它们均有各自的条件，也有各自的行为特征要求，我们要逐一测试。
一个DTU，若满足了本文描述的所有单步骤的测试性能，那么它就可以在网络管理的任意随机组合状态跳转中，游刃有余、畅通无阻，展示出自己无与伦比的可靠性，坚不可摧的鲁棒性。
| 测试项 | 测试方法 |
| NM报文检查（检查最基础的id正确性） | 1、一般而言，行业通用的NM ID范围为0x5XX 2、通过本地唤醒硬线，唤醒DTU，检查DTU发出来的网络管理报文，要和通信矩阵定义的相同，且不存在其他多余的网络管理报文。 3、若DTU不存在本地唤醒，则随便用一个0x5xx报文，通过被动唤醒将其唤醒。 |
| 报文唤醒测试（被动唤醒的正确性） | 2、在DTU已休眠的情况下，对其发诊断报文（id为0x7xx），持续发2s，DTU不应当被唤醒，报文应当持续发送失败，若发送成功（收到了ack），则本项测试不通过。 3、在DTU已休眠的情况下，对其发0x5xx报文，只发送3帧，周期为快周期参数，一般为20ms，DTU应当被唤醒。再等待DTU休眠，逐一轮换其他NM报文（注意避开DTU自己的NM报文id），DTU均应能唤醒。 |
睡眠模式→重复报文状态（被动唤醒性能测试）
测试方法：
在DTU睡眠的情况下，发三帧NM报文，将其激活，DTU将在60ms时间内发出来第一帧NM报文，第一帧NM报文之后20ms内发出来第一帧app报文。
DTU发NM报文的前1500ms称为“重复报文状态”，在该状态阶段，DTU的NM报文周期为500ms。
显然，理论上讲，“重复报文状态”时间段内，应该有约3帧报文。
上述的“60ms”、“20ms”、“1500ms”、“3帧”、“500ms”等参数，均可通过测试用例进行配置，测试系统应完成自动化测试及核对。
睡眠模式→重复报文状态（本地唤醒性能测试）
测试方法：
在DTU睡眠的情况下，控制本地唤醒将其激活，DTU将在100ms时间内发出来第一帧NM报文，第一帧NM报文之后20ms内发出来第一帧app报文。
DTU发NM报文的前1500ms称为“重复报文状态”，在该状态阶段，DTU前10帧报文的周期为20ms，之后的NM报文周期为500ms。
显然，理论上讲，“重复报文状态”时间段内，应该有12帧报文。
上述的“100ms”、“20ms”、“1500ms”、“10帧”、“500ms”等参数，均可通过测试用例进行配置，测试系统应完成自动化测试及核对。
Repete→Normal
所谓Normal状态，就是本地唤醒持续有效的稳定状态。
测试方法：
在DTU睡眠的情况下，通过本地唤醒将其激活，并保持本地唤醒持续有效。
DTU在快周期阶段结束之后，进入慢周期，Repete阶段结束之后，即进入Normal
一般而言，NM报文的自定义区域会有相关字段，表征DTU是否处于Repete阶段。
测试系统应能对上述参数及特征进行全自动校对！
Normal→Repete
Normal转Repete的情况不多见，一般是网络上其他ECU刷存在感，嗷嗷一声我来了，让大家注意点。
测试方法：
在DTU睡眠的情况下，通过本地唤醒将其激活，并保持本地唤醒持续有效，等待DTU进入慢周期的Normal模式。
可以通过特征byte的特征bit，确认DTU已脱离Repete模式，进入了Normal模式。
进入Normal之后，对DTU发一帧NM报文，且相关字段的bit置1，要求DTU跳转至Repete模式，相当于嗷嗷一声。
DTU收到该NM报文之后，应当进入Repete模式，相关的bit置1，表征自己处于Repete状态。当然，这个“置1”也是维持不了多久的，一般也就1500ms。
在整个过程中，DTU的时序及特征值，均有明确定义及要求，测试系统应能自动核对。
Repete→Ready Sleep
此调整一般出现在被动唤醒或者本地唤醒短暂有效的情形。
被动唤醒的ECU，其工作时，绝大多数时间都是Ready Sleep Mode，不发NM报文，只发app报文。
测试方法：
在DTU睡眠的情况下，发三帧NM报文，通过被动唤醒将其激活。
DTU直接进入慢周期，以500ms发NM报文，Repete阶段结束之后，因为其没有持续有效的本地唤醒源，所以立刻就进入Ready Sleep Mode，停发NM报文，仍发app报文。
理论上讲，DTU发NM报文的时间段长度即为Repete阶段，约1500ms。
测试系统应能自动核对DTU的上述特性。
Ready Sleep→Repete
此现象一般出现于2种情况：
1、DTU当前已经没有唤醒网络的必要了（持续被动唤醒，或有效的本地唤醒已取消），NM报文都停了，但是忽然被别的模块刷了一下存在感，被迫进入了Repete模式。
2、DTU从一开始就是被动唤醒的，但是，忽然，自己的本地唤醒源有效了。
测试方法：
在DTU睡眠的情况下，发三帧NM报文，通过被动唤醒将其激活。
DTU直接进入慢周期，以500ms发NM报文，Repete阶段结束之后，因为其没有持续有效的本地唤醒源，所以就进入Ready Sleep Mode，停发NM报文，仍发app报文。
估摸着DTU的NM报文停发1000ms左右，对DTU发NM报文，通过使特定bit置1，对它刷存在感，强迫它进入Repete状态。
DTU收到NM报文之后，应在60ms之内发送出自己的NM报文，以慢周期500ms发送，且通过特定bit，表征自己处于Repete状态。
上述的“500ms”、“1000ms”、“60ms”、“500ms”等参数，均可通过测试用例进行配置，并完成自动化测试及核对。
Normal Operate → Ready Sleep
这个太常见了，一般就是DTU的本地唤醒源有效，实现特定功能之后，本地唤醒源消失，进入了Ready Sleep State。
测试方法：
在DTU睡眠的情况下，控制本地唤醒源有效，唤醒DTU。
DTU先进入Repete状态，先快周期，然后慢周期，然后进入Normal状态。
DTU标表征当前是否处于Repete状态的特征bit也经历了1→0变化。
确认DTU进入Normal之后，取消本地唤醒源，DTU应该出现至少一帧APP报文，距离其前面最后一帧NM报文超过1000ms。也就是说，NM报文停发1000ms了，还有app报文。
测试系统应能自动核对DTU的上述特性。
Ready Sleep → Normal Operate
典型场景就是，DTU被本地唤醒激活，经过Repete进入了Normal，然后取消了本地唤醒，又进入Ready Sleep State。
进入Ready Sleep State超过2000ms，会跳出Net Work Mode，进入Prepare Bus Sleep Mode。
但如果在2000ms内，本地唤醒源又有效了，它又反悔了，则可以再次回到Normal 模式。相比一下，如果被其他ECU通过特定bit刷了存在感的话，则可以进入Repete模式。
测试方法：
在DTU睡眠的情况下，控制本地唤醒源有效，唤醒DTU。
DTU先进入Repete状态，先快周期，然后慢周期，然后进入Normal状态。
确认DTU进入Normal之后，取消本地唤醒源，再等待1500ms，此时距离最近一帧NM报文的时间应该为1000ms左右，且app报文没有停发。
设置本地唤醒有效。
然后，检查DTU发的NM报文中，表征其是否处于Repete的位应当为0，表征其是否位于Normal的bit应当为1，且NM报文为慢周期。
测试系统应能自动核对DTU的上述特性。
Ready Sleep → Prepare Bus Sleep预睡眠状态
测试方法：
可通过本地唤醒或被动唤醒两种方式测试，主要测试DTU在Ready Sleep State阶段待多长时间，典型值是2000ms。
本地唤醒，先有效后无效，使DTU进入Ready Sleep State。
DTU停发NM报文即意味着进入Ready Sleep State，停发app报文即意味着进入Prepare Bus Sleep，二者之差即为DTU在Ready Sleep State阶段待的时间，定义为T_NM_TIMEOUT。
被动唤醒，发3帧周期为20ms的报文，等待1500ms，经过Repete之后，即认为其进入了Ready Sleep State，此时NM报文即停发，然后再等待其停发app报文即可计算时间差。
测试系统应能自动核对DTU的上述特性。
Prepare Bus Sleep预睡眠状态 → Bus-Sleep Mode
app停发之后，超过一定时间T，DTU应进入休眠，该时间应根据DTU的工作属性，在测试用例中做成可配置参数。
测试方法：
通过被动唤醒，发3帧NM报文，唤醒DTU。
对DTU持续发app报文，直至发送失败，收不到ack，此刻距离最后一帧app报文的时间差，即为上述定义T。
测试系统应能回读app报文的发送结果，自动记录时间，自动核对DTU的上述特性。
Prepare Bus Sleep预睡眠状态 → Repete
这个就太讨厌了，都快睡着了，又把我晃醒了。
测试方法：
这个跳转的特征类似于“Bus Sleep Mode → Repete Message State”，区别仅在于，由于此时DTU并没有休眠，所以首帧NM报文发出来的时间要求较高，要短于T_wake-up，典型值为60ms。
其他特性，和“Bus Sleep Mode → Repete Message State”相同，DTU要表征自己处于repete状态，表征自己是否是本地唤醒，对Repete阶段的时长也有要求。
测试系统应能自动核对DTU的上述特性。
总线10讲，东半球最好用的excel2dbc工具，永远免费送
