0、简介
洗车机有多种不同的型号，比如有大型的、自动的，也有本文所述的小型的、自助式的。本文从整体的操作流程、软件的设计思路来分析。
1、设计思路
既然称作是自主式的，那么所有的操作需要用户自己去完成。设备不需要配备工作人员，不过日常维护还是需要的。当然，这可能涉及到具体的运营方式，这里不讨论。基本的工作流程如下。
①机器上会有一个唯一的二维码，用户通过相应的软件（APP、小程序等）扫描，完成必要的操作（选择工作时长，支付等）。
②服务器下发相关的必要信息。
③设备接收到相关信息后，进入就绪状态，等待用户按键操作。这里的按键是设备上的按键，对应不同的功能，比如清水、泡沫、吸尘等。
④用户操作按键后，设备响应不同的功能。
⑤目前交易以时间控制为准，到达设定的工作时长后，机器停机，上传交易，最后恢复空闲状态。
2、整体实现
（1）二维码
每个设备唯一，需要与设备绑定起来。当实现扫码支付后，服务器知道向谁发送信息。
设备使用4G DTU来实现通信的，所以设备在服务器的注册等操作与之相关，比如使用IMEI来唯一标识该设备。
（2）通信
①设备与服务器的通信使用DTU模块来实现。DTU与主板之间使用RS232或者RS485通信，但是按照该DTU的使用说明，二者不应同时使用，因为它们是同一个串口。本文要使用的主板型号也存在同样的问题，同一uart扩展出RS232与RS485，最多只能时分复用。
②通信协议使用mqtt，在这之上需要实现自有的通信协议。为加快进度，同时考虑到单片机RAM，mqtt直接使用DTU的协议栈。我们所要实现的就是自有协议。另一方面，为了具有更好的可移植性，在条件允许的情况下可以由单片机来实现mqtt。
③如一些物联网平台，mqtt通信数据使用json格式。单片机需要解析、打包json数据。
因为json数据可以嵌套，所以为了解析更精简，只支持自定义协议中的格式。
这里有2个问题：为何选择mqtt协议，直接使用TCP/IP不行吗？为何选择json格式数据？
其实对于单片机而言，直接发送数据流最方便，但是对服务器端而言可能就会存在一些不变或者问题。笔者不是太懂，只能冒昧猜测一下，若有不当之处请指出。服务器端需要处理诸多任务，比如支付、账号管理、消费信息处理等等，而mqtt是订阅发布的模式，可以达到异步、解耦的效果。使用json格式的数据，单片机就需要做许多额外的工作，数据解析与打包也更复杂，但是服务器端处理json应该会更加方便了，毕竟在服务器端的工具还是很多的。这个问题还是挺复杂的，架构也是在不断的演进的。
④当设备状态变化时才发数据，而我之前的思路是每隔一段时间（比如2秒）发一次数据。这里的数据不包括心跳数据。
这会有什么问题呢？
一方面，减少设备工作负担，减少通信流量；另一方面，如果因为某种原因通信中断了，服务器如何及时知晓呢？当然可以利用心跳数据，但是其周期是60秒或者更长，那么从真正断线到没有心跳数据这段时间就会存在争议。另一个问题是：对于一些实时数据，服务器是否需要即时知晓？
⑤单片机的控制逻辑中的命令与服务器命令相互独立，也就是软件中常说的低耦合性。
⑥信息之间的时间间隔
这是在测试中实际遇到的问题。如果主板单片机不做控制，那么服务器有可能接收到连接在一起的两个消息，进而造成数据解析问题。
因为数据是经过DTU联网的，其处理过程未知，所以单片机需要保证一定的发送时间间隔。
其实，对于此种情况，服务器端完全可以解析处理。
（3）设备控制逻辑
①设备有多种功能，需要用户去操作按钮以便进行切换。
②每次工作时长的控制。
③超时处理
这个是必要的。就目前的设计方案而言，工作以时间长度控制。设想：如果未达到指定的工作时间，那么设备一直等待用户的下一步操作，但是用户此时可能已经离开了，而APP显示该设备仍在使用中，如此一来潜在的用户就不会去使用。所以在一定状态下，比如没有任何部件处于工作状态，需要超时控制。
当然这个超时处理由谁实现也是一个问题：既可以由设备单片机本身实现，也可以由服务器实现，这就设计到功能划分了。当然，从完整性角度考虑，设备自身需要有一个处理过程，而不能仅仅依靠外界。
设备上可以增加一个结束按钮，这样一切都会简单起来，问题是，不能强迫用户的行为，即便是有结束按钮，用户也可能因为某些原因不去操作，比如忘记了。
④工作时才会计时
比如虽然操作了按键，设备也正常工作，但是因为没有打开水枪开关，此时不能计时。当然，这是目前的设计思路，这样处理更能保证用户的合理权益。
⑤水流速表问题
水流速表一方面可以计量水的体积，另一方面，也可以作为判断是否有水流过的依据。
如果一段时间内没有脉冲，那么可以认为没有水流动。原因可能是真的没有水，也可能是水枪没有打开开关。如果开启水枪功能后，长时间没水，那么就认为存在问题，作停机处理。关键点在于判断时长多少合适？
经过实际的验证，如果时间过短，比如50ms，那么很可能会有问题。原因在于流量问题，如果流量比较小，水流速表的叶轮虽然确实在转动，但是产生的脉冲周期会变长，如果脉冲周期长于50ms，那么显然会造成误判断。所以，在允许的流量范围内，采用一个较大的检测时长，比如500ms。但是又不宜过长，因为检测时长会计入总时长（若不计入总时长，那么很显然设备运营方会受损失，但是计入总时长用户会受损失，所以需要一个平衡）。
⑥其它
还包括其它设备，诸如电接点压力表、LCD显示。
3、后续
目前，软件开发基本完毕，与服务器通信测试也已完成。接下来就是在整机上的实际测试，并且在测试或者使用过程中还需要根据效果或者要求进一步改进。