CAPL 脚本开发参考

你在 CANoe 里踩过的坑，多半不是 UDS 逻辑错

在 Vector CANoe/CANalyzer 里写 CAPL 做汽车诊断与安全测试时，编译器报错往往来自语言边界：CAPL 按 C89/C90 约束，变量不能插在语句中间、局部数组不能用 {} 初始化、Test Module 里函数名必须是 PascalCase（例如 TestWaitForTimeout，不是 testWaitForTimeout）。更麻烦的是 DLL：Windows 的 __declspec(dllexport) 不会让 CANoe 发现你的函数，必须在 CAPL_DLL_INFO4 表里注册，且平台位数、运行时（/MD vs /MT）与 CANoe 必须一致。

技能提供什么

本技能把「能跑起来的参考」整理成可检索的约定与模板，面向 CAPL + DLL 双层架构 的诊断安全测试场景：

• 语法与结构：块顶声明、sprintf/strncpy 等 C89 替代写法、文件骨架与关键事件（on start、on message、on timer、on sysvar_update 等）
• 报文与测试：CAN 帧收发模式、TestStep / TestStepPass / TestStepFail 等双参数调用规范
• DLL 集成：从官方 CAPLdll 示例工程起步，在 capldll.cpp 中按既有条目扩展函数，在 CAPL_DLL_INFO4 table[] 中登记名称、函数指针、类型字符串与调用约定；表末 { 0, 0 } 作为终止项
• 延伸阅读： pitfalls、UDS/安全测试模板、DLL 编译与加载步骤（配置 → Programming → CAPL DLL → 重编译节点 → 在 CAPL Browser 中核对）

遇到 CAPL 相关问题时，技能会优先按 C89 校验示例、用 PascalCase 写 Test Module，并在 DLL 问题上强调「示例工程 + 表注册」，而不是只给一段看似标准的 C++ 导出代码。

适用边界

• 面向 CANoe/CANalyzer 生态，不覆盖非 Vector 工具链
• 严格 C89 与「编译器有时能过」的写法可能不一致；技能倾向可移植、可维护的写法
• DLL 若跨边界传递动态分配内存，/MT 静态 CRT 容易引发释放责任问题；复杂场景应优先 /MD 并与示例中的宏保持一致