引用10楼详细内容：

当然可以。但这样会加重PLC负担，PLC是个对用户而言单线程的东西。站在工业的5层金字塔的高度看，不是好选择，扩展性不行。还是盯着眼前的具体案例不放。

上位机就干这个用的。多线程随便驾驭，随意分层架构，资源和手段海量，PLC根本比不了。和上位机比，PLC就是个穷人，而且是赤贫那种。

PLC负责提供数据接口。通信中最好内嵌自定义协议。可以同时具备Client模式主动发消息通知，和Server模式由上位机主导外部交互。Log在上位机形成，和报警及数据库处理都放在通信层之上的服务层解决掉。在上位机做这种事，太灵活太容易了，手段多样。各种各样的，一大堆各种位于不同层的对象，和很多静态线程，通过接口框架被集成到一起运转。啥是接口？就是规格化的功能。

在工业大架构里，尽量少干扰PLC的工作和负荷。PLC是负责工厂车间地面的，不是用来做数据分析处理的，尤其是当它位于工业IT架构之中的时候。有的人用PLC来和数据库直接交流，这样的选择是短视的。

至于具体协议，都是局部的对象运用，在上位机可以随便搞。面向接口，几种工厂模式，就可以轻松搞定。反之要让PLC干这个，会把它累够呛，资源和手段极度受限。

和上位机有关的东西，玩的就是架构，不是局部技术，尽管技术细节是基础。但是多数搞工控的人，也许是和底层细节打交道多了，总是喜欢把头扎到技术细节中，而对整体的架构构建这样的关键核心忽视不见。

.Net平台和生态提供了海量的对象资源。技术细节根本不是问题，就是熟练功课的事儿，核心还是用接口来搭建分层设计。

所有的具体需求都得封装成各种对象，但这些具体的对象，完全是通过接口体系的规格集合，来动态载入、调度和运转的。

现在的设计早就不是字面上的面向对象的意思了。对象都被剥离出去，做单独的实体依赖性管理。设计越来越框架化、标准化、大型化、跨平台化。web访问、手机App，VR眼镜、PC机等，都是不同的个性平台实例，而软件的架构是通用的，不是面向具体某个平台的。一次开发，多平台部署，都是这种。

以数据库为例。数据库种类太多了，各种各样的数据库，各种云，或者你想保存在Excel，等等。各种存储方式的接口都不同，就需要创建多种不同的对象，来针对性处理数据库业务。为什么需要层呢？就是因为实用的业务是很复杂多变的，不是简单的单一对象能应付的。简单化应对的都不好用，未来变化扩展都锁死。这些对象都是根据需求，动态生成和加载。这都是PLC做不到的。也许有人说：先解决眼前需求再说，遇到新案例再重新另写。如果这样对待，业务稍微复杂化就行不通。这样的付出方式，对程序员来说没有未来。

引用9楼详细内容：

PLC程序能不能像高级语言一样记录一些关键程序Log！通过Mqtt +消息列队 把PLC程序执行Log【包括报警Log】发给C#存入数据库或保存文件的形式！便于以后查询！