news 2026/6/23 5:54:09

Simulink模型转.so实战:高效部署到Qt项目的操作指南

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Simulink模型转.so实战:高效部署到Qt项目的操作指南

Simulink模型转.so实战:高效部署到Qt项目的操作指南

  • 1、背景
    • 1.1 方案对比
    • 1.2 方案选择
  • 2、实践操作
    • 2.1 创建单独的文件夹进行管理
    • 2.2 创建CMakelists
    • 2.3 编译输出so文件
    • 2.4 查看对应的so发布件
    • 2.5 windows平台生成lib
    • 2.6 Qt工程中适配.pro文件
    • 2.7 编译运行
  • 3、总结
    • 3.1 改进项
    • 3.2 启发

1、背景

众所周知,simulink可视化程度高,常常用于各类电气模型建模,极大方便主流电网场景的建模仿真模拟。这些模型要应用到实际场景中,例如部署到控制程序里面,simulink提供转化C接口代码,可以直接将模型直接输出纯C代码,以供外部工程调用相关接口进行使用。

1.1 方案对比

关于将Simulink模型导出的C接口适配到工程中,业界主要采用以下两种方案:

  1. 库文件集成方案:将Simulink生成的C代码编译为静态库(.lib)或动态库(.so),工程通过链接库的方式调用功能。
  2. 源码集成方案:直接将Simulink生成的C源代码整合到工程代码库中,与其他源代码一同编译构建。
方案编号优点缺点
11、代码架构策略与业务解耦,整洁度高;
2、编译速度快;
3、安全性高,可以不用向外部提供核心控制算法;
4、方便当前项目代码架构管理;
5、方便后续策略升级维护,只需要替换so即可
1、需要额外适配CMakelists或者Makefie等;
2、软件debug调试无法进行跟踪到源码,全靠simulink转换代码的正确性;
3、外部工程需要进行特殊适配,例如Qt工程需要适配.pro
21、具有较强的调试便利性;
2、适配工作量相对较少,对项目原工程改动少;
3、编译简单,较容易实现
1、引入simulink代码破坏原先代码架构,不利于管理;
2、编译负担增重,降低编译效率;
3、依赖项复杂。必须手动在 .pro 文件里包含大量 MATLAB 预定义的宏和系统头文件。

1.2 方案选择

综上对比,考虑后续软件代码架构、维护、项目管理等因素,选用方案1进行操作实践。

2、实践操作

2.1 创建单独的文件夹进行管理

将simulink导出来的纯C代码都放在一个目录下,为了方便代码管理,与工程源代码分开新建目录进行保存。此时目录下应该只有.c和.h文件,其他文件可以清除掉。

2.2 创建CMakelists

我本地linux和windows均已安装CMakeLists,为了方便工程验证,采用CMakeLists+make这一套进行编译。CMakeLists内容如下,可供参考:

cmake_minimum_required(VERSION 3.10)project(simtarget C)set(CMAKE_C_STANDARD 11)# === 重新开启函数符号的自动导出 (对函数有效) ===if(WIN32)set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)endif()set(SIM_SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR})add_library(simtarget SHARED ${SIM_SRC_DIR}/*.c#这里可以替换成你想要的.c文件)target_include_directories(simtarget PUBLIC ${SIM_SRC_DIR})set_target_properties(simtarget PROPERTIES LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}OUTPUT_NAME LowVolStrategy)

可以根据自己的实际情况修改,可以指定自己想要编译的核心策略对应的.c文件。为了方便我自己在Windows下也能正常进行编译调试,这个CMakeLists同样适用于windows环境(我本地采用VS 2022进行编译),真正地实现跨平台开发与调试。

2.3 编译输出so文件

编译输出就是常规的指令执行即可:

mkdir build cd build cmake..make

执行结果如下:

到这一步说明执行成功!

2.4 查看对应的so发布件

查看当前build目录下是否生成对应的so发布件,如果有,说明编译成功~

2.5 windows平台生成lib

同理先在windows下进行cmake编译:

然后用VS 2022打开对应sln文件进行编译:

windows是生成对应的依赖库如下:

2.6 Qt工程中适配.pro文件

在对应的编译路径下添加新增的依赖库,记得也需要把头文件路径也包含进去:
windows下添加:

INCLUDEPATH+=$$PWD/alg/lowVolStrategy/#对应头文件目录LIBS+=-L$$PWD/lib/alg-lLowVolStrategy win32:!win32-g++: PRE_TARGETDEPS+=$$PWD/lib/alg/LowVolStrategy.lib

linux下添加:

INCLUDEPATH+=$$PWD/alg/lowVolStrategy/#对应头文件目录LIBS+=-L$$PWD/lib/alg-lLowVolStrategy

2.7 编译运行

编译程序,执行成功~

3、总结

3.1 改进项

  1. simulink转换纯C代码,说实话可读性比较差,不建议对源文件进行直接修改;因为修改源文件的话,后续重新生成C代码又得重新适配,所以能够通过上层工程进行编译改进是最好的方式;
  2. simulink的代码存在大量的全局接口、变量等,如果涉及到与外部的合作,其实是需要包装一层再对外暴露的,相当于自己实现业务适配层,但我觉得是有必要的,这样业务跟策略能够更好的解耦;
  3. 涉及跨平台的场景,尽量将CMakeLists等做得更通用一些,比如我前面介绍的那样;

3.2 启发

1、想到什么有时间就立马去做,越早尝试,越早发现问题
2、一次性把事情做对,先不求做到最好,但一定往最好的方向不断靠近;
3、不断思考如何让工程架构更好、更优、更易于维护,有时候突破也不是要从0到1,也可以每次都比之前更优、更好、操作更便捷~

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/6/23 3:58:33

官方适配完的命令行ruby在鸿蒙PC上的使用方法

ohos-ruby 是为 OpenHarmony 平台编译的 Ruby 编程语言解释器。本文档详细介绍如何在鸿蒙PC上安装和使用官方适配完成的 Ruby 工具,包括 HNP 包的打包、安装、gem 包管理以及 Ruby 脚本的运行方法。 📋 目录 一、项目概述二、为什么需要 HNP 包三、HNP …

作者头像 李华
网站建设 2026/6/23 19:18:57

LobeChat能否接收语音指令?全双工对话体验

LobeChat能否接收语音指令?全双工对话体验 在车载语音助手说出半句话就被打断、智能家居听不清命令反复确认的今天,我们对“真正自然”的人机对话期待已久。理想中的AI助手应该像真人一样——你能随时插话,它也能边说边听,而不是等…

作者头像 李华
网站建设 2026/6/23 14:19:15

LangFlow快速入门:可视化构建AI应用

LangFlow快速入门:可视化构建AI应用 在生成式AI浪潮中,开发者常常面临一个现实困境:想法很清晰,落地却耗时漫长。即便使用了LangChain这样的强大框架,编写和调试多模块协同的LLM流程依然需要大量编码工作。有没有一种…

作者头像 李华
网站建设 2026/6/23 15:07:35

Langflow本地部署:隔离环境安装指南

Langflow本地部署:隔离环境安装指南 在快速迭代的 AI 应用开发中,如何高效验证一个 LLM 工作流的想法?写一堆胶水代码?反复调试导入错误?还是手动管理几十个依赖版本? 其实,你完全可以用拖拽的…

作者头像 李华
网站建设 2026/6/22 20:26:27

云端算力的进化:云服务器架构演进的三重范式变革

在数字化转型的浪潮中,云服务器作为云计算的核心基础设施,正经历着从被动响应到智能协同的跨越式进化。从传统虚拟化到云原生架构,这场静默的技术革命重构了算力释放方式,推动行业向更高效、更智能的方向迈进。云服务器的架构演进…

作者头像 李华
网站建设 2026/6/23 16:50:31

解决facefusion报错No source face detected

解决 FaceFusion 报错:No source face detected 在使用 FaceFusion 进行人脸替换时,你是否曾满怀期待地运行命令,结果却只等来一句冰冷的提示: No source face detected程序戛然而止,换脸流程中断。这并非模型崩溃或内…

作者头像 李华