软件架构案例研究（三）——巡航控制 / CIMS / 混合风格架构
来源：田浩然上传的资料 / 0B105-SoftwareArchitecture / Lecture-4 / Case Study 3.pdf 讲师：周立新博士（北京大学软件与微电子学院） 页数：36 页 语言：英文 + 中文混合
概述
本讲是软件架构课程的案例研究第三讲，通过三个不同领域的案例，展示不同架构风格在实际系统中的应用，以及架构风格的选择对设计质量的决定性影响。
三大案例：
- 巡航控制系统（Cruise Control） — 过程控制风格 vs 面向对象风格的对比
- 计算机集成制造系统（CIMS） — 仓库（Repository）风格在企业级系统中的应用
- 混合风格架构（Mixed Styles） — 实际系统往往是多种架构风格的组合
一、巡航控制系统（Cruise Control）
1. 系统概述
巡航控制系统的作用是即使在地形变化的情况下，也能维持汽车的行驶速度。
输入（8项）：
- System on/off — 系统开关
- Engine on/off — 发动机开关
- Pulses from wheel — 车轮脉冲（车速检测）
- Accelerator — 油门信号
- Brake — 刹车信号
- Increase/decrease speed — 提速/降速指令
- Resume speed — 恢复车速指令
- Clock — 时钟信号
输出：
- Throttle — 节气门控制信号
2. 面向对象视图（Object View）
Booch 的面向对象设计将巡航控制系统分解为 9 个对象：
| 对象 | 角色 |
|---|---|
| Driver | 驾驶员（外部交互主体） |
| Clock | 时钟（时间基准） |
| Wheel | 车轮（执行部件） |
| Current speed | 当前速度（计算/存储） |
| Desired speed | 期望速度（目标车速存储） |
| Brake | 制动器 |
| Engine | 发动机 |
| Accelerator | 油门 |
| Throttle | 节气门（控制输出） |
对象间交互：
- Driver → Brake / Desired speed（驾驶员操作刹车、设定速度）
- Clock → Current speed（时钟用于速度计算）
- Wheel → Current speed（车轮信号计算当前速度）
- Desired speed → Throttle（期望速度控制节气门）
- Throttle → Engine / Current speed（节气门调节动力、影响车速）
问题： 面向对象方法将系统分解为真实世界的实体对象，但巡航控制的核心——控制逻辑和时序——在对象模型中被分散和隐藏，不容易从对象图中直接看出系统的控制策略。
3. 过程控制视图（Process-Control View）
过程控制风格将系统建模为闭环反馈控制系统，核心是控制单元和反馈回路。
完整系统组成（5 个模块）：
| 模块 | 功能 |
|---|---|
| State machine for toggle | 切换状态机（巡航启停切换逻辑） |
| Event table for set point | 设定点事件表（目标车速管理） |
| Control unit | 控制单元（核心处理） |
| Clock | 时钟（时序基准） |
| Wheel rotation | 车轮转动（被控对象） |
信号流向：
- 状态机 → 控制单元：激活/停用切换信号
- 事件表 → 控制单元：期望车速
- 时钟 → 控制单元 / 事件表：时序同步
- 控制单元 → 车轮转动：控制输出
4. 激活状态机
巡航控制系统的工作状态机（5 种状态）：
| 状态 | 含义 |
|---|---|
| OFF | 系统完全关闭 |
| Inactive nil | 发动机已启动，巡航未激活、无设定速度 |
| ACTIVE | 巡航激活，正在工作（核心状态） |
| Inactive fast | 临时非激活，车速高于设定值 |
| Inactive slow | 临时非激活，车速低于设定值 |
关键状态切换：
- OFF ↔ Inactive nil：Engine on/off
- Inactive nil ↔ ACTIVE：System on/off
- ACTIVE ↔ Inactive fast：车速超过 / 回落至设定值
- ACTIVE → Inactive slow：踩下刹车（Brake）
- Inactive slow → ACTIVE：Resume 恢复
全局规则： 所有状态在 Engine off 时回到 OFF；除 OFF 外所有状态在 System off 时回到 Inactive nil。
5. 分析与讨论
架构与问题的对应关系：
- 面向对象方法 → 关注对象识别和交互
- 过程控制方法 → 关注反馈回路、控制策略、性能指标
方法论启示：
- 自上而下的设计方法论（top-down methodology）
- 系统修改的便利性：过程控制风格下修改控制策略更直接
性能（Performance）： 系统响应控制的三种策略
- On/Off control — 开关控制（简单但有振荡）
- Proportional Control — 比例控制（P 控制）
- Proportional plus reset control — 比例+积分控制（PI 控制，消除稳态误差）
正确性（Correctness）： 嵌入式实时系统必须保证控制逻辑的正确性
6. 何时选择控制架构？
当满足以下条件时，应当考虑采用闭环控制设计：
- 任务需要维持持续的动作、行为或特定状态（continuing action, behavior, or state）
- 软件是嵌入在物理系统中的嵌入式软件（embedded in a physical system）
- 开环计算无法满足需求，通常是因为存在外部扰动，或是对外部状态的认知不精确（external perturbations or imprecise knowledge）
7. 巡航控制案例总结
设计方法论的很大一部分效力，来源于它能否在恰当的时机将注意力聚焦在重要决策上。
- 基于过程控制的方法论，比面向对象方法论更能引出巡航控制系统的高层设计决策
- 巡航控制是一类典型问题：嵌入式软件控制实时过程
- 这类问题会提早暴露性能与正确性问题 — 这些问题在其他架构风格下可能不会这么早被发现
二、计算机集成制造系统（CIMS）
1. CIMS 的功能结构
CIMS 包含制造企业的设计、制造、经营管理三种主要功能，由分布式数据库和计算机网络作为支撑环境。
四个功能分系统：
| 分系统 | 核心 | 说明 |
|---|---|---|
| 管理信息分系统 | 以 MRPⅡ 为核心 | 经营管理、生产计划、物料需求 |
| 工程设计自动化分系统 | CAD/CAPP/CAM | 产品设计、工艺设计、数控编程 |
| 制造自动化分系统 | 数控机床 / FMS | 柔性自动化制造 |
| 质量保证分系统 | CAQ | 质量检测、评价、控制、跟踪 |
两个支撑分系统：
- 计算机网络分系统 — 异种机互联、异构网络互联
- 数据库分系统 — 覆盖企业全部信息，支撑各分系统
2. CIMS 集成的内涵
集成 ≠ 简单连接。集成是将原来没有联系或联系不紧密的单元，组成为有一定功能、紧密联系的新系统。
五个层面的集成：
- 系统运行环境的集成 — 硬件、操作系统、网络的统一
- 信息的集成 — 数据共享、一致性、唯一性
- 应用功能的集成 — 各业务系统的协同工作
- 技术的集成 — 多种技术手段的融合
- 人和组织的集成 — 人员、流程、组织结构的整合
3. CIMS 的广泛适用性与效益
广泛适用性：
- 没有行业限制（企业共同目标：高生产率 + 高柔性）
- 没有规模限制（可逐步扩大、量力而行）
- 甚至不用计算机，只要遵循 CIM 哲理寻求最佳经营模式，也可认为是 CIMS
三大效益：
- 工程设计自动化方面 — 缩短产品设计与工艺设计周期，支持复杂产品开发
- 加工制造方面 — 提高制造柔性与质量，提高设备利用率，缩短制造周期
- 经营管理方面 — 报价快速准确，减少在制品，压缩库存，加速资金周转
4. 工业控制系统的层级架构（PROVOX 示例）
典型的工业控制系统采用 5 层金字塔架构：
| 层级 | 功能 | 系统组成 |
|---|---|---|
| Level 5 | Corp. mgmt.（公司管理） | Corp. computers（企业级计算机） |
| Level 4 | Plant management（工厂管理） | PROVOX plus application software |
| Level 3 | Process management（过程管理） | ENVOX configuration software |
| Level 2 | Process supervision（过程监控） | PROVUE consoles（操作控制台） |
| Level 1 | Process measurement and control（过程测量与控制） | PROVOX plus controllers |
这是分层架构在工业控制领域的典型应用，每一层负责不同抽象级别的管理和控制。
5. ITCMS 集成式全面成本管理系统
CIMS 思想在成本管理领域的延伸 — 三层架构：
| 层级 | 模块 | 内容 |
|---|---|---|
| 领导决策层 | 决策 | 战略决策支持 |
| 管理业务层 | 成本管理战略 + 成本管理大纲 | 企业使命研究 / 差异化战略 / 组织框架 / 控制机制 |
| 作业成本管理体系 | 5 大模块 | 产品开发过程成本 / 生产过程成本 / 存货资金成本 / 生命周期成本效益评价 / 质量成本 |
| 作业层（底层） | 4 类业务系统 | CAD/PDM/CAPP + MRPII + CAQ + 营销系统 |
底层支撑：数据库 / 网络支撑系统
三、混合风格架构（Mixed Styles）
实际软件系统很少只使用单一架构风格，更多是多种风格的混合与组合。
1. 分层设计中的不同风格
一个系统的不同层次可以采用不同的架构风格：
| 层次 | 风格 |
|---|---|
| Level 1 | 面向对象模型 |
| Level 2 | 面向对象（使用点集） |
| Level 3 | 面向对象模型 |
| Level 4 | （待补充） |
| Level 5 | 数据处理仓库模型 |
关键洞见： 架构风格不是非此即彼的选择，而是可以按层次组合。下层偏数据表示，上层偏业务处理，不同层次使用最适合的风格。
2. 基于规则的系统（Rule-Based System）
基于规则的专家系统是一种特殊的仓库/解释器混合架构：
四大模块：
| 模块 | 组成 | 功能 |
|---|---|---|
| 工作记忆（Working Memory） | 多维工作记忆 | 暂存输入、中间数据；Inputs/Outputs 接口 |
| 知识库（Knowledge Base） | 规则记忆（激活/非激活）+ 事实记忆（激活/非激活） | 存储规则和事实 |
| 规则与数据选择 | 规则编译器 + 数据流网络 + 元规则 + Agenda 议程 | 匹配规则、冲突消解、优先级排序 |
| 规则解释器 | Scheduler 调度器 + Interpreter 解释器 + Execution stack 执行栈 | 执行规则、控制系统 |
运行循环（匹配-选择-执行）：
- 输入进入工作记忆，与激活的规则/事实匹配
- 匹配成功的候选规则按元规则优先级排序，存入 Agenda
- 调度器选中优先级最高的规则，交给解释器执行
- 执行结果更新工作记忆，触发下一轮循环
3. 黑板架构（Blackboard Architecture）—— Hearsay-II
Hearsay-II 是黑板架构的经典实现（最初用于语音理解）。
三大核心组成：
| 组件 | 作用 |
|---|---|
| Blackboard（黑板） | 全局共享的分层数据结构（Level 1 ~ Level n），存储所有中间结果 |
| Knowledge Sources（知识源 KS） | 独立的领域知识模块，每个 KS = Condition + Action（条件-动作对） |
| 控制模块 | 黑板监控器 + 调度队列 + 调度器 + 控制焦点数据库 |
运行流程：
- 初始数据写入黑板底层
- 黑板监控器检测变化，匹配 KS 条件，满足的 KS 放入调度队列
- 调度器按优先级选择 KS 执行
- KS 的 Action 修改黑板内容
- 新变化再次触发监控，循环往复直到求解完成
核心特征：
- 知识源之间不直接通信，所有信息通过黑板传递
- 机会主义求解 — 哪个 KS 的条件满足就执行哪个
- 控制流与数据流分离
4. 黑板重铸为解释器（Blackboard as Interpreter）
黑板架构可以从另一个视角看：它本质上也是一个解释器架构。
Hearsay-II 的解释器视图：
| 解释器组件 | 对应黑板概念 |
|---|---|
| Program State（程序状态 / 工作内存） | Blackboard 黑板（分层结构） |
| Pseudocode（伪代码 / 知识库） | KS 知识源（Condition + Action） |
| Control State（控制状态） | 调度队列 + 刺激响应帧 |
| Interpretation Engine（解释引擎） | 黑板监控器 + 调度器 + 控制焦点数据库 |
关键洞见：
- 同一个系统可以用不同的架构风格来理解和描述
- 黑板视图 → 强调数据共享和机会主义求解
- 解释器视图 → 强调程序状态 + 知识库 + 解释引擎的循环
- 选择哪种视图取决于设计关注点：是关注数据组织？还是关注执行过程？
Actions are also part of interpretation engine. （知识源的动作部分也属于解释引擎的组成部分。）
核心收获
- 架构风格决定设计视野 — 选择面向对象还是过程控制，会导致你关注的设计决策完全不同
- 嵌入式实时系统适合控制架构 — 当软件嵌入物理系统、需要维持持续状态时，闭环控制比 OO 更合适
- 企业级系统适合仓库风格 — CIMS 是仓库/分层架构在制造业的典型应用，集成是核心理念
- 实际系统都是混合风格 — 很少有系统只用一种架构风格，分层组合、视角转换是常见做法
- 同一系统可以有多种架构视图 — 黑板和解释器是对同一系统的两种抽象，各有适用场景