上篇(海尔热水器遥控功能改进探讨与嵌入式软件需求开发)谈到海尔某款热水器的水温控制在每次重新开水点火的时候,会经历高温与低温上下波动几次最后才稳定到设定温度的过程。在此期间,忽冷忽热的水温会让人感觉不适。
分析其间的缘由,笔者认为可能是热水器采用的温控算法自身限制所造成的。为了让热水器出水温度稳定在设定温度,热水器通过温度传感器实时监测水温,如果水温偏离设定值,则利用火力调节器来调整燃气的供应量,以改变火力大小,从而控制水温回到设定值。
一般热水器会采用简单的负反馈闭环控制算法来实现上述控制程序——当水温偏低时,调高火力,水温随之上升;然而增高的火力幅度往往矫枉过正,水温很快超过设定温度,于是反过来又调低火力,使得水温下降;同样降低的火力幅度也常常超出需要,水温很快又低过设定温度。如此反复多次,随着火力调节的幅度不断减小,水温与设定值偏差越来越小,直到进入允许的精度范围内,火力与水温才最终同时被稳定下来。
要改进热水器的水温控制功能,归根结底就是要改进水温控制的算法。实际上,嵌入式软件开发中的重头戏,除了上篇所讨论的人机交互设计外,就是各类控制算法或服务算法的设计了。而要设计一种好的算法,缺乏相关领域(即算法要解决的问题域)的知识是不可想象的。在嵌入式软件开发过程中,最上游的核心环节是领域建模或分析。我们将通过领域分析来剖析嵌入式系统所要面对的问题域,并收集相关的领域知识,以便开发者据此设计出合适的解决方案(算法)。要强调的是,领域建模的成果除了供设计环节使用外,需求开发环节同样也离不开它们。
嵌入式系统之领域建模的内容主要包括:识别领域概念(实体元素)、领域关系(元素与元素间的关系,例如关联、聚集、泛化等),归纳各种领域规律(例如相关规则、力学原理、数学方程式等),并抽象主要的主动元素(指非实体元素,例如系统的操作者——用户、控制线程、网络节点、处理器或具备处理能力的芯片等)的典型行为(例如可用状态机表述的激励与响应过程),以及相关被动(功能)元素的典型行为特性等。
注意:对于应用软件而言,在需求开发之前的环节是业务建模,业务建模的范围比领域建模大,在领域建模之外还包括诸如识别执行者、描述业务流程等内容。嵌入式系统中的领域概念在业务建模中对应为业务对象;领域规律则主要对应为业务规则等;主动元素的典型行为对应为业务工员(business worker)的典型工作行为。
针对燃气热水器展开领域建模,我们可以识别的领域概念有:燃气、水、温度、单位时间出水量、单位时间供气量、单位时间发热量、(水的)比热容(俗称比热)、(燃气的)燃烧值、热转换率(或热吸收率)等。相应的,识别的领域关系实例有:“水”组合下列属性元素——“温度”、“体积”;“水”与“比热容”关联;“燃气”与“燃烧值”关联等。
经过深入分析,可以归纳若干领域规律,例如,水温与单位时间供气量成正比例,与单位时间出水量成反比例等。
实际上,在这里我们可以直接应用物理热学定理,例如:
温度(变化增量)=热量÷(质量×比热容)
(发)热量=燃烧值×(燃气)质量
经过推论,可以得到:
温度(变化增量)=燃烧值×单位时间供气量×热转换率÷(单位时间出水量×比热容)
接下来,我们还可以抽象得到若干主动元素,例如洗浴用户、水温控制线程;抽象的被动元素则有燃烧室、热水器出水环路等。燃烧室的某个关键典型行为特性是,燃气点火时,会出现一次发热峰值;这是因为出气阀门先打开,等燃烧室积存了足够多的燃气后才点火,而点火后将瞬间烧尽这些燃气,这会产生大量的热量。
我们回过头再研究上述的负反馈闭环控制算法,理论上讲,此算法以一种震荡收敛的模式将水温纠正到设定值,应当能够较好地实现我们要求的温控功能。然而,正是由于上段所述燃烧室点火时出现一次发热峰值的行为特性,使得此算法的实际工作效果难以令人满意。点火后的发热峰值使得水温急剧升高,往往大幅度超出设定水温,于是负反馈算法会在实际供气量正好甚至不够的情形下,仍然计算得到一个较大的供气减少量;此后较大的供气减少量又使得水温急剧降低,大幅度地低于设定水温;虽然之后负反馈算法将确保温度曲线逐渐收敛到设定水温,但起始的过宽曲线振幅,使得这个收敛过程的时间被拖长,当然更要命的还是造成大热大冷的水温让人感觉不适。
如果更深入地分析此领域,我们还可以抽象出一个的被动元素——出气阀门,并识别出其一典型行为特性——出气阀门在短时间内做大幅度调整时,出气量并非即时达到目标值,而是会出现一个波动峰值,之后才逐渐收敛到目标值。显然,此行为特性会对上述温度曲线的收敛过程带来负面作用。此行为特性与燃烧室点火发热峰值特性一样,都会让负反馈算法在计算控制变量时出现误判,因为当前实际(稳定后的)供气量对应实现的水温与当前采样水温发生背离。
根据领域分析的结果,我们不难得到一个结论,就是简单的负反馈闭环控制算法对燃气热水器的水温控制效果不佳。在领域分析结果的指导下,我们完全可以设计出更佳的水温控制算法。针对燃烧室点火和出气阀大幅度调整的行为特性,我们可以改进负反馈算法计算控制(供气)增减量的方法。例如,在点火后第一次进行负反馈控制时,并非简单地依据当前采样水温与设定值的偏离值来确定(供气)增减量,而是要综合点火前的水温采样值、点火后水温的最高峰值、以及水温增高的速率和随后的回落速率等,再对比目标设定值来决定(供气)增减量。这个(供气)增减量还要加上限制,即其绝对值不能太大,即使可能与最终稳定供气量偏差很大,我们也要在后续的负反馈控制过程中小步收敛到最终值。
另外,如果能保存历史数据的话,还可以进一步利用历史温控收敛曲线数据来计算最佳的(供气)增减量控制值序列。这是因为我们做领域分析时会发现,热水器本次的进水原始水温与上次工作时遇到的入水温度差别不会太大,出水量的设定往往也类似,因此利用上次的工作温控收敛曲线数据是可行的。针对洗浴用户这一主动元素进行分析,我们又可以发现若干典型行为——头一次开水点火;和在洗浴过程中,暂时关闭水阀并随后再次开水点火;在持续烧水过程中改变水温设定值。对于第二种行为,利用历史数据的实用价值就更高了,因为暂停后再次开水时的当前水温与设定值偏差通常较小,而且出气阀当前的供气量应当正好就满足设定水温的要求(除非用户在暂停期间改变了水温设定值)。
笔者不是燃气热水器相关领域的专家,这里例举的只是算法改进的一些初步思路,并不具体,甚至本身可能都是错误的。但不管怎样,这些论述应能印证领域建模在此的重大意义。
正常的嵌入式软件开发,应当经历领域建模与分析、系统需求开发、再到分析与设计、编码实施、测试、部署等的环节过程。国内开发团队,很少有明确的系统需求开发环节的,更不用说领域建模环节了。不同的嵌入式软件,其面对的应用领域纷繁复杂,普通的程序员一般开始都不具备相关领域的知识背景,因此委派领域专家将领域知识表达为程序员可理解的领域模型,是决定开发项目成败的关键。可传阅的领域模型同时也能供大家评审,这样还有助于我们及时发现领域认知上的错误与偏差。
另外,要得到一个优秀的算法,很多时候仅仅依靠理论上的分析是远远不够的。为了测试算法的实际效果,需要进行大量的试验,这时候,算法要被具体编码实施出来,并要运行它们,同时收集相关的测试数据。那么这些工作应当归结于哪个开发环节呢?是设计还是实施环节?
国内开发团队对项目管理的认识还是不够深入的。作为工程性的开发项目,其成功要素包含三个——质量、成本与工期。一些核心算法的研究往往需要投入大量的资源和时间,而且还充满各种不确定性(有可能失败)。如果将这些算法的试验和研究放到项目的设计或实施环节来完成,项目的成本特别是工期将很难得到保证。工程性项目管理的一个核心原则就是不要引入任何高风险的因素。为此,惯用做法是专门安排一个预研项目,在此项目中准备相关模拟环境,以开发这些算法等关键技术。而在工程性项目中,算法的优化还是会有的(但不宜进行革命性的改进)。实际上,那些预研项目的性质通常也带有浓厚的领域分析色彩,算法的模拟环境是对领域的模仿,算法的研究归根结底是对领域问题解决的研究。总之,领域建模与分析既是普通工程性项目的最上游开发环节,也是预研性项目的最上游研发环节。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17007506/viewspace-664189/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/17007506/viewspace-664189/