Vehicle alarm system, method and device and storage medium

Abstract

The invention relates to a vehicle alarm system, method and device and a storage medium. The vehicle alarm system comprises a plurality of data layers, the system is used for realizing off-line alarm and real-time alarm through each data processing flow established by the plurality of data layers, the plurality of data layers comprise a data source pasting layer, a data detail layer, a data summarization layer and an application data layer, and the data source pasting layer is used for storing vehicle data; the data detail layer is used for performing data processing on the vehicle data according to the dimension table to generate detail data; the dimension table represents alarm data; the data summarization layer is used for summarizing the detail data according to the alarm judgment logic to generate summarized data; and the application data layer is used for carrying out aggregation processing on the summarized data according to the alarm demand and determining a to-be-displayed alarm result. According to the system provided by the invention, the alarm data can be flexibly deployed through the dimension table, the running state of the vehicle can be comprehensively and continuously monitored, and offline alarm and real-time alarm can be flexibly carried out for different vehicles.

Description

Technical Field

[0001] The present invention relates to the field of vehicle safety technology, and in particular to a vehicle alarm system, method, device and storage medium. Background Art

[0002] Thanks to technological innovation and policy support, the new energy vehicle market has shown a sustained and strong growth trend. Compared with traditional fuel vehicles, new energy vehicles have shown obvious advantages in environmental protection, energy efficiency and operating costs. But at the same time, its safety issues cannot be ignored. Battery thermal management, mechanical stability and electrical safety have always been the focus of new energy vehicle safety monitoring. At the same time, the stability and efficiency of the electric drive and electronic control system are also key factors that cannot be ignored. Therefore, it is crucial to maintain continuous monitoring of the operating status of new energy vehicles, timely detect potential safety risks and issue alarms to ensure the safe operation of vehicles. Summary of the invention

[0003] In order to solve the above technical problems, the embodiments of the present disclosure provide a vehicle alarm system, method, device and storage medium.

[0004] In a first aspect, an embodiment of the present disclosure provides a vehicle alarm system, the system comprising multiple data layers, the system being used to implement offline alarm and real-time alarm through each data processing flow established by the multiple data layers, the multiple data layers comprising a data source layer, a data detail layer, a data aggregation layer and an application data layer, wherein:

[0005] The data source layer is used to store vehicle data;

[0006] The data detail layer is used to process the vehicle data according to a pre-configured dimension table to generate detailed data including a corresponding relationship between the vehicle data and the alarm data; wherein the dimension table represents the alarm data;

[0007] The data aggregation layer is used to aggregate the detailed data according to the preset alarm judgment logic to generate aggregated data; wherein the aggregated result includes at least one alarm result to be performed for offline alarm and / or real-time alarm;

[0008] The application data layer is used to aggregate the summary data according to the acquired alarm requirements and determine the alarm results to be displayed.

[0009] Optionally, the data source layer receives and stores vehicle data through Flink, and the vehicle data is distributed in the cloud through Kafka. The data source layer includes a Hive database and a Kafka message queue, wherein:

[0010] The Hive database is used to store the vehicle data to be used for offline alarm;

[0011] The Kafka message queue is used to store the vehicle data to be used for real-time alarm.

[0012] Optionally, a dimensional model is constructed in the data detail layer, the dimensional model uses the detail table of the vehicle data as a fact table, and is designed with multiple dimensional tables that meet different alarm requirements;

[0013] The data detail layer performs at least one of data processing including cleaning, conversion, integration, organization and business division on the vehicle data through the dimensional model to generate detailed data; wherein the detailed data includes first-category detailed data for offline alarm obtained by data processing using Spark, and / or second-category detailed data for real-time alarm obtained by data processing using Flink.

[0014] Optionally, the multiple dimension tables include a vehicle dimension table, a SOC-OCV configuration table, a daisy chain configuration table, a temperature probe configuration table and an alarm threshold table, wherein:

[0015] The vehicle dimension table uses the vehicle VIN code as the primary key and stores basic vehicle data;

[0016] The SOC-OCV configuration table uses the announcement number as the primary key and stores the corresponding relationship data between SOC and OCV;

[0017] The daisy chain configuration table uses the announcement number as the primary key and stores configuration information related to the vehicle daisy chain, wherein the daisy chain reflects the connection relationship between vehicle components.

[0018] The temperature probe configuration table uses the announcement number as the primary key and stores configuration information related to the vehicle temperature probe and the battery module;

[0019] The alarm threshold table uses the announcement number as the primary key and stores alarm types, real-time requirements, alarm conditions and threshold information.

[0020] Optionally, the detailed data includes alarm type and target data, the target data refers to data used for alarm result judgment determined from the vehicle data and / or the alarm data, and the alarm judgment logic includes algorithm logic and alarm threshold;

[0021] The data aggregation layer determines the alarm judgment logic corresponding to the alarm type, and generates an alarm result when a calculation result obtained after the target data is calculated by the algorithm logic meets the alarm threshold.

[0022] Optionally, the alarm threshold is divided into different level thresholds, and the data aggregation layer is further used to determine the alarm level of the alarm result according to the level threshold.

[0023] Optionally, the data summary layer is used to summarize the detailed data according to a preset alarm judgment logic through Spark to generate the first type of summary data for offline alarm, and after storing the first type of summary data, output the first type of summary data to the application data layer;

[0024] The data aggregation layer is further used to aggregate the detailed data according to the alarm judgment logic through Flink to generate the second type of aggregated data for real-time alarm, and directly output the second type of aggregated data to the application data layer without storing the second type of aggregated data;

[0025] The application data layer is also used to store aggregated data obtained after aggregation processing through Doris, wherein the aggregated data includes the alarm result to be displayed.

[0026] In a second aspect, an embodiment of the present disclosure provides a vehicle alarm method, which is applied to the above-mentioned vehicle alarm system, and the method includes:

[0027] Receive and store vehicle data distributed from the cloud;

[0028] Processing the vehicle data according to a pre-configured dimension table to generate detailed data including a corresponding relationship between the vehicle data and the alarm data;

[0029] The detailed data is aggregated and processed according to a preset alarm judgment logic to generate aggregated data; wherein the aggregated result includes at least one alarm result to be performed for offline alarm and / or real-time alarm;

[0030] Acquire alarm requirements, and aggregate the summary data according to the alarm requirements to determine the alarm results to be displayed.

[0031] In a third aspect, an embodiment of the present disclosure provides an electronic device, including:

[0032] Memory;

[0033] Processor; and

[0034] Computer programs;

[0035] The computer program is stored in the memory and is configured to be executed by the processor to implement the vehicle alarm method as described above.

[0036] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the above-mentioned vehicle alarm method when the computer program is executed by a processor.

[0037] The present application provides a vehicle alarm system, which includes multiple data layers. The system is used to realize offline alarm and real-time alarm through each data processing flow established by the multiple data layers. The multiple data layers include a data source layer, a data detail layer, a data summary layer and an application data layer, wherein: the data source layer is used to store vehicle data; the data detail layer is used to perform data processing on the vehicle data according to a pre-configured dimension table, and generate detailed data containing the correspondence between the vehicle data and the alarm data; wherein the dimension table represents the alarm data; the data summary layer is used to summarize the detailed data according to a pre-set alarm judgment logic, and generate summary data; wherein the summary result includes at least one alarm result to be performed for offline alarm and / or real-time alarm; the application data layer is used to aggregate the summary data according to the acquired alarm requirements, and determine the alarm result to be displayed. The system provided in this application can flexibly deploy alarm data such as alarm types, alarm thresholds and alarm logic through dimension tables, distribute, store, process and calculate vehicle data, complete comprehensive and continuous monitoring of vehicle operating status, and flexibly perform offline alarms and real-time alarms for different vehicles, so as to timely discover potential safety risks, improve vehicle safety, and ensure personal safety and property safety to a certain extent. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0039] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0040] Figure 1 A schematic diagram of the structure of a vehicle alarm system provided by an embodiment of the present disclosure;

[0041] Figure 2 A data processing architecture diagram of a vehicle alarm system provided by an embodiment of the present disclosure;

[0042] Figure 3 A schematic diagram of the structure of a dimensional model provided in an embodiment of the present disclosure;

[0043] Figure 4A flow chart of a vehicle alarm method provided by an embodiment of the present disclosure;

[0044] Figure 5 A schematic diagram of the structure of a vehicle alarm device provided by an embodiment of the present disclosure;

[0045] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0046] In order to more clearly understand the above-mentioned objectives, features and advantages of the present disclosure, the scheme of the present disclosure will be further described below. It should be noted that the embodiments of the present disclosure and the features in the embodiments can be combined with each other without conflict.

[0047] In the following description, many specific details are set forth to facilitate a full understanding of the present disclosure, but the present disclosure may also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present disclosure, rather than all of the embodiments.

[0048] At present, there are many challenges in building a vehicle alarm system driven by cloud data. Taking new energy vehicles as an example, new energy vehicles send a frame of data to the cloud every 10 seconds or 1 second. Hundreds of thousands or even millions of vehicles will generate massive amounts of data every day. At the same time, there are many types of alarm algorithms, and the calculation logic of different algorithms is independent of each other, which puts extremely high demands on the system's data processing capabilities. In addition, different vehicles have different requirements for different alarm algorithms. Some alarms of some models need to be reported in real time and processed immediately (i.e. real-time alarms), while other faults do not need to be reported, or the alarm time is allowed to have a certain time lag (i.e. offline alarms). Therefore, the vehicle alarm system needs to be able to be flexibly deployed according to the different alarm requirements of different models. Finally, in order to adapt to the addition, removal and iterative update of algorithms in the future, the system must have high reusability and scalability.

[0049] Although the existing technical solutions can realize vehicle alarms based on Internet of Vehicles data, they are not designed in terms of system scalability and configuration flexibility. That is, alarm data such as alarm items and alarm thresholds are fixed in the program and difficult to maintain. At the same time, the existing technical solutions can only realize offline alarms or real-time alarms separately, and cannot be carried out simultaneously. In addition, Internet of Vehicles data covers various aspects of data of various components such as batteries, electric drives and electronic controls. The existing technical solutions only monitor one aspect of battery data, which is not comprehensive enough, and thus affects the accuracy of alarms.

[0050] In view of the above technical problems, this application aims to develop a vehicle alarm system that can withstand high loads, has flexible configuration, and has high scalability and reusability, so as to meet the alarm requirements of different types of alarms in different business scenarios. Detailed description is given through one or more of the following embodiments.

[0051] The vehicle alarm method provided by the embodiment of the present disclosure can be applied to vehicle offline alarm and real-time alarm scenarios. The method can be executed by a vehicle alarm device, which can be implemented by software and / or hardware, and the device can be integrated in an electronic device. Among them, the electronic device can include but is not limited to mobile terminals such as smart phones, laptops, digital broadcast receivers, personal digital assistants (Personal Digital Assistant, PDA), tablet computers (Tablet Personal Computer, Tablet PC), PMP (portable multimedia player), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), wearable devices, etc., and fixed terminals such as digital televisions, desktop computers, smart home devices, etc.

[0052] Figure 1 The present invention provides a schematic diagram of the structure of a vehicle alarm system provided by an embodiment of the present invention. The vehicle alarm system (hereinafter referred to as the system) includes multiple data layers. The system is used to realize offline alarm and real-time alarm through various data processing flows established by multiple data layers. The multiple data layers include a data source layer, a data detail layer, a data summary layer and an application data layer, wherein:

[0053] It is understandable that the system includes multiple data layers, and a data processing architecture integrating stream processing and batch processing is established between the multiple data layers. Offline alarms can be realized by batch processing, and real-time alarms can be realized by stream processing. That is, there is a data processing flow for offline alarms and a data processing flow for real-time alarms. Different data processing flows built based on multiple data layers can realize offline alarms and real-time alarms simultaneously. Among them, the multiple data layers include the data source layer (ODS layer, Operational Data Store), the data detail layer (DWD layer, Data Warehouse Detail), the data summary layer (DWS layer, Data Warehouse Summary) and the application data layer (ADS layer, Application Data Store).

[0054] The data source layer is used to store vehicle data;

[0055] It can be understood that the data source layer is used to store vehicle data from the vehicle side. The data source layer can also be understood as a data storage layer. Vehicle data refers to Internet of Vehicles data, that is, raw data. Taking new energy vehicles as an example, the sources of vehicle data include multiple components such as the whole vehicle, battery, motor, electronic control, chassis and air conditioning. Specifically, the vehicle data generated by each component is aggregated by Tbox (Telematics box, on-board communication module) and transmitted to the cloud through the 4G / 5G network, and then sent from the cloud to the data source layer.

[0056] The data detail layer is used to process the vehicle data according to a pre-configured dimension table to generate detailed data including a corresponding relationship between the vehicle data and the alarm data; wherein the dimension table represents the alarm data;

[0057] It can be understood that the data detail layer is used to clean the vehicle data from the data post source layer, and to process the vehicle data based on the pre-configured dimension table to generate detailed data containing the correspondence between the vehicle data and the alarm data, wherein the dimension table represents the alarm data. Based on the dimension table, different alarm requirements and / or business requirements of different models can be flexibly configured to reduce system maintenance costs. Among them, the correspondence between the alarm data and the vehicle data refers to the correspondence between the target alarm conditions pre-configured in the dimension table of the target vehicle that generates the vehicle data and the actual vehicle data. For example, the detailed data includes the correspondence between the battery data in the vehicle data and the battery temperature threshold in the alarm data. In one possible scenario, the alarm requirement is to alarm when the battery temperature is higher than the threshold. In this scenario, the detailed data can be expressed as a judgment statement of whether the battery temperature is greater than the battery temperature threshold, or a fact statement that the battery data is A and the battery temperature threshold is B.

[0058] The data aggregation layer is used to aggregate the detailed data according to the preset alarm judgment logic to generate aggregated data; wherein the aggregated result includes at least one alarm result to be performed for offline alarm and / or real-time alarm;

[0059] It is understandable that the data aggregation layer aggregates the detailed data generated by the data detail layer based on the business objectives, and stores the generated aggregated data. The data aggregation layer can be understood as performing the first aggregation processing. Among them, the business objectives refer to the alarm judgment logic set according to business needs. For example, based on the above example, the detailed data includes a judgment statement of whether the battery temperature is greater than the threshold, and the alarm judgment logic is an alarm result of real-time alarm when the battery temperature is higher than the threshold, or the alarm judgment logic is an alarm result of offline alarm (alarm after 5 minutes) when the battery temperature is higher than the threshold, or the alarm judgment logic is a non-alarm result when the battery temperature is higher than the first threshold but lower than the second threshold. It is understandable that the data aggregation layer will generate at least one alarm result during the aggregation processing, and will also generate process data for alarm logic judgment, and will also generate relevant data for non-alarm results.

[0060] The application data layer is used to aggregate the summary data according to the acquired alarm requirements and determine the alarm results to be displayed.

[0061] It is understandable that the application data layer further summarizes the summary data generated by the data summary layer to determine the alarm results to be displayed for display by the application system. The application data layer can be understood as performing a second summary process. For example, the application data layer will sort at least one alarm result based on the alarm type and the real-time requirements to determine the alarm result to be displayed. For example, the alarm types include but are not limited to voltage, insulation, temperature, electric drive, and charging pile types. The alarm types can be flexibly configured according to the alarm requirements to expand the monitoring scope.

[0062] Optionally, the data source layer receives and stores vehicle data through Flink, and the vehicle data is distributed in the cloud through Kafka. The data source layer includes a Hive database and a Kafka message queue, wherein: the Hive database is used to store the vehicle data to be subjected to offline alarm; and the Kafka message queue is used to store the vehicle data to be subjected to real-time alarm.

[0063] It is understandable that after the data generated by each component is transmitted to the cloud, the cloud receives the data sent by the vehicle through Kafka and distributes the data to the downstream (vehicle alarm system). The system uses Flink to receive and distribute the data and store it in the data source layer. Among them, the data source layer includes the Hive database and the Kafka message queue. The vehicle data in HIVE and Kafka will be used for the corresponding data processing flows of offline alarm and real-time alarm respectively.

[0064] For example, see Figure 2 , Figure 2 A vehicle alarm system data processing architecture diagram provided in an embodiment of the present disclosure, Figure 2In the architecture diagram shown, there are data flows for offline alarms and data flows for real-time alarms. The system includes four data layers, and different modules are divided inside each data layer to combine with modules in other data layers to realize different data processing flows. Other possible data processing flows except for offline alarms and real-time alarms are not limited. For example, in the data processing process of offline alarms, the data is mostly in HIVE format, and in the data processing process of real-time alarms, the data is mostly in Kafka format. HIVE is a data warehouse tool based on Hadoop, which is used for data extraction, transformation, and loading. It is a mechanism that can store, query, and analyze large-scale data stored in Hadoop, and supports data batch processing; Kafka is a high-throughput distributed publish-subscribe messaging system that can process all action stream data and supports data stream processing, that is, real-time processing.

[0065] It is understandable that offline alarm can obtain the vehicle data of the nth day from the HIVE database of the data post source layer on the n+1th day for processing and output, that is, offline alarm can be processed at intervals, while real-time alarm is based on Flink and Kafka to implement real-time operation of alarm algorithm. This division of data processing flow is due to the fact that real-time analysis requires a lot of resources. In the case of limited computing resources, real-time alarm can be performed only for some models that need to be focused on, and offline alarm can be performed for others, that is, the alarm conditions of real-time alarm and offline alarm can be adjusted at any time.

[0066] Optionally, a dimensional model is constructed in the data detail layer, which uses the detail table of the vehicle data as the fact table and is designed with multiple dimensional tables that meet different alarm requirements; the data detail layer performs at least one of data processing including cleaning, conversion, integration, organization and business division on the vehicle data through the dimensional model to generate detailed data; wherein the detailed data includes a first type of detailed data obtained by using Spark for data processing and used for offline alarms, and / or a second type of detailed data obtained by using Flink for data processing and used for real-time alarms.

[0067] Understandably, a dimensional model is constructed in the data detail layer. The dimensional model uses the detail table of vehicle data as the fact table, and is designed with multiple dimensional tables that meet different alarm requirements / business requirements, such as the vehicle dimension table, SOC-OCV configuration table, daisy chain configuration table, temperature probe configuration table, and alarm threshold table. The dimensional model can also be understood as a data warehouse model. The dimension table can be used to flexibly configure and adjust alarm information and algorithm information. Among them, the algorithm information includes whether the algorithm is online, the algorithm threshold, and whether the algorithm needs to be real-time. The alarm information can be understood as the pre-configuration information required for the alarm. Later, if you need to add, update, or adjust a certain alarm information, you only need to modify the corresponding configuration table (dimensional table), which greatly reduces the maintenance cost. Specifically, the data detail layer uses the dimensional model to clean, convert, integrate, combine and divide the vehicle data into business data to generate detailed data. The detailed data can be a detailed table showing the corresponding relationship between each vehicle data and alarm data. The detailed table can also be divided according to components. For example, the detailed data includes the first category of data related to air conditioning, the second category of data related to batteries, and the third category of data related to windows. In the first category of data corresponding to each component, it can be further divided into details of various aspects such as temperature, voltage, and current. The specific data and form included in the detailed data are not limited and can be set according to user needs.

[0068] Understandably, there are differences in the processing methods of the data detail layer between real-time alarms and offline alarms. Specifically, offline alarms use Spark large-scale data processing (batch processing) to clean, integrate and organize data, and store the processed detail data in HIVE tables; real-time alarms use Flink to process data in real time and store the processed data in Kafka tables. Figure 2 In the processing architecture shown, for the offline alarm process, the data in HIVE in the ODS layer is processed by Spark and stored in HIVE in the DWD layer. For the real-time alarm process, the data in KAFKA in the ODS layer is processed by Flink and stored in KAFKA in the DWD layer.

[0069] Optionally, the multiple dimension tables include a vehicle dimension table, a SOC-OCV configuration table, a daisy chain configuration table, a temperature probe configuration table, and an alarm threshold table, wherein: the vehicle dimension table uses the vehicle VIN code as the primary key and stores basic vehicle data; the SOC-OCV configuration table uses the announcement number as the primary key and stores the corresponding relationship data between SOC and OCV; the daisy chain configuration table uses the announcement number as the primary key and stores configuration information related to the vehicle daisy chain, wherein the daisy chain reflects the connection relationship between vehicle components. The temperature probe configuration table uses the announcement number as the primary key and stores configuration information related to the vehicle temperature probe and the battery module; the alarm threshold table uses the announcement number as the primary key and stores alarm types, real-time requirements, alarm conditions, and threshold information.

[0070] It can be understood that multiple dimension tables include signal conversion table, vehicle dimension table, SOC-OCV configuration table, daisy chain configuration table, temperature probe configuration table and alarm threshold table, etc. Specifically, the vehicle dimension table uses the vehicle VIN code as the primary key and stores the basic information of the vehicle. The basic information includes vehicle model, announcement number, battery model, production date, sales date and sales location, etc. Among them, the announcement number is the unique number corresponding to each vehicle approved for sale, which contains the basic information and relevant technical parameters of the vehicle; the SOC-OCV configuration table uses the announcement number as the primary key and stores the corresponding relationship data of the battery SOC (battery state, State of Charge) and OCV (open circuit voltage, Open Circuit Voltage); the daisy chain configuration table uses the announcement number as the primary key and stores the vehicle daisy chain related configuration information. Daisy Chain is a way to connect multiple devices, in which each device is connected in series to form a chain-like connection path. For example, the connection status of the battery cell can be understood based on the daisy chain configuration table; the temperature probe configuration table uses the announcement number as the primary key and stores the configuration information related to the vehicle temperature probe and the battery module. Each probe corresponds to a different battery module; the alarm threshold table uses the announcement number as the primary key and stores the alarm type, real-time requirements, alarm conditions and threshold information of different announcement numbers; the signal conversion table uses the announcement number as the primary key and stores the conversion relationship between different vehicle signals; other dimension tables can be flexibly added according to business needs and are not described here.

[0071] For example, see Figure 3 , Figure 3 A schematic diagram of the structure of a dimensional model provided in an embodiment of the present disclosure. Considering the actual business needs, the readability of the model and the query efficiency, a star model can be selected to organize and store data. That is, the dimensional model can be as follows: Figure 3 The model architecture shown in Figure 3As shown in the figure, the model uses the vehicle data detail table as the fact table, and designs the vehicle dimension table, SOC-OCV configuration table, daisy chain configuration table, temperature probe configuration table and alarm threshold table connected with the detail table. It can be understood that Figure 3 The star schema shown includes dimension tables and Figure 2 The dimension tables involved in the DWD layer shown are the same. Figure 3 Shows the data structure between multiple dimension tables.

[0072] Optionally, the detailed data includes alarm type and target data, the target data refers to data used for alarm result judgment determined from the vehicle data and / or the alarm data, and the alarm judgment logic includes algorithm logic and alarm threshold;

[0073] It can be understood that the detailed data includes the alarm types and target data determined according to the dimension table, wherein the alarm types include but are not limited to: insulation failure at the charging pile end, insulation failure at the charging vehicle end, insulation failure of the whole vehicle high-voltage system, insulation failure inside the battery pack, large temperature difference in the same module, module temperature outlier, invalid voltage sampling, abnormal thermal management circuit of the whole vehicle, abnormal battery thermal management circuit, abnormal thermal management temperature, voltage sampling line break failure, abnormal battery internal resistance alarm, daisy chain non-update alarm, temperature sensor failure, temperature jump, all NTC failures of the same module, single cell inconsistency alarm, abnormal leakage current of the sampling circuit, severe self-discharge alarm, thermal runaway alarm, etc. The alarm types can be flexibly expanded according to business needs. The target data refers to the data determined from the vehicle data and the alarm data set in each dimension table. It is the data required for judging the alarm result. For example, for the alarm type of large temperature difference of the same module, the target data includes the current temperature of the battery module determined from the vehicle data and the temperature difference threshold of the battery module determined from the alarm data. It may also include the default historical temperature of the battery determined from the historical vehicle data. The current temperature difference has been calculated based on the historical temperature and the current temperature. It is only for comparing the current temperature difference and the temperature difference threshold to determine whether an alarm is needed.

[0074] It is understandable that each alarm type is pre-set with a corresponding alarm judgment logic, which involves algorithm logic and alarm threshold. The alarm threshold refers to the threshold for determining the final alarm result. The alarm threshold table in the above dimension table refers to the threshold for determining a certain component in a certain aspect.

[0075] Optionally, the data aggregation layer determines the alarm judgment logic corresponding to the alarm type, and generates an alarm result when the calculation result obtained after the target data is calculated by the algorithm logic meets the alarm threshold.

[0076] It can be understood that after the data aggregation layer determines the alarm judgment logic corresponding to the alarm type, it determines whether to generate an alarm result or a non-alarm result based on the alarm judgment logic. The non-alarm result means that the component is running normally and no alarm is required. Specifically, when the target data is calculated by the algorithm logic and the calculation result meets the alarm threshold, this alarm result can be output.

[0077] Optionally, the alarm threshold is divided into different level thresholds, and the data aggregation layer is further used to determine the alarm level of the alarm result according to the level threshold.

[0078] It is understandable that the alarm thresholds can also be graded and further divided into different level thresholds. The subsequent data aggregation layer outputs alarm results of different levels when the calculation results meet different level thresholds, or the alarm level of the alarm result can be determined according to the level threshold. For example, the first-level alarm result requires real-time alarm, and the second-level alarm result can alarm within a certain time (1 minute).

[0079] Optionally, the data summary layer is used to summarize the detailed data according to a preset alarm judgment logic through Spark to generate the first type of summary data for offline alarm, and after storing the first type of summary data, output the first type of summary data to the application data layer;

[0080] It is understandable that, at the data aggregation layer, offline alarms implement algorithm logic based on Spark, aggregate and process the detailed data, and save the generated first-category aggregate results or first-category calculation results in HIVE, and transmit them to the application data layer at the same time. Figure 2 In the processing architecture shown, the DWS layer stores the data in HIVE after aggregation processing through Spark, and transmits it to the ADS layer through Spark for further aggregation processing before alarm display at the ADS layer.

[0081] Optionally, the data aggregation layer is also used to aggregate the detailed data according to the alarm judgment logic through Flink, generate a second type of summary data for real-time alarm, and directly output the second type of summary data to the application data layer without storing the second type of summary data.

[0082] It is understandable that at the data aggregation layer, the real-time alarm is based on Flink to implement the algorithm logic, and after the detailed data is aggregated, the generated second-category aggregation results or second-category calculation results are transmitted to the application data layer in real time. Figure 2In the processing architecture shown, the DWS layer receives the data distributed by Kafka in the DWD layer and aggregates it through Flink, and then transmits the calculation results directly to the ADS layer for further aggregation and processing before the alarm display in the ADS layer. In order to ensure the operating efficiency during real-time alarm, the calculation results are not stored in the DWS layer, but the data is directly output to the ADS layer through Flink.

[0083] The application data layer is also used to store aggregated data obtained after aggregation processing through Doris, wherein the aggregated data includes the alarm result to be displayed.

[0084] It is understandable that the application data layer is the top layer of the processing mechanism, directly facing the application system. At the application data layer, the summary data needs to be aggregated according to business needs to facilitate subsequent display on the application system page. Among them, the results output by the application data layer also include a lot of calculated process data. The process data can be used for subsequent data analysis and algorithm iteration, but most process data do not need to be displayed on the page, so it is necessary to further summarize at least one alarm result included in the summary data to determine the alarm result to be displayed. In addition, the page has high requirements for query speed, so the application data layer can uniformly use Doris to store the summary results. In Doris, the data is logically described in the form of a table.

[0085] The vehicle alarm system provided by this application can realize offline and real-time alarms simultaneously, and can flexibly configure different alarm requirements for different models based on the dimension table. When the alarm data needs to be adjusted, only the corresponding alarm algorithm logic and dimension table need to be adjusted, which effectively reduces the system maintenance cost. In addition, different alarm types can be set through the dimension table, which expands the scope of monitoring alarms, and the alarm types can be flexibly adjusted according to business needs, which is more flexible and practical.

[0086] Based on the above embodiments, Figure 4 A flow chart of a vehicle alarm method provided by an embodiment of the present disclosure, which is applied to the above-mentioned vehicle alarm system, specifically includes the following steps: Figure 4 The following steps are shown:

[0087] S401, receiving and storing vehicle data distributed from the cloud.

[0088] S402: Process the vehicle data according to a pre-configured dimension table to generate detailed data including a corresponding relationship between the vehicle data and the alarm data.

[0089] S403: Summarize the detailed data according to a preset alarm judgment logic to generate summary data.

[0090] The summary result includes at least one alarm result to be performed for offline alarm and / or real-time alarm.

[0091] S404: Acquire alarm requirements, and aggregate the summary data according to the alarm requirements to determine alarm results to be displayed.

[0092] Optionally, the above-mentioned receiving and storing the vehicle data distributed from the cloud includes:

[0093] The vehicle data distributed by Kafka in the cloud is received through Flink, and the vehicle data is stored in the Hive database for offline alarm and the Kafka message queue for real-time alarm.

[0094] Optionally, the vehicle data is processed according to the pre-configured dimension table to generate detailed data containing the corresponding relationship between the vehicle data and the alarm data, including:

[0095] The vehicle data is cleaned, converted, integrated, organized and divided into business units through a pre-built dimensional model to generate detailed data; wherein the detailed data includes first-category detailed data for offline alarm obtained by data processing using Spark, and / or second-category detailed data for real-time alarm obtained by data processing using Flink; wherein the dimensional model uses a detailed table of the vehicle data as a fact table, and is designed with multiple dimensional tables that meet different alarm requirements.

[0096] Optionally, the multiple dimension tables include a vehicle dimension table, a SOC-OCV configuration table, a daisy chain configuration table, a temperature probe configuration table, and an alarm threshold table, wherein: the vehicle dimension table uses the vehicle VIN code as the primary key and stores basic vehicle data; the SOC-OCV configuration table uses the announcement number as the primary key and stores the corresponding relationship data between SOC and OCV; the daisy chain configuration table uses the announcement number as the primary key and stores configuration information related to the vehicle daisy chain, wherein the daisy chain reflects the connection relationship between vehicle components. The temperature probe configuration table uses the announcement number as the primary key and stores configuration information related to the vehicle temperature probe and the battery module; the alarm threshold table uses the announcement number as the primary key and stores alarm types, real-time requirements, alarm conditions, and threshold information.

[0097] Optionally, the detailed data includes alarm type and target data, the target data refers to data determined from the vehicle data and / or the alarm data for judging the alarm result, and the alarm judgment logic includes algorithm logic and alarm threshold.

[0098] Optionally, the detailed data is aggregated and processed according to a preset alarm judgment logic to generate aggregated data, including:

[0099] The alarm judgment logic corresponding to the alarm type is determined, and an alarm result is generated when a calculation result obtained after the target data is calculated by the algorithm logic meets the alarm threshold.

[0100] Optionally, the detailed data is aggregated and processed according to a preset alarm judgment logic to generate aggregated data, including:

[0101] The detailed data is aggregated and processed by Spark according to a preset alarm judgment logic to generate a first type of aggregated data for offline alarm, and after storing the first type of aggregated data, the first type of aggregated data is output to the application data layer; the detailed data is aggregated and processed by Flink according to the alarm judgment logic to generate a second type of aggregated data for real-time alarm, and the second type of aggregated data is directly output to the application data layer without storing the second type of aggregated data; the aggregated data obtained after the aggregation processing is stored by Doris, wherein the aggregated data includes the alarm results to be displayed.

[0102] It is understandable that the specific implementation instructions of the steps involved in the above-mentioned vehicle alarm method can be found in the above-mentioned embodiment and will not be repeated here.

[0103] The vehicle alarm method provided in this application can cope with the alarm needs of different types of alarms in different business scenarios, and has high scalability and reusability.

[0104] Figure 5 The schematic diagram of the structure of a vehicle alarm device provided by an embodiment of the present disclosure. The vehicle alarm device provided by an embodiment of the present disclosure can execute the processing flow provided by an embodiment of the vehicle alarm method. As shown in the figure, the device 500 includes a receiving unit 501, a first processing unit 502, a second processing unit 503 and a third processing unit 504, wherein:

[0105] A receiving unit 501, used to receive and store vehicle data distributed from the cloud;

[0106] The first processing unit 502 is used to perform data processing on the vehicle data according to a pre-configured dimension table to generate detailed data including a corresponding relationship between the vehicle data and the alarm data;

[0107] The second processing unit 503 is used to summarize the detailed data according to a preset alarm judgment logic to generate summary data; wherein the summary result includes at least one alarm result to be performed for offline alarm and / or real-time alarm;

[0108] The third processing unit 504 is used to obtain an alarm requirement, and aggregate the summary data according to the alarm requirement to determine the alarm result to be displayed.

[0109] It is understandable that the specific implementation steps of each unit are not repeated here.

[0110] Figure 5 The vehicle alarm device of the illustrated embodiment can be used to implement the technical solution of the above-mentioned method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0111] Figure 6 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present disclosure. Figure 6 , which shows a schematic diagram of the structure of an electronic device 600 suitable for implementing the embodiment of the present disclosure. The electronic device 600 in the embodiment of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle terminals (such as vehicle navigation terminals), wearable electronic devices, etc., and fixed terminals such as digital TVs, desktop computers, smart home devices, etc. Figure 6 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0112] like Figure 6 As shown, the electronic device 600 may include a processing device 601 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 to a random access memory (RAM) 603 to implement the vehicle alarm method of the embodiment described in the present disclosure. In the RAM 603, various programs and data required for the operation of the electronic device 600 are also stored. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0113] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 6The electronic device 600 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0114] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart, thereby implementing the vehicle alarm method as described above. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 609, or installed from the storage device 608, or installed from the ROM 602. When the computer program is executed by the processing device 601, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0115] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0116] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0117] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0118] Optionally, when the above one or more programs are executed by the electronic device, the electronic device may also execute other steps described in the above embodiments.

[0119] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including, but not limited to, object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0120] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0121] The units involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of a unit does not, in some cases, limit the unit itself.

[0122] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0123] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0124] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or gateway that includes a series of elements includes not only those elements, but also other elements that are not explicitly listed, or also includes elements inherent to such process, method, article or gateway. In the absence of further restrictions, the elements defined by the sentence "comprise one..." do not exclude the presence of other identical elements in the process, method, article or gateway that includes the elements.

[0125] The above description is only a specific embodiment of the present disclosure, so that those skilled in the art can understand or implement the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to the embodiments described herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A vehicle alarm system, characterized in that: The system includes multiple data layers, and the system is used to realize offline alarm and real-time alarm through each data processing flow established by the multiple data layers. The multiple data layers include a data source layer, a data detail layer, a data summary layer and an application data layer, wherein: The data source layer is used to store vehicle data; The data detail layer is used to process the vehicle data according to a pre-configured dimension table to generate detailed data including a corresponding relationship between the vehicle data and the alarm data; wherein the dimension table represents the alarm data; The data aggregation layer is used to aggregate the detailed data according to the preset alarm judgment logic to generate aggregated data; wherein the aggregated result includes at least one alarm result to be performed for offline alarm and / or real-time alarm; The application data layer is used to aggregate the summary data according to the acquired alarm requirements and determine the alarm results to be displayed.

2. The system according to claim 1, characterized in that The data source layer receives and stores vehicle data through Flink, and the vehicle data is distributed in the cloud through Kafka. The data source layer includes a Hive database and a Kafka message queue, wherein: The Hive database is used to store the vehicle data to be used for offline alarm; The Kafka message queue is used to store the vehicle data to be used for real-time alarm.

3. The system according to claim 1, characterized in that A dimensional model is constructed in the data detail layer, the dimensional model uses the detail table of the vehicle data as a fact table, and is designed with multiple dimensional tables that meet different alarm requirements; The data detail layer performs at least one of data processing including cleaning, conversion, integration, organization and business division on the vehicle data through the dimensional model to generate detailed data; wherein the detailed data includes first-category detailed data for offline alarm obtained by data processing using Spark, and / or second-category detailed data for real-time alarm obtained by data processing using Flink.

4. The system according to claim 3, characterized in that The multiple dimension tables include a vehicle dimension table, a SOC-OCV configuration table, a daisy chain configuration table, a temperature probe configuration table, and an alarm threshold table, wherein: The vehicle dimension table uses the vehicle VIN code as the primary key and stores basic vehicle data; The SOC-OCV configuration table uses the announcement number as the primary key and stores the corresponding relationship data between SOC and OCV; The daisy chain configuration table uses the announcement number as the primary key and stores configuration information related to the vehicle daisy chain, wherein the daisy chain reflects the connection relationship between vehicle components; The temperature probe configuration table uses the announcement number as the primary key and stores configuration information related to the vehicle temperature probe and the battery module; The alarm threshold table uses the announcement number as the primary key and stores alarm types, real-time requirements, alarm conditions and threshold information.

5. The system according to claim 1, characterized in that The detailed data includes alarm type and target data, the target data refers to data used for alarm result judgment determined from the vehicle data and / or the alarm data, and the alarm judgment logic includes algorithm logic and alarm threshold; The data aggregation layer determines the alarm judgment logic corresponding to the alarm type, and generates an alarm result when a calculation result obtained after the target data is calculated by the algorithm logic meets the alarm threshold.

6. The system according to claim 5, characterized in that The alarm threshold is divided into different level thresholds, and the data aggregation layer is further used to determine the alarm level of the alarm result according to the level threshold.

7. The system according to claim 1, characterized in that The data aggregation layer is used to aggregate the detailed data according to a preset alarm judgment logic through Spark to generate the first type of aggregated data for offline alarm, and after storing the first type of aggregated data, output the first type of aggregated data to the application data layer; The data aggregation layer is further used to aggregate the detailed data according to the alarm judgment logic through Flink to generate the second type of aggregated data for real-time alarm, and directly output the second type of aggregated data to the application data layer without storing the second type of aggregated data; The application data layer is also used to store aggregated data obtained after aggregation processing through Doris, wherein the aggregated data includes the alarm result to be displayed.

8. A vehicle alarm method, characterized in that: Applied to the vehicle alarm system as described in any one of claims 1 to 7 above, the method comprises: Receive and store vehicle data distributed from the cloud; Processing the vehicle data according to a pre-configured dimension table to generate detailed data including a corresponding relationship between the vehicle data and the alarm data; The detailed data is aggregated and processed according to a preset alarm judgment logic to generate aggregated data; wherein the aggregated result includes at least one alarm result to be performed for offline alarm and / or real-time alarm; Acquire alarm requirements, and aggregate the summary data according to the alarm requirements to determine the alarm results to be displayed.

9. An electronic device, characterized in that: include: Memory; processor; as well as Computer programs; Wherein, the computer program is stored in the memory and is configured to be executed by the processor to implement the vehicle alarm method as claimed in claim 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the vehicle alarm method according to claim 8 are implemented.

Images