1. 智能燃烧控制器系统
1.1. 产品概述
智能燃烧控制器系统(又称为Jewos)。燃烧器的燃烧状态决定了锅炉蒸汽压力的输出大小，已有的燃烧器系统，只有锅炉上下限压力保护系统，超出压力范围自动启停，这一情况很难保证供气的稳定性。所谓燃烧控制器就是控制某些必要的生产参数变化，间接达到控制某一或多个输出变量达到某一设定值，这里我们称作“目标值”。智能燃烧器系统是可根据目标压力动态调整燃烧状态。具体地说就是依据当前输出压力与目标压力的差值调整燃烧器油嘴的开关和风门的正反转来实现大小火的切换，这样可以最大程度上减少停机情况的发生，维持供气的稳定。本方案借助的是APIECO边缘计算机实施，APIECO一方面作为数据采集器(适配器)对设备参数进行采集和上传云端MixIoT，另一方面对燃烧设备进行本地计算分析，计算得到策略参数，进一步进行反向控制。同时，考虑到实际生产环境的复杂性和多样性，方案中开发了多种控制模式。
1.2. 适用场景
（1）无目标参数，无反馈结果，即现场没有目标值（如目标压力），也没有目标变量的反馈结果（如当前正在输出的锅炉压力）。
（2）有目标参数，无反馈结果。实际生产中的情况就是：有目标压力的输出要求，但是现场无法实时获取锅炉的输出压力。
（3）有目标参数，有反馈结果。这是比较理想的情况,我们拥有内部反馈：油嘴、风门信号可读写；拥有外部反馈：锅炉输出压力或者温度可实时读取。
1.3. 运行机制
以下分析的举例都是假设在工频条件下分析的，对于可调频的工况，“输出”和“目标”之间反馈的信号并无差别，只是对于反馈结果所做出的回应不一样，对于工况条件下，做出的回应是开关位信号或者其他触发式信号，而对于“调频”而言，做出的回应则是更为精细的信号，可以具体到：增加或减少某一输入的具体数值。
1.3.1. 无目标参数，无反馈结果
首先考虑的是最简单的工况也是最基本的控制，即现场没有目标值（如目标压力），也没有目标变量的反馈结果（如当前正在输出的锅炉压力），那么这个时候需要的就是人为介入，要做到可以手动调节大小火，即手动调节各个油嘴的开启，以及风门的大小（即正反转），以此来间接控制锅炉的输出压力或者温度，这里我们称之为“手动控制模式”。手动模式下我们直接通过该平台的UI界面，通过触控的方式，实现控制油嘴的开关，和风门的正转、反转。
1.3.2. 有目标参数，无反馈结果
第二种我们考虑到的工况是：有一个既有的目标值，但是没有目标变量的反馈结果。针对这种情况，我们设计了一种程序控制模式，简称“程控模式”。简单的来说就是根据目标输出的要求，事先设置好控制生产工序的执行脚本，而脚本的内容就是一些命令，告诉机器在什么时间执行哪些操作，例如：
- 风门正转到10°，点火（此时1#油嘴打开）；
- 风门正转到20°，打开2#油嘴；
- 风门正转到40°，打开3#油嘴，保持当前状态30分钟；
- 关闭3#号油嘴，风门调整到25°，保持当前状态15分钟
- 风门调整到40°，打开3#油嘴，保持当前状态20分钟
- 关闭3#号油嘴，风门调整到25°，保持当前状态10分钟
- 风门调整到40°，打开3#油嘴，保持当前状态15分钟
- 跳转到第（6）步，执行100次循环。
- 停机
上诉的脚本内容的逻辑可通过UI界面手动设置好，再由后台控制算法解析相关数据进行执行。这一算法在前期需要根据目标值（如：压力），事先手动调试好相关生产参数，并记录，最后将满足要求的生产参数手动填入程控界面，后续将交由算法自动执行，当拥有了一定的生产经验后，可直接通过目标值查找合适的执行脚本，来完成满足输出目标的要求。
1.3.3. 有目标参数，有反馈结果
这种情况我们可通过目标值的反馈信息来实现自动控制，又称为“自动模式”。举个简单的例子：就好比我们日常使用的空调，我们设定好了目标温度T,在达到目标值之前，我们可以开足马力制冷就行（当然，不影响安全），当达到T时，我们就得减小制冷的输出功率，只要其功率输出能够维持住由于热交换造成的温度损失就行，如果由于外界的变化，导致实际温度大于T时，我们再增大一点功率，当达到T时再降低输出功率，如此往复，根据反馈的结果控制制冷机的输出功率。在本产品中的原理是一样的，我们通过反馈的压力值和目标压力值来控制油嘴的开关和风门的正反转以此来实现控制大小火，从而控制输出压力，达到稳定控制输出压力的目标。
1.4. 组成部分
我们的燃烧控制器整体有五个部分组成，分别是：外部的反馈，燃烧器的反馈，计算（算法），燃烧器的执行机构控制，UI交互。在本方案中：外部反馈指的是：锅炉的输出压力或流量；燃烧器的反馈指的是：油嘴开关信号的读写，风门正反转信号的写入以及当前的角度，计算指的是：控制算法部分；燃烧器的执行机构控制指的是：智物联apieco对所控制硬件地址位信号的读写，UI 交互指的是：基于UI的软件控制平台通过apieco对于生产设备数据的读写。针对上诉五个部分可能发生的情况，我们需要采取进行以下分类：
1.4.1. 正常情况
首先场景多样性是一种正常情况。外部反馈可能会因为不同客户而变得多样和复杂，我们假设了三种可能的工况场景，并构建了相应的算法模型。分别为上诉介绍的“手动模式”、“自动模式”、“程控模式”。这三种模式其实也是一种通用模式，即使是其他类型的控制器，也大多逃不过这几类情况，这是参数变量变了而已，其逻辑本质不变。
1.4.2. 异常情况
异常判断是除了外部反馈多样性以外的其他所有意外情况。 （1）外部反馈在“自动控制模式”，即“有目标值有反馈”的情况下，并没有数据通过执行机构和UI交互回传给算法进行计算，这时需要判断执行机构本身是否异常，如果执行机构正常，则可能是由于网络等其他原因导致数据信号并没有被获取到，这时需要等待，等待进一步判断。并且需要判断是内部反馈数据还是UI交互参数没有获取到。如果是内部反馈数据没有获取到，则短暂等待下一次获取，如果是长时间则需要放弃自动控制。如果是UI参数没有交互完成，则需要检查网络，以及UI输入参数是否填写正确，否则将不执行控制。同时，如果是执行机构本身检测到控制异常，这是一种综合异常，需要进行停机检查，以避免由于控制异常导致的生产问题。
（2）“程控模式”下需要判断脚本是否按照规范进行，例如：油嘴的打开顺序正确例如：实际情况必须是1#，2#，3#这样的顺序，不能跳跃，否则将无法解析脚本文件进行控制。
（3）“手动控制模式”下，需要判断各个信号是否被获取到，以及是否被传递到，如果传递异常需要调整到小火停机检查，并且放弃转控。
（4）算法计算结果输出异常，这一异常并不是由算法本身直接导致，很多时候是由于输入给算法的信号数据异常，直接导致经过算法计算后输出的结果也是‘异常’，对于这类情况，算法本身会有判断，即算法每次输出的控制幅度最大为K,当经过算法计算的输出信号大于K时，截断输出信号，输出K,这样可以保证控制的稳定性和安全性。
1.5. 前端展示
图1，2分别是工频和调频工况下的显示主界面。考虑到一台Apeico会接多台设备的情况，这里增加了设备选择模块，（如图1中，“燃烧器#1”为下拉选择模块，此时显示或控制的将是燃烧器#1的数据），每一工况下无论是“手动”、“程序”、“自动”,除了控制模式名称不一样外，其三者的主界面都一样，只是“手动”模式下，油嘴和风门对应的信号位是可手动触发或输入的。当在其他两种模式下，油嘴和风门的触发开关是失效的，主界面只会起到显示作用。
图3是工频情况下进入程序控制模式后，需要进行执行逻辑的脚本设置，通过上图各键位按照一定的逻辑输入即可，在确认保存后会由程序将其解析为已经确定好的脚本格式，再由算法自动执行脚本，完成程序控制。相应的调频情况下，油嘴的开关信号改为了具体输入数值，和图2中右下角处油嘴的输入格式是一样的。
图4，是“程控”模式下，增加的一项“油嘴型号参数配置”模块，可通过点击图3中1#、2#、3#油嘴进行配置，其本身的有无不影响程序运行，这是根据实际的现场工况来设计的，实际工况中，根据实际的生产要求可能会更换油嘴，而决定油嘴的差异是“型号”（具体参数暂时不知）。此设计，可以在长期的程控模式中积累详细的数据，为后续在数据积累到一定数量后,进行自动选择脚本创造条件。