4. 识别系统边界与外部接口
系统边界不是画在图纸上的一条装饰线，而是决定“谁负责、谁不负责”的工程契约。在SysML建模中，边界一旦确定，内部模块的职责分配、接口的归属、验证的范围都会随之收敛。本节的任务是：从用例和需求出发，把系统上下文（System Context）定义清楚，并提取出外部参与者、外部系统与顶层接口清单，为后续的接口架构设计提供输入。
一、系统边界的三层含义
在工程实践中，“边界”至少包含三层含义，缺一不可：
- 职责边界：系统承诺完成的功能集合，通常由用例描述。边界之外的功能由外部参与者或外部系统承担。
- 物理边界：系统实际占据的硬件/软件载体范围，例如一个车载域控制器、一套地面站软件。
- 接口边界：系统与外部交换能量、物质、信息的连接点集合，是本节要提取的核心对象。
三者不一定重合。例如，一个“自动驾驶域控制器”的职责边界包含感知融合与轨迹规划，但物理边界可能只包含计算板卡，而摄像头、雷达属于外部系统，通过接口边界与它相连。建模时必须明确：接口边界上的每一个连接点，都对应一个需要被管理的顶层接口。
二、从用例提取外部参与者
用例图是识别外部参与者的第一手资料。做法是：把系统画成一个矩形（System Under Design，SUD），所有与它交互的人、设备、系统都放在矩形之外，用关联线连接。每一条关联线都暗示一个潜在的接口。
以一个“无人机地面控制站”为例，从用例“规划航线”“监控飞行状态”“上传任务”“接收遥测”出发，可以识别出以下外部参与者：
- 操作员（人）：通过显控界面输入航线、查看状态。
- 无人机飞控系统（外部系统）：接收任务、回传遥测。
- 差分GPS基准站（外部系统）：提供RTCM差分改正数。
- 气象数据服务（外部系统）：提供风场与能见度信息。
注意区分“参与者”与“外部系统”：参与者可以是人、组织或外部系统；而外部系统通常指具有独立接口、可被单独建模的工程实体。在SysML中，两者都可以用Actor或外部Block表示，但外部系统往往需要进一步展开其接口。
三、从需求补充边界约束
用例给出的是“交互意图”，需求则给出“交互约束”。以下需求类型会直接影响边界与接口清单：
- 性能需求：如“遥测更新率不低于5Hz”，决定接口的周期与带宽。
- 安全需求：如“任务上传需双向认证”，决定接口的安全机制。
- 环境需求：如“工作温度-40℃~+70℃”，可能决定接口的物理介质。
- 法规需求：如“符合DO-178C”，决定接口数据的完整性等级。
把这些需求逐条映射到边界上，就能判断哪些接口是“必须显式定义”的，哪些可以合并或省略。例如，若需求规定“遥测数据必须加密”，则遥测接口必须包含加密算法与密钥管理两项子接口，而不能只写一个“遥测下行”。
四、顶层接口清单的提取方法
顶层接口清单是本节最直接的交付物。推荐按“参与者—交互—接口”三层展开：
- 列出所有外部参与者与外部系统。
- 对每个参与者，列出它与系统之间的交互项（数据、能量、物质）。
- 对每个交互项，定义接口名称、方向、介质、协议、周期/触发方式、数据内容。
下表给出无人机地面控制站的顶层接口清单示例（参数为教学假设，非实测值）：
| 接口编号 | 接口名称 | 外部对象 | 方向 | 介质/协议 | 周期/触发 | 主要数据 |
|---|---|---|---|---|---|---|
| IF-01 | 任务上传 | 无人机飞控 | 出 | 无线电信道 / MAVLink | 事件触发 | 航点序列、速度、高度 |
| IF-02 | 遥测下行 | 无人机飞控 | 入 | 无线电信道 / MAVLink | 5Hz周期 | 位置、姿态、电量 |
| IF-03 | 差分改正数 | 差分GPS基准站 | 入 | 串口 / RTCM 3.x | 1Hz周期 | 伪距改正、载波相位改正 |
| IF-04 | 气象数据 | 气象服务 | 入 | 以太网 / HTTP+JSON | 10min周期 | 风速、风向、能见度 |
| IF-05 | 操作员指令 | 操作员 | 入 | 人机界面 / 键鼠 | 事件触发 | 航线编辑、模式切换 |
| IF-06 | 状态显示 | 操作员 | 出 | 人机界面 / 图形 | 10Hz刷新 | 飞行态势、告警 |
清单中的每一行，后续都应能在SysML中对应到一个接口块（Interface Block）或流端口（Flow Port）。方向定义必须统一：本文约定“出”表示数据从系统流向外部，“入”表示从外部流入系统。若切换参照系，必须显式说明。
五、系统上下文图与接口关系
把上述内容整合成一张系统上下文图，是本节最值得可视化的成果。下图以无人机地面控制站为中心，展示外部参与者、外部系统与顶层接口的方向和介质关系。图中每个接口编号与上表一致，便于对照检查。
对照上图与接口清单，可以检查三件事：第一，每个外部对象是否至少有一条接口线；第二，每条接口线是否有编号、方向与介质；第三，是否存在“有交互但无接口”的遗漏，例如操作员与系统之间除了指令和显示，是否还有告警确认、日志导出等交互。遗漏的接口在后续集成阶段往往表现为“未定义行为”，是排障成本最高的缺陷来源。
六、边界评审的检查要点
完成初稿后，建议用以下问题做一次边界评审：
- 系统边界内是否包含了不该由本系统承担的功能？例如把“气象数据解析”放在系统内，而它本可由外部服务完成。
- 外部参与者是否被误当作内部模块？例如把“操作员”建模为系统内部的一个Block。
- 接口方向是否与数据流一致？是否存在“只定义了下行、没有定义上行”的单向遗漏。
- 接口的周期与需求中的性能指标是否匹配？例如需求要求5Hz，接口却定义为1Hz。
- 安全与加密需求是否落到具体接口上，而不是停留在系统级描述。
本节交付的顶层接口清单，将直接作为下一阶段接口架构设计的输入。清单中的每个接口编号，后续都应能在SysML模型中追溯到对应的接口块、端口和流属性，形成从需求到实现的完整链路。