📚 课程目录第4章操作系统与运行环境

4、操作系统与运行环境：Linux系统裁剪、Docker容器化部署、实时内核（RT-Preempt）配置

边缘计算网关作为连接厂务PLC与上层信息系统的核心枢纽，其操作系统与运行环境直接决定了数据采集的实时性、系统的稳定性以及部署运维的便捷性。本章将深入讲解如何构建一个专为工业现场设计的轻量级、高实时、易维护的软件运行底座，涵盖Linux系统裁剪、Docker容器化部署以及RT-Preempt实时内核配置三大核心模块。

4.1 工业级Linux系统裁剪

通用Linux发行版（如Ubuntu Server、Debian）包含大量工业边缘场景不需要的服务和组件，不仅占用宝贵的存储和内存资源，还会增加攻击面和系统启动时间。系统裁剪的目标是移除所有非必要组件，构建一个仅包含内核、核心库、必要驱动和特定应用的最小化运行环境。

  裁剪核心原则： 最小权限、最小依赖、最小攻击面。只保留PLC通信驱动（如Profinet、EtherNet/IP、Modbus TCP）、边缘数据处理服务、Docker运行时及SSH管理服务。

4.1.1 裁剪方法与工具链

常用的裁剪方法包括使用Yocto Project、Buildroot或基于Debian的debootstrap进行手动精简。对于厂务场景，推荐使用Yocto Project，因为它能提供完整的交叉编译环境和灵活的定制能力。

裁剪工具	适用场景	镜像大小（典型值）	定制灵活性	学习曲线
Yocto Project	大规模量产、硬件固定、深度定制	50 MB – 200 MB	极高	陡峭
Buildroot	中小规模、快速原型、简单嵌入式	30 MB – 150 MB	高	中等
debootstrap + 手动精简	单台或少量网关、快速验证	200 MB – 500 MB	中等	较低

厂务实践建议： 对于采用x86或ARM64架构的通用边缘网关，优先选择Yocto Project。它允许你精确控制内核配置、驱动模块和用户空间库，确保系统仅包含PLC协议栈（如libplctag、Snap7）和Docker所需的依赖。

4.1.2 裁剪后的系统组件清单

一个典型的裁剪后Linux系统应包含以下核心组件，其余均可移除或按需添加：

内核： 启用RT-Preempt补丁，裁剪无用驱动（如显卡、声卡、蓝牙），保留网卡、存储、GPIO、I2C、SPI及实时时钟驱动。
核心库： glibc（或musl libc）、libpthread、librt、libstdc++。
基础工具： busybox（替代coreutils）、dropbear（替代OpenSSH）、systemd（或sysvinit）。
运行时： Docker CE、containerd、runc。
PLC通信： 根据现场总线类型，预装对应的用户态驱动或库。

4.2 Docker容器化部署

在裁剪后的Linux系统上，Docker容器化部署是管理边缘应用的最佳实践。它将PLC数据采集服务、本地处理逻辑、边缘AI推理等模块封装为独立的容器，实现环境隔离、版本管理和快速迭代。

4.2.1 容器化架构设计

厂务边缘网关的容器化部署通常采用微服务架构，每个容器负责单一职责：

采集器容器： 运行PLC通信库（如Snap7、libplctag），负责轮询或订阅PLC数据点。
处理容器： 运行数据清洗、格式转换、阈值判断等本地处理逻辑。
转发容器： 将处理后的数据通过MQTT、OPC UA或REST API上传至中心平台。
管理容器： 提供本地Web管理界面或REST API，用于配置采集点和查看运行状态。

注意： 容器化部署时，必须将PLC通信所需的网络接口（如host模式或macvlan）正确映射。对于Profinet等实时以太网协议，建议使用host网络模式以避免NAT带来的延迟抖动。

4.2.2 Docker Compose编排示例

以下是一个典型的docker-compose.yml文件，用于启动采集、处理和转发三个服务：

version: '3.8'

services:
  plc-collector:
    image: factory-edge/plc-collector:1.2.0
    container_name: plc-collector
    network_mode: "host"
    volumes:
      - ./config/plc_points.yaml:/app/config/plc_points.yaml:ro
      - ./data:/app/data
    restart: unless-stopped
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

  data-processor:
    image: factory-edge/data-processor:1.1.0
    container_name: data-processor
    depends_on:
      - plc-collector
    volumes:
      - ./config/rules.yaml:/app/config/rules.yaml:ro
      - ./data:/app/data
    environment:
      - LOG_LEVEL=info
      - PROCESS_INTERVAL_MS=100
    restart: unless-stopped

  mqtt-forwarder:
    image: factory-edge/mqtt-forwarder:1.0.0
    container_name: mqtt-forwarder
    depends_on:
      - data-processor
    environment:
      - MQTT_BROKER_URL=mqtt://192.168.1.100:1883
      - MQTT_TOPIC_PREFIX=factory/line1/gateway
    restart: unless-stopped

4.2.3 容器化部署的优势

特性	传统部署（裸机）	Docker容器化部署
环境隔离	依赖系统全局库，易冲突	每个容器独立文件系统，互不干扰
版本管理	手动更新，回滚困难	镜像标签化管理，秒级回滚
资源限制	进程抢占，无精细控制	cgroups限制CPU/内存/IO
启动速度	分钟级（依赖系统初始化）	秒级（容器进程直接启动）
批量部署	逐台配置，易出错	镜像仓库分发，一键拉取运行

4.3 实时内核（RT-Preempt）配置

厂务PLC数据采集对实时性有严格要求。标准Linux内核的调度延迟通常在几毫秒到几十毫秒不等，无法满足PLC扫描周期（通常为10ms-100ms）内的确定性响应。RT-Preempt（Real-Time Preemption）补丁通过将内核中的自旋锁和中断控制器替换为可抢占的互斥锁，使Linux内核具备硬实时能力。

4.3.1 RT-Preempt核心原理

RT-Preempt的主要改造点包括：

中断线程化： 将硬件中断处理程序转换为内核线程，允许被更高优先级的实时任务抢占。
自旋锁替换： 将spinlock替换为支持优先级继承的rt_mutex，避免优先级反转。
高精度定时器： 启用HRTIMER，提供微秒级定时精度。
内核抢占点： 在内核代码中增加更多可抢占点，降低最大延迟。

  关键指标： 经过RT-Preempt优化后，典型x86网关的最大调度延迟可从数毫秒降低至50μs以下，ARM64网关可控制在100μs以内，完全满足厂务PLC数据采集的实时性要求。

4.3.2 配置与验证步骤

以下是在Yocto或Buildroot中启用RT-Preempt的标准流程：

获取内核源码： 从kernel.org下载与RT-Preempt补丁版本匹配的内核源码。
应用补丁： 使用patch命令将RT-Preempt补丁打到内核源码树。
配置内核： 执行make menuconfig，启用以下选项：
- CONFIG_PREEMPT_RT_FULL=y (Fully Preemptible Kernel)
- CONFIG_HIGH_RES_TIMERS=y
- CONFIG_NO_HZ_FULL=y (可选，减少定时器中断)
编译与部署： 编译内核及模块，将生成的zImage/bzImage和设备树文件部署到网关。
验证实时性： 使用cyclictest工具测量调度延迟。

4.3.3 实时性测试与调优

部署RT-Preempt内核后，必须进行实时性验证。以下是一个典型的cyclictest命令及输出解读：

# 运行cyclictest，测量10000次，间隔1000微秒，优先级80
cyclictest -l 10000 -m -n -p 80 -i 1000 -h 100

# 输出示例：
# T: 0 (7) P: 80 I: 1000 Min:      3 Act:    5 Avg:    6 Max:     47
# T: 1 (8) P: 80 I: 1000 Min:      3 Act:    4 Avg:    5 Max:     42

输出字段说明：Min为最小延迟，Act为当前延迟，Avg为平均延迟，Max为最大延迟。对于厂务PLC采集场景，要求Max值不超过500μs，且无异常尖峰。

调优注意： 如果最大延迟超过预期，应检查以下因素：BIOS中是否关闭了CPU节能状态（C-States）、是否绑定了实时任务到独立CPU核心（isolcpus）、以及是否屏蔽了不必要的硬件中断（使用irqbalance或手动设置SMP affinity）。

4.4 本章小结

操作系统与运行环境是边缘计算网关的软件基石。通过Linux系统裁剪，我们移除了工业现场不需要的冗余组件，将系统体积缩小至通用发行版的十分之一以下，同时降低了安全风险。Docker容器化部署则让PLC数据采集、本地处理和转发服务实现了标准化封装与独立运维，大幅提升了部署效率和系统可靠性。最后，RT-Preempt实时内核的配置确保了数据采集任务的确定性延迟，使通用Linux平台能够胜任原本需要专用实时操作系统的厂务控制场景。三者结合，构成了一个轻量、灵活且坚如磐石的边缘计算运行环境。