企业官网建设流程全解析

一枚火箭被送到了21.5 km的高度，创下业余火箭的高度纪录。托住这次发射的，是一套用 LabVIEW 和 CompactRIO 搭起来的地面控制系统。

火箭地面测发控系统与传感器网络，LabVIEW 界面监测加注参数与时序

01 挑战：点火前的每个动作，都只有一次机会

目标是造出一枚从设计、制造到发射全部自主完成的火箭，最终飞向太空。作为通往这个目标的中间一步，一枚火箭被研制出来，并送到了 21.5 km 的高度。

火箭本身很复杂。对系统的要求只有一条：所有系统都必须尽可能可靠，因为这里几乎没有犯错的空间。

真正难的，是地面上的那一半。发动机试车和正式发射期间，人不能待在火箭旁边，所有加注、监测、点火动作都必须远程完成。需要一套地面控制系统（GCS），它要能跟火箭通信，采集发动机压力、火箭重量、错误信息等子系统状态数据，把这些数据回传到远程工作站，同时还要执行对试验或发射成败至关重要的时间关键任务。

除此之外还有两条硬约束：系统必须模块化，随时能按新需求改造或扩展；同时必须足够坚固，因为它会被放在发射和试车的极端环境里。可靠性在这里不是一个指标，而是所有操作安全的前提。

02 难点不在采集，在"时间关键"四个字

先看被控对象。这枚火箭用的是一台混合动力发动机，以液态一氧化二氮作氧化剂，燃烧固体燃料药柱。它的峰值推力达到 12 kN，足以抬起一辆汽车；设计工作时间 25 s，平均推力 8 kN，总冲量 180 kN。

围绕这台发动机，GCS 要控制的是一整套供应系统：7 个阀门，覆盖加注、点火、主工作、熄火等动作。要读的传感器也不少：

• 2 个称重传感器，分别测氧化剂贮箱的质量和发动机产生的推力；
• 压力传感器，测氧化剂供应压力、供应系统状态和发动机工作时的燃烧压力；
• 8 支热电偶，获取燃烧室的热状态，用来发现燃烧过程中的热问题；
• 继电器触点传感器，监测执行机构控制回路的通断，以便发现执行子系统里可能出现的任何失效。

称重和压力传感器都采用高采样率，目的是捕捉试车过程中可能出现的不稳定现象。

软件要做的事，才是真正的难点：

1.自动化的飞行前/试车前系统检查——验证发动机点火流程的完整功能，发现并定位执行机构的故障；
2.氧化剂贮箱加注与增压——在所有系统就位、发射台人员清空之后才开始；
3.时间关键的发动机启动时序——操作员发起后由软件执行：点火药激活、燃烧室预充、打开主阀。这三步中任何一步没有在规定时间窗内完成，发动机就会点火失败；
4.时间关键的运行中诊断——在发动机工作期间实时监测压力与温度，通过实时处理数据发现可能的故障并立即关机；
5.紧急关机时序——发动机工作异常时执行。

注意第 3 条和第 4 条。这类动作的容错窗口是以时间计的，通信延迟、数据的先后顺序、一次漏读，都可能直接变成一次失败的点火，或者一次该关没关的关机。这才是选平台时真正要回答的问题。

03 方案：把时间关键的任务交给 CompactRIO，把判断留在界面

最终以 CompactRIO 为核心搭起了整套 GCS，围绕它建起一整套电气系统，重点就放在整体的坚固性上。

分工是这样的：传感器和执行机构直接接到 CompactRIO 上，由它完成高采样率的数据采集和实时控制动作；用 LabVIEW 编写的监控软件负责把数据取回来、处理，并发出实时控制指令。

到了发射阶段，任务集合变了——GCS 要跟火箭通信，做的是和试车阶段完全不同的一套事情。应对方式是在软件上做扩展：实现了自研的 Launch-Box 协议和一套类寄存器的内存映射，让 GCS 能与其他所有子系统通信，并把信息路由到控制面板。协议跑在 RS232 串口上，用 LabVIEW 实现。

值得一提的是调试。在实现 Launch-Box 协议时，LabVIEW 的调试功能支持在报文编码和解码的每一步查看消息字符串——协议实现恰恰是最容易藏 bug 的地方。

04 结果

两年时间里，一共做了14 次发动机试车，在一次次的失败和改进中迭代：燃烧室热失效、燃烧不稳定等问题都被逐一克服。最后一次试车时，发动机工作了 23 s 后燃料耗尽，燃烧室因为壁面直接暴露在高温火焰中而破裂——但那已经是所有问题被解决之后的一次极限工况。

在整个试车过程中，GCS 证明了它是一套高度坚固、可靠的系统。它带来的直接好处是：精力可以放在解决发动机的故障模式上，而不是去修有问题的电路。软件也能很快适配新需求，LabVIEW 界面则让发动机状态一目了然，用起来清晰、简单、易用。

发射阶段，三周时间完成了所有系统和载荷的测试与集成。模块化架构再一次体现出价值：硬件改动可以很快、很顺利地完成。最终火箭顺利升空，抵达 21.5 km。

最有说服力的是时间账：从开发开始到一套完整、可用、坚固、模块化的系统，只用了4 个半月。而如果从零自研一套 GCS，设计、搭建和测试软硬件至少需要10 到 11 个月。也就是说，开发时间缩短了一半以上。

05 这类项目能给我们什么启示

先分清哪些动作"必须当场完成"

时间关键的时序和联锁应该留在控制器本地闭环执行，通信链路只负责传状态和指令。把安全动作押在链路上，风险不可控。

模块化是保命项，不是加分项

试车和发射是两套差别很大的需求。选平台时先问一句：需求变了，改一次要多久，要不要推倒重来。

调试工具要算进选型成本

协议和时序这类代码的 bug 最难在现场复现。能逐步查看报文编解码过程，省下的是最贵的排故时间。

界面也是可靠性的组成部分

现场没人有耐心翻日志。状态看得清，异常才判断得快，这是提前暴露风险最便宜的手段。

06 写在最后

小团队做复杂系统，选对平台比堆人力更管用。在同样的人手规模下，用对了开发方式，交付周期能从十个月压到四个半月——这个差距，在预算和窗口期都紧张的工业项目里同样成立。

我们专注 LabVIEW 软件开发与测试测量系统集成，从硬件选型、方案设计到现场交付调试，提供一站式服务。像这类传感器多、时序严、还得在现场一次做对的测控系统，正是我们每天在做的事。有需求欢迎在评论区留言；身边朋友有类似项目，也欢迎帮忙引荐。