2. 功能架构设计基础
在MBSE（基于模型的系统工程）中，功能架构是连接需求与物理实现的桥梁。要建立可验证、可追溯的功能架构，首先必须厘清四个基础概念：功能、行为、接口、流。它们不是同义词，而是从不同视角描述系统“做什么”的互补维度。
功能回答“系统要完成什么任务”，是对系统能力的抽象声明，通常用“动词+名词”表达，例如“提供制动力”“调节舱内温度”。功能是需求分配到架构的载体，具有层级性，可逐级分解。行为回答“功能如何随时间展开”，强调动作的顺序、触发条件、状态迁移与并发关系。同一个功能可以由不同行为实现，行为是功能的动态视图。接口回答“功能之间在哪里、以什么方式交互”，它定义了交互点、交互协议与约束，包括逻辑接口（信号、数据、能量）和物理接口（机械、电气、热）。流回答“交互中传递什么”，是接口上流动的物质、能量或信息，例如燃油流、电流、控制指令、状态数据。
四者的关系可以概括为：功能通过行为实现，行为通过接口连接，接口承载流。理解这一链条，是避免“功能分解成空壳、接口定义成摆设”的关键。
核心区分：功能是“能力声明”，行为是“时序展开”，接口是“交互契约”，流是“传递内容”。在SysML中，功能常映射为活动或用例，行为映射为活动图/状态机，接口映射为端口与流属性，流映射为流属性与项流。
功能分解与功能层次结构
功能分解是把顶层功能逐级拆解为可分配、可验证的子功能的过程。分解不是随意切分，而应遵循三条原则：完备性（子功能合起来能完整实现父功能）、独立性（子功能之间尽量低耦合）、可分配性（每个叶子功能能明确分配到物理组件或软件模块）。
功能层次结构通常表现为树状：顶层是系统级功能，第二层是子系统级功能，第三层是组件级功能。例如“提供制动力”可分解为“生成制动指令”“传递液压压力”“执行摩擦制动”“调节防滞”。每个子功能再继续分解，直到功能粒度足以直接映射到物理架构中的组件或软件单元。
分解过程中要同步记录功能-行为-接口-流的绑定关系。一个常见错误是只画功能树，不定义行为与接口，导致功能无法验证。正确做法是：每分解出一个叶子功能，就明确它的输入流、输出流、触发条件、执行行为以及对外接口。这样功能架构才具备可执行、可仿真的基础。
功能架构在MBSE中的表达方式与建模语言选择
MBSE中功能架构的表达依赖建模语言。SysML提供了多种图型，选择哪种取决于你要回答的问题：
- 用例图（Use Case Diagram）：适合表达系统与外部参与者的交互边界，回答“系统为谁提供什么服务”。在功能架构早期用于界定系统范围，不用于内部功能分解。
- 活动图（Activity Diagram）：适合表达功能的行为展开，包括控制流、对象流、分叉与汇合、泳道分配。它是功能分解与行为建模的主力图型，能直接映射功能层次与流。
- 状态机图（State Machine Diagram）：适合表达功能在事件驱动下的状态迁移，例如刹车系统的“正常—防滞—故障”状态切换。当功能行为具有明显状态依赖时优先使用。
- 块定义图（Block Definition Diagram）：适合表达功能架构的静态结构，包括功能块、接口块、流属性及其组合关系。它回答“功能由哪些部分构成、彼此如何连接”。
- 内部块图（Internal Block Diagram）：适合表达功能块之间的内部接口与流连接，是接口与流建模的核心图型。
选择原则可以归纳为：先边界、后分解、再行为、最后接口与流。早期用用例图界定系统边界；用活动图做功能分解与行为展开；当行为具有状态依赖时补充状态机图；用块定义图固化功能结构；用内部块图精确定义接口与流。不要试图用一张图表达所有内容，也不要默认所有章节都画流程图——功能架构的本质是结构、行为、接口、流的多视图一致性。
实践建议：在功能分解时，为每个叶子功能建立一张“功能卡”，字段包括：功能名称、父功能、输入流、输出流、触发事件、执行行为、接口端口、分配对象、验证方法。这张卡是功能架构从抽象走向可执行的最小单元。
最后需要强调：功能架构不是一次性完成的静态文档，而是随需求迭代、物理架构细化而持续演进的模型。功能、行为、接口、流四者必须保持追溯一致——任何一个功能变更，都要检查其行为、接口和流是否同步更新。只有做到这一点，功能架构才能真正支撑后续的物理架构分配与验证。