ARTICLE · 1126787

【PDF下载】可通讯状态机框架CSM学习笔记(完结)

发布时间：2026-10-05 12:44:01 最近访问：2026-10-05 12:44:02

常见 LabVIEW 编程框架比较

四大框架简介

DQMH：在 LabVIEW QMH 的基础上拓展实现“模块”的概念，解决 QMH 模块循环间通讯不直接、不易支持可复制模块、不容易搭建系统框架等限制，是目前 LabVIEW 生态中非常流行的程序框架。DQMH 模块 = LabVIEW Library + 主 VI + API + 通讯自定义控件；Request 是基于 User Event 实现的外部接口，Broadcast 基于 User Event 实现，用于通知外部模块的状态变化；
Actor Framework：LabVIEW 实现的 Actor Model 方案，多个 Actor 可以独立运行并相互通信，提供面向对象体系结构的一组类。该模型提供两个父类：Actor（拥有数据状态的模块）与 Message（消息在操作者间传递用来触发状态改变），实际开发时需要创建它们的子类；
SMO（JKI-State-Machine-Objects）：对 JKI-State-Machine 的扩展，可以创建多个异步运行的 JKI-State-Machine 对象，它们之间通过动态事件通讯。模块即类，通过类的方式操作模块；概念上支持可复制模块；支持子模块。

十二维度对比

下表从十二个维度对比 DQMH、SMO、Actor Framework 与 CSM 四个框架：

表6常见 LabVIEW 编程框架十二维度对比

维度	DQMH	SMO	Actor Framework	CSM
外部接口	Script 辅助创建 API	类公共接口作为 API	类封装的 Message 消息通讯	字符串格式的消息通讯，非必须创建 API
状态反馈	User Event，外部需要存在事件结构添加订阅逻辑<o:page></o:page>	User Event，外部需要存在事件结构添加订阅逻辑	消息处理中封装反馈消息	消息通过 JKISM 机制传递，无需 User Event Structure；隐式传递，订阅无需修改侵入代码，可外部调用
可复制模块	复杂，两套模板	容易，类实现，框架不区分	容易，类实现，消息和模块独立，灵活性高	容易，VI 属性决定
代码依赖	调用方需要依赖模块的自定义事件和参数定义，需预先开发框架定义部分的接口代码	调用方高度依赖模块实现，必须先开发框架接口部分	调用方可能有继承依赖和消息依赖，需预先定义消息类和方法	调用方开发无需依赖框架代码；消息、参数均用字符串，不显式依赖，不易 broken；复杂参数需要依赖
参数传递	任意类型，使用 User Event 传递	任意类型，使用 User Event 传递	任意类型，需要封装 Message 类	字符串，复杂类型需转换
代码复杂度	框架逻辑简单，模块代码冗余度高，不依赖 script 增删比较复杂	框架特别复杂，模块逻辑基于 JKI 状态机，需理解 JKI SMO 的概念逻辑	框架特别复杂，实现高度依赖 OOP	继承 JKISM 优点，代码逻辑集中，理解消息通讯状态跳转后与 JKISM 编程思路相同
生态	最佳	社区中仅有 JKI 提供模板和工具	一般，通常作为企业内部统一架构	待完善
OOP	无	有	有	无
执行效率	依赖 Event Structure	依赖 Event Structure / LabVIEW OOP	LabVIEW OOP	依赖参数的解析
UI 编写	支持	支持	支持	支持
RTOS	支持	不推荐	不推荐	支持
高级模式	无	可组合，模块能作为子模块	继承 Actor Core.vi 实现特殊模式	并行工作者模式、责任链模式

各框架优缺点

表7四大框架优缺点对比

框架	优点	缺点
DQMH	继承于应用最广泛的框架 QMH，且无 OOP，对大多数 LabVIEW 用户比较友好；社区活跃度高，资料/工具众多	代码接口冗余；两套模板实现 Singleton/Standalone 模块
SMO	非常符合面向对象的概念；模块独立性好，操作调用直观；最适用的场景是模块复用，不与调用方一起开发<o:page></o:page>	框架复杂度高，对用户要求高；目前社区用户少、更新频率不高；资料比较少
Actor Framework	操作者、消息均解耦，解耦程度高，便于多人协作开发；熟悉 OOP 的开发人员使用方便	框架复杂度高，对用户要求高；项目需要架构师角色
CSM	继承于 JKISM，代码集中度高；无 OOP，对大多数 LabVIEW 用户比较友好；通过文档定义接口分工，无需代码；容易实现操作序列化（Serialization）；内置多种高级模式	所有消息必须使用 STRING 格式传递，有转换的开销；目前工具/资料还不完善

案例分享

案例一：数据连续采集并保存程序

连续的数据采集、存储和分析是一种非常常见的 LabVIEW 程序场景，LabVIEW 和 VIPM 社区都有类似的模板程序。本项目基于 CSM 完成了同样的场景，并演示了 CSM 作为框架简洁、灵活、复用性强的优势；该模板已上传 VIPM Community，可在 VIPM 中直接安装。

该案例中 CSM 保证了以下几点：

模块独立：功能模块相互没有任何调用关系，通过业务逻辑（UI 模块）订阅状态；
模块可替换：相同接口的模块不需要调整业务代码；
模块接口可通过文档描述提前定义，不需要架构师提前编写接口；
波形数据通过 CSM MassData Arguments 传递，无需创建数据传输通路。

模块间交互逻辑为：Sampling（采集模块）发布 Data Sampled >> Waveform(MassData) 状态，UI、Logging（存储模块）订阅该状态；FFT（分析模块）可随时加入，同样订阅波形数据并发布 FFT Data >> Waveform(MassData)，实现“添加分析模块”而无需改动既有模块。

案例二：复杂系统的组件化及序列化测试

面对越来越复杂的系统，模块化和组件化的设计能够通过自顶而下的划分将复杂的问题简单化，针对复杂的测试系统亦是如此。本项目假设复杂的测试场景，基于 CSM 框架完成复杂系统的组件化及序列化测试，演示了 CSM 框架的灵活性、复用性以及解耦合特性。

应用场景：将复杂测试系统分解为多个不同的模块/组件，不同的模块/组件联合实现不同功能完成相应测试，对所有功能测试序列化以满足复杂系统的自动化测试需求。实现分为三步：

测试系统模块化：将系统划分为系统模块（组件1、组件2、组件3）与系统采集（数采1、数采2）等独立 CSM 模块，每个模块具备 start / action / stop 等操作及 error occurred / status changed / data sampled 等状态；
测试项组件化：各独立模块组合成相应的测试需求，基于 CSM 实现组件与测试项交互。例如：测试1 = 组件1 + 组件2 + 数采1；测试2 = 组件1 + 组件3 + 数采1；测试3 = 组件2 + 组件3 + 数采2；每个测试项具备 error handler / status ready / data sampled / test status 等状态；
测试文件序列化：通过“测试项列表库”加载所有测项，双击任意测项配置参数、添加测试步骤，实现测试序列化自动化；测试流程可任意编排，例如：步骤1（测试1）→ 步骤2（测试2）→ 步骤3（测试3）→ 步骤4（测试1）→ 步骤5（测试3）……

图8测试系统模块化、测试项组件化与测试文件序列化（原PPT第31页）

案例三：基于 CSM 的通用自动化测试框架

中大型院所、单位和公司具有多型号的测试任务，自动化测试软件框架的通用化、标准化设计能够复用已有测试资源，简化系统开发周期，提升系统的易用性。本项目基于 CSM 框架应用抽象层（Abstract Layer）的设计思想，定义标准化的通信接口，实现通用自动化测试软件，演示了 CSM 框架的易用性、复用性以及扩展性。

两个基本概念：

HAL（Hardware Abstract Layer，硬件抽象层）：通过对同种类仪器的接口进行标准化抽象和实现，从而使用相同的接口操作不同厂家的同种仪器；
MAL（Measurement Abstract Layer，测量抽象层）：建立在 HAL 基础上，对测量方法进行抽象。

该框架提供两种自动化测试方式：

基于 TestStand 实现自动化测试：硬件设备（Devices / Third Party Devices）通过标准化接口（AI、AO、DMM、Serial……）接入接口通信层，再经测量方法层完成指令发送+应答采集、多波形采集与特性分析等测试业务；
自动化测试脚本化：可快速实现纯文本的自动化测试调用。脚本示例（片段）：“Write-DBL(1Ch1S) >> Data : 3.000000 -@ VoltageAO”“DUT-OhmLaw >> dev-Volt : VoltageAI ; dev-Amps : CurrentAI ; Signal : c0 -@ MeasResistor”“Write >> PWM:Frequency:20%0A -@ Serial”“ScalarMeasure >> Dev : Scope ; Channel : 0 ; Measurement : 2 -@ ScopeScalar”等，用于多设备协同测试（电压、电阻、PWM、示波器等）。

要点总结：以模块化设计、成熟的测试管理软件及活跃的开源生态为基础；HAL 标准化硬件调用接口，在不同厂商设备之间可以实现硬件的快速替换以及标准化调用；MAL 以 HAL 为基础，实现测试业务中的标准测试过程，编写一次代码即可在不同项目间复用；可快速实现纯文本的自动化测试调用。

案例四：gRPC 调用封装——汽车 HIL 故障注入系统

汽车 HIL 故障注入系统使用 LabVIEW 开发，需要增加 gRPC 远程调用接口，从而帮助客户实现跨平台、跨语言的远程自动化控制。gRPC 是一个高性能、跨语言、跨平台的远程过程调用（RPC）框架。配合 CSM 框架与 gRPC-LabVIEW 自动代码生成功能（开源：github.com/ni/grpc-labview），可以快速、高效地为 LabVIEW 应用程序添加 gRPC 远程调用封装。

CSM 在该案例中的作用：

CSM 独立模块在其他编程框架中易于调用，调用方法清晰，外部改动少；
CSM 的工作者模式（Worker Mode）可以以不添加额外代码的方式，提高 gRPC-Executor 模块的并行吞吐量。

系统架构：gRPC Client 通过 gRPC Server 与 ADAS HIL System 的 LabVIEW Application 通信；LabVIEW 侧由 Main / Console / Server Controller 通过 CSM Calls 调度 CSM 模块；gRPC Executor 以 Worker Mode（名称含 #）多实例运行，处理 Service 的 Proto Request & Response，再以 CSM Calls 或 Private Calls 完成内部调用。该案例展示了 CSM 框架的易用性和扩展性。

案例要点速览

表8四个案例要点速览

案例	场景	CSM 体现的核心价值
数据连续采集并保存	连续采集、存储与分析程序模板（已上架 VIPM）	模块独立、模块可替换、接口文档化、MassData 传输大数据
复杂系统组件化及序列化测试	复杂测试系统分解为模块/组件，测试项组合与测试序列化	灵活性、复用性、解耦合；测试文件可编排
通用自动化测试框架	多型号测试任务的标准化自动化测试软件	易用性、复用性、扩展性；HAL/MAL 抽象层；脚本化调用
gRPC 调用封装（汽车 HIL）	为 LabVIEW 应用添加 gRPC 跨平台远程调用接口	易用性、扩展性；Worker Mode 提升并行吞吐量

总结与资源

核心要点回顾

CSM 是 JKISM 的扩展框架：保留字符串消息队列状态机的简单直观，用关键词扩展出同步消息（-@）、异步消息（->）、状态订阅/取消订阅（->/ ->）等模块间通信能力；
高复用框架 = 模块化：通过调度 API、操作 API、状态接口三类接口隔离模块，配合消息、错误处理、停止三类内部机制，实现模块独立、可替换、可文档化分工；
参数体系完备：Safe String、Hex String、Error String、MassData、API String、INI-Static-Variable 覆盖从简单字符串到大波形数据的传输场景，且支持脚本化（纯文本调用）；
高级模式实用：Worker Mode（#）提升并行吞吐量、Chain Mode（$）实现优先级责任链、Side-loop 处理阻塞性旁路工作；
选型参考：与 DQMH、SMO、Actor Framework 相比，CSM 无 OOP、代码集中度高、适合序列化操作与 RTOS，但工具/资料生态尚待完善，字符串消息存在转换开销；
案例验证：连续采集保存、复杂系统组件化序列化测试、通用自动化测试框架（HAL/MAL）、gRPC 远程调用（汽车 HIL）四个案例，覆盖了 CSM 从简单到复杂的应用场景。

资源	地址	用途
JKI State Machine	github.com/JKISoftware/JKI-State-Machine	CSM 的底层基础框架（预读资料）
Introduction to DQMH	www.ni.com 官网检索（NICONNECT 2023 资料）	了解 DQMH 框架（预读资料）
Communicable State Machine	github.com/NEVSTOP-LAB/Communicable-State-Machine	CSM 框架主仓库，含 Wiki 与 Development Plan
CSM Continuous Measurement and Logging	github.com/NEVSTOP-LAB/CSM-Continuous-Meausrement-and-Logging	案例一源码；VIPM Community 可安装模板
gRPC-LabVIEW	github.com/ni/grpc-labview	gRPC 自动代码生成（案例四）