在經過反覆討論後，初版流程確定如下：
1.車主通過微信公衆號地圖查看空位並導航到目的地，車位空閒狀態下擋板默認下降，車主可自由駛入車位。
2.車位裝置檢測到車輛入場，通過物聯網平臺會上報信息到軟件後臺，後臺會將此車位狀態更新爲佔用(待用)並記錄入場時間。
3.車在入場過程中會不斷調整位置，直到車停固定後，這個時候語音會提示相關信息，並上報信息到後臺，這個時間點即爲免費開始停車時間並生成待支付訂單，並將此車位狀態更新爲佔用(計費)並記錄計費時間。
4.後臺根據每個車位的免費停車時間(根據運營策略每個車位停車時間不一樣)計算，當免費時間結束的時候，會通過物聯網平臺下發升擋板的指令，車位的擋板這個時候會升起，並上報信息到後臺，這個時間點即爲開始收費時間。
5.車主要從車位駛出的時候，需要通過微信公衆號裏面掃碼繳費掃碼二維碼，這個時候後臺會計算此訂單明細，在有效的時候內車主確定後點支付，支持成功，提示相關信息。
6.微信支付回調收到微信支付成功消息後，會通過物聯網平臺下發下降擋板指令，車位的擋板這個時候會下降。
這個流程在討論中有個地方一直有爭議，就是車主入場的時候免費時間段到底由設備端來計算還是後臺來計算，之前是想入場時間免費時間開始由設備端來處理，設備端來計算 免費時間結束，當免費時間結束後，升起擋板，這個時候上報信息到後臺，而不是由後臺來計算免費時間到再來通知設備端升擋板，再由設備端來上報信息計費開始。後面考慮 到2個問題。
1.設備端能不能計算這個時間?定時任務?
2.關於免費時間策略每個車位可能不一樣，也就是說當後面車位免費時間策略在後臺改變的時候需要下發指令同步信息到設備端，當然設備端每次在上線的時候也會去拉一次。
其實這個計算免費時間如果在後臺做的話從邏輯上來講是完全ok的，那麼後臺需要通過一些方式去計算。陳工之前的公司是這樣做的，就是後臺啓定時調度去輪詢所有設備，計算時間差來確定免費是否到時候，當時聽到這個方案的時候心裏有點打顫，幾百個設備還無所謂，如果幾十萬幾百萬個設備以上通過定時調度來做是否會存在很大的問題？其實定時調度輪詢需要解決2個問題。
1.調度的時間頻率能不能在時間內完成這一波任務，這邊的頻率肯定是1秒鐘輪詢一次。
2.調度輪詢肯定有時間差，可能幾秒也可能10幾秒。
當然調度輪詢也可以不斷的去優化，比如調度輪詢的數據庫可以放在分佈式緩存redis去加快速度，還有調度輪詢的粒度可以更小，比如可以拆分幾個甚至十幾個調度任務，每個任務去處理一批數據，這些都是可以去做。
我當時在想，互聯網電商項目裏面經常有搶購活動，如果搶購後不付款，幾分鐘後這個商品就會釋放也就是回倉，還有就是網上買高鐵票也是一樣的道理，難道這種項目都是通過輪詢機制？能不能把訂單放到一個地方，時間到的時候自動去通知或者做處理？