jasonj333

有这样一个需求：用户想回放一个CAN文件，同时监测回放的数据流里是否有CAN ID 100的报文。如果有，则在面板上亮起红灯，否则亮绿灯。

在文章《如何让CANoe或Wireshark自动解析应用层协议》中，我们通过设置指定端口号为SOME/IP报文的方式，可以让CANoe中的Trace窗口对此端口号的报文当成是SOME/IP报文进行解析。

当我们使用CANoe软件或Wireshark工具抓取以太网总线上的报文时，网卡首先会把以太网总线上的模拟信号解析成以太网帧数据。数据链路层根据二层头部中的Type字段值确定上层的协议。

TLS，Transport Layer Security，传输层安全协议。是在传输层和应用层之间，为了保证应用层数据能够安全可靠地通过传输层传输且不会泄露的安全防护。

Vector Security Manager 是 Vector 公司提供的一种工具，它为像 CANoe 这样的 Vector 工具提供安全功能，例如安全相关的通信（SecOC）、诊断、认证等，这些功能都是在安全配置文件中进行管理的。所有支持的工具都采用统一的配置方式。

TCP keep alive机制我们已经讲过太多次，车内很多控制器的TCP keep alive机制相信很多开发和测试的人也配置或者测试过。我们今天想知道CANoe软件自带的TCP/IP协议栈中TCP keep alive机制是如何工作的。

我们知道，CANoe软件中配置以太网通道后，添加的仿真节点可以作为一个主机或者一个应用来实现以太网通信。但不管是作为主机还是应用，仿真节点都需要配置TCP/IP协议栈。

从12版本以后的CANoe软件，以太网网络采用Network-based mode（基于网络的模式），而非Channel-based mode（基于通道的模式）。这样设计的意图是更符合以太网通信拓扑：交换式网络。

在CANoe测量期间（CANoe运行时），总线数据经由Measurement Setup界面的各分析模块的输入口流入Trace、Graphics、Data等窗口中，或统计、或显示、或分析。总线数据除了能流入分析窗口中做解析外，还可以保存到log文件中，留作其他人分析或复现的文件。

Trace窗口的目的是在测量期间（CANoe运行时）记录总线活动。在测试设置（Measurement Setup）中的Trace窗口的输入处接收到的所有消息都在Trace输出窗口中显示为文本。

TCP超时重传机制我们已经讲过太多次，车内很多控制器的TCP超时重传的参数相信很多开发和测试的人也配置或者测试过。我们今天想知道CANoe软件自带的TCP/IP协议栈中TCP超时重传的参数是怎样的值。

在文章《CANoe-Ethernet IG和Ethernet Packet Builder的使用和区别》中，我们讲过Packet Builder可以组装多种类型的以太网报文：

27服务解锁的工作原理可以在文章《诊断27服务介绍》查看，这里简单介绍下流程：

在CANoe 15软件版本中，Communication Setup导入arxml文件后，可以在model editor中打开arxml并修改配置。关闭model editor后再打开，可以看到修改的配置被保存了。

我们在文章《CANoe中的工作模式之争：由一段简单的代码引出的问题》中，介绍了模拟总线模式下的三种工作方式：

有网友问我一个CAPL中timer定时器的代码问题。他在CANoe工程中写了一段代码：每5秒循环触发一次定时器事件程序，输出一句文本信息到Write窗口。但是执行后发现并不是每5秒触发一次定时器事件程序，而是非常快的触发定时器事件程序。当他把这段代码复制到一个新的CANoe工程后，一切又正常了起来。这件事情令他非常困扰。

在CANoe的Environment菜单下有一个模块叫：Symbol Mapping。

在CANoe运行时，想要随时改变系统变量的值为任意值，怎么办？（这里的值指的是数值）

当我们想在CANoe中制作一个面板，实现：在一个文本框中输入某个信号的值，点击发送按钮，就能把信号所在的CAN消息发送出去，此时信号的值就是文本框中输入的值。

当我们使用CANoe实现TCP通信时，希望在Trace窗口直观显示报文的类型：SYN、ACK、FIN。显然Trace窗口也是支持这样的功能的。但很多时候由于一些人为的不正确的设置和配置，造成无法显示。

CANoe是德国Vector公司的一款用于开发、测试和分析单个ECU和整个ECU网络的综合性工具，包括软件和硬件。它在整个开发过程中为网络设计者、开发和测试工程师提供支持：从规划到系统级测试。由于其多种变体和功能能够对不同的项目提供支持，被全球OEM和供应商广泛使用。

网友在微信上问我，她使用CANoe给DUT发送以太网报文时，发现Trace窗口显示某些以太网数据包报错，报错的内容是：mac地址无效

我们在文章《CANoe-Start Values窗口是做什么的》中，介绍了Start Values窗口的作用。这篇文章将介绍Start Values窗口的基本功能。

当我们在canoe中编写了一个capl程序，在程序运行前，希望对canoe里的符号，比如系统变量、环境变量、信号、分布式对象等进行初始化赋值时，我们会把它写在on start或on preStart的事件函数中。这样当canoe运行时，会自动触发on start或on preStart的执行，以此自动完成符号初始化

Channel-based access是基于总线搭建车载网络的，就是创建总线通道接入多个ECU节点，这符合LIN或CAN网络的网络布局而对于以太网来说，交换机才是它的标志，所有数据通过以太网端口进行转发，所有的设备连接在交换机的端口上，这就是为什么Network-based access又称为Port-based network access当然CANoe的以太网也可以用Channel-based access来搭建，但是这种方式需要在Simulation Setup上创建Eth channe.

CANoe-什么是vTESTstudiovTESTstudioCANoe平台提供了Simulation Setup用于ECU的仿真模拟通信，提供了Test Modules用于ECU的测试序列，虽然它们能为ECU覆盖很多的测试用例，但是却具有不可移植、编写手段不够灵活等缺点vTESTstudiovTESTstudio是一个用于创建自动化ECU测试的强大的开发环境，它可以提高测试设计的效率，并简化了可复用性，提供了一下两种方法：基于编程和表图形化的测试符合和开发方法它的优点：多样的测试设计

python如何操作CANoe按照我以前的想法，如果CANoe想让python调用，就需要基于python开发一个集成各个功能接口的模块，python通过安装导入这个模块以及调用里面的接口实现CANoe的功能后来发现还是我想的简单了，运行在windows系统中的CANoe和python，完全可以借助windows系统提供的COM组件来实现互通性COMComponent Object Model，是微软公司为计算机系统的软件生产而开发的一种新的软件开发技术，在COM框架下，能实现软件之间的互操作性

CANoe网络通信分析：CANoe用户可以在台架上或者车辆中分析ECU和整个系统的多总线通信。Trace窗口：用于列出所有总线活动，例如消息或错误帧。对于每条消息，都可以显示单独的信号值Graphics窗口：用于在时间轴上以图形方式在线显示消息和诊断请求中传输的值，例如rpm或温度值Statistics窗口：用于显示有用的网络和节点统计信息，例如节点和帧级别的总线负载、突发计数器/持续时间、帧和错误的计数器/速率、控制器状态Data窗口：用于显示预选数据，例如数字或条形图数据。

初接触宏模块时，我还记得当时我主要的测试内容是RVC/OPS（倒车影像/雷达）和Climate（空调）。当时的测试手法是通过CANoe上的面板，模拟RVC/OPS/Climate ECU发送CAN总线消息给IVI（中控，娱乐音响系统），实现RVC/OPS/Climate功能在IVI上的显示与控制

最近有人问我一个问题，就是Simulation Setup界面下的仿真网络里，有两条线：红线、蓝线。它们表示什么意思呢？

当CANoe为Channel-based access模式时，需要配置软硬件通道的映射；当CANoe为Network-based access模式时，需要配置软硬件网络的映射通道映射：网络映射：当然，只有CANoe软件工作模式为Real bus时，才需要软硬件通道或网络映射。如果工作模式为Simulated bus时，不需要软硬件映射其实软硬件通道映射和软硬件网络映射的主要区别在硬件侧。

如同经典通信模式中，在Simulation Setup界面创建网络、添加节点、导入dbc数据库一样，新型通信模式使用System And Communication Setup完成这些配置System And Communication Setup界面有两个子菜单：System Definition、System Explorer。

接触过UDS诊断的人应该知道，诊断通信有两种方式：物理寻址和功能寻址。那什么是物理寻址和功能寻址呢？

我们以VN5650为例：

CANoe通信的关键是通信双方（应用部分）和用于传输的介质的严格分离，以确保灵活、易操作、不干扰。为此，CANoe在应用程序和传输介质之间提供了一个层，即所谓的中间件。面向信号通信的交互层，面向服务通信的SOME/IP、DDS，都属于中间件

传统的以ECU为单元的整车通信架构，是面向信号的以CAN/LIN等总线为代表的经典通信模式。而以车载以太网为总线，SOME/IP或DDS等为中间件的SOA面向服务的新型通信模式，在以域控为单元的整车通信架构中被越来越多的使用CANoe作为仿真和测试环境提供了统一的跨网络通信概念。这种通信概念支持经典和新通信模式的应用程序相关建模。通信概念提供了应用层逻辑通信与网络层协议的一致解耦。

CANoe工具是汽车仿真测试开发中使用最广泛的工具。

CANoe对传统的CAN/LIN总线的软硬件通道连接（或称为映射），采用的是Channel-based模式。在【Vector Hardware Config】中设置软硬件通道映射关系（其实就是把软件通道加入硬件端口下） 从【CANoe.Option Ethernet 12.0/Hardware Driver 11.1】开始，以太网接口卡（VN5000 系列）配置方式逐渐向基于网络（Network-Based）的方式转变。分别把软件和硬件的工作模式设置为Network-based mode，然后通

vector.canoe模块（.py文件），包含了Python API的通用的类和函数

从vTESTstudio 7.0版本开始，vTESTstudio支持使用Python 3.9.2版本进行编程测试。vTESTstudio为此安装了一个Python解释器，并使用特殊的API对其进行扩展，使其能够具有和CAPL相同的功能。比如test sequences、test cases和函数的编程，对事件程序编程，比如按键触发或定时器触发，把测试内容输出到测试报告函数等，访问分布式对象，也就是SOA通信