1. 课程导入与架构设计总览
在开始学习 TIA Portal 的具体操作之前，先建立一个整体认知：自动化项目架构设计并不是“把程序写出来”这么简单，它指的是在动手编程之前，对项目的硬件组成、网络结构、程序组织、数据流向、接口边界和交付标准做出系统性的规划。TIA Portal（全集成自动化门户）把 PLC 编程、HMI 组态、驱动配置、网络组态和诊断功能集成在同一个工程环境中，这既带来了便利，也意味着如果前期架构混乱，后期修改成本会成倍增加。因此，本课程的第一节不急于打开软件，而是先回答三个问题：架构设计到底设计什么、它要达成什么目标、最终交付什么。
一、什么是自动化项目架构设计
可以把一个自动化项目拆成四个层次来看：硬件层（PLC、IO 模块、变频器、仪表、执行机构）、网络层（PROFINET、PROFIBUS、以太网、远程 IO）、程序层（OB/FB/FC/DB 的组织方式）和人机层（HMI 画面、报警、配方、权限）。架构设计就是在这四层之间建立清晰的对应关系和边界约定。
举个具体例子：一条包装线需要 1 台 S7-1200 PLC、2 台 G120 变频器、1 台 KTP700 触摸屏和 16 个远程 IO 站点。架构设计要回答的不是“怎么写电机启动程序”，而是：变频器走 PROFINET 还是硬接线？远程 IO 用几个站点、如何分配 IP？程序按设备分 FB 还是按功能分 FB？HMI 报警号与 PLC 报警位如何一一对应？这些问题一旦确定，后续编程就是“填空”；如果没确定，编程就会变成反复返工。
二、架构设计的目标
架构设计的目标可以归纳为四条，它们之间是相互制约的：
- 可运行：满足工艺要求，控制逻辑正确、联锁可靠、故障可安全停机。
- 可维护：程序结构清晰，命名规范统一，别人（或半年后的自己）能快速定位问题。
- 可扩展：预留 IO 点、网络地址、DB 空间和程序接口，增加设备时不需要推翻原有结构。
- 可交付：图纸、程序、注释、备份、文档齐全，能通过验收并支持后续运维。
这四条目标中，初学者最容易忽略“可维护”和“可扩展”。一个能跑起来的程序，如果所有逻辑都塞在 OB1 里、变量名是 M0.0、M0.1，那么三个月后连作者自己都不敢改。架构设计的价值，正是在项目早期用少量时间换取后期大量的修改成本。
三、交付物与全流程
一个完整的 TIA Portal 项目，最终交付的不只是程序文件。典型的交付物包括：硬件配置与网络拓扑图、IO 分配表、程序结构说明、HMI 画面与报警清单、参数备份文件、以及必要的操作与维护说明。这些交付物不是形式主义，它们对应着项目不同阶段的设计决策。
从需求到落地的全流程，可以概括为下面这张图所表达的关系。它强调的不是“步骤顺序”，而是每一层设计如何向下传递约束、向上反馈验证：
图中上半部分是“设计决策”，下半部分是“实现与交付”。需要特别注意的是右侧那条橙色虚线：验证反馈与迭代。架构设计不是一次性的，现场调试中发现的 IO 点不足、通信干扰、报警遗漏，都会反向修改硬件或程序结构。好的架构设计不是“一次做对”，而是“改起来不痛苦”。
四、一个可参考的架构设计检查清单
在项目启动阶段，可以用下面这份清单快速自检。它不是强制模板，而是一个防止遗漏的思考框架：
| 设计项 | 需要确认的内容 | 典型输出 |
|---|---|---|
| 硬件配置 | PLC 型号、IO 点数、模块顺序、电源容量 | 硬件清单、IO 分配表 |
| 网络规划 | 设备名、IP 地址、拓扑结构、通信协议 | 网络拓扑图、地址表 |
| 程序结构 | OB 划分、FB/FC 命名、DB 分类、接口变量 | 程序结构图、变量表 |
| HMI 规划 | 画面层级、报警分组、权限等级、配方结构 | 画面清单、报警清单 |
| 交付标准 | 备份方式、注释要求、文档格式、验收条件 | 交付清单、验收记录 |
以 IO 分配为例，假设一条输送线有 8 个启动按钮、8 个停止按钮、8 个电机接触器反馈和 4 个光电传感器，那么数字量输入至少需要 20 点，输出至少 8 点。如果选用 S7-1200 CPU 1214C（14DI/10DO），就需要额外扩展一个 8DI/8DO 模块。这个计算过程就是架构设计中最基础的“点数核算”，它直接决定硬件采购和机柜布局。
总结来说，TIA Portal 自动化项目架构设计的本质，是在需求与实现之间建立一座结构化的桥梁。它要求我们同时具备工艺理解能力、硬件选型能力、网络规划能力和软件组织能力。本节建立的“需求—硬件/网络—程序—HMI—交付”五层框架，以及“可运行、可维护、可扩展、可交付”四条目标，将作为后续所有章节的判断依据：每学一个功能，都要问它落在哪一层、解决什么问题、对交付有什么影响。