海尔热水器功能改进探讨与嵌入式软件开发思路.docVIP

海尔热水器功能改进探讨与嵌入式软件开发思路 海尔热水器遥控功能改进探讨与嵌入式软件需求开发 笔者近日购置了海尔某最新型号的热水器，此款热水器采用恒温控制，并配有无线遥控器。笔者在使用过程中，感觉其遥控器的操作较为繁琐，例如，每次调节温度时，除了按 “+”或“-”键设置温度值，最后还要按一个“确定”键；另外，水温控制在每次重新开水点火的时候，总是从室温（凉水）逐渐升温到一个较高（烫手）的水温，然后再下调，再上升，反复波动几次最后才稳定到设定温度。 分析上述第一个功能问题，笔者估计海尔设计人员之所以选用这种遥控操作模式，可能是为了节省遥控器的用电功耗。遥控器与主机通过无线电信号通信，并且常常要穿透水泥墙（海尔称此款型号最高可穿透3层墙），需要较高的射频功率。假定用户要调高水温3度，则其要按“+”键3次。按海尔的设计，此后用户还要按一次“确定”键，然后遥控器才发送一次无线信号给主机；而如果要提升用户操作体验，省掉按“确定”键的步骤，最直接的做法则是每次按 “+”键时，遥控器都随即发送无线信号给主机一次，但这样较之海尔当前设计多出2次无线射频发射，功耗明显增高（可以认为是提高了2倍，无线遥控主要功耗就是射频发射）。显然遥控器更换电池间隔时间即使缩短一半，用户也会感觉不爽，但繁琐地按“确定”键也让人感觉不便。那么有两全其美的解决途径吗？ 在开发嵌入式软件过程中，最开始要做的是分析目标系统（SuD）的操作场景（领域建模与分析），然后识别系统的功能目标，再据此定义系统的需求规格（需求开发），之后才是系统的设计与实施等。 就本文的例子，通过需求开发，我们可以识别得到一个用例UseCase——【遥控调节水温】，此用例有一个功能需求就是“用户在远离主机位置将系统当前工作水温设定到用户期望的数值”；为了达成此功能目标，需要用户与系统进行一系列的交互（交互需求）。 （图一）主要的系统用例示意 而编制用例最主要的任务就是编写这个交互序列，这实际上就是所谓的人机交互式设计。很多开发人员认为需求开发是描述用户已存在的需要，是属于“发现”范畴，而非“发明”范畴；但实际上，需求的内容并非都是已存在的事物，还有很多内容是通过人机交互式设计出来的东东，它们确确实实却是属于“发明”范畴。 在针对本功能进行人机交互式设计时，我们深入分析用户按键的行为，可以发现，用户在面板显示水温没有到达期望数值前，会本能地连续而快速地按“+”或“-”键，两次相邻按键的时间间隔一般不会超过1秒。于是，我们可以这样设计本用例的交互序列： 【前置条件】用户在远离主机位置，遥控器与主机通讯正常 【基本流】 用户期望改变系统当前工作水温设定时，启动本用例 （当前水温比用户期望水温低）用户按“+”键一次 遥控器将当前工作水温增加1度，同时在面板上更新显示新的当前工作水温 （在2秒内没有任何按键操作，而当前工作水温已经发生变化）遥控器与主机建立无线通讯连接，将当前工作水温发送主机 主机更新当前工作水温，本用例结束 【可选流】 3a、（当前水温仍然比用户期望水温低）用户在间隔上次按键2秒之内继续按“+”键一次，转到step2（用例转到第2步继续往下执行） 注：编号3a指本可选流步骤是在基本流中对应的第3步开始的，a则表示其为第a个可选步骤 3b、（当前水温比用户期望水温高了）用户在间隔上次按键2秒之内继续按“-”键一次 3b1、遥控器将当前工作水温减少1度，同时在面板上更新显示新的当前工作水温，转到step3（用例转到第3步继续往下执行） 注：编号3b1指本可选流步骤跟随可选流步骤3b执行 1a、（当前水温比用户期望水温高）用户按“-”键一次 【异常流】 4a、（遥控器与主机通讯失败）遥控器重新将当前工作水温发送主机 我们可以看到，采用上述操作设计，遥控器的功耗较之海尔当前设计不会高多少（考虑超过2秒按键的几率，可能高5~10%左右），但对用户而言，其操作体验要好很多。另外，同样是为了降低功耗，海尔的设计让遥控器在较短时间内，如没有用户操作的情况下，将关闭LCD的显示。从用户的体验角度，面板在用户使用热水器的过程中，一直显示水温、用水量等信息是有必要的。实际上LCD的功耗较之无线射频要低上几个数量级，随时关闭它对节省功耗贡献比较有限。笔者认为，系统应当提供对应的操作功能，让用户选择一直开启LCD显示，还是为省电而及时自动关闭。 （图二）【遥控调节水温】系统用例交互序列图示意 国内开发团队，特别是嵌入式软件的开发团队，很少有细致地进行系统需求开发的。这使得国产电子产品常常没有国外同类产品好用，无形中降低了国产产品的竞争力。需求开发中的人机交互设计对相关人员的素质要求很高，直接交给普通程序员去承担，其结果通常是不妙的。在嵌入式软件开发过程中，划分出独立的领域分析与需求开发环节，指派团队中高水平的人员来完