3. 协同工程中的系统架构设计

在多学科模型协同工程中，系统架构设计承担着“把需求翻译成可分工、可验证、可集成的结构”的职责。它并不是画一张漂亮的框图，而是要在功能、逻辑、物理三个抽象层级之间建立可追溯的映射关系，并把学科之间的接口、参数、约束显式化。架构一旦确定，各学科团队的建模边界、交付物格式和集成顺序也随之确定。因此，架构设计质量直接决定了后续协同建模的返工率。

基于模型的系统架构框架

基于模型的系统架构框架通常以四层视图组织：需求视图、功能视图、逻辑视图、物理视图。需求视图记录利益相关者需求与系统需求，并给出唯一标识（如 REQ-001）；功能视图描述系统“做什么”，用功能分解与功能流表达；逻辑视图描述“由哪些逻辑组件协作完成”，关注职责分配与信息交互；物理视图描述“用什么实体实现”，关注材料、尺寸、功率、重量等工程参数。四层之间通过分配关系（allocate）和满足关系（satisfy）连接，形成可追溯链路。

在工具层面，SysML 的模块定义图（BDD）、内部模块图（IBD）、活动图、参数图分别支撑上述视图。协同工程的关键在于：这些模型不是某一个学科私有的，而是跨学科共享的“架构基线”。架构基线一旦冻结，各学科在其下开展详细设计；若需变更，必须走变更影响分析流程。

功能-逻辑-物理架构分解

功能分解从系统级功能出发，逐层拆解到可分配的子功能。以纯电动车为例，顶层功能“提供驱动力”可分解为“电能转换”“扭矩输出”“扭矩调节”三个子功能。分解的停止条件是：子功能能够被单一逻辑组件承担，且其输入输出可以用明确的物理量描述。

逻辑分解把功能分配给逻辑组件，并定义组件之间的交互。逻辑组件是“职责的载体”，不涉及具体实现。例如“电机控制器”承担“电能转换”和“扭矩调节”两个功能，它向“电机”输出三相电流指令，从“电池管理系统”接收可用功率限值。逻辑视图的核心交付物是内部模块图（IBD），其中每个端口（port）对应一个交互点。

物理分解把逻辑组件映射到具体实体，并赋予工程参数。例如“电机控制器”映射为“SiC 逆变器”，其关键参数包括开关频率 20 kHz、效率 98.5%、冷却方式液冷。物理视图必须与逻辑视图保持一一对应或明确的多对一关系，否则集成阶段会出现“功能无人认领”或“实体重复实现”的问题。

三层分解的追溯关系可以用分配矩阵表达。矩阵的行是功能，列是逻辑组件或物理实体，交叉点标记分配关系。当某个功能没有对应逻辑组件时，矩阵出现空行，提示架构不完整；当某个逻辑组件没有承担任何功能时，出现空列，提示冗余设计。

多学科接口定义

接口定义是协同工程中最容易出问题的环节。接口分为三类：物理接口（机械安装点、管路接头、线束连接器）、能量接口（电功率、热功率、流体流量）、信息接口（信号、总线报文、控制指令）。每类接口都需要定义方向、量纲、范围、更新率和容差。

以电池包与整车控制器的信息接口为例，需要定义：信号名称“BMS_AvailablePower”、方向“BMS → VCU”、量纲“kW”、范围“0～150”、更新率“10 ms”、容差“±2%”。这些定义必须写入接口控制文档（ICD），并由双方学科负责人签字确认。ICD 是架构基线的一部分，任何变更都需要重新评审。

接口定义还应包含“接口失效模式”。例如冷却液接头泄漏时，热管理模块应能检测流量异常并上报故障码；高压连接器断开时，电池管理系统应在 100 ms 内切断主继电器。这些失效响应逻辑属于架构级设计约束，必须在分解阶段就分配给相应逻辑组件。

架构权衡方法

架构权衡是在多个候选方案之间做选择的过程。常用的方法包括：加权评分法、Pugh 矩阵、多目标优化。以“电池包冷却方案”为例，候选方案有风冷、液冷、相变材料冷却三种。评价准则包括：散热能力、重量、成本、可靠性、维护性。权重根据需求优先级确定，例如散热能力权重 0.35，重量 0.25，成本 0.20，可靠性 0.15，维护性 0.05。

评分采用 1～5 分制，1 分最差，5 分最优。风冷方案散热能力 2 分、重量 5 分、成本 5 分、可靠性 4 分、维护性 5 分，加权总分 = 2×0.35 + 5×0.25 + 5×0.20 + 4×0.15 + 5×0.05 = 0.70 + 1.25 + 1.00 + 0.60 + 0.25 = 3.80。液冷方案散热能力 5 分、重量 3 分、成本 3 分、可靠性 4 分、维护性 3 分，加权总分 = 1.75 + 0.75 + 0.60 + 0.60 + 0.15 = 3.85。相变材料方案散热能力 3 分、重量 4 分、成本 2 分、可靠性 3 分、维护性 4 分，加权总分 = 1.05 + 1.00 + 0.40 + 0.45 + 0.20 = 3.10。液冷方案以微弱优势胜出，但需注意其成本与维护性得分较低，若成本权重提高到 0.30，则风冷方案可能反超。这说明权重设置对结果敏感，必须由利益相关者共同确认。

架构权衡还应考虑“接口兼容性”。例如选择液冷方案后，电池包需要增加进出液口，整车需要增加冷却回路，热管理模块需要增加水泵和换热器。这些新增接口会改变逻辑视图和物理视图，因此权衡决策必须同步更新架构模型，保持四层视图一致。

架构基线与协同流程

架构设计的最终交付物是“架构基线”，包含：四层视图模型、接口控制文档、权衡分析报告、分配矩阵。基线冻结后，各学科在基线约束下开展详细设计。协同流程通常按以下顺序推进：架构组发布基线 → 各学科认领逻辑组件和接口 → 学科内部详细建模 → 接口联调 → 集成验证。若学科发现基线存在冲突，应提交变更请求（ECR），由架构组评估影响范围后决定是否修订基线。

在实际项目中，架构基线不是一次成型的。通常先发布“初版基线”用于启动学科建模，再根据学科反馈迭代 2～3 轮，最终冻结为“正式基线”。每轮迭代都应记录变更内容、影响范围和决策依据，形成可追溯的架构演进历史。这样，当后期出现集成问题时，可以快速定位是架构定义缺陷还是学科实现偏差。