###### tags: `meeting minutes`

# 新系統開會紀錄 2020/01/06

## Converto
- during_trip event增加欄位
:::success
- 增加一個欄位說明來源是L1 report或L2 report

    {
        "eventType": "during_trip",
        ...,
        "reportType": number // 1: "Level 1", 2: "Level 2"
    }

:::

## Sensol
- Integrate with SQS (for )
- 解析完ble_data後, 須將結果透過SQS通知需要的microservice
- drivo
- vehicol

    {
        IMEI: string,
        tpms: [
            {
                "id": string, // simple ID
                "uuid": string, // UUID
                "pressure": number,
                "temperature": number,
                "batteryError": boolean,
                "pressureSuddenDecreasing": boolean
            }
        ],
        others: [] // TBD, reserved for other sensor
    }

## Tripo
- 打包時機調整
- 目前: 聽Converto發送的engine off
- 可能會有誤判的情況 (例如頻繁的on/off, 導致trip被切成很多段)
:::success
- 更動: 聽Converto發送的sleep start
- 當VM-325進入Sleep mode時打包 (避免頻繁的on/off)
:::
- vehicle_statuses.summary:
::: success
- 增加欄位
- speedDistance (透過vssSpeed計算)
- gpsSpeedDistance (透過gpsSpeed計算)
- gpsDistance (透過經緯度計算)
- 修改欄位
- curObdTime -> reportTime (object)

        {
            "reportTime:": {
                "curObdTime": number // unit time
                "level1ReportTime": number // unit time
            }
        }

- reportTime.level1ReportTime 用於計算invertal time of level 1 report
:::
- trip_points.tripInfo內所有distance的定義調整
- 目前: 兩點之間的距離
:::success
- 討論後異動: 定義應該為從起點累積到現在這個tripPoint的距離
- 增加欄位
- speedDistance
- gpsSpeedDistance
- gpsDistance 為相鄰兩gps points距離之總和, gps distance += now gps point - last gps point
:::

## Drivo
- 打包時機調整
- 目前: 聽Tripo發送的trip_end event
- 更動: **聽Converto發送的engine off**
- 會不會有誤判的狀況?
例如駕駛開車加油站熄火 (發送Engine off, Drivo打包), 在還沒收到sleep start時就回到車內開車 (engine on), 回到家熄火 (發送Engine off, Drivo打包 -> 二次打包會有問題), 收到sleep start (tripo打包結束旅程)
如果要以旅程結束時就打包的話, 似乎還是只能聽sleep start, 不然可能要更改打包時機
:::success
- 討論後異動：
- Listen trip_end event from Tripo via SQS
- Retrieve vehicle_status from collection "trip_histories"
- Package record (daily -> weekly -> monthly)

    {
      "eventType": "trip_end",
      "IMEI": string // $imei,
      "tripId": $tripId
    }

:::
- **DailyRecord 15分鐘平均速度計算方式調整**
- 目前: 透過該trip的trip points計算得出
:::success
- 討論後異動：
- vehicle_statuses.dashBoard.driver 新增欄位
- quaterHourAvgSpeedRecord[] (收到during_trip時即時計算, 並將結果保存至此array)

            {
                "quaterHourAvgSpeedRecord": [
                {
                    "tripId": string,
                    "timeIndex": number,
                    "avgVssSpeed": number,
                    "avgGpsSpeed": number
                }
                ]
            }

:::

## Vehicol ([Schema](https://dbdiagram.io/d/5e0dc48fedf08a25543f8d6b))
- 打包時機調整
- 目前: 聽Tripo發送的trip_end event
- 更動: 聽Converto發送的engine off
:::success
- 討論後異動：
- Listen trip_end event from Tripo via SQS
- Retrieve vehicle_status from collection "trip_histories"
- Package record (daily -> weekly -> monthly)

    {
      "eventType": "trip_end",
      "IMEI": $imei,
      "tripId": $tripId
    }

:::
- vehicle_statuses.journeyData
- **如何計算SpeedDistance?**
- 原先DMS的作法如下:
avgVssSpeed (from L1) * L1Duration / 3600
L1 duration的定義為收到此次L1 report的curObdTime - 前一次L1 report的curObdTime
- 目前的設計沒有地方可以取得/計算L1 duration
:::success
- 討論後異動:
- vehicol不處理距離相關的資訊
- duration刪除
- speedDistance, gpsSpeedDistance, gpsDistance移至vehicle_statuses.summary, 由tripo負責
:::
- fuelRate
- 如果VM-325獲取不到原始數據時, DMS是透過下列式計算:
fuelUsed / L1Duration / 3600
跟SpeedDistance一樣, 會需要使用到L1 duration
- fuelUsed
- 目前似乎只能透過計算獲得, 那還有需要放在journeyData內嗎
:::success
- 討論後異動：
- 刪除journeyData.fuelUsed，且留下calculated.fuelUsed
- fuelUsed可由fuelRate算出，若fuelRate值為空則用airUsed算出
- API gateway 看需求要仔細抓calculated或journeyData (from OBD)
:::
- fuelLevel
- 目前都只使用原始數據, 故calculated的fuelLevel應可以刪掉?
:::danger
沒記錄到QQ
:::
- fuelTankCapacity
- 當APP建立車輛時透過vehicleModel取得, 有需要放到curVehicleStatus內嗎? 如需要的話應該也只要放到journeyData?
:::success
- 討論後異動：
- 只留profile中的fuelTankCapacity
- 刪除calculated.fuelTankCapacity, journeyData.fuelTankCapacity
:::
- vehicle
- fuelStats (計算時機?) (先不考慮上下坡，油電車)
- fuelVssSpeed[] // 0: best, 1: average, 2: worst
- fuelAccSpeed[] // 0: best, 1: average, 2: worst
:::success
- 討論後異動：
1. 增加fuelSpeed[] , fuelAcc[] 用來儲存每個狀態(L3)的Fuel_Acc_Speed, Fuel_Vs_Speed，(參考vehicol dbdiagram)
2. 最後收到trip end再計算成上方fuelVssSpeed[], fuelAccSpeed[]
:::

## Devicio ([Schema](https://dbdiagram.io/d/5e0edf93edf08a25543f938c))
- deivceOBDII
- calibration.powerByBattery
- 布尔类型，这个字段什么含义?
:::success
- Def: 是否接在電池或點菸器上，若接在點菸器上車子熄火OBD就會關機，則不會有sleep start等event
- True為接在電池上，False則反之
:::
:::danger
- 透過L3 report的OBD mode決定 (if 1 true, else false)
:::
- bindVehicleId (priority 較低)
- 这个应该是接收 engin on 事件时检查更新，还是应该设备重启时检查更新？
:::danger
- Def:紀錄使用過此OBD之vehicle
- 接收valueAdded Report XXX讀取vin(?)
- update此欄位和vehicle.XXXX
:::
- curBindApp
- 这个字段是 app 更新？
:::success
- 應用: 讓vehicle/ETP owner知道有哪些app user可以看到此台vehicle/OBD的資訊
- Def: 紀錄哪些app user有加此OBD
:::
:::danger
- A: 是 OAO?
:::
- WiFi
- 依照內容來看, 應該是紀錄目前OBD的config
- 可能由Commando更新? (當改動的時候)
:::success
- 由Fronto維護 (API GW -> Fronto -> Commando)
- 上面那樣做只有考慮到APP的改動, 但其實也可以透過簡訊更改,這樣會有不同步的問題, 可能統一由Commando更新會是比較好的選擇
:::
- cellular.simICCID
- 因為不確定會不會使用我們的SIM卡, 是不是改成填value added的IMSI?
:::success
移除此field, 改成IMSI (from value added 133)
:::
- 打包時機?
- TBD
>>
- dailyRecord
- Operating min
:::success
定義為收到engine on的時間直到收到engine off的時間
:::
- Sleep min
:::success
定義為收到第一筆keep alive report到收到engine on的時間
:::
- gpsLossMin
:::success
- 定義:
為收到第一筆quality report (經緯度為null) 至收到quality report (經緯度不為null) 的時間
- journeyData需要新增此欄位
:::
- cellularLossMin
:::success
- 定義:
收到第一筆cellular service (cellularId or lac 為null) 至收到cellular service (cellularId or lac不為null) 的時間
- journeyData需要新增此欄位
:::
- VehicleStatus
- device.cellular.status
- generation 这个字段不清楚
:::success
- Def: 2G, 3G, 4G, 5G (5th generation mobile networks)
- From L2 Report Cellular Status
:::
- signalStrengthLevel 这个字段不清楚
:::success
- (Greg: 填cellular_service的signalStrength)
:::
- iccid 这个字段不清楚
:::success
移除此field, 改成IMSI (from value added 133)
:::
- connected
>> TBD
- device.cellular.dataAmountBySim 这个字段不清楚
:::success
移除, 但在打包daily record時, 透過呼叫SIMO取得並寫入daily record
:::
- device.WiFi.connectedUsers 这个是connectedMac的数组长度？
:::success
- (Greg: 是, 目前連線的client數量)
:::
- device.OBD (可能拿來判斷進地下室，因為角度變了，這兩個字段先放置)
- deviceOrientation 这个值如何计算
:::warning
TBD (James說可以先忽略, OBD會提供, 目前計算orientation的值可以透value added "Calibration Complete Report"內的 X, Y, Z, cosx)
:::
- vehicleOrientation 这个值对应的是 header 里面的 heading？
:::warning
TBD (James說可以先忽略, OBD會提供, 先忽略)
:::
- device.gps.hdop 是否是 GPS Accuracy： The radius of uncertainty for GPS location ?
:::success
- (Greg: 是)
:::