简介

近年来，我国新能源汽车行业出现蓬勃发展的态势。主机厂曾经收集了大量的电动车的车联网数据，包含三大类（动态车辆数据、实时处理数据和实时车辆告警数据）160多项数据。主机厂心愿从这些数据中失去报警的统计和剖析，并且心愿延长到报警的预测，能够及时召回可能产生故障的车辆或者被动推送更新软件到车端进行修复，升高电池事变造成的损失，晋升客户的满意度。

本篇介绍了如何利用Amazon Web Services的服务组件疾速搭建电动车电池告警预测平台，包含存储海量测试数据，构建基于XGBoost分类算法的电池故障报警预测模型，推理预测数据以及可视化的数据展现。

代码仓库

https://github.com/aws-sample...

架构概述

该解决方案是基于数据驱动来对电池单体一致性偏差报警事件进行预测，借助于Amazon SageMaker，您能够疾速便捷地构建本人的机器学习模型（如XGBoost，递归神经网络等），并实现模型训练，模型推理。该解决方案中应用Amazon DynamoDB和Amazon S3来存储预测事件的输出和推理后果。当您部署完该解决方案后，在SageMaker Notebook中会预置一个基于XGBoost二分类的机器学习模型脚本（xgboost_beginner.ipynb）以及样例数据(series_samples.csv)，运行该机器学习脚本能够实现预测模型的疾速构建和主动部署。本解决方案反对的推理事件有两种形式：其一为用户间接应用POST申请携带输出特色数据获取推理后果，该形式是基于Amazon API Gateway和 Lambda实现；其二为用户上传收集到的批量电池数据（能够来源于您on-premise数据库，或实时车辆网收集到的电池数据）至Amazon S3桶，数据上传事件会主动触发Lambda进行推理。所有的POST申请推理和S3上传事件触发的推理均能够通过Apache Superset进行可视化，它是由 Fargate进行承载，不便您实时查看具体的电池单体一致性偏差报警事件。架构图中各个组件之间的关系用连贯箭头示意，其具体含意别离为：

  1. 主机厂或电池厂商将采集的电池数据上传至 S3桶中，用于模型建模和训练；
  2. SageMaker Notebook Instance获取电池数据；
  3. 在SageMaker Notebook Instance中实现模型建模，训练和部署，部署后的Inference Model是一个Runtime Endpoint，它用来提供预测推理服务；
  4. 利用场景一：车辆网上传的数据推送到的S3桶，S3桶中新减少的Batch数据即为须要推理的数据；
  5. 利用场景一：新减少的Batch数据主动调用Lambda进行转发申请；
  6. 利用场景一：Lambda调用SageMaker Runtime Endpoint进行前向推理；
  7. 利用场景一：前向推理的后果写入到Dynamo DB进行存储；
  8. 利用场景一：前向推理的后果写入到S3进行存储（供Superset可视化）；
  9. 利用场景二：用户调用API进行前向预测推理，用户采纳POST调用；
  10. 利用场景二：API Gateway将申请路由到Lambda函数；
  11. 利用场景二：Lambda调用SageMaker Runtime Endpoint进行前向推理；
  12. 利用场景二：前向推理的后果写入到Dynamo DB进行存储；
  13. 利用场景二：前向推理的后果写入到S3进行存储（供Superset可视化）；
  14. Superset后盾部署在Fargate Service, 基于SQL数据查问拜访实时推理后果的数据；
  15. Amazon Athena从Glue Data Catalog中的数据库和表中查问数据；
  16. Glue Data Catalog的表格Schema是对预测后果S3桶中记录的定义。

解决方案部署

部署能够在北京区、宁夏区、美东一区进行，若在国内部署须要开明ICP Exception。能够间接基于Cloudformation部署，cloudformation的模板下载链接进行，创立堆栈时参数放弃默认值即可。

美东一区：
https://aws-gcr-solutions.s3....

中国区（宁夏/北京）：
https://aws-gcr-solutions.s3....

数据分析/模型训练/模型部署

在解决方案部署实现之后，在SageMaker控制台中会创立一个笔记本实例。内置XGBoost的脚本和电池样例数据集，用户在实在应用场景中能够基于本身的电池数据集来进行模型构建，训练和部署。

关上SageMaker控制台，能够看到部署之后预置的笔记本实例：

点击 [关上Jupyter]，进入界面如下：

关上 xgboost_beginner.ipynb，顺次执行每一个代码块，便能够逐渐进行数据加载，各维度数据分析与可视化，数据集划分，XGBoost分类模型构建与训练，模型主动部署，模型性能测试等一系列操作。

样例数据集中蕴含了“车架号VIN”，“采集工夫Date”，“总电压(V)”，“总电流(A)”，“电池单体电压最高值(V)”，“电池单体电压最低值(V)”， “最高温度值(℃)”， “最低温度值(℃)” 信息。最初一列的Label表征数据在该天是否产生了电池单体一致性差报警，0示意没有报警，1示意产生报警。在xgboost_beginner.ipynb脚本中，选取历史14天的样本并聚合在一起造成一个 14*6 维度的特征向量，基于该向量预测将来14天内是否呈现电池一致性差报警，此问题被形象成一个二分类问题。

在构建模型输出数据集时，首先将历史特色聚合成一个大的向量，并将将来14天内的电池一致性报警标签进行聚合，举例说明：对于第x天而言，第x-14天（含）到第x-1天（含）这共计14天的特色（维度为6）聚合成一个84维度的特征向量；若第x天（含）到第x+13天（含）这将来14天呈现电池单体一致性报警，则该特征向量对应的分类标签为1；反之为0。通过滑窗操作对所有数据执行上述操作，提取所有的样本，再依照4:1划分为训练集和验证集。

实现模型训练后能够看到训练迭代过程中的error (loss)逐渐收敛，如下图所示：

模型部署须要5分钟左右，放弃脚本中的 sm_endpoint_name参数不变即可，在解决方案中lambda函数会以此名调用Sagemaker endpoint：

在XGBoost模型部署实现之后在SageMaker终端节点中会呈现如下处于“InService”状态的推理节点。

继续执行xgboost_beginner.ipynb的代码块，能够对电池故障报警分类算法的性能作出评估，采纳的性能指标包含：

  • 真阳(True Positive): 实际上是正例的数据被分类为正例
  • 假阳(False Positive): 实际上是反例的数据被分类为正例
  • 真阴(True Negative): 实际上是反例的数据被分类为反例
  • 假阴(False Negative): 实际上是正例的数据被分类为反例
  • 召回率(Recall): Recall = TPR = TP / (TP + FN), 掂量的数据集中所有的正样本被模型辨别进去的比例
  • 准确率(Persion): Persion = TP / (TP + FP), 掂量的模型辨别进去的正样本中真正为正样本的比例
  • 假阳率(False Positive Rate, FPR): FPR = FP / (FP + TN), 掂量的是 被错分的反例 在所有反例样本中的占比

基于不同分类阈值绘制出ROC曲线（FPR-TPR），当抉择的阈值越小，其TPR越大，FPR越大；ROC曲线下的面积约靠近1.0阐明模型越优。下图为示例数据训练后在验证集上的性能出现。

基于POST申请调用触发推理

在SageMaker推理节点部署胜利后，你能够通过HTTP POST申请来调用电池预测推理服务，POST数据中携带特色数据，在该解决方案中以14天数据为特色，每一天蕴含“总电压(V)”，“总电流(A)”，“电池单体电压最高值(V)”，“电池单体电压最低值(V)”， “最高温度值(℃)”， “最低温度值(℃)”这六个维度的特色，共计84维数据，POST申请地址为cloudformation部署诚征的API Gateway地址后加上“inference”路由。基于curl调用示意如下所示：

curl --location --request POST 'https://<your_api_gateway_route_address> /inference' \--header 'Content-Type: text/csv' \--data-raw '{    "vin": "1DS7KPXR9HJU3MB6L",    "date": "2018-02-11",    "features": "3.384580459770114658e+02,8.701149425287356687e-01,3.532045977011495363e+00,3.516270114942528391e+00,2.154597701149425149e+01,1.897701149425287426e+01,3.398913612565444851e+02,-6.835078534031412412e-01,3.543062827225131439e+00,3.532743455497382445e+00,2.099476439790576165e+01,1.978534031413612482e+01,3.402831125827814844e+02,-5.124999999999998446e-01,3.547005794701986403e+00,3.537400662251656058e+00,2.720033112582781953e+01,2.516390728476821081e+01,3.407290270270270298e+02,-8.411351351351350480e-01,3.551178918918919791e+00,3.541806486486486882e+00,2.770324324324324650e+01,2.623675675675676189e+01,3.402226449275361801e+02,-5.949275362318843241e-01,3.546726449275362736e+00,3.536807971014492402e+00,2.436594202898551131e+01,2.247463768115942173e+01,3.403696066746126121e+02,7.842669845053640287e-02,3.548485101311084744e+00,3.537239570917760201e+00,2.264600715137067866e+01,2.049463647199046434e+01,3.404395087001022944e+02,-7.123848515864886211e-02,3.549054247697031705e+00,3.538847492323438981e+00,2.271340839303992354e+01,2.069907881269192274e+01,3.408940234791888315e+02,-3.463180362860191486e-01,3.553680896478121021e+00,3.543157950907150688e+00,2.316648879402347916e+01,2.132337246531483643e+01,3.408360576923076906e+02,1.437499999999999889e-01,3.552947115384615273e+00,3.542481971153845777e+00,2.368870192307692690e+01,2.163942307692308020e+01,3.407270958083831829e+02,-7.137724550898206788e-01,3.552561377245509355e+00,3.539895209580837587e+00,2.052095808383233688e+01,1.858532934131736170e+01,3.412096446700508068e+02,1.184433164128595624e-02,3.556835025380711723e+00,3.546649746192892749e+00,2.414890016920473670e+01,2.245685279187816974e+01,3.421997359735972850e+02,5.627062706270629100e-01,3.567919471947194943e+00,3.558117491749174466e+00,2.529174917491748786e+01,2.353729372937293363e+01,3.405827586206896171e+02,-5.479623824451408387e-01,3.549921630094044378e+00,3.538965517241378755e+00,2.196238244514106697e+01,2.023824451410658654e+01,3.414845094664372027e+02,-1.037693631669534877e+00,3.560283993115317625e+00,3.548870912220310370e+00,2.196385542168674831e+01,1.999311531841652467e+01"}'

基于S3桶批量数据上传触发推理

此解决方案还反对批量数据预测，测试数据能够从下方地址下载：
https://github.com/aws-sample...

将此数据上传至部署账户中名为bev-bms-infer-<region_name>-<account_id>的S3桶中（该桶在部署时曾经主动创立），数据上传事件会主动触发推理。

推理后果会实时写入到DynamoDB数据表中，如下所示：

Apache Superset配置

此解决方案基于Apache Superset来对预测的电池单体一致性偏差报警事件进行可视化，首先关上Cloudformation部署胜利后的输入链接，如下所示：

登录用户名和明码均为admin.

点击[Source]à[Databases]，如下图所示：

点击右上角+号，创立Database，如下图所示：

增加Database，Database处输出“demo”,  SQLAlchemy URI处输出：
“awsathena+rest://@athena.< region_name>.amazonaws.com.cn/default?s3_staging_dir=s3://bev-bms-events-<region_name> -<account_id >/query”

输出实现后能够点击[TEST CONNECTION]测试连通性，确认能够与Amazon Athena相连通。

滚动到最上面，点击[Save]，呈现如下界面：

推理事件可视化

点击Superset页面顶端导航栏[SQL Lab]à[SQL Editor]，左侧顺次抉择Database, Schema, Table, 在SQL查问输出栏中输出查问语句，如：

SELECT "request_id",       "vin",       "date",       "predicted_prob",       "total_voltage_1",       "total_current_1",       "cell_max_voltage_1",       "cell_min_voltage_1",       "max_temperature_1",       "min_temperature_1"FROM "battery-consistency-bias-alarm-prediction-glue-database"."battery-consistency-bias-alarm-prediction-events"LIMIT 100

查问后果如下图所示：

点击上图中的 [EXPLORE]，抉择排序形式为依据预测报警概率从高到低排序，如下图所示，能够清晰地看到推理后果中电池单体一致性偏差报警概率高的车辆VIN码，日期等信息。

用户能够编写其余SQL语句来查询数据库表中的推理事件，如针对某一辆车，某个日期进行查问，等等。

总结

此解决方案提供了在亚马逊云上构建电动汽车电池单体一致性偏差预测解决方案，并提供REST API调用推理和批量数据推理性能，最初还反对应用Apache Superset进行推理后果可视化出现。该解决方案实用于主机厂（OEM）或电池供应商来对电动汽车的电池衰弱状况进行监测和预测，同时实用于具备自主开发需要的OEM或电池供应商，能够基于该解决方案来自行开发算法模型，实现疾速生产部署。

本篇作者


徐高伟
亚马逊云科技解决方案架构师
负责基于亚马逊云科技的云计算计划的征询与架构设计，致力于亚马逊云科技云服务在汽车，物联网，人工智能等行业的利用和推广。在退出亚马逊云科技之前曾在BMW无人驾驶研发核心负责机器人和人工智能专家，负责无人车环境感知，行为预测和决策布局研发。


曹菱欣
亚马逊云科技汽车行业资深解决方案架构师
超过20年IT行业工作教训，有售前，施行和研发教训，5年以上针对客户PaaS和SaaS方面的我的项目施行教训。专一于亚马逊云科技云计算在车联网，无人驾驶，汽车生产制作，银行证券等畛域的技术咨询和施行。