物联网概论：定义、边界与参考架构

物联网之所以难以“一句话讲清楚”，根源在于它并非单一技术，而是一类将物理世界与信息世界耦合起来的系统工程范式：传感器把状态转化为数据，网络把数据跨空间搬运，计算把数据转化为知识与决策，执行器再把决策回写到物理过程之中，从而形成可观测、可分析、可控制的闭环。对初学者而言，建立清晰的定义边界、分层视图与非功能指标框架，是后续学习通信协议、设备接入、平台架构、安全治理与行业应用的前提。

1.1 从 CPS 与泛在计算理解物联网

1.1.1 信息物理系统（CPS）的系统观

CPS（Cyber-Physical Systems）强调计算过程与物理过程的紧密耦合，典型特征包括： 1) 物理过程可测量：通过传感器获得状态量（温度、振动、电流、位置等）； 2) 计算过程可推断：通过模型、规则或学习算法将数据映射为对系统状态的估计与预测； 3) 控制过程可执行：通过执行器或控制器改变物理过程（阀门开度、转速、制冷功率等）； 4) 时间约束显著：延迟、抖动、采样频率会影响系统稳定性与安全性。

在工程抽象上，可将一个 CPS/IoT 系统表示为三元组： $$ \mathcal{S}=\langle P,\ C,\ N\rangle $$ 其中 $P$ 表示物理对象与过程（Physical），$C$ 表示计算与软件（Cyber/Compute），$N$ 表示连接与通信网络（Network）。物联网可被视为 CPS 在“可互联、可规模化部署”的背景下的具体实现路径之一：它把对象接入网络，使跨域观测与协同控制成为可能。

1.1.2 泛在计算的服务观

泛在计算（Ubiquitous Computing）关注“计算无处不在但不被感知”，强调以场景为中心的服务编排：设备异构、网络不稳定、用户行为不确定、隐私约束强。物联网应用常常并不以“设备”作为终点，而以“服务体验”作为目标，例如：自动化节能、预测性维护、全链路追溯、风险预警。

> 侧栏：两种视角的互补 > - CPS 强调“闭环控制与安全边界”，常见于工业、交通、能源等高风险领域。 > - 泛在计算强调“人机融合与体验连续性”，常见于家庭、办公、零售等人居场景。 > 物联网工程实践往往需要兼顾两者：既要能闭环控制，又要能稳定提供服务。

1.2 物联网的工作定义：对象、连接、数据与服务

<!-- tag:definition --> 在本书中，给出一个面向工程的工作定义：

物联网（IoT）是指：以可标识的物理对象为载体，通过传感、连接、计算与控制能力，将对象状态与行为映射为可处理的数据，并在业务规则或智能算法驱动下形成闭环服务的系统集合。

该定义刻意包含四个关键词，分别对应工程落地的四个核心要素：

1. 对象（Thing）与标识（Identity） 对象可以是设备（电机、路灯）、部件（轴承）、环境（库房）、资产（托盘）、甚至人或动物（可穿戴）。要进入系统工程视野，首先要“可标识”，常见方式包括序列号、二维码、RFID、eSIM、证书、公钥指纹等。

2. 连接（Connectivity）与可达性（Reachability） 连接不仅是“能上网”，还包括网络拓扑、地址与路由、NAT 穿越、断连重连、带宽与资费、漫游策略等。IoT 的连接形态呈显著多样性：以太网、Wi‑Fi、蜂窝（4G/5G/NB‑IoT）、低功耗广域（LoRaWAN 等）、短距（BLE/Zigbee/Thread）并存。

3. 数据（Data）与语义（Semantics） 同样的“温度”在不同语义下含义不同：采样频率、单位、位置、校准方式、传感器漂移、时间戳来源、缺失值处理。没有语义约束的数据难以复用，最终会导致平台“只存不算”或“算不准”。

4. 服务（Service）与闭环（Closed Loop） 物联网的价值通常不来自数据本身，而来自“数据驱动的行动”：告警、调度、优化、自动控制、对外 API 能力等。闭环意味着系统不仅“看见”，还要能“影响”。

1.2.1 物联网系统的边界：到哪里算“物联网”？

工程中常见争论是：某个系统究竟是“物联网”还是“传统信息系统 + 设备数据”？本书建议用两条边界线判断：

• **对象边界**：是否存在与物理对象一一对应的数字表示（设备影子、资产台账、数字孪生的最小形态），并可追溯其状态变化？
• **闭环边界**：系统是否具备将分析或规则结果回写到现场的能力（自动/半自动执行），从而形成“采集—处理—决策—执行”的链路？

若两条边界线都成立，通常可将其视为完整的 IoT 系统工程问题；若只满足其一，则更接近“数据采集系统”或“远程监测系统”。

1.3 IoT、IIoT、M2M、智能硬件与边缘计算：关系与差异

1.3.1 概念对比与常见误区

下面给出一个面向初学者的对比表（并非标准定义，而是工程实践中最常用的区分方式）：

| 概念 | 关注点 | 典型场景 | 关键约束 | 常见协议/技术 | |---|---|---|---|---| | IoT（物联网） | 泛场景互联与服务闭环 | 家居、零售、城市、物流 | 规模、成本、隐私、异构 | MQTT/HTTP/CoAP、BLE、NB‑IoT | | IIoT（工业物联网） | 生产过程与工业控制协同 | 制造、能源、化工 | 安全、实时、可靠、合规 | OPC UA、TSN、工业以太网、DDS | | M2M（机机通信） | 设备到设备通信 | 抄表、车队管理 | 连接稳定、报文简单 | SMS/UDP/专线、早期私有协议 | | 智能硬件 | 单品能力与用户体验 | 手表、耳机、扫地机 | 交互、功耗、供应链 | 移动端 SDK、蓝牙、私有云 | | 边缘计算 | 靠近现场的计算与自治 | 产线、园区、门店 | 低时延、断网可用、算力受限 | 容器/K3s、边缘网关、规则引擎 |

三点容易混淆的地方需要澄清：

1. IIoT 不是 IoT 的“子集”那么简单：工业场景的风险等级、停机代价、合规要求显著更高，导致体系结构上常强调确定性通信、分区隔离、变更治理与生命周期管理。 2. M2M 更偏“连接与传输”，IoT 更偏“平台化与服务化”：很多 M2M 系统能传数据但缺少统一语义、设备管理与应用生态，难以规模化复用。 3. 边缘计算不是 IoT 的替代品，而是 IoT 架构的一个位置选择：计算可在端、边缘、云之间分布，关键取决于实时性、带宽、隐私与成本。

> 侧栏：一个实用判断 > 当需求从“把数据传上来”转向“统一设备生命周期管理、统一数据模型、统一安全治理、支持多应用复用”时，系统往往就进入 IoT 平台工程的范畴。

1.4 “端—网—云—用”全链路视图与分层参考模型

1.4.1 全链路视图：工程角色与责任划分

“端—网—云—用”是一种便于跨团队协作的责任切分方式：

• **端（Device/Edge Node）**：传感、执行、局部控制、设备身份与可信根、固件升级、功耗管理。
• **网（Connectivity/Transport）**：接入网络、路由与隧道、消息传输、质量保障（QoS）、断连恢复。
• **云（Platform/Cloud）**：设备管理、消息接入、数据存储与计算、规则与告警、权限与审计、开放 API。
• **用（Application）**：业务流程、可视化、运营工具、工单与调度、报表与 KPI、与企业系统集成（ERP/MES/CRM）。

该视图的价值在于：它强制工程团队回答“能力放在哪里更合适”，并显式暴露跨层依赖，例如：端侧时间戳是否可信会影响云端时序分析；网络 QoS 策略会影响告警误报率；平台数据模型会影响应用开发效率。

1.4.2 分层模型：感知层 / 网络层 / 平台层 / 应用层

与“端—网—云—用”相对应，可使用四层参考架构描述系统内部构成：

• **感知层（Perception）**：传感器、执行器、嵌入式系统、现场总线、PLC/RTU、边缘网关。
• **网络层（Network）**：接入与传输网络、协议适配、消息路由、边界网关、安全通道（TLS/VPN）。
• **平台层（Platform）**：设备接入与管理、消息总线、时序/对象存储、流式/批处理、规则引擎、数字孪生/设备影子。
• **应用层（Application）**：行业应用、可视化大屏、移动端、运营管理、第三方集成与生态。

下面给出一个可直接用于讲解与建模的示意图：

```mermaid graph TD subgraph 应用层[应用层 Application] A1[监控告警] A2[优化调度] A3[业务系统集成 ERP/MES/CRM] end

subgraph 平台层[平台层 Platform] P1[设备接入与认证] P2[设备管理/OTA] P3[消息总线与规则引擎] P4[数据存储: 时序/对象/关系] P5[分析计算: 流处理/批处理/ML] P6[数字孪生/设备影子] end

subgraph 网络层[网络层 Network] N1[接入网络: BLE/Wi-Fi/蜂窝/LPWAN] N2[传输协议: MQTT/HTTP/CoAP/OPC UA] N3[安全通道: TLS/VPN/专线] end

subgraph 感知层[感知层 Perception] D1[传感器] D2[执行器] D3[控制器/PLC] D4[边缘网关] end

D1 --> D4 --> N1 --> N2 --> P1 D2 --> D3 P1 --> P2 --> P6 P1 --> P3 --> P4 --> P5 --> A2 P3 --> A1 P5 --> A3 A2 --> P3 --> N2 --> D3 ```

1.4.3 为什么要分层：降低复杂度与提高可演进性

分层的核心目的不是“画图好看”，而是把复杂系统拆解为可验证、可替换的模块。分层带来三类工程收益：

1. 解耦：应用不应直接依赖设备厂商私有协议，而应依赖平台抽象（统一 API、统一数据模型）。 2. 复用：同一平台能力可支撑多应用；同一设备管理能力可支撑多产品线。 3. 演进：网络从 4G 升级到 5G、协议从 HTTP 迁移到 MQTT，不应迫使应用重写。

1.5 典型业务闭环：采集—传输—处理—决策—执行

1.5.1 闭环结构与数据流/控制流

物联网系统普遍存在“观测—理解—行动”的闭环，可形式化为：

• **数据流（Data Flow）**：从端到云/边的上行链路，用于状态观测、事件上报、日志与指标采集。
• **控制流（Control Flow）**：从云/边到端的下行链路，用于参数下发、策略更新、远程控制、任务调度。

用流程图表达如下：

```mermaid flowchart LR S[采集 Sensing] --> T[传输 Transport] T --> P[处理 Processing] P --> D[决策 Decision] D --> A[执行 Actuation] A --> S

S -.上行数据流.-> T D -.下行控制流.-> A ```

该闭环在不同场景下的“决策位置”不同：

• 在智能家居中，决策可能在云端（统一场景联动），也可能在本地（断网仍可用）。
• 在工业控制中，安全相关的控制往往要求在现场（PLC/边缘）完成，云端更多承担优化与策略更新。

1.5.2 时间约束：端到端时延预算

闭环是否有效，很大程度取决于端到端时延。可将总时延近似分解为： $$ L_{e2e}=L_{sense}+L_{queue}+L_{net}+L_{compute}+L_{act} $$ 其中 $L_{net}$ 受网络制式与拥塞影响，$L_{compute}$ 受计算位置（云/边/端）与负载影响。工程上常用“时延预算”指导架构选型：若 $L_{e2e}$ 的上界必须小于某阈值（例如 100ms），则控制与计算更可能需要下沉到边缘或现场。

1.5.3 事件驱动与状态驱动

闭环实现上，常见两类模式：

• **事件驱动（Event-driven）**：设备只在“变化”时上报（告警、门磁触发），平台按事件触发规则。优点是省带宽、省电；缺点是对“持续状态”的可见性不足。
• **状态驱动（State-driven）**：设备周期性上报状态（每 1s/10s/1min）。优点是可做趋势分析与预测；缺点是成本更高，对存储与计算要求更强。

实际系统往往混合：状态上报提供可观测性，事件上报提供实时响应与异常优先。

1.6 关键非功能指标：把“能用”提升到“可运营、可扩展、可信赖”

物联网的难点常常不在“实现功能”，而在“在真实世界长期稳定运行”。以下六类非功能指标构成后续章节反复引用的工程坐标系。

1.6.1 安全（Security）

物联网安全要覆盖端、网、云、用四层，并贯穿生命周期（生产、出厂、部署、运维、退役）。初学者至少需要建立三个概念：

• **身份与认证**：设备必须具备可验证身份（证书/密钥/安全芯片），平台必须验证接入合法性。
• **最小权限与分区隔离**：不同设备、租户、应用之间需隔离；控制指令必须严格授权。
• **可更新性（Patchability）**：设备存在长期运行与漏洞暴露的现实，安全更新（OTA）不是“可选项”，而是系统能力的一部分。

可参考（电子版可点击）：[NIST IoT 网络安全指南](https://www.nist.gov/)（检索 “NIST IoT cybersecurity”）、[IETF](https://www.ietf.org/) 相关标准与最佳实践。

1.6.2 隐私（Privacy）

隐私不同于安全：安全关注“防攻击”，隐私关注“合规与正当使用”。物联网隐私风险常源于位置、行为与环境数据的可推断性。工程措施包括：

• 数据最小化：只采集实现业务所需的最少字段与频率；
• 本地化处理：能在端/边缘完成的推断不必上云；
• 脱敏与匿名化：尤其是与个人相关的数据（例如家庭能耗、可穿戴健康数据）；
• 明示同意与可撤回：在产品与运营流程中实现可审计的授权。

1.6.3 可靠性（Reliability）与可用性（Availability）

物联网系统的可靠性既包括设备硬件可靠，也包括平台服务可靠与网络可靠。工程上常用可用性公式： $$ A=\frac{MTBF}{MTBF+MTTR} $$ 其中 MTBF 为平均无故障时间，MTTR 为平均修复时间。平台侧常以 SLO/SLA 形式约束（如月度可用性 99.9%），而端侧更关注“断网可用”“离线缓存”“失败重试与幂等”。

1.6.4 实时性（Real-time）与确定性（Determinism）

实时性不仅是“平均延迟低”，更强调“最坏情况可控”。工业场景中常需要确定性通信与调度（例如 TSN 思路），而消费场景更常采用“尽力而为 + 体验容错”。工程上应区分：

• **软实时**：延迟偶尔超标可接受（例如环境监测上报）。
• **硬实时**：超标即失效甚至危险（例如某些控制保护链路）。

1.6.5 可扩展性（Scalability）

可扩展性要回答三个规模问题：

1. 设备规模：从 100 台到 100 万台，接入、认证、连接保持、消息吞吐如何线性扩展？ 2. 数据规模：时序数据写入、冷热分层、保留策略、查询性能如何规划？ 3. 组织规模：多租户、多团队、多环境（开发/测试/生产）如何隔离与治理？

1.6.6 成本（Cost）：硬件、连接、平台与运维的总拥有成本

物联网成本不应只看 BOM（硬件物料），而应看 TCO（Total Cost of Ownership）：

• 端侧：硬件成本、功耗导致的电池/维护成本、现场安装成本；
• 网侧：流量资费、专线/VPN 成本、网关部署；
• 云侧：消息接入、存储与计算成本；
• 运维：设备故障处理、上门维护、备件管理、合规审计。

> 侧栏：一个常见陷阱 > 早期 PoC 只关注“能连上、能显示”，忽略 OTA、日志、告警、权限、审计等运维能力；当规模扩大后，这些“非功能”会迅速成为交付瓶颈。

1.7 三个案例：把抽象架构落到真实场景

1.7.1 案例一：智能恒温与家庭能耗优化（IoT/智能硬件）

目标：在保证舒适度的前提下降低能耗，并支持 App 远程控制与自动场景联动。 端：温湿度传感器、红外/继电控制、可能含本地 AI（入住检测）。 网：家庭局域网（Wi‑Fi/BLE Mesh），外网通过路由器出站；需考虑 NAT、断网。 云：设备影子（同步状态）、规则引擎（如“回家前 10 分钟开启空调”）、数据分析（能耗统计）。 用：移动端控制、家庭成员权限（儿童/访客）、与语音助手集成。

关键约束与策略：

• 隐私：家庭作息可被能耗曲线推断，需最小化采集与明确授权；
• 可靠性：断网时仍需本地可控；
• 成本：若上报频率过高会抬升云端与网络成本，需用事件 + 低频状态组合。

1.7.2 案例二：设备预测性维护（IIoT）

目标：对电机/泵/风机等旋转设备进行故障早期预警，降低非计划停机。 端：振动、温度、电流传感器；采样频率可能从 Hz 到 kHz 量级不等。 边缘：特征提取（RMS、峭度、频谱峰值）、局部模型推断、断网缓存。 网：产线网络通常与办公网分区，需严格边界与白名单策略。 云/平台：资产模型、工况标签、模型训练与版本管理、告警与工单系统。 用：维修计划、备件管理、KPI（MTBF 提升、停机时间下降）。

关键约束与策略：

• 实时与确定性：某些保护动作必须在现场完成，云端不承担硬实时控制；
• 可靠性：需要完整的设备生命周期管理与标定记录，否则模型解释性与可追溯性不足；
• 安全：工业网络的访问控制与审计要求更严，通常采用分区隔离与最小暴露面。

1.7.3 案例三：城市停车与诱导（城市 IoT）

目标：感知车位占用，提供诱导与计费，辅助城市治理。 端：地磁/视频/道闸等多类型设备，供电条件差异大。 网：NB‑IoT/4G/专网混用，存在盲区与漫游。 云/平台：多租户（不同运营方/区域）、数据融合（车位、路网、支付）