lpProject.txt

1. 物联网卡流量管理

    支持车辆物联卡查询，恢复/断开上网，流量充值，套餐计算等功能。支付服务使用支付宝服务。
    定时（每2h）检查数据库中所有车辆的物联网剩余流量情况，根据结果更新上网状态，流量低于阈值放入缓存中检查频率更高（20min）的紧急集合，并将查询结果放入另一个缓存，供车机查询。
    缓存中的剩余流量采用定时（每2h）+惰性（车机查询时检查是否过期）更新策略，有效期最长5分钟。
    此方案可以减少平台轮询压力又不会出现断网不及时的情况，且保证车机查询到的流量5分钟内有效

    困难/问题：
    1. 流量充值后，流量从负变为正，支付宝Api充值回调中需要调易达通恢复上网接口，支付宝回调返回超时，会重复调用产生业务bug。	易达通相关接口为耗时操作，导致支付宝支付回调超时。	在充值回调中起线程完成业务操作，使立刻充值回调立刻返回。
    2. 在月初/底查询流量时，需要统计当月充值流量，由于数据库中时间与运行环境时间不一致，导致统计得到的当月充值流量错误。比如在8月1号1点查询当月充值流量，使用数据库内置函数curdate()可能会返回7月31号19点，这样查询出来的充值流量将为7月充值流量，产生bug。

    后因为新车型使用不同的流量套餐策略调整方案：
    T03流量套餐方案如下，前提为用户充值流量有效期为当月+下月，而非充值后30日，请参考：
    引用月转结流量的概念，优先使用赠送流量和上月转结流量，只转结用户充值流量没用完的部分到下个月。在每月底清算每辆车的剩余流量即转结流量，存入数据库。在计算剩余流量时，加上上个月转结流量。
    月底清算用户转结流量时，若用户 当月使用量 < (赠送流量+上月转结流量)，当月转结流量=用户当月充值流量；否则，当月转结流量=赠送流量+上月转结流量+用户当月充值流量-当月已用流量
    用户某个时间点剩余流量=赠送流量+上月转结流量+用户充值流量-当月已用流量
    赠送流量根据车型和使用时间计算：S01车型永久6G；T03车型购买一年内1G，一年后0G。



2. 乐橙设备SDK/流媒体平台

    使用RTSP/RTP协议实现视频推流（车辆视频上传）及拉流端（客户端视频播放），根据需求与设计定制开源流媒体服务器EasyDarwin（多路视频会话控制及传输）。
    后调整为全面使用大华乐橙视频方案，使用乐橙设备SDK，接入大华乐橙平台，使用乐橙APP API。主要负责使用乐橙（大华）提供的设备SDK（c++动态库），利用jni开发基于android的设备端应用层功能，包括音视频采集与播放、本地录像查询等。支持H264视频格式，AAC/g711a音频格式

    技术上涉及jni编程，ndk编译方法，Android应用开发
    1. Android层：
        ·实现MP4视频文件解析，读取，拖动进度条（桢重定位），Android麦克风音频采集解析，ACC/g711a音频数据
    2. jni层
        ·与jvm的连接管理（获取jvm实例，获取Java调用对象实例）
        ·Java和c++互相调用（传递基本类型，数组，对象），将Java变量转化为c++层变量
        ·使用RAII技术使用一个类来封装Attach/Detach JVM线程的操作，即分别在构造和析构函数中Attach和Detach JVM，这样可以确保Attach之后一定会Detach
    3. cpp层：c++层设备实例管理（与乐橙平台通信）
        ·本地录像查询，月历掩码，
        ·实时/点播视频播放，跳转
        ·多线路管理

    主要困难：在乐橙设备SDK本身未经测试、有很多bug的情况下，开发自身功能的同时协助乐橙开发解决SDK内部bug
    1. 乐橙提供的库虽然是编译为arm架构的库，但Android程序仍然无法加载，崩溃。自己编译生成可被Android程序加载的c++库，通过排除法确定是乐橙提供的库无法使用，后前往大华与开发人员交流，让他们用NDK编译SDK库，最终可以使用
    2. 乐橙提供的库存在内存泄露，Android程序调试困难，问题重现困难（有一种情况是在信号不好的情况下，比如把Android开发板的4G信号遮挡），jni层无法使用调试，只能通过日志定位，乐橙提供的SDK内部错误无法准确定位，也只能通过排除法排除我们这边的问题。
    开发过程中自己写过很多模拟工具，从视频文件读取帧数据，模拟摄像头采集


3. 车辆实时数据解析，存储与分析

    平台与车辆通过消息中间件EMQTT来传递数据，考虑到消费速度赶不上生产速度，引用kafka，把emqtt收到的消息再写入kafka，kafka消息一个给订阅消息的数据解析模块消费，另一边写入hdfs供之后大数据（历史数据）分析。最终实现车辆数据解析，存储，故障发现与上报。
    故障报文协议：一辆车有多个部件，每个部件有8字节的数组的故障状态数据(can报文)，每个字节中的每一位表示一个故障的状态。因此车辆上报的数据是状态值，而非故障事件。
    约定车辆只上传状态前后有变化的报文数据。
    平台在缓存记录所有车辆所有部件的当前状态值（不断更新），代表当前有/无故障，一个是用来与下次故障状态数据对比，来判断出是否有新增/修复故障事件发生，因此需要维护上一次行程和当前行程的故障状态（记录数据库主键值）；另一个是供用户查询当前车辆是否有故障。
    后由于车辆bug，高频上报故障新增修复事件（有故障无故障不断切换），新增故障去重机制，在车辆一次行程中，相同故障只记录一次，故障新增/修复事件重复上报，只更新不新增。

    困难/问题：
    1. 车机上传数据混乱，重复，倒序，没有按协议完全实现，平台需要过滤无效报文，并增加额外逻辑处理没有按协议实现的数据。
    2. 故障报文数据结构复杂，数据量大，每个部件故障种类数量不同，多的70多个，每个故障的等级与含义都不相同，而车型不同，对应的故障也不相同，需要将字节中每一个bit转换为约定的故障存入平台缓存与数据库。等级高的故障需要重点上报。
    3. 将对象放入缓存后再取出，使用强转失败，定义无参构造函数和属性的get/set方法后正常。猜测虽然redis中存储的是对象而非json字段串，但从redis取出数据转化为对象时，还是依赖反序列化。


4. 流媒体全家桶

5. 零云监控平台功能：
展示车辆基本状态信息（行驶状态， 充电状态，位置），各个零部件信息（电池，车灯，胎压，空调，电机，车机仪表，安全气囊），车辆统计信息，分为单车和所有车，统计历史轨迹，能耗，里程，驾驶行为，制作成年度报表发给车主
故障查询，远程升级


    ·首页展示旗下所有车辆，全国分布图，总数，在线数，充电中，行驶中
    ·车辆状态
        ·整车状态：是否上电，上否在充电，是否在行驶，胎压，空调，各种灯，电池，温度，位置
        ·温度变化过程监控，包括驱动电机和电池包
        ·车辆各个零部件版本信息，比如BMS，驱动电机，空调系统，OBC，EPB，EPS，ESC，车机仪表，安全气囊
        ·历史轨迹：记录车辆每一段轨迹信息，包括空调使用情况，剩余里程，各部件能耗，速度信息，电池温度，温度（车内，车外，仪表，车机），驾驶行为，比如急加速，急减速，急刹车
        ·整车日志：
        ·用车统计：车载应用使用统计，充电记录，用车时长，里程能耗统计，电池温度电压极值分析，远程控制记录
        ·
    ·车辆维护
        ·车辆管理，展示所有车辆基本信息
        ·故障列表
        ·远程can报文拉取
        ·国标数据展示
        ·OTA升级，升级包上传/管理，各个车辆各个部件的升级状态/记录
        ·物联网卡查询管理
        ·音乐充值记录
    ·数据统计
        新增车辆变化
        车辆总里程，月行驶里程（平均值，最大值），日行驶里程
        车辆使用率，每日用车时长，每月用车时长（平均值，最大值），用车次数
        充电统计，快/慢充，
        BMS压差异常统计
        能耗统计，每日平均，百公里，每月（最大/小，平均）
        车速统计
        数据导出：整车，驱动电机，VCU整车控制器，BCM车身控制器，BMS电池管理系统，仪表，车机MMI，PTC加热系统，空调，安全气囊，EPB，EPS，ESC，热管理，事件状态协议，车辆能耗统计，充电机，胎压，
        百公里能耗排名
    ·系统管理
        用户管理，对监控平台用户分配各个功能权限
        角色管理：OTA，售后，车辆状态和故障查询，产品线，管理员
        权限管理
        系统日志，记录各个用户操作记录


6. 车辆端功能
    音乐，FM，行车记录，预约充电，导航，空调，乐橙，自动泊车，途记，天气，微信，身份认证，语音，