tpi管理密码是什么意思（轮胎tpi是什么意思）

作者：仁威

（一）什么是车联网

未来智能互联化是一个不可逆转的趋势，生活中常用的物品都在逐渐联网化，例如洗衣机、电视、智能家居等设备，通过联网可以用手机控制，甚至于智能穿戴的设备，衣服、眼镜、鞋都有逐渐联网的趋势。

手机作为第一个智能终端，它已经从简单的通话工具演变成了可以社交，查看新闻，甚至办公的工具。汽车也是一样，现在汽车正在逐渐联网，成为第二个智能终端。汽车作为智能终端接入网络之后，利用车载设备实现智能化交通、移动金融服务、购物、车家互控等场景逐渐成为现实。这些场景下会产生越来越多的数据，比如，现在可以从手机端直接连接汽车4S店的服务。甚至汽车跟手机的终端打通，已经可以互联互通互动。也可以从汽车端直接控制家电，比如在汽车上有些高端车，可以直接车家互动，在车里面控制家里的空调、洗衣机等。

除了这些，未来娱乐内容等方面的数据，以及车上产生的状态轨迹数据都会逐渐向云端存储，而5G的发展无疑加速了进程。

（二）市场趋势

随着5G网络的建设，传统的移动互联网市场已经饱和，一部分企业开始瞄准5G带来的汽车互联网机遇，探索5G所驱动的汽车革命；同时，汽车企业在过去几年时间提升了认识，逐步开始实践数字化转型，部分企业已经初见成效。之所以5G可以给汽车互联网带来发展机遇，主要原因5G支撑了云计算在汽车上的应用，这使得云语音等服务成为可能。

与其他设备的移动互联网应用不同，汽车互联网的应用有一定难度，主要是汽车企业主动性不强，完全外部安装的设备不容易发挥作用，利用5G带来的云平台接入，给汽车企业带来了主动数字化转型的动力，那么汽车互联网的发展会大大加快。

第一阶段：2G/3G/4G联网的时候，主要是解决“通”的问题，能看到汽车的状态，比如现在租车或网约车汽车的状态与位置，用2G/3G/4G数据传就足够了。

第二阶段：带宽逐渐增加之后，就可以拿到更多车上产生的数据，做大联网的数据。但车联网的大数据分析，能够为保险行业或者其他金融行业提供车主驾驶行为的数据判断。

第三阶段：V2X、5G、云端互联，带宽已经越来越高的情况下，可以实现更多车和其他系统的对接，更多更丰富的功能。

第四阶段：可以借助于云端无穷无尽的计算能力，去做一些智能化的计算和判断，实现智能驾驶***连接系统，对接第三方系统，对接车车的互联，车和路测终端，更紧密的互联等更大场景下的智能化应用。

中国车联网用户规模不断攀升，5G/V2X技术应用有望实现强劲增长，2022年用户总规模将超过5100万。短期，中国车联网市场规模的增长主要依赖软硬件装载量的提升。中长期，随着车联网生态的丰富，广告、CP/SP等以车联云为核心的车内增值服务将带来更广阔的增长空间。

早在2017年，***就推出了车联网行业的新四化：“网联化”、“智能化”、“共享化”、“电动化”。无论从***规划还是从科技发展趋势来看，这四化都将成为未来汽车行业的发展方向。未来，所有汽车行业都会从传统的汽车制造企业向出行服务方向进行转型。随着国内汽车保有量和人均收入的快速增长，给客户提供更加可靠、安全、优质的出行服务，将变成车企的主要目标。针对这个目标，阿里云存储产品需要给车企提供可信赖的数据支撑，便于车企对自身进行优化、改进。

图源见水印，侵删

据前瞻产业研究院发布的《车联网行业市场前瞻与投资占率规划分析报告》数据显示，2020年中国汽车保有量约为2.5~3亿辆，按照15%的渗透率，具备联网能力的车辆将达到4000万辆左右。以每辆1000元的硬件产品价格来估算，单是硬件市场就有400亿元规模。而随着产品功能的丰富，单辆车的硬件产值也会翻倍提高，加之互联网服务，车联网市场的空间可以在5~10年内达到千亿甚至万亿规模。

（一）车联网系统数据存储

汽车企业在生产系统中采用云战略实现上云上平台，一方面可以解决过去难以解决的各个系统互联互通问题，另外一方面，可以通过推进产业互联网平台，为各地域的工厂（不一定是同一家公司）之间共享信息提供基础条件。

上图左右放的是智能互联系统的云端架构图，从左边这个逻辑架构图可以看到，从下面产品通过网络接入云端，首先连接底层的是产品的数据库，云端在资源池化之后，让用户以更贴近业务的方式去定义业务相关的一些应用和产品。

所以说，从第一层把数据对接上来，就要进入云端的数据库集中的存储，有了集中的数据存储层之后，才需要往上去建立应用层应用平台，或者是智能化的规则引擎，数据来驱动平台。根据不同的业务互动场景，去建设相关的应用。

右端是数据架构图，表示数据首先从车企端采集以后，不单纯是车上的各个指标数据，还有它的位置信息以及其他更丰富的数据，比如智能后视镜，采集的视频数据、语音的数据和云端服务交互的数据。这些数据是多样化的，无结构的，半结构的或者结构化的数据都会有。所以需要有一个Delegate池化的大数据云端存储平台，能够支撑多模、异构的数据的存储、查询和解析。

这些数据不光是车产生的，还有可能第三方系统的，比如车跟支付宝平台对接，微信对接，第三方***银联的平台，或者是内容提供商的平台对接，服务提供商的平台对接，这些数据源也都可以作为我们数据库全景数据的补充。

有了全景数据，未来才能支撑更多更丰富的场景。

大致的部署结构如下所示：

首先车企端在一般情况下使用OBD、OBU把数据导出来。TBox是车集中的计算平台，就像我们的电脑似的，它把数据从OBD、OBU平台拿到之后上传，通过SIM卡跟云端发生交互。云端拿到数据之后，通过数据解析，一致化之后，再融入第三方数据源，实现不同场景下数据的应用，比如，车载应用：IVI新功能规划、新的交互模式、智能座舱体验；TSP服务：加油充电、道路求援、交通信息、停车服务；正常导向：***标准（国VI、EV）、第三方数据输入、安全体现等，都可以基于云端的数据，去搭建需求应用系统。

（二）车联网典型数据场景–新能源汽车监控

BEV新能源汽车监控场景主要是为了满足GB/T32960国标和地标的需求，以便车厂能够获得平台符合性及车辆符合性认证。整个车厂建设过程中，出于日常运营需求，往往在国标基础上建设额外服务，例如：通知、告警、监控、追迹、调度服务、系统报表、数据转发等功能。

调度服务：可选服务，可用于车辆运营。

报警信息：可选服务，可通知车主、4S店等定制化报警服务。

统计报表：可选服务，基于OEM要求进行定制。

数据存储：实施接受（10S频率），北京区域要求存储1年，上海地区存储3年。

数据查询：各个数据（实时数据/历史数据）的查询显示接口，需求提供报警新展示，单体蓄电池电压数据展示；动力蓄电池包温度数据展示；整车数据展示；极值数据展示。

（三）车联网典型数据场景–Telematics

Telematics是指应用无线通信技术的车载计算机，新一代Telematics将以公有云为核心，实现车辆***控制、***读取信息和智能赋能。目前有内置和OBD接头两种实现的方式，其本质都是对于汽车各系统ECU的***监控，已经实现的功能有***检测，***控制，呼叫中心等，比较成熟的有bluelink, 安吉星on-star，美国的snap-on，还有delphi出的Verizon Wireless等。

（四）车联网典型数据场景–智能后视镜监控

为贯彻交警“便捷高效，互联互通，共享共治”的互联+思维理念，充分发挥智能行车记录仪在交警执法中的积极作用，运营商积极配合深圳市交警局打造“车联网生态系统平台”，建立中国智能交通产业联盟上下游企业生态圈，支持车联网生态圈等相关企业发展，实现星级用户车主“一人一车一设备”的愿景，为车主提供多样化的车联网平台管理方案，以提高交警对车辆管理的效率。

（五）车联网典型数据场景–车载娱乐系统

车载信息娱乐系统（IVI）是智能驾驶舱信息交互的重要载体，基于车身总线系统和互联网服务，形成车载综合信息处理系统，可提供导航定位、车体控制、无线通信、车内娱乐和汽车移动等多种服务内容。产业链中，中控厂商凭借对硬件和软件的整合的产品优势和技术累积，占据了座舱电子产业链的制高点，未来，中控系统将成为人机交互的核心驱动，具备广阔的应用前景。目前，IVI能够实现包括三维导航、实时路况、IPTV、辅助驾驶、故障检测、车身控制、移动办公、无线通讯、基于在线的娱乐功能及TSP服务等一系列应用，车辆电子化，网络化和智能化水平强依赖云端能力。

云端和车机端的数据的交互量会大幅的提升，不光是服务能力赋能汽车，同时视频和音频汽车车主驾驶的时候操作的数字路径，都需要从云端去获取，这些数据也需要在云端去集中的存储，就是现在的一个场景和海量数据存储的一个现状。

（一）什么是云原生多模数据库Lindorm？

云原生多模数据库Lindorm适用于任何规模、多种规模的云原生数据库服务，支持海量数据的低成本存储处理和弹性按需付费，兼容HBase、Solr、SQL、OpenTSDB等多种开源标准接口，是互联网IoT、车联网、广告、社交、监控、游戏、风控等场景首选数据库。

未来，车联网场景将会是数据量大，数据类型多。不同场景下产生的数据类型多种多样，会有视频、文本、代码链路、用户数字轨迹等方面的数据，以及在车机端点击应用的操作行为。这些都会使得云端数据库建设对应的存储模型，以及查询能力，因此云端多模的存储能力是必选项。

同时，需要考虑对现有系统和第三方平台的对接能力，多模的数据库需要有一个***的标准和协议支持，支撑更大范围的数据生态。

Lindorm主要有以下四个特点：

1.极致性价比

当遇到数据量激增的场景，如果没有很好的数据压缩存储或者冷热数据自动转存的方案，数据成本也会激增。大部分的监控数据是机架式密度数据，有一些运维数据在不出故障的时候就没有什么价值。只有出了故障，在回溯分析定位的时候，它才会发挥价值。像这种数据，如果用传统的关系数据库或者是自建的数据库存储，运维和数据授权的成本非常高昂，是不经济的存储方式。

因此，未来需要极致性价比的物联网存储，能够提供PB级甚至EB级存储能力的存储平台，才能有效支撑这种场景。

2.云原生弹性

未来，我们需要云端提供随时进行池化资源的使用方式，没有业务的时候可以收缩资源占用量，节约成本。业务并发量大的时候，在保证性能的前提下满足成本控制的需求。

因此，弹性伸缩数据库的存储，是云原生场景下很关键的能力。

3.企业级稳定性

支撑如此庞大数量在线运行车辆的场景，稳定性至关重要。

例如汽车OTA场景，当发生故障或网络中断、数据丢失的情况，汽车升级可能发生中断，导致了车机端的故障或是智能化控制指令丢失，执行失败等。

4.数据生态融合

对接更广泛的生态，无疑可以支撑我们更大场景下的这个数据应用，这个也是非常关键的。

目标行业：工业物联网、 车联网、APM运维、NPM运维……

这些场景都有一个共同的特点，就是产生海量、带持续指标的监控数据，而这些数据的价值密度非常低，它需要一种经济且友好的数据库进行存储。

上方为Lindorm数据库体系图。

目前Lindorm的核心能力除了能够对接广泛的数据生态等，在数据库内部也有多模数据转存的通道，能够在宽表、时序、全文检索、文件检索引擎之间做数据的协同。

上层除了支持SDK等接口之外，还支持其他应用比较广泛的大数据生态接口查询语言。

（二）Lindorm产品策略

上方为产品发展策略，未来演进方向是云原生多模超融合数据库。

首先在金字塔底层的第一阶段，要具备海量多模数据的存储能力，把结构化、半结构化、无结构化的数据以较为经济的方式存储下来，对这些数据做云化的处理，称为数据云。

在此基础上，再建设跨数据库引擎的横向融合能力，如宽表、时序、图、关系等模型数据，实现数据库协同查询能力。

在Lindorm数据库内部，用户可以通过一致的查询语句，透明查询多种数据库，拿到所需要的信息。无论这个信息是从宽表、时序还是从文本检索引擎来的，均对用户透明化处理，从而更友好地支撑未来数据应用的开发。

再往上层的纵向融合指的除了数据库引擎、上层数据交换、ETF流数据处理以及计算引擎，可以在上层搭建数据库内部的运行，例如异常检测、趋势预测、关联性分析、相关性分析等，纵向地将数据库的能力进一步融合，进而达到超融合，实现统一的查询语言、数据视图，数据访问。

在车联网的一些具体场景下，比如新能源汽车当前电池包的健康状态监控，或者是公共场景下带业务特征的计算，都可以做成数据库内计算的算子，或是以函数直接通过标准SQL语句去调用，最后连存到算一体化执行，最终实现顶层推理的效果。

推理的效果指的是我们只需要告诉数据库我们的需求，则可得到相应的信息。建立统一的数据视图之后，可以用SQL语句定义，比如导致生产次品率上升的主要原因，汽车故障发生告警的主要原因等，这些能力都是现有的数据库和查询所不能实现的。

如果要提供以上能力，需要一系列的数据工具，如下所示。

上图为逻辑架构图，图中的最下方是能对接的第三方数据源，提供无缝的对接和支持。数据进来之后到宽表时序等文件引擎，在这里面根据业务场景不同，可以划分不同场景进行存储，有配套的数据转储和数据采集工具。

再上方就是计算引擎，还有数据检索的引擎。如Phoenix SQL引擎，Lindorm监控服务，以及时序数据分析等服务。再上层是人机界面，为了方便基于数据库开发数据应用，最上层是应用系统。

1）高性价比存储

2）多模超融合检索

1）时序数据压缩

2）工业场景数据建模

3）时序统计及非确定性推理检索

1）LindormStudioIDE、工具、SDK

2）文档、方案、案例库

3）***、体系化IT&OT融合服务能力

1）***生态：开源：CQL、PhoneixSQL、 ES、MachineBeat…

2）商业：OSIsoftPI、Splunk

OSIsoft、Intel、工业大脑、IoT、东软、 飞象互联…

上方为以前和当前存储方案对比，原来的部署方案需要应用开发人员和运营人员具备较高的动手能力，后续数据量增加的话，每个系统要单独做集群，需要耗费大量的人力和专家进行支撑。

当前的Lindorm存储方案是一个数据库帮助客户解决日常问题，用一个接口查询所有多模型的数据库。

（三）Lindorm车联网数据存储解决方案

在部署形态上，未来的车联网与物联网是便载、地域分布广的场景，单独在云端搭建数据库无法满足性能实时性的需求，所以未来数据库形态逻辑和物理部署可能是一对多，称为云边端一体化的数据库部署方案。

边缘端不管是车联网路测端的设备或者车机上的TBox，都可以去嵌入轻量级持续数据采集的数据库或者是多模数据库。在工业场景下，已经实现了在边缘计算节点上部署边缘数据库，它可以无缝对接混合云、私有云数据中心或者是公有云平台数据库，做实时或按策略批量的数据同步。

用户在实际部署和使用过程中，可以把分布部署的数据库作为逻辑一体的数据库来管理和实现。比如边缘端部署，它可以采集存储一段时间周期的数据，然后支撑实时面向边缘端所连接的设备或者车辆数据，实时查询与监控的场景。

一旦需要全景数据或者是需要回溯分析出报表，统计数据的时候，可以借助云端强大的计算能力与存储能力，做全量数据的回溯，做复杂计算以及根源分析，甚至机器学习场景的模型训练，完美实现逻辑一体，实际物理分离。既能支撑实时场景，又能支撑批量分析场景的数据存储解决方案。

BEV新能源汽车监控场景主要是为了满足GB/T32960国标和地标的需求，以便车厂能够获得平台符合性及车辆符合性认证。在整车厂建设过程中，出于日常运营需求，往往会在国标基础上建设额外服务，例如：通知、告警、监控、追迹、调度服务、统计报表、数据转发等功能。

针对这个场景，我们提供了基于阿里云Lindorm数据库的整体解决方案。

首先，这个方案里除了Lindorm，还用到了其他阿里云数据库产品，比如多维数据分析数据库ADB，第三方开源的Spark streaming，还有IoT网关MQTT等。

这个流程从车机端对接云端一般有两套方案，一套方案是车厂对接车联网的服务提供商，他们有自己私有云平台来对接车机端的提供，然后再由他们的平台来对接到阿里云的Lindorm数据库。

另外也可以直接按标准协议去对接车机端现有的TBox，直接用 REST接口来同步数据，或者MQTT协议直接发送到IoTGateway。这些数据到了云端之后，它可以分成两个流，一个实时写入Lindorm，快速上报***平台，周期10秒，在周期内完成上报***平台以及存入数据库这些动作。

另外一个为了实现实时报警与数据分析，数据流也同步推送一份到Spark streaming，由它做实时流数据分析生成事件，然后再存入Lindorm数据库。

如果有第三方数据的对接，比如车厂以及其他第三方系统做数据的归集备份，或者是第三方的平台的应用也需要这块数据，就需要推到Kafka里边，然后再由Kafka消息队列发到车场的数据中心。

车场数据中心也可以部署一套Lindorm数据库和云端做实时数据同步，当出现网络链路不稳定，或者车厂做数据分析的时候，在车场本地的数据中心也可以完成数据分析的工作。

***数据平台最主要是北理工的平台，有标准的接口协议直接在云端开发相应的数据推送服务节点对接***平台，地方平台有地方标准和相应接口，可以云端直接转发。

这里用到的数据库主要有，Lindorm数据库做全量数据的存储，Lindorm数据库中需要结合其他数据，比如说CRM的数据，车辆信息数据，基于密码查询相关的信息等复杂高维的数据查询，可以同步到ADB，再用ADB同步到数据分析平台QuickBI，来做数据的统计和可视化。

另外一个就是开源的Grafana，如果是需要监控全景或针对特定车辆的信息，可以通过Grafana来实时查看最近时间窗口的状态。

IoTGateway主要负责和车机端对接，或者和车联网的专有云平台对接。

（四）车联网场景下Lindorm商业价值在哪？

1）高通量车联网数据并发写入快

2）时序数据聚合、划窗、统计计算快

3）海量监控数据检索查询快

4）数据全生命周期管理流程搭建快

1）海量车联网数据存储成本省

2）占用计算、存储资源省

3）数据库搭建、应用对接开发工作量省

4）数据全生命周期运维管理成本省

在车联网场景下Lindorm商业价值可以总结为两点，一个是快，另外一个就是省。

快就是，说在高通量的车联网数据并发写入的场景下，可以在云端进行云原生的模式，随机汲取的模式，去实现车企端、在线车辆产生的实时海量高通量的数据，可以快速地在云端数据库写入以及数据快速向第三方平台转发。

时序数据聚合、划窗、统计时，在有原生的自研时序数据库情况下，很快地在数据库内做大量数据的聚合、划窗、统计分析。海量监控数据检索查询快，因为它是时序数据库引擎来处理的，可以支持海量多维度数据的聚合查询的计算检索。

数据全生命周期的管理流程搭建很快，因为很多能力都是数据库内提供的，就不需要再去人工搭建，或者是维护自建的开源数据库来定制开发能力，或者数据对接的接口，所以说搭建过程也很快。阿里云之上开通Lindorm数据库，几分钟时间就可以完成。

省就是，对海量数据存储成本会有大幅的下降，除了自研的冷数据、热数据备份的策略，在存储层也做了自己的优化。在时序数据库数据压缩方面，在现有的压缩算法上做了一些改进，达到了10倍数据压缩效果。

占用计算存储资源通过云原生的方式，随机汲取，在没有太多的在线车辆的情况下，收缩它的计算能力，按实际的数据的访问使用量来收费，这样就节约很多数据超配的成本。

数据库搭建应用对接开发工作量也会省下很多的人工的成本，一方面是数据库本身支持很多的第三方大数据生态接口的对接，另外云端搭建就不需要关心数据库安装和备份策略等配置的问题。

数据库全生命周期运维管理的成本，也会节省很多，灾备集群的方案，数据库的整个转储等这些都是数据库内自动解决的。

（五）Lindorm关键技术优势

1. 实时无损，高压缩比存储> 10:1

10:1的深度优化，基于ZSTD算法的压缩，可以把原始的采集的时序数据，比如10GB数据存入到数据库内去做无损的压缩，做到10GB数据存到数据库内，1GB数据的存储容量就足够了，压缩效率相比现在业绩通用的SNAPPY压缩提升50%以上的压缩效率。

2. 面向低价值密度监控数据的冷热分离低成本存储

冷热分离的低成本的存储方案，我们是在Lindorm数据库内做的一体化整个分离，数据也是自动做分层，冷热的分离，就不需要人工介入。冷数据存储成本一般比现在的热数据要降低80%以上，热数据为了满足性能的要求，一般用SD等高端的存储来存冷数据，性价比较高的存储来存这些历史数据。这样的话既兼顾了查询的性能，同时又节约了成本。

3. 云边端融合存储，数据自动实时、批量同步

1）边缘版轻量级快速集成部署

2）2HA高可用架构

3）具备与云端版本一样的功能

4）数据自动同步至阿里云TSDB实例集群

云边端一体化的存储的方案，边缘端的数据库、嵌入的数据库，根据策略去做实时的云端数据同步以及批量的数据的导入与导出。

4. 多引擎超融合数据快速迁移同步

在数据库内部是集成了一个ETL工具，做多模数据之间的数据导入导出，甚至对接第三方的HBase或者Cassandra、OpenTSDB等数据的迁移，可以把第三方的数据源数据通过LTS直接迁移到Lindorm数据库，就不用再依赖于第三方工具实现。

5. 多模数据融合检索打通IT&OT数据交互

多模数据融合检索打通IT&OT数据交互，实现跨多引擎引擎查询，提供全维检索能力。

1）系统自动维护索引，应用开发不感知索引表

2）索引支持非冗余、冗余部分列、全冗余

3）查询时基于编译优化（RBO）全自动路由到搜索引擎，并智能判断是否需要回查宽表/时序引擎

1）异步增量索引，基于LTS提供可扩展的同步通道，数据同步可视化

2）实时同步索引，引擎间数据强一致

针对IT数据和OT数据的交互融合，这一点可以实现一致的跨引擎查询，全文全维度的数据检索能力，通过上层一致数据，试图来帮助评比下层的数据存储、数据引擎的异构性，进一步简化使用成本和维护成本。

#阿里云# #数据库#

本文内容由互联网用户自发贡献，该文观点仅代表作者本人，因此内容不代表本站观点、本站不对文章中的任何观点负责，内容版权归原作者所有、内容只用于提供信息阅读，无任何商业用途。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站（文章、内容、图片、音频、视频）有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至353049283@qq.com举报，一经查实，本站将立刻删除、维护您的正当权益。