白酒发酵过程信息化监测软件的设计与实现
2022-10-19庹先国张贵宇
罗 林,庹先国,张贵宇,3,王 昆,高 婧
(1.四川轻化工大学 自动化与信息工程学院,四川 宜宾 644000;2.四川轻化工大学 人工智能四川省重点实验室,四川 宜宾 644000;3.西南科技大学 信息工程学院,四川 绵阳 621010)
0 引 言
在白酒固态发酵环节,发酵温度与窖内微生物的新陈代谢相互影响,间接导致白酒品质受到影响。发酵时入窖温度偏高,会使发酵过程中的升温速度过快,可能导致酵母菌活性降低,从而引发白酒品质下降等问题。入窖温度适宜,则酿造的酒大多品质较高。对于整个发酵周期,温度需满足“前缓、中挺、后缓落”的变化趋势。
鉴于发酵温度对白酒品质的影响,各大酒企对白酒固态发酵过程中的温度数据十分关注。传统的白酒酿造过程中利用人工监测方式对发酵过程中的温度数据进行监测,以温度计作为数据采集手段,利用纸质方式记录和存储,但存在数据误差大、时效性差及人工成本高等问题。近年来,各白酒企业为提高生产效率纷纷投入到自动化酿造研究中,欲借助自动化技术实现白酒的信息化、智能化生产,以技术创新降低人力成本,同时提高生产效率。现已实现润粮、装甑、流酒等工序的自动化,但发酵过程中的自动化技术发展却相对滞后,无论是数据存储还是发酵过程可视化方面都并未有有效的监测软件。针对发酵环节自动化水平的滞后性以及发酵温度的重要性,以发酵温度为主要研究对象,借助Android设备便携、开发成本低等优点,设计了一款白酒发酵过程信息化监测软件,为白酒行业在发酵过程中实现精确化控制、数字化管理提供条件,突破人工监测的局限。
1 软件架构设计
本设计以Android为载体进行人机交互环境的搭建,借助移动设备的便携性解决发酵现场难以随时随地监控的问题。信息化监测软件以C/S模式设计,由服务器和客户端组成。软件结构如图1所示。服务器内部的数据分析模块可对数据进行逻辑处理,为客户端进行正确应答,客户端负责与用户交互,并为用户呈现发酵过程中产生的实时数据。
图1 软件结构
为满足实际需求,软件总体功能模块分为管理功能和基础功能两大部分,其中管理功能模块负责软件中车间的创建与删除、车间窖池信息锁定及各项报警阈值的设定。基础功能模块分为用户模块、发酵概况模块、报警模块和窖池详情模块,用于展示分析或者响应结果。功能结构关系如图2所示。
图2 功能结构
2 客户端设计及实现
2.1 客户端整体布局设计以及实现
软件所有交互性功能模块均在Login_Activity、Home_Activity和WorkShop_Activity三个自定义Activity中实现,各Activity与功能模块的关系如图3所示。Activity间通过Intent对象传递用户等级和状态标志等信息,进行正确的资源更新。
图3 Activity关系
Home_Activity作为软件的主页,需要将每个车间的整体发酵情况呈现给工作人员,空间压力较大。鉴于Viewpager左右滑动的特性,可成功解决空间占用问题,故本软件利用Viewpager+Fragment,通过滑页的方式将发酵概况模块与报警模块进行显示。由于Viewpager内部机制的原因,会加载用户不需要的资源,导致资源浪费,运行速率降低,为处理资源问题,本软件采用懒加载机制进行资源加载。
懒加载机制可让软件在用户可见时加载资源,降低软件任务量。可通过监听Viewpager滚动或调用Fragment内部API两种方式实现,为使软件具有更好的封装性,本软件采用调用Fragment内部API的方式。
Fragment内部的setUserVisibleHint函数会在用户可见时调用,故Viewpager加载机制加载的Fragment不会执行此函数,基于此在 Fragment的生命周期函数和setUserVisibleHint函数中做逻辑处理即可成功实现懒加载机制。
2.2 发酵车间管理模块
本软件的车间管理功能可以根据企业车间情况对车间进行创建与删除,将想要观测的车间添加到软件上,同时也可将无需观测的车间从软件上删除。车间管理功能由Recyclerview、Viewpager、自定义的SaveStatue类 以及PopupWindow共同实现。Recyclerview作为软件的车间条目,可以保证软件使用的流畅性。SaveStatue是SharePreference的一个封装类,通过键值对对必要数据进行保存,用于保存软件状态信息。车间创建的窗口由PopupWindow实现。功能执行流程如图4所示。
图4 车间管理执行流程
2.3 车间窖池锁定模块
车间创建完成后需要对车间进行窖池信息匹配,建立好待监测窖池ID与车间之间的关联,从而获取正确的数据信息。为减少重复布局,车间窖池锁定功能利用自定义的窖池选择控件实现,考虑到存在车间窖池数量太多的情况,将匹配方式分为点击匹配和输入匹配两种。点击匹配为工作人员提供一个含有所有窖池ID的复选框界面,工作人员可勾选车间包含的ID进行匹配设置。输入匹配为工作人员提供一个区间输入的界面,有上限和下限两个输入项,当两个项输入内容相同时表示匹配一个窖池ID,否则表示匹配区间内所有ID。设置信息会由自定义窖池选择控件传到Fragment,再由Fragment传到Activity中利用SharePreference进行持久化处理。自定义窖池选择控件、Fragment、Activity之间通过接口通信。功能执行流程如图5所示。
图5 窖池ID匹配流程
在本软件开发中需要用到大量的重复布局,使用Android原生UI将会使程序结构臃肿,不仅开发效率低而且维护成本也较高。为提升开发效率和维护性,选择控件与本软件的自定义UI均通过自定义组合控件的方式实现,实现步骤如下:(1)将原生UI进行组合布局到XML文件中;(2)在Values.attrs.xml文件中为自定义组合控件设置属性集;(3)自定义UI类继承布局基类LinearLayout或RelativeLayout,构造方法中获取属性设置信息,并在此类中定义好相应交互接口。
2.4 窖池详情模块
当车间的窖池ID设置完成后,Android端会将设置的车间窖池ID发送到服务器,获取该车间所有窖池的温度数据以及测温设备的电量等信息,为工作人员提供数据展示。为避免ANR现象,采用异步任务的方式进行网络请求。数据展示共有普通展示模式和列表展示模式两种,每种模式对应一种自定义的窖池UI。一个自定义窖池UI对应一口窖池信息,以轮询的方式进行实时数据获取并更新。温度曲线绘制由MPAndroidChart实现,将每个窖池在本发酵周期内一定量的温度数据分上中下三层进行绘制。此外,还提供了入窖日期筛选、温度筛选以及发酵天数筛选3个子筛选功能,用户可根据需求按照酒培入窖日期、酒培上中下三层温度、酒培已发酵天数进行数据筛选。
轮询主要以Service、BroadcastReceiver、AlarmManager三大组件实现。当开启服务时,在Service内部动态注册广播监听器,并开设用于通知Activity更新数据显示的线程,然后利用AlarmManager设置定时任务,到达设定时间时激活广播,广播反向激活Service,并发送线程使能标志到Service,此时被再次激活的Service便会启用线程,对服务器发起访问,实现实时更新。
2.5 报警模块
报警功能如下:
(1)报警综合显示是将测温设备电量异常、服务器异常、入窖温度过高、入窖温度过低、顶火温度过高、顶火温度过低、顶火温度出现过早、顶火温度出现过迟8个方面的异常情况放于主页进行综合显示,以轮询的方式向服务器不断检测是否发生异常,根据报警数据量动态生成TextView控件并布置到主页对应布局进行显示。
(2)报警分类显示是依据8个报警项设8个报警条目,当用户点击某个条目时以弹窗显示该车间内哪些窖池有此异常,以及这些窖池何处出现异常。
(3)报警归档功能会将报警信息保存到Android本地,由File类和IO流实现,当发现某车间有窖池存在发酵异常时,软件先借助Context的getExernalFilesDir获取本应用程序在Android设备中的存储路径,然后利用File类在该路径下创建该车间的报警文件夹,结合输出流将报警信息归档到本地存储。当进行归档数据读取时,软件会利用输入流对对应车间的归档文件夹进行查询,以动态布局的方式显示归档数据。
2.6 发酵天数概况模块
发酵天数概况模块用于对某车间中发酵天数在一定区间范围内的窖池进行数量统计,以柱形图的方式展示。
由于白酒发酵主要关注“前缓”和“中挺”两个阶段,而浓香型白酒一般在发酵后的15~30天内结束“中挺”阶段,故横坐标上共设10个刻度点,每个刻度点表示一个发酵天数区间,针对发酵天数区间从“1~3天”以三天为一段一直到“28~30天”的窖池数量进行柱形图绘制,柱形图绘制以MPAndroidChart实现。
除对对应发酵天数的窖池数量进行展示外,为显示对应天数区间的窖池具体情况,还针对“数量”设立了详情功能。详情功能通过OnChartValueSelectedListen接口监听柱形图是否被点击,点击事件被触发则获取对应的刻度信息,即天数区间,并调用异步任务将其作为参数传至服务器查询,以PopupWindow和Fragment形成的弹窗对结果进行展示。
3 服务器以及数据库设计
3.1 数据库设计
数据库是软件的基础,良好的数据库可以为软件运行提供有力支撑。设计时需充分考虑数据完整性、冗余性等问题,以避免出现删除异常、更新异常等情况。本软件采用SQL Server数据库进行数据存储。为提高软件运行效率,以范式标准对数据库进行限制和设计。
3.1.1 信息表设计
根据实际企业需求,需要对发酵过程中各车间中各窖池的设备状态以及产生的温度数据进行存储,据此分析可得到车间、窖池、记录信息和测温设备4大实体,各实体间的属性以及逻辑结构如图6所示。Workshop对应实体车间,Pit对应实体窖池,Record_Info对应实体记录信息,Equip_Measure对应实体测温设备。
图6 E-R图
4大实体分别对应车间信息表、窖池信息表、记录信息表和设备信息表。车间信息表用于记录生产车间的基础信息。窖池信息表记录发酵窖池的基础信息。记录信息表记录对应发酵过程中产生的重要信息,如上中下三层的发酵温度、温度采集时间等。测温设备信息表记录测温设备的基础信息,如测温设备型号、设备购入时间等。以记录信息表结构为例进行展示,见表1所列。
表1 记录信息表
3.1.2 表间关系结构
各表之间的关系可通过主键和外键进行构造,以保证实体完整性和数据完整性。如窖池ID可以对窖池信息表进行唯一标志,在记录表中又可以将窖池ID设立为外键,保证数据一致性,表间关系结构如图7所示。
图7 EDR图
3.2 服务器设计
服务器是在.Net框架下创建的一个Web服务端,由WebService和ADO.Net实现,负责对客户端请求进行相应的业务处理,并返回处理结果,为客户端提供计算支持。
WebService以消息互操作的方式完成分布式计算,具有跨软件操作的优点,利用WebService向Android客户端提供访问接口,以完成PC与Android的信息交互,Web服务端与客户端之间以Soap协议通信,本软件利用Ksoap2进行消息的序列化处理,远程调用Web服务接口。
ADO.Net是.Net框架下的数据库访问组件,通过Connection、Command、DataReader和 DataAdapter四 大 核心元素完成数据库信息交互。
4 软件验证与分析
该软件的实现使得现场监测的人力成本下降,由现场监测变成了移动监测。引入懒加载机制后数据加载速度获得了极大提升。具体数据见表2、表3所列。
表2 懒加载效率表
表3 人力成本使用情况表
5 结 语
考察了实际发酵工艺环节后,从实用性、稳定性、可拓展性等方面入手设计并实现了发酵温度信息化应用软件,使得人工现场监测变成了移动监测,改变了白酒行业传统的数据监测方式,大大提升了监测效率,为发酵环节的数字化、信息化、精细化提供了基础。软件在设计上充分考虑了发酵温度的重要性,从基础信息展示、异常数据报警,以及数据统计等方面完成了发酵过程中温度数据的有效监测,此外,还提供了测温设备信息展示功能。在实现上以轮询方式保证数据实时更新,通过懒加载方式减轻资源压力。