18 移动系统

susemm

已于 2025-02-14 16:04:52 修改

阅读量696

点赞数 30

分类专栏：软件架构实践（第4版）文章标签：软件架构

于 2024-11-05 22:25:25 首次发布

本文链接：https://blog.youkuaiyun.com/susemm/article/details/143531348

版权

软件架构实践（第4版）专栏收录该内容

33 篇文章

订阅专栏

第18章移动系统

与 Yazid Hamdi 和 Greg Hartman 合作完成

电话将被用来通知人们电报已发出。

——亚历山大·格拉汉姆·贝尔（Alexander Graham Bell）

那么，亚历山大・格雷厄姆・贝尔（Alexander Graham Bell）到底知道些什么呢？移动系统，包括尤其是手机，在当今世界无处不在。除了手机之外，它们还包括火车、飞机和汽车；它们包括轮船和卫星、娱乐和个人计算设备以及机器人系统（自主或非自主的）；它们基本上包括任何与持续充足电源没有永久连接的系统或设备。

移动系统具有在移动过程中持续提供部分或全部功能的能力。这使得处理其某些特性与处理固定系统有所不同。在本章中，我们将重点关注其中的五个特性：

能源。移动系统的电源有限，必须关注高效用电。
网络连接性。移动系统往往在移动过程中通过与其他设备交换信息来实现其大部分功能。因此，它们必须与这些设备连接，但它们的移动性使这些连接变得棘手。
传感器和执行器。移动系统往往比固定系统从传感器获取更多信息，并且它们经常使用执行器与环境交互。
资源。移动系统往往比固定系统受到更多资源限制。一方面，它们通常体积很小，以至于物理封装成为一个限制因素。另一方面，它们的移动性常常使重量成为一个因素。必须小巧轻便的移动设备在可提供的资源方面存在限制。
生命周期。移动系统的测试与其他系统的测试有所不同。部署新版本也会带来一些特殊问题。

当为移动平台设计系统时，你必须处理大量特定领域的需求。自动驾驶汽车和自主无人机必须安全；智能手机必须为各种各样差异极大的应用程序提供一个开放平台；娱乐系统必须能处理多种内容格式和服务提供商。在本章中，我们将重点关注许多（如果不是全部的话）移动系统共有的特性，这些特性是架构师在设计系统时必须考虑的。

18.1 能源

在本节中，我们重点关注与管理移动系统能源最相关的架构问题。对于许多移动设备而言，其能源来源是电池，而电池的能量供应能力非常有限。其他移动设备，如汽车和飞机，依靠发电机产生的电力运行，而发电机又可能由使用燃料的发动机提供动力 —— 这同样是一种有限的资源。

架构师的关注点

架构师必须关注电源监测、控制能源使用以及容忍断电情况。我们将在接下来的三个小节中详细阐述这些关注点。

监测电源

在关于能源效率的第 6 章中，我们介绍了一类称为 “资源监测” 的策略，用于监测作为能源消耗者的计算资源的使用情况。在移动系统中，我们需要监测能源来源，以便在可用能量变低时能够启动适当的行为。具体而言，在由电池供电的移动设备中，我们可能需要告知用户电池电量低，将设备切换到省电模式，提醒应用程序设备即将关机以便它们为重启做准备，并确定每个应用程序的功耗。

所有这些用途都依赖于监测电池的当前状态。大多数笔记本电脑或智能手机使用智能电池作为电源。智能电池是一种带有内置电池管理系统（BMS）的可充电电池组。可以查询 BMS 以获取电池的当前状态。其他移动系统可能使用不同的电池技术，但都具有某种等效功能。在本节中，我们将假设读数表示剩余电量的百分比。

电池供电的移动系统包含一个组件（通常位于操作系统内核中），该组件知道如何与 BMS 交互，并能根据请求返回当前电池容量。电池管理器负责定期查询该组件以获取电池状态。这使得系统能够告知用户能量状态，并在必要时触发省电模式。为了通知应用程序设备即将关机，应用程序必须向电池管理器注册。

电池随着使用时间增长有两个特性会发生变化：最大电池容量和最大持续电流。架构师必须考虑在可用功率不断变化的范围内管理能耗，以便设备仍能在可接受的水平上运行。监测在配备发电机的系统中也起着作用，因为当发电机输出较低时，一些应用程序可能需要关闭或进入待机状态。电池管理器还可以确定哪些应用程序当前处于活动状态以及它们的能耗是多少。然后可以根据此信息估算电池容量总体变化的百分比。

当然，电池管理器本身会占用资源 —— 内存和 CPU 时间。电池管理器消耗的 CPU 时间量可以通过调整查询间隔来管理。

控制能源使用

可以通过终止或降低系统中消耗能量的部分来减少能耗；这就是第 6 章中描述的控制使用策略。具体的实现方式取决于系统的各个组件，但一个常见的例子是降低智能手机显示屏的亮度或刷新率。其他控制能源使用的技术包括减少处理器的活动核心数量、降低核心的时钟频率以及减少传感器读数的频率。例如，不要每隔几秒就获取一次 GPS 位置数据，而是改为大约每分钟获取一次。不要依赖诸如 GPS 和手机信号塔等不同的位置数据源，而只使用其中一个。

容忍断电

移动系统应该妥善地容忍断电和重启情况。例如，此类系统的一项要求可能是在恢复供电后，系统能在 30 秒内重新启动并以正常模式运行。这一要求意味着对系统不同部分有不同要求，例如以下方面：

硬件要求示例：
- 如果在任何时候断电，系统的计算机不会遭受永久性损坏。
- 只要提供足够的电力，系统的计算机就能稳健地（重新）启动操作系统。
- 系统的操作系统在准备就绪后就能立即启动计划中的软件。
软件要求示例：
- 运行时环境可以随时被终止，而不会影响永久存储中的二进制文件、配置和操作数据的完整性，并且在重启（无论是重置还是恢复）后保持状态一致。
- 应用程序需要一种策略来处理在其不运行时到达的数据。
- 运行时能够在故障后启动，使得从系统上电到软件处于就绪状态的启动时间小于规定时长。

18.2 网络连接性

在本节中，我们重点关注与移动系统网络连接性最相关的架构问题。我们将聚焦于移动平台与外部世界之间的无线通信。网络可能被用于控制设备或发送和接收信息。

无线网络根据其作用距离进行分类。

在 4 厘米以内：近场通信（NFC）用于钥匙卡和非接触式支付系统。GSM 联盟正在制定这一领域的标准。
在 10 米以内：IEEE 802.15 系列标准涵盖了这个距离范围。蓝牙和 Zigbee 是这一类别中的常见协议。
在 100 米以内：IEEE 802.11 系列标准（Wi-Fi）在这个距离范围内使用。
在几公里以内：IEEE 802.16 标准涵盖了这个距离范围。WiMAX 是 IEEE 802.16 标准的商业名称。
超过几公里：这通过蜂窝通信或卫星通信实现。

在所有这些类别中，技术和标准都在迅速发展。

架构师的关注点

设计通信和网络连接性要求架构师平衡大量关注点，包括以下内容：

要支持的通信接口数量：由于存在各种不同的协议且它们在快速发展，架构师很容易想要包含所有可能的网络接口。但设计移动系统的目标恰恰相反：应仅包含严格需要的接口，以优化功耗、热量产生和空间分配。
从一种协议转换到另一种协议：尽管需要采用极简主义方法处理接口，但架构师必须考虑到在一个会话过程中，移动系统可能从支持一种协议的环境移动到支持另一种协议的环境的可能性。例如，视频可能正在通过 Wi-Fi 流传输，但随后系统可能移动到没有 Wi-Fi 的环境，视频将通过蜂窝网络接收。这种转换对用户来说应该是无缝的。
动态选择合适的协议：如果多个协议同时可用，系统应根据成本、带宽和功耗等因素动态选择一个协议。
可修改性：鉴于大量的协议及其快速发展，在移动系统的生命周期内，很可能需要支持新的或替代的协议。系统应设计为支持涉及通信的系统元素的更改或替换。
带宽：应分析要与其他系统通信的信息的距离、容量和延迟要求，以便做出适当的架构选择。这些协议在这些特性方面各不相同。
间歇性 / 有限 / 无连接：设备在移动过程中可能会失去通信（例如，智能手机穿过隧道）。系统应设计为在连接丢失的情况下保持数据完整性，并且在连接恢复时能够无一致性损失地恢复计算。系统应设计为妥善处理有限连接甚至无连接的情况。应动态提供降级和回退模式以应对此类情况。
安全性：移动设备特别容易受到欺骗、窃听和中间人攻击，因此应对此类攻击应是架构师关注的一部分。

18.3 传感器和执行器

传感器 是一种检测其环境的物理特性并将这些特性转换为电子表示的设备。移动设备收集环境数据，要么是为了指导自身的操作（例如无人机中的高度计），要么是将该数据报告回给用户（例如你智能手机中的磁罗盘）。

换能器 感应外部电子脉冲并将其转换为更有用的内部形式。在本节中，我们将使用 “传感器” 一词来涵盖换能器，并假设电子表示是数字的。

传感器中枢 是一个协处理器，有助于整合来自不同传感器的数据并进行处理。传感器中枢可以帮助将这些任务从产品的主中央处理器上卸载下来，从而节省电池消耗并提高性能。

在移动系统内部，软件将抽象出环境的某些特性。这种抽象可能直接映射到一个传感器，例如温度或压力的测量，或者它可能整合多个传感器的输入，例如在自动驾驶汽车控制器中识别出的行人。

执行器 与传感器相反：它以数字表示作为输入并在环境中引起某种动作。汽车中的车道保持辅助功能利用执行器，就像你的智能手机发出的音频警报一样。

架构师的关注点

架构师在传感器方面有几个关注点：

如何根据传感器输入创建环境的准确表示。
系统应如何响应环境的这种表示。
传感器数据和执行器命令的安全性和隐私性。
降级操作。如果传感器发生故障或无法读取，系统应进入降级模式。例如，如果在隧道中无法获得 GPS 读数，系统可以使用航位推算技术来估计位置。

由系统创建并对其采取行动的环境表示是特定于领域的，降级操作的适当方法也是如此。我们在第 8 章中详细讨论了安全性和隐私性，但在这里我们将只关注第一个关注点：根据传感器返回的数据创建环境的准确表示。这是通过传感器栈来实现的 —— 一组设备和软件驱动程序的组合，有助于将原始数据转换为关于环境的解释信息。

不同的平台和领域往往有自己的传感器栈，并且传感器栈通常带有自己的框架，以便更容易地处理设备。随着时间的推移，传感器可能会涵盖越来越多的功能；反过来，特定栈的功能也会随时间而变化。在这里，我们列举了无论特定分解将它们放置在何处，栈中必须实现的一些功能：

读取原始数据。栈的最低层是一个用于读取原始数据的软件驱动程序。该驱动程序直接读取传感器，或者在传感器是传感器中枢的一部分的情况下，通过中枢读取传感器。驱动程序定期从传感器获取读数。周期频率是一个参数，它将影响读取和处理传感器的处理器负载以及所创建表示的准确性。
平滑数据。原始数据通常有很大的噪声或变化。电压变化、传感器上的污垢或灰尘以及无数其他原因可能使传感器的两次连续读数不同。平滑是一个使用一段时间内的一系列测量来产生一个估计值的过程，这个估计值往往比单次读数更准确。计算移动平均值和使用卡尔曼滤波器是平滑数据的众多技术中的两种。
转换数据。传感器可以以多种格式报告数据 —— 从毫伏的电压读数到以英尺为单位的海拔高度再到摄氏度的温度。然而，两个测量同一现象的不同传感器可能以不同的格式报告其数据。转换器负责将传感器报告的任何形式的读数转换为对应用程序有意义的通用形式。正如你可能想象的那样，这个功能可能需要处理各种各样的传感器。
传感器融合。传感器融合将来自多个传感器的数据组合起来，以建立比任何单个传感器都更准确、更完整或更可靠的环境表示。例如，汽车如何在白天或夜晚、各种天气条件下识别其路径中或在其到达时可能在其路径中的行人？没有单个传感器可以完成这一壮举。相反，汽车必须智能地组合来自热成像仪、雷达、激光雷达和摄像头等传感器的输入。

18.4 资源

在本节中，我们从物理特性的角度讨论计算资源。例如，在能源来自电池的设备中，我们需要关注电池的体积、重量和热性能。对于网络、处理器和传感器等资源也是如此。

资源选择中的权衡在于所考虑的特定资源的贡献与其体积、重量和成本之间。成本始终是一个因素。成本包括制造成本和非经常性工程成本。许多移动系统是以数百万计制造的，并且对价格高度敏感。因此，处理器价格的微小差异乘以嵌入该处理器的系统的数百万副本数量，可能会对生产该系统的组织的盈利能力产生重大影响。批量折扣和跨不同产品重复使用硬件是设备供应商用来降低成本的技术。

体积、重量和成本是由组织的市场部门和其使用的物理考虑因素所给出的约束。市场部门关注客户的反应。设备使用的物理考虑因素取决于人为因素和使用因素。智能手机显示屏必须足够大，以便人能够阅读；汽车受到道路重量限制的约束；火车受到轨道宽度的约束等等。

对移动系统资源（以及因此对软件架构师）的其他约束反映了以下因素：

安全考虑。具有安全后果的物理资源不得发生故障或必须有备份。备用处理器、网络或传感器会增加成本和重量，并占用空间。例如，许多飞机都有一个紧急电源，在发动机故障时可以使用。
热限制。热量可以由系统本身产生（想想你放置笔记本电脑的膝盖），这可能对系统性能产生不利影响，甚至导致故障。环境的环境温度 —— 过高或过低 —— 也可能产生影响。在做出硬件选择之前，应该了解系统将在其中运行的环境。
其他环境问题。其他问题包括暴露于潮湿或灰尘等不利条件下或被掉落。

架构师的关注点

架构师必须围绕资源及其使用做出许多重要决策：

将任务分配给电子控制单元（ECU）。较大的移动系统，如汽车或飞机，有多个不同功率和容量的 ECU。软件架构师必须决定哪些子系统将分配给哪些 ECU。这个决策可以基于以下几个因素：
- ECU 与功能的适配性。功能必须分配给有足够能力执行该功能的 ECU。一些 ECU 可能有专门的处理器；例如，带有图形处理器的 ECU 更适合图形功能。
- 关键程度。更强大的 ECU 可能被保留用于关键功能。例如，发动机控制器比舒适功能子系统更关键且更可靠。
- 在车辆中的位置。头等舱乘客可能比二等舱乘客有更好的 Wi-Fi 连接。
- 连接性。一些功能可能分布在几个 ECU 之间。如果是这样，它们必须在同一个内部网络上并且能够相互通信。
- 通信的局部性。将相互之间强烈通信的组件放在同一个 ECU 上会提高它们的性能并减少网络流量。
- 成本。通常制造商希望最小化部署的 ECU 数量。
将功能卸载到云端。诸如路线确定和模式识别等应用可以部分由移动系统本身（传感器所在的位置）执行，部分由驻留在云端的应用部分执行（那里有更多的数据存储和更强大的处理器可用）。架构师必须确定移动系统是否有足够的能力执行特定功能，是否有足够的连接性来卸载一些功能，以及当功能在移动系统和云端之间分割时如何满足性能要求。架构师还应考虑本地可用的数据存储、数据更新间隔和隐私问题。
根据操作模式关闭功能。未使用的子系统可以缩小其占用空间，允许竞争的子系统访问更多资源，从而提供更好的性能。在跑车上，一个例子是开启 “竞赛模式”，这会禁用负责根据道路轮廓计算舒适悬挂参数的进程，并激活扭矩分配、制动功率、悬挂硬化和离心力的计算。
信息显示策略。这个问题与可用的显示分辨率相关。在 320×320 像素的显示屏上可以进行 GPS 风格的映射，但需要付出很多努力来最小化显示屏上的信息。在 1280×720 的分辨率下，有更多的像素，所以信息显示可以更丰富。（能够更改显示屏上的信息是诸如 MVC 模式的强大动力 [见第 13 章]，以便可以根据特定的显示特性交换视图）。

18.5 生命周期

移动系统的生命周期往往具有一些架构师需要考虑的特殊之处，这些与为传统（非移动）系统所做的选择不同。我们继续深入探讨。

架构师的关注点

架构师必须关注硬件选择、测试、部署更新和日志记录。我们将在接下来的四个小节中详细阐述这些关注点。

硬件优先

对于许多移动系统，硬件是在软件设计之前被选择的。因此，软件架构必须适应所选硬件带来的约束。

早期硬件选择的主要利益相关者是管理层、销售部门和监管机构。他们的关注点通常集中在降低风险的方法上，而不是提升质量属性的方法上。对于软件架构师来说，最好的方法是积极推动这些早期讨论，强调其中的权衡，而不是被动地等待结果。

测试

移动设备在测试方面有一些独特的考虑因素：

测试显示布局。智能手机和平板电脑有各种各样的形状、大小和宽高比。验证所有这些设备上的布局正确性很复杂。一些操作系统框架允许从单元测试中操作用户界面，但可能会遗漏一些不愉快的边界情况。例如，假设你在屏幕上显示控制按钮，布局用 HTML 和 CSS 指定，并且假设它是为你预期使用的所有显示设备自动生成的。对于一个非常小的显示屏，一个幼稚的生成可能会在 1×1 像素上产生一个控制，或者控制在显示屏的边缘，或者控制重叠。这些在测试期间很容易被遗漏。
测试操作边界情况：
- 应用程序应该在电池耗尽和系统关闭的情况下存活下来。在这种情况下，状态的保存需要得到确保并进行测试。
- 用户界面通常与提供功能的软件异步操作。当用户界面没有正确反应时，重现导致问题的事件序列是困难的，因为问题可能取决于时间，或者取决于当时正在进行的特定操作集。
测试资源使用情况。一些供应商会向软件架构师提供他们设备的模拟器。这很有帮助，但用模拟器测试电池使用情况是有问题的。
测试网络转换。确保系统在有多个通信网络可用时做出最佳选择也很困难。当设备从一个网络移动到另一个网络（例如，从 Wi-Fi 网络到蜂窝网络，然后再到另一个 Wi-Fi 网络）时，用户应该不会察觉到这些转换。

交通或工业系统的测试往往在四个层面上进行：单个软件组件层面、功能层面、设备层面和系统层面。它们之间的层面和边界可能因系统而异，但在一些参考流程和标准中是隐含的，如汽车软件过程改进及能力评定（Automotive SPICE）。

例如，假设我们正在测试汽车的车道保持辅助功能，车辆在道路标记所定义的车道内行驶，并且无需驾驶员输入即可做到。对这个系统的测试可能涉及以下层面：

软件组件。一个车道检测软件组件将通过单元测试和端到端测试的常用技术进行测试，目的是验证软件的稳定性和正确性。
功能。下一步是在模拟环境中运行软件组件以及车道保持辅助功能的其他组件，例如用于识别高速公路出口的地图组件。目的是在功能的所有组件一起工作时验证接口和安全并发。在这里，模拟器用于向软件功能提供与车辆在有标记的道路上行驶相对应的输入。
设备。捆绑的车道保持辅助功能，即使它在模拟环境和开发计算机上通过了测试，也需要部署在其目标电子控制单元（ECU）上，并在那里进行性能和稳定性测试。在这个设备测试阶段，环境仍然是模拟的，但这次是通过连接到 ECU 端口的模拟外部输入（来自其他 ECU 的消息、传感器输入等）。
系统。在最后的系统集成测试阶段，所有具有所有功能和所有组件的设备都构建成全尺寸配置，首先在测试实验室中，然后在测试原型中。例如，车道保持辅助功能可以与它对转向和加速 / 制动功能的作用一起进行测试，同时提供投影图像或道路视频。这些测试的作用是确认集成的子系统一起工作并提供所需的功能和系统质量属性。

这里的一个重要点是测试可追溯性：如果在步骤 4 中发现问题，它需要在所有测试设置中可重现和可追溯，因为修复必须再次通过所有四个测试层面。

部署更新

在移动设备中，系统更新要么修复问题，要么提供新功能，要么安装未完成但可能在早期版本发布时部分安装的功能。这样的更新可能针对软件、数据或（较少情况下）硬件。例如，现代汽车需要软件更新，可以通过网络获取或通过 USB 接口下载。除了在操作期间提供更新能力之外，以下具体问题与部署更新有关：

保持数据一致性。对于消费设备，升级往往是自动的且单向的（没有办法回滚到早期版本）。这表明将数据保存在云端是个好主意 —— 但然后需要测试云端和应用程序之间的所有交互。
安全性。架构师需要确定系统的哪些状态可以安全地支持更新。例如，在汽车在高速公路上行驶时更新汽车的发动机控制软件是个坏主意。这反过来意味着系统需要了解与更新相关的安全状态。
部分系统部署。重新部署整个应用程序或大型子系统将消耗带宽和时间。应用程序或子系统应该进行架构设计，以便经常变化的部分可以很容易地更新。这需要一种特定类型的可修改性（见第 8 章）和对可部署性的关注（见第 5 章）。此外，更新应该容易且自动化。访问设备的物理部分进行更新可能很麻烦。回到发动机控制器的例子，更新控制器软件不应该需要访问发动机。
可扩展性。移动车辆系统往往具有相对较长的寿命。在某些时候，对汽车、火车、飞机、卫星等进行改装可能会变得必要。改装意味着通过替换或添加将新技术添加到旧系统中。这可能是由于以下原因：
- 组件在整个系统达到其寿命终点之前达到其寿命终点。寿命终点意味着支持将停止，这在出现故障时会产生高风险：将没有可信赖的来源以合理的成本获得答案或支持 —— 也就是说，无需对有问题的组件进行剖析和逆向工程。
- 出现了更新更好的技术，促使进行硬件 / 软件升级。一个例子是用与智能手机连接的信息娱乐系统改装 21 世纪初的汽车，而不是旧的收音机 / CD 播放器。
- 有新的技术可用，可以在不替换现有功能的情况下添加功能。例如，假设 21 世纪初的汽车根本没有收音机 / CD 播放器，或者没有倒车摄像头。

日志

在调查和解决已经发生或可能发生的事件时，日志至关重要。在移动系统中，日志应该搬到一个无论移动系统本身是否可访问都可以访问的位置。这不仅对事件处理有用，而且对系统的使用进行各种类型的分析也很有用。许多软件应用程序在遇到问题时会做类似的事情，并请求允许将详细信息发送给供应商。对于移动系统，这种日志记录功能特别重要，并且它们很可能不会请求获得数据的许可。

18.6 小结

移动系统涵盖了广泛的形式和应用，从智能手机和平板电脑到汽车和飞机等交通工具。我们将移动系统与固定系统之间的差异归类为基于五个特征：能源、连接性、传感器、资源和生命周期。

许多移动系统的能源来自电池。对电池进行监测，以确定电池的剩余使用时间以及各个应用程序的能耗。可以通过限制单个应用程序的能耗来控制能源使用。应用程序应构建为能够在电源故障时存活下来，并在电源恢复时无缝重新启动。

连接性意味着通过无线方式连接到其他系统和互联网。无线通信可以通过短距离协议（如蓝牙）、中距离协议（如 Wi-Fi 协议）和长距离蜂窝协议进行。当从一种协议类别移动到另一种协议类别时，通信应该是无缝的，并且诸如带宽和成本等考虑因素有助于架构师决定支持哪些协议。

移动系统利用各种传感器。传感器提供外部环境的读数，架构师随后使用这些读数在系统内部开发外部环境的表示。传感器读数由特定于每个操作系统的传感器栈处理；这些栈将提供对表示有意义的读数。可能需要多个传感器才能开发出有意义的表示，然后将这些传感器的读数进行融合（整合）。传感器也可能随着时间的推移而性能下降，因此可能需要多个传感器才能准确表示正在测量的现象。

资源具有物理特性（如尺寸和重量）、具有处理能力并且有成本。设计选择涉及在这些因素之间进行权衡。关键功能可能需要更强大和可靠的资源。某些功能可以在移动系统和云端之间共享，并且某些功能在某些模式下可以关闭，以释放资源供其他功能使用。

生命周期问题包括硬件选择、测试、部署更新和日志记录。与固定系统相比，移动系统的用户界面测试可能更加复杂。同样，由于带宽、安全考虑和其他问题，部署也更加复杂。