如何用树莓派diy一个边缘计算plc？看完这篇你可以出师了！

part.01

为啥要用“树莓派”？

raspberrypi(中文名为“树莓派”)是为学生计算机编程教育而设计，只有信用卡大小的卡片式电脑。树莓派基于开放式linux系统，可以自由进行c/c++、python、javascript等等编程语言的开发，为众多编程爱好者提供了的学习测试平台。借助于开放式的软硬件资源，让我们快速实现iec61131-3标准的边缘计算plc产品成为了可能。

什么是边缘计算plc？

正式介绍实现树莓派边缘计算plc之前首先我们还是需要看看边缘计算plc的概念提出的背景。在工业4.0时代，传统的控制技术ot(operationtechnology)与信息技术it(informationtechnology)的边界越来越模糊，目前在工业自动化领域如果需要将传统plc控制器与it系统进行结合，大量使用网关产品，在目前阶段也许这是无奈之举。

但是系统架构的复杂化大大增加了工业数据的延时，降低了大数据的采集效率，从而制约了未来的工业大数据分析的性。同时所有的工业原始数据将由云平台服务器进行收集以及分析，随着工厂应用越来越复杂，云平台的算力限制以及数据库的臃肿不堪都将使得未来工业智能面临极大的挑战。

因此，我们需要尽可能简化工业4.0时代的系统设计，需要一种新型的plc产品能够将ot与it技术相融合，既能高速处理工业现场ot数据，同时能够承担与it系统的开放式交互，并且具有一定的运算能力可以对大量的工业现场ot数据进行预处理，仅仅交付云平台需要的数据，而不是所有的数据处理功能都在云平台上完成，这就是我们理想中的边缘计算plc。

为了实现这一目标，除了强大的数据处理能力，大容量的存储器等等硬件支持以外，在软件上需要同时支持开放式ot与it平台，例如：iec61131-3编程、plcopenmc运动控制、ethercat、canopen、modbus等等传统ot技术，开放式物联网编程平台node-red、本地嵌入式数据库、opc-ua、mqtt等等it技术。

而树莓派作为的主角是一个非常不错的硬件平台，同时基于x86架构的pcbased解决方案则会为我们开启另外一扇窗，本部分文章中，我们将聚焦分析树莓派实现边缘计算plc的关键技术点。

树莓派硬件用于工业控制可能会有啥问题？

稳定可靠的硬件是工业控制器的基础，即使有强大的开源社区软硬件资源的支持，但是由于标准的树莓派（包括新的树莓派3b/3b+/4b）产品硬件不是面对工业级的应用而设计，仅仅适用于实验、学习与测试，而不适合于在环境较复杂以及对可靠性要求较高的工业现场进行使用。面对工业级产品应用，树莓派官方社区发布了新的树莓派3b+compute module核心板（后面统一简称树莓派cm核心板），通过ddr2sodimm接口连接扩展板信号，可以用于工业级控制器产品设计：

这里我们也为大家初步整理了下树莓派3b+ compute module核心板的相关技术参数：

处理器：broadcom bcm2837b0, cortex-a53 (armv8) 64-bit soc @1.2ghz

ram存储器：1gb lpddr2 sdram

flash存储器：8gb/16gb/32gb emmc flash

工作温度范围：-25℃ - 80℃

硬件认证：

electromagnetic compatibility directive (emc) 2014/30/eu

restriction of hazardous substances (rohs) directive2011/65/eu

维护截止日期：2026年1月

从整体硬件规格来看，树莓派cm核心板在硬件设计上保持比较高的规格，处理器性能较高，存储器空间非常大，成本较低，符合工业级的温度以及硬件认证要求，并且其硬件设计原理图完全都公开，因此基于树莓派cm核心板实现的plc产品可以有极高的运算性能与超大的存储器空间。

但是经过全面分析，我们认为树莓派cm核心板处理器面向工业控制应用时，其外设接口上依然偏少，比如实现工业控制器的rs232/rs485/rs422接口的uart外设只有2个，没有can总线接口，以太网必须通过usb接口的芯片扩展出，大大限制网络交互实时性，对于一些速度要求较快的现场总线将会是较大的挑战：如ethercat，主要受限于该模块内部的usb转以太网接口芯片的带宽以及usb芯片处理以太网报文的实时性。

当然我们需要给予基于树莓派cm核心板开发的工业控制器产品一个合适的定位，充分发挥出其硬件特点。通常传统工业控制器使用的处理器主频较低，存储器空间非常有限，因此对于树莓派cm工业控制器来说，就是应该发挥出其高性能运算以及大存储容量的特点，原来传统工业控制需要上到云端进行的运算以及数据存储，可以根据需要下放到树莓派cm工业控制器上实现，这就是我们在前面介绍的边缘计算plc的概念，同时其还可以通过工业现场总线以及通讯协议与其他工业控制器或者传感器进行通讯，如：modbus、canopen、ethercat、opc-ua等等。

关于硬件部分，后需要特别说明的一点：树莓派cm核心板处理器发热较严重，设计需要做好散热工作，同样其功耗较高，并不适合一些低功耗或者对控制器发热量有要求的应用场景。

part.02

树莓派提供了标准开源linux系统raspbian（基于debian的发行版）支持，但是标准的linux用于工业控制系统时，我们永远绕不开一个话题：实时性realtime。

工业控制器到底是否需要实时性？

工业控制器到底是否需要实时性？这是在开发工业控制器产品时很常见的问题。实时性的定义就是系统在规定时间内的响应能力，这里的“规定时间”没有明确的定义，因此实时性的要求是与实际现场应用紧密结合的。

举个例子，例如：我们使用手机过程中，点击一个界面后，手机响应快一点或者慢一点，我们的使用者感觉是不一样的，这个就是一种实时性的体现。

安卓系统手机使用时间越长，响应速度会越慢，实时性就越低，而苹果手机相对安卓手机的实时性就要高很多，所以感觉更流畅，因此我们对手机的实时性是有要求的。但是日常生活中的应用要求实时性要求并不高，并且即使出现了偶然性的超时，并不会造成严重的后果，多体验上稍稍差了点，这就是软实时的概念。

在咱们工业自动化领域的控制器则有些小目标，有些工业应用场景要求非常高，在接收到外部信号后需要立即进行处理并输出信号，通常使用plc中断子程序来进行处理。而要求不是很高的场景通常使用指定的周期进行循环即可：读取i/o信号->进行逻辑处理->输出i/o信号，通常根据应用场景不同达到jingque的1-500ms的plc程序执行循环周期，plc工作原理如下图所示：

无论是触发外部信号中断立即执行plc程序逻辑，还是jingque定时从而可以达到jingque的1-200ms循环周期执行plc程序逻辑，本文中涉及树莓派的linux操作系统实时性就是非常关键的因素，而实时性与操作系统的定时精度、中断响应时间、任务切换时间等等因素的确定性都息息相关，相关因素的时间需要具有严格确定性才可以称之为硬实时。

不同场景以及对plc循环周期的要求

这里我们通过下面的例子讲解不同的应用场景对于实时性以及plc循环周期的要求：

运动控制场景

控制器通过ethercat总线控制驱动器，plc系统通常需要在收到数据50us以内就做出总线数据处理，这样才能实现稳定的1ms周期循环发送位置指令给驱动器。

工厂自动化场景

智能制造工厂内的实时数据需要稳定实现4-32ms的周期性数据通讯。

过程控制场景

而过程控制应用场景（如水处理、油气、化工、电力等等行业）控制周期则在100-500ms范围。

但是无论如何，工业控制器作为工业自动化的核心大脑，是不允许出现任何偶发性超出实时性要求的情况发生，不然会对整个复杂的工业现场造成极大的风险，这就是硬实时的概念，也是一些国产品牌工业控制器不稳定的源头之一（在研发工业控制器产品前，操作系统选型上可以参考国外类似控制器产品的选型，尽可能选用稳定可靠的实时操作系统，如：freertos、embos、keilrtx、rt-thread、ucosiii、vxworks、qnx、rtx64、intime等等。如果一定需要用到linux系统，那么请注意开发面向运动控制的产品尽量选用rtai与xenomai而不是preempt-rt实时内核补丁，关于实时操作系统分析与linux实时内核的扩展，我们可以在以后的文章中再详细与大家一起分享）。

因此对于开发工业控制器的工程师与产品经理而言，一定不能抱有侥幸心理，一定要选择稳定可靠的实时操作系统（rtos）构建工业控制器的基础平台，除非是现场的实际应用需求只有软实时的要求，系统实时性出现问题不会造成重大的现场问题，例如：智能楼宇商用应用场合，灯光、风机、空调开关偶然性慢一点虽然好能够及时响应，但是偶然超出设计指标也不会造成什么问题，那么这种场合下软实时的要求就可以了。

回到树莓派的话题上，树莓派支持的传统的linux系统raspbian是没有任何硬实时的支持，因此将树莓派cm核心板用于实现工业控制器时，一定需要对标准的linux其进行升级改造才能提高其实时性。因此这里我们对标准的树莓派linux系统进行了升级改造，集成linux的preempt-rt实时内核补丁，将树莓派上标准的控制差的响应延时从不确定的>200us（通常在200-500us，但是随着处理器负荷提高，偶发性的响应延迟将达到ms级别以上）控制在确定的<120us以内（通过cyclictest工具在处理器满负荷情况下测定）。

这里提到的确定性就是达到硬实时的一个条件，只要能确保这个响应的完全确定性，那么就可以认为其达到了硬实时，虽然不同场合下对硬实时的要求是有不同，具体还是得结合应用场景来进行分析。

因此我们这里对前面文章中树莓派硬件与基础平台linux操作系统得出结论：

1、经过preempt-rt实时性优化后，树莓派可以达到<120us以内的硬实时响应要求，对应于工业自动化领域内的通用工厂自动化、过程控制、智能楼宇等等对硬实时要求不高的应用。

2、由于处理器功耗与发热量较大，在低容量电池供电（agv小车电池容量较大，相对于x86解决方案功耗依然较小，因此也适用），以及对于控制器发热量有防爆要求的场景需要慎用（例如煤矿、油气现场控制器等）。

3、由于树莓派cm核心板需要通过usb接口扩展出以太网接口，因此对于要求较高的工业以太网现场总线（如:ethercat）需要进一步考量其稳定性和确定性，防止现场出现偶发性故障风险。

part.03

前面两部分我们着重分析了树莓派cm核心板应用于工业场景的软硬件优劣势。在这一部分内容中我们将正式引入实现边缘计算plc的软件平台iec61131-3标准logiclab与开放式物联网开发平台node-red。

为什么选择iec61131-3标准？

从1968年美国gm（通用汽车）公司提出取代继电器控制装置的要求，并在第二年美国数字公司研制出了代可编程序控制器plc以来，plc产品经历了20多年的发展后，诞生了大量编程风格的技术与产品。不同plc厂家对于plc理解的不同，都有各自的技术实现，编程语法风格也越来越多，造成使用者在不同厂家plc产品之间转换碰到极大的挑战。

1993年，在那个plc战火纷飞的年代，iec61131-3标准（初次命名为iec1131-3，后更名为iec61131-3，后文统称iec61131-3标准）终于诞生了，国际电工委员会（internationalelectrotechnicalcommission，简称iec）搜集了市场上主流plc编程标准，并在1993年制定了iec61131-3标准用于统一plc的编程语法（五种主流plc编程语言，包括功能块图fbd、梯形图ld、结构化文本st、顺序流程图sfc与指令表il）、通用plc架构模型（配置configuration、资源resource、多任务multitask、变量variable、地址address、程序program、功能function、功能块functionblock、功能/功能块二次封装与代码重用等等概念）。

到离iec61131-3标准的诞生已经将近三十年时间，plc产品经历了漫长的发展与变革，在近十年间西门子、三菱、欧姆龙、施耐德、罗克韦尔等等业内企业都在逐步支持iec61131-3的编程体系与系统模型。而在欧洲iec61131-3标准则是plc编程的入门必经之路，几乎每一位plc工程师都是从iec61131-3标准中的fbd、ld、st语言入门学习，而在我国则远远落后，这里我们就不深挖，在以后的文章中我们再与大家一同分享。但是无论怎样，面对未来的plc产品开发与应用，iec61131-3标准毫无疑问是未来工业自动化控制系统长远发展的大方向。

前面聊了下iec61131-3标准的历史与近些年的发展，那么对应到具体树莓派边缘计算plc产品上，我们需要支持面向ot应用的iec61131-3控制技术与面向it应用的开放式物联网平台，项目规划之初我们再次面临选择：完全自主研发iec61131-3编程软件与控制器产品or 基于成熟软件技术由团队协助进行二次开发？

为什么成熟iec61131-3技术伙伴？

为什么中小企业应成熟iec61131-3技术伙伴而不是自主研发基础平台？

首先我们依然聚焦在iec61131-3标准的控制器平台技术上，从iec61131-3诞生到已经将近三十年时间，欧美日的plc控制器企业早早开始投入大量资金研发符合iec61131-3标准的控制器平台软件与硬件产品，而国内企业起步相对较晚。由于工业自动化市场细分行业较多，并且单个细分市场的体量较小，这些工业自动化细分领域的公司难以投入巨量的资金进行基础iec61131-3平台研发工作。根据过去十年我们的经验，如果期望自主研发具有一定国际竞争力的覆盖小型、中型以及大型的plc系统，投入的研发资金可能会达到大几千万到上亿元人民币不等，从产品规划、研发、市场推广应用，并具备一定的影响力可能需要5-20年时间，这对于国内大量的工业自动化细分行业企业来说，是非常大的一个挑战。

大量企业需要自主研发符合iec61131-3标准的控制器产品，而自主研发投入又是巨大的资金需求，因此欧美在过去的二十多年诞生了专门为这些中小企业实现iec61131-3标准控制器的plc软件解决方案公司，这里我介绍一下我所在的翌控科技的战略合作伙伴意大利axels.r.l.公司，在二十年前意大利axels.r.l公司成立并开始为伺服驱动器与变频器厂商在非常有限的处理器平台上实现高性能的plc编程软件与运行时runtime，这些设备空闲存储器资源非常有限，通常按照kb级别来计算，同时由于运行了高速的算法，空闲的处理器资源也相当有限，因此axel公司的plc代码编译器与运行时runtime就是面向低资源、高性能、扩展性强为目标而设计。

我们在工业自动化iec61131-3软件平台方向上努力十年时间，虽然相对整个plc发展历史来说只是弹指一瞬间，但是借助于这十年的iec61131-3标准、现场总线、运动控制、各种处理器平台、实时操作系统等等技术的积累，同时与axel公司深度绑定与合作，将继续为国内企业提供贴近客户需求的稳定、高效、开放的plc系统级解决方案。

相信到这里，大家应该已经明白自主研发iec61131-3标准的plc产品，应该如何布局未来研发路线。从目前工业自动化市场格局来看，大多数的plc控制系统都把持在欧、日、美三大派系企业上，所以对于我们各个工业自动化细分领域的企业来说，首先确保控制系统硬件产品完全自主研发，并且通过与国内外的软件技术合作伙伴合作实现iec61131-3平台与系统，再逐步自主研发，这可能是更稳妥的路线。

怎么快速实现树莓派边缘计算plc？

笔者认为，与我们共同合作开发是快速、稳定、风险小的路线。目前我们已经提供标准iec61131-3标准的logiclab编程工具，包括支持五种标准编程语言（fbd、ld、st、sfc与il）与实时多任务架构，同时支持丰富的调试手段与功能（在线变量实时监控、包括强制、软件示波器、断点与单步调试等等功能），logiclab编程工具可以进行oem贴牌以及进行二次扩展开发进行开放式定制，另外也支持modbus、canopen、ethercat等现场总线，hmi与运动控制等等解决方案：

基于树莓派标准硬件平台，使用logiclab系统可以通过树莓派扩展i/o控制工业信号，如下图所示：

也可以对modbus总线进行组态，实现plc之间的站间访问，而在未来我们也将为树莓派can总线扩展板添加canopen协议以及访问自定义协议的i/o模块的驱动支持。

通过开放式的logiclab runtime csdk，开发者可以将任何基于linuxc语言开发的功能或算法通过插件方式集成到iec61131-3应用体系中，包括树莓派标准的i/o扩展，uart、spi、i2c接口的外设访问，各种运行在linux上的c语言应用程序等：

另外面向工业物联网应用，node-red平台将进一步增强控制器的开放性，提升数据处理与通讯能力。node-red是由ibm主导的开源物联网开发平台，基于node.js开发。使用web浏览器就可以对数据流进行拖拽式组态、参数设定、程序加密、调试与下载等等，有了这么的平台，我们为什么要去重复造轮子呢？

在树莓派的linux平台上logiclab已经支持与node-red之间的无缝数据交换，logiclab与node-red之间通过llsymbol远程访问组件相互交换数据，进程间的通讯数据访问效率与及时性更高，因此这样的架构更能支撑未来边缘计算plc对于数据及时性的需求。

写在后

经过这部分内容，我们从概念到硬件再到系统及控制软件，对使用树莓派快速开发边缘计算plc做了详细阐述。树莓派作为近几年的开源社区产品，强大的社区资源可以大大降低产品研发投入，借助于我们对树莓派与实时linux系统的应用经验，可以快速开发出面对适合工业应用场景的iec61131-3标准的工业控制器产品。我们也为大家准备了资料包，包括基于树莓派3b/3b+的预集成实时linux镜像，集成linuxpreempt-rt实时内核补丁，logiclabsoftplc运行系统，node-red物联网开发平台，一体化的镜像更方便系统安装与测试。大家可以快速进行实时linux内核+plc系统+node-red环境安装并进行iec61131-3与node-red编程实践。