一、自动化设备软件架构概述

大家好，我是老张。在自动化设备这个行当摸爬滚打了十几年，今天咱们来聊聊设备端软件架构这件事。说实话，我刚入行那会儿，哪有什么架构概念，代码能跑就行。后来吃了不少亏，才慢慢悟出些门道。

1.1 什么是设备端软件

设备端软件，说白了就是跑在自动化设备上的那套程序。它不像手机App那么花哨，也不像网站后台那么复杂。但它有个特点——得跟硬件打交道。

我遇到过不少刚转行的朋友，总觉得设备软件就是写写PLC逻辑。其实远不止这些。一套完整的设备端软件，通常包含：

• 运动控制模块：控制伺服电机、步进电机怎么转、转多少
• IO管理模块：处理传感器信号、控制电磁阀通断
• 通信协议栈：跟PLC、上位机、MES系统打交道
• 状态机引擎：管理设备的各种工作状态和切换逻辑
• 异常处理机制：出错了怎么恢复、怎么报警

你想想看，这些模块要是都揉在一个文件里，那维护起来得多痛苦？

1.2 架构设计的核心目标

为什么要搞架构设计？我个人的理解，核心就三个目标：

目标	说明	我的经验
可维护性	代码改起来不费劲，加功能不伤筋动骨	我曾经接手过一个项目，改一行代码要翻3个文件，那叫一个酸爽
可复用性	换个设备型号，核心代码还能用	我习惯把通用逻辑抽成库，新项目直接引用，省事多了
可靠性	设备7x24小时跑，不能动不动就死机	嗯，这一点在工业现场尤其重要，停机一分钟就是钱啊

1.3 常见架构模式介绍

这些年我接触过的设备软件架构，主流的有这么几种。每种都有它的适用场景，没有银弹。

分层架构

这是最经典的模式，也是我入行时学的第一种。说白了就是把代码按职责分成几层：

┌─────────────────────┐
│    应用层            │  ← 业务逻辑、工艺流程
├─────────────────────┤
│    服务层            │  ← 任务调度、状态管理
├─────────────────────┤
│    驱动层            │  ← 硬件抽象、IO操作
├─────────────────────┤
│    硬件层            │  ← 实际物理设备
└─────────────────────┘

我建议新手先从分层架构入手。它好理解，也好维护。但要注意一点：别让上层直接调用下层，那样分层就失去意义了。

事件驱动架构

这种模式在自动化设备里特别常见。为什么呢？因为设备本质上就是对外部事件做出响应。

举个例子：

• 传感器触发 → 启动传送带
• 到位信号到达 → 执行抓取动作
• 报警信号触发 → 停止所有运动

事件驱动架构的核心就是：

事件源 → 事件总线 → 事件处理器

我做过一个贴片机项目，用了事件驱动模式。每个模块只管自己关心的事件，互不干扰。后来加了个新的检测功能，只需要注册一个新的事件处理器就行，完全不影响现有逻辑。

微服务架构

听到微服务，你可能觉得这是互联网公司的玩意儿。其实在大型自动化设备里，微服务也挺实用。

比如一台复杂的贴片机，可以拆成：

• 供料器服务
• 贴装头服务
• 视觉定位服务
• 传送带服务

每个服务独立运行，通过消息队列通信。这样好处很明显：

• 某个服务挂了，不影响其他服务
• 可以单独升级某个服务
• 资源分配更灵活

但说实话，微服务在设备端用得不多。因为设备资源有限，跑那么多进程太奢侈。我一般只在高端设备或者产线级系统里用。

1.4 三种模式的对比

模式	优点	缺点	适用场景
分层架构	结构清晰、易上手	层间耦合、不够灵活	中小型设备、新手团队
事件驱动	松耦合、响应快	调试困难、事件风暴	IO密集型、多传感器设备
微服务	独立部署、高可用	资源消耗大、复杂度高	大型设备、产线级系统

1.5 架构选型建议

说了这么多，到底该选哪种？我个人的经验是：

• 别为了架构而架构。一个简单的传送带控制，用分层架构就够了，非得上微服务，那是给自己找麻烦。
• 可以混搭。我做过一个项目，整体用分层架构，内部模块之间用事件驱动。效果还不错。
• 考虑团队水平。如果团队都是新手，先搞分层架构。等大家熟练了，再引入更复杂的模式。

1.6 本章知识体系

下面这张图，是我画的本章节知识结构。你可以把它当作一个思维导图来看：

这张图把本章的核心内容串起来了。你仔细看看，其实设备端软件架构没那么玄乎。说白了就是：搞清楚要做什么（软件组成），想清楚为什么做（核心目标），选好怎么做（架构模式）。