武器挂载点建模：挂架数据结构设计、挂载点状态机、武器类型枚举与属性定义

好，咱们接着往下聊。上一章我们把武器管理的顶层架构搭起来了，这一章要深入到底层——挂载点建模。

说白了，挂载点就是飞机上那些挂武器的“钩子”。但你别小看这个“钩子”，它背后涉及的数据结构、状态流转、类型定义，直接决定了整个火控系统能不能正确识别、管理和发射武器。

我个人习惯，在设计任何嵌入式系统时，先把数据模型想清楚。数据模型稳了，后面的逻辑代码就是“填空”。

挂架数据结构设计

先看一个典型的挂架结构体。我在某型战机的火控升级项目中，就遇到过因为数据结构设计不合理，导致挂载点编号混乱、武器类型匹配出错的问题。后来我重新设计了这套结构，才把问题彻底解决。

// 挂架数据结构
typedef struct {
    uint8_t     rack_id;            // 挂架编号 (1-12)
    uint8_t     station_id;         // 站位编号 (物理位置)
    RackType    rack_type;          // 挂架类型 (重型/轻型/复合)
    RackStatus  status;             // 当前状态
    WeaponNode  *p_weapon;          // 指向挂载的武器节点
    uint32_t    max_weight_kg;      // 最大承重 (kg)
    uint8_t     max_stores;         // 最大挂载数量
    uint8_t     current_stores;     // 当前挂载数量
    uint16_t    bus_address;        // 总线地址 (MIL-STD-1553)
    uint8_t     power_rail;         // 供电线路编号
    uint8_t     signal_cond;        // 信号调理通道
} RackDescriptor;

这里有几个关键点我要强调一下：

• rack_id vs station_id：rack_id是逻辑编号，station_id是物理位置。为什么要分开？因为挂架可以互换位置，但逻辑编号不变。我曾经见过一个项目把这两个混在一起，结果换挂架后整个武器管理逻辑全乱了。
• p_weapon指针：指向武器节点，而不是直接内嵌武器数据。这样设计的好处是，一个武器可以挂在不同挂架上，只需要改指针，不需要复制数据。
• bus_address：1553总线地址。每个挂架在总线上都有独立地址，火控计算机通过这个地址下发指令。

挂载点状态机

挂架不是一成不变的。从挂弹到发射，中间要经历好几个状态。我习惯用状态机来管理，这样逻辑清晰，不容易出bug。

嗯，这里要注意：状态机的设计要覆盖所有可能的路径，包括异常情况。我曾经在测试中发现，如果挂架在“挂弹中”状态突然断电，恢复后状态就乱了。后来我加了一个“状态恢复”机制，才解决这个问题。

typedef enum {
    RACK_EMPTY          = 0x00,  // 空载
    RACK_LOADING        = 0x01,  // 挂弹中
    RACK_LOADED         = 0x02,  // 已挂载
    RACK_ARMING         = 0x03,  // 解保中
    RACK_ARMED          = 0x04,  // 已解保
    RACK_LAUNCHING      = 0x05,  // 发射中
    RACK_LAUNCHED       = 0x06,  // 已发射
    RACK_JETTISONING    = 0x07,  // 应急抛射中
    RACK_JETTISONED     = 0x08,  // 已抛射
    RACK_FAULT          = 0xFF   // 故障状态
} RackStatus;

状态转换规则如下：

当前状态	触发事件	下一状态	说明
RACK_EMPTY	挂弹指令	RACK_LOADING	开始机械挂载
RACK_LOADING	挂载完成	RACK_LOADED	电气连接确认
RACK_LOADED	解保指令	RACK_ARMING	解除保险
RACK_ARMING	解保完成	RACK_ARMED	可发射状态
RACK_ARMED	发射指令	RACK_LAUNCHING	点火/投放
RACK_LAUNCHING	发射完成	RACK_LAUNCHED	武器离架
RACK_LAUNCHED	复位指令	RACK_EMPTY	准备下一轮
任意状态	故障检测	RACK_FAULT	异常处理

武器类型枚举与属性定义

武器类型枚举，说白了就是给每种武器一个“身份证号”。但光有编号不够，还得有属性描述——重量、长度、制导方式、战斗部类型等等。

你想想看，如果火控系统不知道武器的重量，怎么计算飞机的重心变化？如果不知道制导方式，怎么选择发射时机？

// 武器类型枚举
typedef enum {
    WPN_AIM_120      = 0x01,  // 中距空空导弹
    WPN_AIM_9X       = 0x02,  // 近距格斗弹
    WPN_AGM_65       = 0x03,  // 空地导弹
    WPN_GBU_31       = 0x04,  // 精确制导炸弹
    WPN_MK_82        = 0x05,  // 普通航弹
    WPN_AGM_88       = 0x06,  // 反辐射导弹
    WPN_JSOW         = 0x07,  // 联合防区外武器
    WPN_AMRAAM_ER    = 0x08,  // 增程型中距弹
    WPN_IRIS_T       = 0x09,  // 红外制导空空弹
    WPN_CUSTOM       = 0xFF   // 自定义武器
} WeaponType;

// 武器属性结构体
typedef struct {
    WeaponType      type;               // 武器类型
    uint16_t        weight_kg;          // 重量 (kg)
    uint16_t        length_mm;          // 长度 (mm)
    uint16_t        diameter_mm;        // 直径 (mm)
    GuidanceType    guidance;           // 制导方式
    WarheadType     warhead;            // 战斗部类型
    uint16_t        range_km;           // 最大射程 (km)
    uint8_t         max_overload_g;     // 最大过载 (G)
    uint8_t         launch_angle_min;   // 最小发射角 (度)
    uint8_t         launch_angle_max;   // 最大发射角 (度)
    uint16_t        safe_arm_time_ms;   // 解保时间 (ms)
    uint8_t         bus_id;             // 总线ID
    uint8_t         weapon_id;          // 武器自身编号
} WeaponDescriptor;

这里有个细节：guidance和warhead也是枚举类型。我习惯把它们单独定义，方便扩展。

typedef enum {
    GUIDANCE_INERTIAL,      // 惯性制导
    GUIDANCE_SEMI_ACTIVE,   // 半主动雷达
    GUIDANCE_ACTIVE_RADAR,  // 主动雷达
    GUIDANCE_IR,            // 红外制导
    GUIDANCE_LASER,         // 激光制导
    GUIDANCE_GPS,           // GPS制导
    GUIDANCE_ANTI_RADIATION // 反辐射
} GuidanceType;

typedef enum {
    WARHEAD_BLAST,          // 爆破
    WARHEAD_FRAG,           // 破片
    WARHEAD_PENETRATOR,     // 穿甲
    WARHEAD_SHAPED_CHARGE,  // 聚能
    WARHEAD_NUCLEAR,        // 核
    WARHEAD_INERT           // 惰性 (训练弹)
} WarheadType;

挂载点与武器的关联

有了挂架数据结构和武器属性定义，接下来就是怎么把它们关联起来。我通常用一个“挂载表”来管理：

// 挂载表 - 每个挂架一个条目
typedef struct {
    RackDescriptor      rack;           // 挂架描述
    WeaponDescriptor    *weapon;        // 指向武器描述
    uint8_t             rail_position;  // 导轨位置 (复合挂架用)
    uint8_t             release_priority; // 发射优先级
    uint32_t            load_time_ms;   // 挂载时间戳
    uint32_t            last_maintenance; // 最后维护时间
} StoreStation;

这个结构体把挂架和武器“绑定”在一起。其中release_priority很重要——它决定了武器发射的顺序。比如，为了保持飞机平衡，你可能需要先发射左侧的武器，再发射右侧的。

我记得有一次在仿真测试中，就是因为优先级设置错误，导致飞机在连续发射后重心偏移过大，差点失控。从那以后，我对优先级算法格外小心。

实战中的注意事项

最后，分享几个我在项目中踩过的坑：

• 挂架编号不要从0开始：飞行员习惯从1开始数，你从0开始容易造成沟通误解。我一般用1-12。
• 状态机要加超时处理：比如挂弹中状态，如果5秒内没完成，自动切到故障状态。否则挂架会一直卡在中间状态。
• 武器属性要固化：不要在运行时动态修改武器属性。所有属性应该在系统初始化时从数据库加载，运行中只读。
• 考虑复合挂架：一个挂架可以挂多枚武器（比如双联装、三联装）。这时候rail_position字段就派上用场了。

下一章，我们会讨论武器选择逻辑——当飞行员按下“发射”按钮时，系统如何决定发射哪枚武器。那才是真正考验算法设计的地方。