System and method for vehicle monitoring and telematics

Abstract

Systems and methods for reducing a data set related to vehicle information of a telematics system or telematics load while also preserving the ability of a cloud-based server to perform analysis on the reduced data set that would otherwise require full fidelity data. According to one embodiment, a method includes the step of obtaining a data set from a plurality of sensors on a vehicle, where the data set includes vehicle-related metrics indicative of operation of the vehicle. The method also includes the step of extracting relevant data from the data set to reduce a telematics load. Additionally, the method includes the step of wirelessly transmitting the relevant data to a remote server using an external interface. The step of extracting the relevant data is configured to preserve the ability of the remote server to perform high-fidelity analysis on the relevant data.

Description

Technical Field

[0001] This disclosure generally relates to vehicle monitoring and telematics systems and methods. More specifically, this disclosure relates to reducing the size of telematics datasets while retaining the ability of cloud-based remote servers to perform high-fidelity analysis on the reduced datasets. Background Technology

[0002] Generally speaking, the field of "telematics" or "vehicle telematics" involves using onboard sensors and instruments to detect various characteristics of a vehicle and transmitting these characteristics wirelessly to other vehicles or remote computer servers. This information can then be processed to determine various conditions and perform additional actions in response to different conditions. Therefore, telematics encompasses technologies for sending, receiving, and storing information from one or more vehicles; the use of telecommunications and computer science to control vehicles on the road; global navigation systems using satellite and mobile communication technologies; and so on.

[0003] Additionally, telematics can refer to in-vehicle automation, such as emergency warning systems, GPS navigation, integrated hands-free cellular phone systems, secure wireless communications, driver assistance systems, and autonomous driving systems. For example, such telematics systems can utilize wireless technologies and computing as defined in standards such as IEEE 802.11p.

[0004] In addition, telematics is used for vehicle tracking purposes, where the location, movement, route, status, and / or behavior of vehicles can be monitored. In some cases, vehicle status can be transmitted to emergency or distribution services. Telematics can also be used to track trailers, cargo containers, or other tractor-trailers or mobile vehicles or equipment. Furthermore, fleet management can use telematics to manage a fleet of vehicles, vans, trucks, ships, trains, etc.

[0005] The field of telematics can also encompass other operations, such as satellite navigation, which uses GPS and / or other mapping tools to enable a vehicle driver to determine their current location, plan a route, navigate that route, and replan the route as needed based on various conditions. In some cases, mobile communications are used to transmit radio waves to a computer in real time. These devices can be used while inside a vehicle (e.g., fixed data terminal equipment) or both inside and outside the vehicle (e.g., mobile data terminal equipment).

[0006] Telematics can also involve wireless communications related to vehicle safety, road safety, and hazards. Communication may include the exchange of safety information, vehicle position and speed, and hazardous locations. This communication can operate via short-range radio links and may involve temporary ad hoc wireless local area networks (LANs). Wireless units can be installed in vehicles and at fixed locations along roads, such as near traffic lights and emergency call boxes. Mobile and fixed sensors can be configured to share information with a wide network so that other vehicles can respond to current conditions as needed. In some cases, information about hazards can be updated in real time and relayed to approaching vehicles. Road condition information can be used to control traffic lights to optimize traffic and avoid congestion and the likelihood of accidents. Additionally, adaptive cruise control or other vehicle control systems can utilize current information and can connect to the vehicle's throttle and braking systems as needed. In some cases, groups of vehicles can travel together to save fuel and road space.

[0007] It is understandable that various systems using telematics may require multiple components (e.g., the vehicle itself, fixed traffic control systems, cloud-based remote servers, etc.) to share and process large amounts of data. Typically, this data needs to be high-fidelity. In other words, this data can include a large amount of information that can then be processed. However, storing massive amounts of data on the vehicle itself or on cloud-based servers can be expensive. Furthermore, transmitting large amounts of data can also be expensive. In addition, cloud computing can also be costly. Therefore, there is a need in the field of telematics to provide systems that can transmit relevant data on demand with other vehicles and with cloud computing servers located in the cloud. However, instead of transmitting large amounts of data, there is a need to reduce the amount of data in the field of telematics while retaining the cloud server's capacity to adequately store and process the data to continue performing the high-fidelity analysis required for the aforementioned purposes such as safety, vehicle route planning, vehicle control, vehicle usage monitoring, and performance optimization. Summary of the Invention

[0008] This disclosure relates to systems and methods for reducing datasets or telematics loads (including vehicle operation information) within a telematics system. This data reduction process can be performed to extract useful data while preserving the ability of a cloud-based server to perform analytics that would otherwise require full-fidelity data transfer to the cloud-based server.

[0009] According to one embodiment, the process for extracting vehicle data may include the step of obtaining datasets from multiple sensors on the vehicle, wherein these datasets may include vehicle-related metrics indicative of vehicle operation. The process may also include extracting relevant data from these datasets to reduce the telematics load. Additionally, the process may use an external interface to wirelessly transmit the relevant data to a remote server. Specifically, the step of extracting relevant data may be configured to preserve the remote server's ability to perform high-fidelity analysis on the relevant data.

[0010] In some implementations, the process may further include storing the relevant data in a solid-state drive (SSD) or any other type of persistent storage device after the step of extracting relevant data from these datasets. Additionally, the step of extracting relevant data may include utilizing persistent memory and multiple nodes operationally separate from the components used to perform motion functions in the vehicle. For example, each of these nodes may include random access memory (RAM) and a central processing unit (CPU).

[0011] Furthermore, the steps for extracting relevant data may include utilizing a) multiple metric extraction container groups arranged in parallel; b) orchestration container groups; c) decoding container groups for obtaining data frames or similar in-memory data structures from log data and forwarding the data frames or similar formatted data to the multiple metric extraction container groups; d) collector container groups configured to receive useful metrics from the multiple metric extraction container groups; and / or e) persistent storage having one or more of a decoding (DBC) component, a decoded image component, a metric image component, a metric script component, and a main image component.

[0012] The process may also include the step of inducing an external interface to wirelessly transmit relevant data to a remote server via a cellular system. The remote server may be a cloud-based server communicating with the cellular system. In some cases, the relevant data may also include Global Positioning System (GPS) data received from one or more GPS satellites.

[0013] According to some implementation schemes, the process may also include steps of sensing or detecting one or more vehicle characteristics related to position, speed, direction, acceleration, battery temperature, battery usage, airbag deployment, propulsion use, throttle use, brake use, vehicle dashboard warnings, etc., and in some cases, may also include obtaining information related to traffic and road conditions from one or more nearby vehicles and road signaling equipment.

[0014] Those skilled in the art will recognize that the concepts of this disclosure are applicable to vehicles (or fleets of vehicles) (whether internal combustion engine (ICE) vehicles, hybrid electric vehicles (HEVs), or electric vehicles (EVs)), and also to stationary storage devices, battery charging systems, and the like. However, the concepts of this disclosure are not necessarily applied in an automotive context, but can also be applied to eVTOL, aerospace, and hyperloop systems – any system that requires operation based on high-fidelity measurements and functional safety-related ECUs. Attached Figure Description

[0015] This disclosure is illustrated and described with reference to various accompanying drawings. Where appropriate, similar reference numerals are used to denote similar parts / steps. Unless otherwise stated, the parts depicted in the drawings are not necessarily drawn to scale.

[0016] Figure 1 This is a schematic diagram illustrating a vehicle monitoring system for monitoring multiple vehicles according to various embodiments of this disclosure.

[0017] Figure 2 This is a block diagram illustrating a standalone vehicle telematics system for communicating with a remote server, based on various implementation schemes.

[0018] Figure 3 This is a block diagram illustrating another vehicle telematics system with local storage and remote upload capabilities, based on various implementation schemes.

[0019] Figure 4 This is a block diagram illustrating the processing pipeline of a server for computing vehicle data in the cloud, based on various implementation schemes.

[0020] Figure 5 It is based on the illustration of various implementation schemes. Figure 1 A flowchart illustrating the operation of the vehicle monitoring system.

[0021] Figures 6A to 6C This is a graph illustrating an example of a data reduction solution for obtaining low-fidelity data.

[0022] Figure 7 This is a block diagram illustrating the system and network architecture (such as Local Interconnect Network (LIN), Controller Area Network (CAN), Ethernet, etc.) of a vehicle according to various embodiments of this disclosure.

[0023] Figure 8 This is a block diagram illustrating another separate vehicle telematics system for communicating with a remote server, according to various embodiments of this disclosure.

[0024] Figure 9 It is coupled to various implementation schemes as shown. Figure 8A block diagram of the data extraction unit of a standalone vehicle telematics system.

[0025] Figure 10 It is based on the illustration of various implementation schemes. Figure 9 A block diagram of the computing cluster for the data extraction unit.

[0026] Figure 11 The block diagram illustrates a data extraction unit relative to a vehicle telematics system telematics unit, according to various embodiments of this disclosure, in the context of telematics / logging units.

[0027] Figures 12A to 12E It is based on various implementation plans. Figure 11 The data extraction unit and telematics / logging unit shown illustrate the process for extracting meaningful data from a vehicle telematics system.

[0028] Figure 13 It is based on the illustration of various implementation schemes. Figure 1 The vehicle monitoring system uses Figure 8 A block diagram illustrating the operation of the vehicle telematics system for each vehicle to be monitored.

[0029] Figure 14 This is a flowchart illustrating the process for extracting vehicle data according to various implementation schemes.

[0030] Figure 15 This is a diagram highlighting over-the-air (OTA) downloads, under which different parts of the data warehouse (data processing device) disclosed herein can be updated. Detailed Implementation

[0031] This disclosure relates to systems and methods for reducing datasets or telematics loads related to vehicle information in telematics systems, while retaining the ability of cloud-based servers to perform analysis on the reduced datasets, which would otherwise require full-fidelity data. Dataset reduction may include vehicle-based processing separate from other vehicle computation and control processes involved in the normal operation of the vehicle. This prevents the vehicle's operating system from being overused and / or degraded during the preprocessing data reduction. Therefore, the entirety of the original data can be analyzed in a preprocessing step in dedicated hardware and software to reduce the dataset to a significantly smaller data load. The reduced load can then be wirelessly transmitted to one or more cloud-based servers for storage and analysis, and / or wirelessly transmitted to nearby vehicles for analysis. By significantly reducing the dataset as described in detail throughout this disclosure, transmission costs can be substantially reduced. Additionally, cloud computing costs and runtime can be significantly reduced.

[0032] Most data analytics systems and methods (or "data science" in general) require high-fidelity data for different types of vehicle-related analysis and product understanding. For example, some of these vehicle-related systems may include emergency warning systems, safety systems, GPS navigation systems, driver assistance systems, autonomous driving systems, vehicle tracking systems, vehicle movement, route planning, route rerouting, status, battery, propulsion and behavior detection systems, road hazard warning systems, adaptive cruise control systems, automatic braking systems, automatic steering systems, vehicle usage monitoring systems, and so on. Of course, each of these various systems may require certain types of information, which can be monitored or sensed on the vehicle itself and / or by external sensing systems and other nearby vehicles.

[0033] However, logging and transmitting the high-fidelity data required for analyzing and understanding these vehicle-related systems can be 1) extremely expensive to transmit, especially on a large scale relative to a large number of vehicles (e.g., thousands), and 2) technically impractical to store in the vehicles, as the memory drives of multiprocessor systems and the telematics communication modules (TCMs) that serve as communication links between vehicles and servers degrade over time due to continuous read / write operations on these memory drives. In some cases, significant amounts of degradation can render these memory drives unusable over 3 to 5 years. Meanwhile, low-fidelity data does not meet the needs of these data analytics systems. Therefore, the problem in this regard is how to perform vehicle analysis and run machine learning (ML) models that require high-fidelity data if only low-fidelity data is available, especially when these analytics systems are operating on a large scale with a large number of vehicles operating simultaneously.

[0034] To address this problem, this disclosure provides datasets for reducing the load on vehicle telematics processing, while also preserving various implementations of systems and methods for performing high-fidelity analysis on the reduced data load using vehicle-based and / or cloud-based analytics systems. In some aspects, hardware, software, firmware, etc., can be used in a dedicated manner to perform these data reduction processes (or data extraction processes) before storing or processing the raw vehicle-based data in different analytics systems, thereby reducing the load on these analytics systems. This hardware, software, firmware, etc., used to extract relevant data from the raw data may be referred to as a "data warehouse" or "data processing device," and may include a combined framework for addressing the aforementioned problems. This "data extraction unit," "data warehouse," or "data processing device" can be considered a novel concept in a technology stack placed on top of the hardware, software, and firmware layers. Therefore, a "data warehouse" is a separate, modular layer placed on top of the vehicle stack and performing its functions, updates, etc., while being completely isolated from critical vehicle operations.

[0035] From a physical perspective, a data extraction unit (data warehouse) can be an in-vehicle cluster isolated from regular vehicle operations that perform in-situ data analysis, metric extraction, and / or ML inference. The data extraction unit can then send a highly reduced amount of data output to the cloud. Standalone hardware may not be sufficient in this case, so the data warehouse can also be embodied within the vehicle itself, implementing the various protocols and software systems required for this data extraction. Therefore, the data extraction unit (data warehouse) allows on-vehicle computing systems to perform analysis / extraction on the necessary high-fidelity data while sending only a minimal amount of data to external computing systems in other vehicles or in the cloud via telematics. In some cases, the reduced data can be wirelessly transmitted via long-range communications (e.g., satellite-based systems, GPS, etc.), cellular communication protocols (e.g., LTE, etc.), and / or short-range radio communications (e.g., UWB, Wi-Fi, Bluetooth, etc.). The data warehouse effectively allows cloud processing and data transfer to be moved to a separate vehicle to perform data reduction / extraction within the vehicle, resulting in significant reductions in cloud processing and cloud storage costs.

[0036] Therefore, the features of this disclosure have been outlined rather extensively to facilitate a better understanding of the detailed description and the present contribution to the art. Additional features exist for various embodiments described herein. It should be understood that this disclosure is not limited to the details of the construction and the arrangement of components set forth in the following description or shown in the accompanying drawings. Rather, embodiments of this disclosure may be capable of having other implementations and configurations and may be practiced or performed in a variety of ways. Furthermore, it should be understood that the wording and terminology used are for descriptive purposes and should not be considered limiting.

[0037] Therefore, those skilled in the art will understand that the inventive concepts upon which this disclosure is based can be readily used as the basis for designing other structures, methods, and systems for achieving the various objectives described in this disclosure. Those skilled in the art will understand that embodiments may include various equivalent constructions, provided they do not depart from the spirit and scope of the invention. Additional aspects and advantages of this disclosure will become apparent from the following detailed description of exemplary embodiments illustrated in the accompanying drawings.

[0038] Figure 1This is a schematic diagram illustrating an embodiment of a vehicle monitoring system 10 for monitoring multiple vehicles 12. As shown, the vehicle monitoring system 10 includes multiple cellular towers 14, each configured to wirelessly communicate with vehicles 12 within the communication range of the respective cellular tower 14. The cellular towers 14 are configured to receive reduced datasets from each vehicle 12 within range and transmit this information to a server 16 deployed in a cloud 18. In this respect, the server 16 is considered a cloud-based server for performing any suitable type of cloud computing services related to vehicle tracking, route planning, safety, etc. Each vehicle 12 can be configured to provide cellular, real-time updates (in reduced or extracted form) during its operation. It will be apparent to those skilled in the art that the vehicle network need not be cellular-based, but can also utilize wireless, near-field, and / or other conventional and novel technologies.

[0039] When server 16 receives reduced data from one or more vehicles 12, server 16 is configured to store the data in memory and / or perform several types of cloud computing actions on the information, depending on the type of service performed. The results of the cloud computing performed by server 16 may include information to be stored in memory and / or information to be transmitted back to one or more vehicles 12. For information to be transmitted to vehicle 12, the information is passed to one or more cellular towers 14, which are then configured to communicate wirelessly with vehicle 12 on demand. It can be noted that since each vehicle 12 may be in motion, server 16 may need to determine one or more cellular towers 14 most likely to contact vehicle 12 based on the known location and orientation information of each vehicle 12. Information transmitted to vehicle 12 may also be transmitted to vehicle 12 via non-cellular, wireless networks.

[0040] According to an additional embodiment, the vehicle monitoring system 10 may also include a fixed or mobile sensing detection system that communicates with the server 16 to relay vehicle information. Additionally, the vehicle monitoring system 10 may include one or more satellites configured to assist the vehicle 12 with global positioning information and / or to transmit vehicle position / direction information to the server 16.

[0041] Typically, each vehicle 12 may include a computing system. The vehicle computing system may include various control / operation devices and networks (e.g., one or more electronic control units (ECUs), one or more central processing units (CPUs), various memory devices (e.g., random access memory (RAM), etc.), in-vehicle networks (e.g., local area network (LIN), controller area network (CAN), Ethernet, etc.), telematics systems, logging systems, wireless communication systems, etc. Each vehicle 12's computing system may be configured to perform some functions on the vehicle 12 itself while simultaneously transmitting some functions to the server 16 to provide cloud computing services. Therefore, one of the objectives of this disclosure is to reduce the amount of data transmitted to the server 16 to lower transmission costs and cloud computing costs. Figures 2 to 5 Some general systems for transmitting vehicle telematics data between vehicle 12 and server 16 are shown, and details of the data logging / analysis system are illustrated.

[0042] Figure 2 This is a block diagram illustrating an embodiment of a vehicle telematics system 20. In this embodiment, the vehicle telematics system 20 includes a vehicle 12 communicating with a server 16 in a cloud 18. The vehicle 12 may include an electronic control unit (ECU) 22 or other control / operation devices. The ECU 22 may include an operating system (OS) (e.g., Linux), software / firmware and controls (e.g., C), algorithms (e.g., Simulink), etc. The vehicle 12 in this embodiment also includes a network 24 through which the ECU 22 communicates. The network 24 may include LIN, CAN, Ethernet, or other suitable networking systems on the vehicle 12. The vehicle 12 also includes a telematics / logging unit 26 for transmitting data to the server 16 (e.g., via Wi-Fi, cellular, LTE, etc.) for logging and processing purposes. Signals 28 transmitted from each ECU 22 may be captured and logged in packet capture (PCAP) logs, application programming interface (API) logs, high-fidelity data, low-fidelity data, etc. In some aspects, the vehicle telematics system 20 may represent an existing data communication system. As used in this article, the PCAP log is merely illustrative and can refer to any full-fidelity log file without restriction.

[0043] Figure 3This is a block diagram illustrating another embodiment of a vehicle telematics system 30. In this embodiment, the vehicle telematics system 30 may include local storage capabilities and remote upload capabilities, and may represent an existing high-fidelity logging system. The vehicle telematics system 30 may include an Ethernet (or other network) system 32, a telematics communication module (TCM) device 34, a PCAP logging device 36 for storing high-fidelity data (e.g., a ten-minute full-fidelity log), and a solid-state drive (SSD) (or other persistent storage device) 38. As used herein, the TCM device 34 refers to any device or module operable to record data and transmit data externally. These data recording and external communication functions may be performed by different devices or modules, by sub-devices or modules within the same device or module, or by different devices or modules, all of which are generally referred to herein as the TCM device 34. It will be apparent to those skilled in the art that although SSD 38 is used herein by way of illustration and for simplicity, SSD 38 may also refer to any other type of persistent storage device without limitation. Ethernet system 32, TCM device 34, PCAP or similar logging device 36, and SSD 38 can be part of the vehicle network. SSD 38 (or similar persistent storage device) can be used to store high-fidelity data, which is then uploaded as part of a telematics process using LTE upload action 40 and / or Wi-Fi upload action 42 to upload the high-fidelity data to a remote processing system (e.g., server 16). Similarly, Figure 3 The vehicle telematics system 30 can, in some respects, represent existing data communication systems.

[0044] Below is an example of the use of an onboard SSD 38 and cloud-based teleprocessing without reducing the amount of high-fidelity data. In this example, it can be assumed that a vehicle logs 100 to 150 MB of data on a PCAP logging device 36 every 10 minutes (e.g., approximately 125 MB per 10 minutes on average). It is also assumed that each vehicle operates for an average of one hour per day, which would generate approximately 0.75 GB of data transferred per day. It is further assumed that one million vehicles are being monitored in a region or country (e.g., the United States), resulting in 750 TB of data transferred per day. Over a year, this amounts to a total of 273,750 TB of data being transferred, processed, stored in the cloud, and so on. Therefore, there is a need to reduce the amount of raw data to be transferred, logged, and processed.

[0045] Figure 4This is a block diagram illustrating an implementation of a server processing pipeline 50 configured to compute vehicle data in the cloud. Processing pipeline 50 (or processing mode) may include a central data repository for storing all received logs from multiple vehicles, as indicated in box 52. Logs of time-series data may be scraped to the cloud to extract metrics for analytics, ML models, etc. Processing pipeline 50 may also include cluster computation operations 54, which may be large-scale ETL (extract, transform, load) or similar operations on a cluster using Spark, Hadoop, Pandas, etc. For example, these operations may group data by vehicle identification number (VIN), date, source logs, etc., and cluster computation may be applied in Spark modules, Pandas modules, Python modules, etc., configured to produce a table of extracted meaningful metrics 56, which can be used to process the data to perform useful services for the vehicles.

[0046] Figure 5 It is shown Figure 1 The vehicle monitoring system 10 uses Figure 2 and Figure 3 Functional diagram 60 illustrates an implementation scheme for the operation of one or both of the vehicle telematics systems 20 and 30. Functional diagram 60 may represent existing systems and methods for transmitting high-fidelity data or raw (unreduced) data. Functional diagram 60 includes a logging phase 62, in which PCAP logs 36, etc., are created in vehicle 12. Telematics phase 64 includes the expensive process of transmitting all PCAP logs to cloud 18.

[0047] Functional diagram 60 also includes a cloud storage phase 66, in which server 16 is configured to store all PCAP logs 36, etc., in the cloud 18. The next phase in functional diagram 60 is the cloud processing phase 68. The cloud processing phase 68 is also very expensive and includes a clustering step 70 and multiple n parallel steps 72-1, ..., 72-n for analyzing the PCAP logs 36. Based on these multiple steps 72-1, ..., 72-n, functional diagram 60 creates a meaningful table 74 of the data and a data science and analysis phase 76 for analyzing the meaningful table 74. Functional diagram 60 essentially packages and decompresses a large amount of data to obtain a small portion of meaningful information (i.e., the meaningful table 74). The function of the cloud processing phase 68 is to efficiently and advantageously move the data to a new data warehouse appliance 100. Figure 7 ), 116 Figure 8 ).

[0048] The data flow explicitly expressed in Functional Figure 60 can be reduced by transforming ECU 22 into a logger, using the control system to estimate distributions and extract values ​​(e.g., current and temperature distributions from a battery state of health (SOH) monitor), and transmitting those values ​​via CAN. However, ECU 22 should be used for performing functional operations and control, not for logging and data computation. Additionally, ECU 22 typically has limited memory (e.g., RAM, flash storage, etc.) designed for storing calibration and retaining values. Furthermore, ECU updates should only be performed within a reasonable over-the-air (OTA) timeframe based on vehicle usage. It should also be noted that there may be functional safety implications for any ECU code changes or memory-intensive operations such as data processing. Another issue is that ECUs cannot handle longer cycles that might be required for data analysis.

[0049] Furthermore, data issues could be addressed by limiting the signals recorded. This becomes difficult to achieve with the extensive set of signals required for development and the interdependencies across teams. Additionally, there may be too many core processes to model and understand, making it impossible for OEMs to achieve a 100-1000x reduction in data. Even a 10x reduction (or a reduction to 10% of the total raw data) could be an ambitious goal for this approach.

[0050] In the past, some solutions may have included novel compression methods or file formatting approaches. For example, PCAP logs may have already been highly compressed compared to their decoded counterparts. However, achieving the required 100x to 1000x reduction in this regard may have been difficult or nearly impossible.

[0051] Therefore, the problem of excessive raw data (e.g., PCAP logs 36, etc.) can impose excessive costs on server 16 and the original equipment manufacturer (OEM) of the production vehicle. Similar problems of excessive costs associated with excessive data can affect other industries, such as the production and use of other mobile products (e.g., vehicles, airplanes, trains, ships, etc.) and / or stationary products (e.g., home appliances, personal computers, entertainment equipment, etc.). In this context, these mobile or stationary products refer to those configured (e.g., via wired or wireless communication) to connect to the Internet so that servers or other service-based systems can perform analytics on these products. Servers may require high-fidelity, time-series data to perform diverse services, but cannot do so using conventional systems. Therefore, the systems and methods of this disclosure are configured to reduce the size of the dataset at the product itself to prevent the storage and processing of excessive raw data.

[0052] Therefore, according to embodiments of this disclosure, some principles of solutions to the aforementioned problems may include data analysis and / or metric extraction that can function separately from the operational controls and algorithms used in conventional vehicles. There should be no functional safety (FuSa) impact on the data analysis / metric extraction code. Additionally, the solutions of this invention may include data analysis and / or metric extraction that should be performed in a computational language designed for this type of environment (e.g., Python or Go, not a C or Simulink compiled model). Furthermore, the solutions of this invention can function with changes to data analysis and / or metric extraction being completely independent of changes or updates to the ECU software. In this respect, changes may be more frequent than OTA releases of vehicle software.

[0053] Figures 6A to 6C Graphs 80a, 80b, and 80c are shown, illustrating examples of data reduction solutions related to high-fidelity data processing for obtaining low-fidelity data. Figure 6A As shown in graph 80a, vehicle current is measured over time to obtain time-series data 82 in its raw form. A characteristic of time-series data 82 is the presence of large positive current pulses 84, which can represent regenerative braking processes in which the vehicle's kinetic energy is converted into electrical energy to recharge the battery, thereby slowing the vehicle down. Therefore, time-series data 82 represents a sample of a full-fidelity trace, where a negative current occurs during normal driving phases when the battery supplies power to the vehicle, and a positive current occurs during vehicle braking and when a regenerative process is applied to the battery during braking.

[0054] exist Figure 6B In Figure 80b, the basic low-fidelity data sampling process is illustrated, where a significantly reduced number of data samples are acquired every N seconds. When analyzing and plotting five data points (such as...),... Figure 6C When the problem is seen (as seen in the text), it can become very obvious. That is, Figure 6C The low-fidelity data in Figure 86 omits crucial information relevant to the entire regeneration pulse 84. Therefore, sending low-fidelity data at this point in time is ineffective because some critical information has been omitted. A balance needs to be struck between large-scale high-fidelity data and non-intelligent low sampling rates used to reduce dataset size, in order to intelligently reduce the data to a reasonable dataset size without losing the information needed to perform high-fidelity analysis.

[0055] Sending low-fidelity data involves considerations such as: a) the cost of LTE, which is typically expensive, and b) logging and waiting for Wi-Fi availability, which does not meet the needs of some customers because vehicles may not frequently encounter Wi-Fi hotspots and the SSD 38 of TCM 34 can experience significant degradation after 3 to 5 years of operation under excessive read / write rates. Additionally, low-fidelity data does not meet some of the analytical needs of server 16. This again raises the question of how to perform analytics and run ML models that require high-fidelity data if high-fidelity data is not transmitted to the server on a large scale (e.g., thousands of vehicles).

[0056] Therefore, an agenda may include operating within an existing data generation system, implementing data processing methods, and attempting to implement certain solutions to overcome the aforementioned problems using specific principles, and establishing solutions and technical details for success. The desired outcome is thus to intelligently reduce the dataset of raw data (e.g., telematics load) associated with the characteristics of multiple vehicles in a telematics system. Data reduction is performed by embodiments of this disclosure, but simultaneously retains the ability of cloud-based servers to perform high-fidelity analysis on the reduced dataset without compromising the quality of cloud-based computation and analysis.

[0057] Figure 7According to a block diagram of this disclosure, an implementation of a system and local interconnect network (LIN), controller area network (CAN), Ethernet, etc., 90 of a vehicle (e.g., vehicle 12) operating within a defined area, in which data can be transmitted to a server (e.g., server 16) for remote logging and processing of data representing a reduced telematics workload, is provided. In the illustrated implementation, system 90 may be a digital computing architecture that generally includes one or more control / operation devices 92, such as one or more ECUs 93a, coupled to LIN, CAN, Ethernet, etc. 93a is associated with critical and non-critical vehicle operating functions and receives signals from one or more vehicle sensors or sensor clusters 95. For example, an ECU 93a may be a battery management ECU in an electric vehicle (EV) coupled to sensors for monitoring voltage, current, temperature, etc. Each ECU 93a typically includes a CPU 93b, transient memory 93c, and permanent non-volatile memory 93d, the latter collectively forming a memory device 94. System 90 also includes an input / output (I / O) interface 96 and an external interface 98 coupled to network 102. Furthermore, TCM 101 is coupled to network 102 and communicates with ECU 93a. It should be noted here that TCM 101 generally refers to and indicates a data recording device or module, and it may be implemented as part of an ECU, etc. This data recording device or module may itself include the external interface 98, or may simply communicate with the external interface. Therefore, as used herein, TCM 101 refers to a data recording device or module that can incorporate or utilize external communication capabilities (such as cellular, WiFi, etc.). Data warehouse device 100 (or database retrieval unit 116) Figure 8 The data warehouse device 100 is coupled to and communicates with the TCM 101, while being decoupled from the vehicle's ECU 93a and operational functions. This allows for the operation, modification, and updating of the data warehouse device 100 and the instructions executed by it without affecting critical vehicle operations processed by the ECU 93a. The data warehouse device 100 receives complete datasets from the TCM 101 and processes these datasets to return subsets of data, consisting of extracted metrics, test results, or reduced datasets, to the TCM 101 for subsequent storage and / or transmission to an external server via, for example, external interface 98. The data warehouse device 100 may utilize its own processing equipment, memory, etc. It should be understood that... Figure 7System 90 is depicted in a simplified manner. Some embodiments may include additional components and appropriately configured processing logic to support known or common operating characteristics. Components (i.e., 92, 94, 95, 96, 98, 100) may be communicatively coupled via a local interface or network 102. Local interface 102 may include, for example, one or more buses or other wired or wireless connections. Local interface 102 may also include controllers, buffers, caches, drivers, repeaters, receivers, and other elements to enable communication. Furthermore, local interface 102 may include address, control, and / or data connections to enable appropriate communication between components 92, 94, 95, 96, 98, 100.

[0058] It should be understood that, according to some embodiments, the control / operation device 92 may include one or more electronic control units (ECUs) 93a and one or more CPUs 93b for controlling vehicle operation. The control / operation device 92 may include or utilize one or more general-purpose or special-purpose processors (e.g., microprocessors, ECUs, CPUs, digital signal processors (DSPs), network processors (NPs), network processing units (NPUs), graphics processing units (GPUs), field-programmable gate arrays (FPGAs), semiconductor-based devices, chips, etc.). The control / operation device 92 may also include or utilize stored program instructions (e.g., stored in hardware, software, and / or firmware) to control the network 90 by executing the program instructions to implement some or all of the functions of the systems and methods described herein. Alternatively, some or all of the functions may be implemented by a state machine that may not necessarily include the stored program instructions, may be implemented in one or more application-specific integrated circuits (ASICs), and / or may include functions that can be implemented as custom logic or circuitry. Of course, combinations of the above methods may be used. For some of the embodiments described herein, the corresponding device in the hardware (and optionally having software, firmware, and combinations thereof) may be referred to as a “circuit” or “logic” “configured” or “suited” to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc., on digital and / or analog signals as described herein for various embodiments.

[0059] Memory device 94 may include volatile memory elements (e.g., random access memory (RAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), static RAM (SRAM), etc.), non-volatile memory elements (e.g., read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), hard disk drive, magnetic tape, compact disc ROM (CD-ROM), etc.) or combinations thereof. Furthermore, memory device 94 may include electronic, magnetic, optical, and / or other types of storage media. Memory device 94 may have a distributed architecture, in which various components are remotely located relative to each other but accessible by processing device 92.

[0060] Storage device 94 may include a data repository, database, etc., for storing data. In one example, the data repository may be located internally to network 90 and may include, for example, an internal hard drive connected to local interface 102 in network 90. ​​Alternatively, in another embodiment, the data repository may be located externally to network 90 and may include, for example, an external hard drive (e.g., SCSI or USB connection) connected to input / output (I / O) interface 96. In yet another embodiment, the data repository may be connected to server 90 via a network and may include, for example, a network-attached file server.

[0061] The software stored in memory device 94 may include one or more programs, each program including an ordered list of executable instructions for implementing logical functions. The software in memory device 94 may also include a suitable operating system (O / S) and one or more computer programs. The O / S essentially controls the execution of other computer programs and provides scheduling, input / output control, file and data management, memory management, and communication control and related services. The computer programs may be configured to implement the various processes, algorithms, methods, techniques, etc., described herein.

[0062] Furthermore, some embodiments may include a non-transitory computer-readable medium having instructions stored thereon for programming or enabling a computer, server, processor (e.g., control / operation device 92), circuit, appliance, device, etc., to perform the functions described herein. Examples of such non-transitory computer-readable media may include hard disks, optical storage devices, magnetic storage devices, ROMs, PROMs, EPROMs, EEPROMs, flash memory, etc. When stored in a non-transitory computer-readable medium, software may include (e.g., instructions executable by control / operation device 92 or other suitable circuitry or logic). For example, when executed, the instructions may cause or enable control / operation device 92 to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc., as described herein according to various embodiments.

[0063] The methods, sequences, steps, techniques, and / or algorithms described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in software / firmware modules executed by a processor (e.g., control / operation device 92), or any suitable combination thereof. The software / firmware modules may reside in memory device 94, a memory controller, dual data rate (DDR) memory, RAM, flash memory, ROM, PROM, EPROM, EEPROM, registers, hard disks, removable disks, CD-ROMs, or any other suitable storage medium.

[0064] Those skilled in the art will understand that various implementation schemes can be described as logical blocks, modules, circuits, algorithms, steps, and sequences of actions that can be executed or otherwise controlled by: general-purpose processors, DSPs, ASICs, FPGAs, programmable logic devices, discrete gates, transistor logic, discrete hardware components, elements associated with computing devices, controllers, state machines, or any suitable combination thereof, designed to perform or otherwise control the functions described herein.

[0065] In some embodiments, sensor 95 may include any suitable equipment for detecting any type of parameters, characteristics, conditions, states, usage, etc., of the vehicle on which system 90 is employed. Sensor 95 may detect position, speed, direction, external temperature, battery temperature, battery voltage, battery current, battery usage, propulsion usage, acceleration, vehicle roll detection, airbag deployment, throttle usage, brake usage, vehicle warnings and alerts, nearby vehicle status, road congestion, road construction status, traffic conditions, etc. Sensor 95 can acquire raw data, which can then be reduced to a more reasonable dataset size using the systems and methods of this disclosure.

[0066] I / O interface 96 can be used to receive user input from one or more devices or components and / or provide system output to them. For example, user input can be received via one or more of a keyboard, keypad, touchpad, and / or other input receiving devices. System output can be provided via a display device, monitor, user interface (UI), graphical user interface (GUI), and / or other user output devices. I / O interface 96 may include one or more of, for example, a serial port, a parallel port, a Small Computer System Interface (SCSI), an Internet SCSI (iSCSI), an Advanced Technology Attachment (ATA), a Serial ATA (SATA), Fibre Channel, InfiniBand, Peripheral Component Interconnect (PCI), a PCI Expansion Interface (PCI-X), a PCI Fast Interface (PCIe), an infrared (IR) interface, a radio frequency (RF) interface, and a Universal Serial Bus (USB) interface.

[0067] External interface 98 can be used to enable TCM 101 to communicate via wireless networks (e.g., via cellular tower 14, satellite, etc.), the Internet, wide area networks (WAN), local area networks (LAN), vehicle battery charging stations, etc. In some embodiments, external interface 98 may include one or more antennas 104 or other suitable structures to wirelessly transmit radio signals to and detect vehicle and / or traffic information or to transmit such information to cellular tower 14, satellite, nearby vehicles, nearby traffic information stations, or other external devices or systems on which network 90 is set up. In wired communication setups (e.g., when the vehicle is stationary and connected to a fixed communication station via an Ethernet cable), external interface 98 may include, for example, wired Ethernet communication equipment, such as an Ethernet card or adapter (e.g., 10BaseT, Fast Ethernet, Gigabit Ethernet, 10GbE) or a wireless LAN (WLAN) card or adapter (e.g., 802.11a / b / g / n / ac). External interface 98 may include address, control, and / or data connections to enable appropriate communication on a network (e.g., connection to cloud 18 and / or server 16). External interface 98 may be configured with a telematics module for transmitting vehicle parameters. In some embodiments, external interface 98 and / or I / O interface 96 may include GPS equipment (e.g., GPS sensors) to allow the detection of location and / or route planning information.

[0068] It should be noted that the data warehouse device 100 of system 90 can be configured to operate substantially independently of the rest of system 90. The data warehouse device 100 may ultimately receive data from control / operation devices 92 and sensors 95 or data obtained via user input using I / O interface 96. The received data may be preprocessed by the data warehouse device 100 in a manner that reduces the size of the dataset, thereby including only the information required to perform various vehicle-related services and analyses. The data warehouse device 100 can significantly reduce data, thereby reducing the cost of data transmission (e.g., telematics stage 64), data storage (e.g., cloud storage stage 66), and the costs of cloud processing stage 68 and data science and analysis stage 76. Figure 5 ).

[0069] Figures 8 to 11 and Figures 12A to 12E The following embodiments of the data warehouse device 100 and / or other data reduction / extraction systems consider a new layer in the data processing stack. In some aspects, the following embodiments may be referred to as preferred embodiments of this disclosure and are believed to include advantages over the previously described embodiments. The data warehouse device 100 may also be isolated from any control / operational devices or networks critical to conventional vehicle operation (e.g., steering, braking, navigation, sensing, etc.). While conventional vehicle operation may include some operational dependencies, the data warehouse device 100 may include a layer that is completely isolated from these other vehicle functions and may have no operational dependencies.

[0070] Therefore, according to some implementations, the network operating the vehicle may include multiple sensors (e.g., sensor 95), external interfaces (e.g., external interface 98), control / operation devices (e.g., ECU 22, control / operation device 92, data warehouse device 100, node 124, CPU, data extraction unit 140, computing cluster 142, etc.), and memory devices (e.g., data extraction unit 140). The memory device (e.g., using data extraction unit 140) may be configured to store a computer program with instructions that, when executed, enable the processing device to obtain a dataset from the multiple sensors. For example, the dataset may include vehicle-related metrics indicating vehicle operation. The instructions may also enable the data warehouse device to extract relevant data from the dataset to reduce the telematics load. Furthermore, the instructions may enable the data warehouse device to cause the external interface to wirelessly transmit relevant data to a remote server. The action of extracting relevant data may be configured to preserve the remote server's ability to perform high-fidelity analysis on the relevant data.

[0071] Figure 8 This is a block diagram illustrating another embodiment of a vehicle telematics system 110 for communicating with a remote server (e.g., server 16 of cloud 18). Figure 8 The vehicle telematics system 110 includes and Figure 2 It shares many similarities with the vehicle telematics system 20, and includes an ECU 22 and network 24 similar to the vehicle telematics system 20. However, as Figure 8 As shown in the implementation scheme, the vehicle telematics system 110 also includes a telematics processing / logging unit 112, which is configured to perform additional steps before transmitting the metric 114 to the server 16. Additionally, the vehicle telematics system 110 includes a data warehouse device 116 (or data reduction / extraction device), which may have... Figure 7 Similarities to the data warehouse device 100 shown. The telematics / logging unit 112, for example, includes interfaces with the data warehouse device 116 to allow the data warehouse device 116 to reduce additional steps in data set processing by extracting relevant data that can be used to perform various vehicle-related services.

[0072] Figure 9 It is shown Figure 8 A block diagram of portion 120 of a vehicle telematics system 110 is shown, illustrating a telematics / logging unit 112 and a data warehouse device 116 (or other suitable data reduction and / or extraction unit). The telematics / logging unit 112 may be configured to communicate with the data warehouse device 116 via an Ethernet device 122. The data warehouse device 116 may include a cluster of nodes (e.g., units, modules, elements, etc.) 124-1, 124-2, ..., 124-x. Each node 124 in the cluster includes RAM and a CPU. The data warehouse device 116 also includes one or more persistent storage units 126-1, ..., 126-y. The nodes 124 in the cluster are arranged to communicate with the persistent storage units 126.

[0073] Data warehouse appliance 116 is configured to reduce data load while preserving full-fidelity analysis without compression, which is typically the most common method for reducing dataset size. However, conventional compression algorithms cannot achieve the 100x data reduction that might be required for significant size reduction. Nevertheless, compression can still be used to enhance the data reduction / extraction capabilities of embodiments of this disclosure, such as the reduced dataset produced by the operation of data warehouse appliance 116.

[0074] Additionally, the data warehouse device 116 can also be arranged to be completely separate from the operational control and algorithms of conventional vehicle functions. This allows the data warehouse device 116 to be updated independently of the vehicle's over-the-air (OTA) communications (e.g., wireless communication systems) and is configured without functional safety implications.

[0075] The data warehouse appliance 116 can be configured to run in data-first languages ​​(e.g., Python, Go, etc.) compared to embedded languages ​​(e.g., C, etc.) not designed for data analysis / data science / ML inference. Furthermore, the configuration of the cloud-connected cluster of nodes 124-1, 124-2, ..., 124-x (each node configured to run a "container group" within the vehicle for real-time data analysis) differs from other conventional systems, thus enabling functionalities unavailable in conventional systems.

[0076] For example, a data cluster or allocation block may refer to a memory unit (e.g., RAM) combined with a computing unit (e.g., CPU). The grouping of memory and computing resources within a cluster allows for fine-tuning of resource allocation when operations are performed on the cluster. As used in this disclosure, a "container group" may refer to a set of computing elements linked together within Kubernetes or other computing architectures. Container groups provide distributed, fault-tolerant, parallel operations within a cluster. In some implementations, a container group may be defined as a single container (or a small number of tightly coupled containers sharing resources). These clusters and container groups may resemble the architecture of microprocessors and supercomputers, as well as other cloud computing services. Therefore, this advanced infrastructure can also be implemented using vehicle computing systems to provide high-fidelity operations, thereby offloading the complexities of cloud computing to the vehicle itself.

[0077] As described in this disclosure, persistent memory can refer to memory used to enable data structures to be efficiently stored so that these data structures can be accessed using memory instructions or memory APIs even after the process of creating or last modifying them has ended. Unlike non-volatile random access memory (NVRAM), persistent memory is associated with the concept of persistence in its emphasis on program state existing outside the fault region of the process that created it.

[0078] Figure 10 This is a block diagram illustrating an implementation of a compute cluster 130 created by the hardware of a data warehouse appliance 116. In one implementation, the data warehouse appliance 116 may utilize a container orchestration system (e.g., Kubernetes) to automate the deployment, scaling, and management of the data warehouse appliance 116's capabilities (e.g., software). In some implementations, the nodes 124 or clusters of the data warehouse appliance 116 may be connected to Kubernetes to create an efficient compute cluster (e.g., compute cluster 130).

[0079] Figure 11 It is shown that... Figure 8A block diagram of another embodiment of a data extraction unit 140 (e.g., a data warehouse device) connected to the telematics / logging unit 112 of a vehicle telematics system 110. In some aspects, the data extraction unit 140 may be considered as the mentioned embodiment. The data extraction unit 140 includes a computing cluster 142 (e.g., computing cluster 130) and persistent storage 144 (e.g., persistent storage 126).

[0080] In this embodiment, the telematics / logging unit 112 includes a receiving unit 146 configured to receive real-time Ethernet data from an ECU (e.g., ECU 93a). The telematics / logging unit 112 may also include a data checking unit 148 configured to check against a data extraction unit 140 to see if the data can be reduced or extracted. The data checking unit 148 transmits the received data (e.g., PCAP logs, etc.) to the data extraction unit 140 via an Ethernet system for data extraction. The data extraction unit 140 then extracts the data as appropriate and provides the extracted data back to the data checking unit 148. The returned data may include metrics in JSON format or another similar format via an Ethernet system. Furthermore, in this embodiment, the telematics / logging unit 112 includes a transmission unit 150 configured to transmit the extracted metrics from the data extraction unit 140 to the cloud (e.g., cloud 18).

[0081] The computing cluster 142 of the data extraction unit 140 includes an orchestration container group 152, a decoding container group 154, multiple metric extraction container groups 156-1, 156-2, ..., 156-z, and a collector container group 158. The persistent storage 144 of the data extraction unit 140 can be configured to store the decoding (DBC) component 160, the decoded image component 162, the metric image component 164, the metric script component 166, and the main image component 168.

[0082] Persistent storage 144 can be configured to update the data warehouse (e.g., data extraction unit 140) on demand. Persistent storage 144 is configured to store base or master images, DBC files of the current software release version, calibration / parameter files, decoded and measurement images, measurement application scripts, and / or other data or software.

[0083] Data extraction unit 140 (or data warehouse) can use metric extraction container group 156 on individual logs within a storage device or database to run a series of metric extraction applications in parallel with other vehicle operations. After logs have been generated on the vehicles, the applications for metric extraction container group 156 can be run on the cluster.

[0084] Orchestration container group 152 sends time-series log data to decoding container group 154, which is then configured to prepare log data frames (or similar in-memory time-series data structures) and pass these structures back to orchestration container group 152. The time-series log data (data frames) is then passed in parallel to each metric extraction container group 156. It will be apparent to those skilled in the art that, as used herein, data frames are merely illustrative and other code-based data structures can also be used. Each metric extraction container group 156 can be configured to run a separate container group (e.g., an application) using, for example, common lightweight Python image analysis as a containerized application. Each metric extraction container group 156 exports data in a common pattern to collector container group 158, which then sends the final data via Ethernet cable to telematics / logging unit 112 for subsequent broadcast to the cloud.

[0085] According to some implementations, the data extraction unit 140 (e.g., a data warehouse) is configured to execute five main processes for extracting meaningful data from the vehicle telematics system. These five main processes can be independently configured. Figures 12A to 12E The system is shown below. These five main processes may include:

[0086] I. Receive full-fidelity log data

[0087] II. Preparing Data for Measurement Applications

[0088] III. Run the measurement application

[0089] IV. Exporting Data

[0090] V. Update the data warehouse

[0091] Figure 12A This is a block diagram illustrating an implementation of a log generation system 170, which is the data source for the first process of receiving full-fidelity log data. The log generation system 170 includes a receiving unit 146, a data inspection unit 148, and an Ethernet structure 172 for transferring PCAP logs, etc., from memory to the data extraction unit 140. An indication that PCAP logs are not being transferred to an SSD, etc. (e.g., SSD 38), is also shown because these logs are not being written to memory that would otherwise be overloaded or exhausted.

[0092] Instead of writing the PCAP log to an SSD, the remote information processing / logging unit 112 is configured to transmit the log (e.g., 10 minutes of full-fidelity log data) to the data extraction unit 140 (e.g., a data warehouse) via an Ethernet structure or the like. Therefore, for example, the full-fidelity log exists only in RAM and prevents continuous degradation of the SSD.

[0093] Figure 12B This is a block diagram illustrating an implementation of a data preparation system 180 for performing a second process of preparing data for metric extraction. The data preparation system 180 includes a receiving unit 146, a data checking unit 148, and related portions of the data extraction unit 140. Since each metric extraction container group 156 of the computing cluster 142 needs to be configured to decode time-series log data in memory structures (data frames, etc.), the orchestration container group 152 is configured to send all logs from the data checking unit 148 to the decoding container group 154. The orchestration container group 152 can be initialized using a master image from the master image component 168 in persistent storage 144.

[0094] The orchestration container group 152 receives the data via Ethernet and generates a decoding container group 154. The decoding container group 154 ​​uses the DBC file of the DBC component 160 and the decoded image of the decoding image component 162 to obtain the time-series signal data. The decoding container group 154 ​​then returns this information to the orchestration container group 152. At this point, the orchestration container group 152 has a time-series log in memory as a data frame, etc. In some embodiments, the decoding container group 154 ​​may run in Go, so the exact output may not be a data frame, but rather a data frame or similar format that can be easily converted to the orchestration container group 152.

[0095] Figure 12C This is a block diagram illustrating an embodiment of a measurement execution system 190 for performing a third process of running a measurement application. The measurement execution system 190 may include relevant portions of a data extraction unit 140. During this process, the decoding container group 154 ​​can be temporarily terminated as needed. Figure 12C (Not shown in the image) to restore its memory and CPU. Orchestration container group 152 is configured to evaluate contextual information about the received logs to determine what state has occurred. Orchestration container group 152 is then configured to trigger the appropriate metric analysis process based on the log context. Metric extraction container groups 156-1, 156-2, ..., 156-z use applications to share common analytical base images, such as metric images and metric scripts from persistent storage 144 and metric scripts from persistent storage 144. In this sense, the metric scripts reside outside the images in persistent storage 144 and metric extraction container group 156 is configured to run as a parallel application.

[0096] The data processing cluster 142 of the data extraction unit 140 is configured to operate independently of the log generation process and the vehicle operation process. Therefore, the log generation process and the log processing process are fundamentally separated, and these two processes can be performed in parallel. Furthermore, to reduce log processing time, the data can be processed in a set of parallel container groups (e.g., metric extraction container group 156) or other suitable applications, allowing sufficient time before the next log is received.

[0097] Figure 12D This is a block diagram illustrating an implementation of a data export system 200 for performing the fourth process of exporting data. In addition to the relevant portions of the data extraction unit 140, the data export system 200 may also include a data inspection unit 148 and a transmission unit 150 of the telematics / logging unit 112. The metric extraction container group 156 can be configured to export data as a dictionary using a unified pattern such as the following:

[0098] {

[0099] 'app_id':<env variable> ,

[0100] 'metrics':

[0101] {

[0102] '<metric name> ':

[0103] {

[0104] 'value':<numeric value, nullable> ,

[0105] 'string':<string value, nullable>

[0106] },

[0107] }

[0108] }

[0109] The Python dictionary above is merely an example of a memory key-value data structure, and various other data structures can be used in this disclosure.

[0110] Collector container group 158 can be configured to receive these dictionaries and package them into "data warehouse metrics" 202. Collector container group 158 can then send the data warehouse metrics 202 back to the data inspection unit 148 of the telematics / logging unit 112 via an Ethernet structure. The extracted, highly reduced data (i.e., data warehouse metrics 202) is then transmitted to the cloud via transmission unit 150.

[0111] Figure 12E This is a block diagram illustrating an implementation of the repeating system 210, whereby the data preparation system 180 (process II), the metric execution system 190 (process III), and the data export system 200 (process IV) can be executed on demand in that specific sequence to repeat various processes for each log. When all logs have been processed, the repeating system 210 can pause until additional logs are received from the telematics / logging unit 112.

[0112] Figure 13 It is function diagram 220, which includes Figure 1 The vehicle monitoring system 10 uses Figure 8 The vehicle telematics system 110 (according to a preferred embodiment) operates on each vehicle 12 to be monitored. The operation of the functional diagram 220 includes a logging phase 222-0, a telematics phase 222-1, a cloud storage phase 222-2, a cloud processing status 222-3, and a data science and analysis phase 222-4.

[0113] Specifically, each vehicle 12 performs data extraction to obtain data warehouse metrics 202, which is related to the logging phase 222-0 and produces a highly reduced dataset of the aforementioned vehicle-related information. Therefore, the telematics phase 222-1 is simplified by reducing data transmission, thereby... Figure 5 This makes the stage cheaper compared to the expensive telematics stage 64 of the functional diagram 60. Additionally, cloud storage stage 222-2 involves storing a reduced dataset of data warehouse metrics 202 in the cloud, further saving costs. Furthermore, cloud processing stage 222-3 (cloud computing) is simplified due to the need to process less data. Cluster component 224 operates on the reduced dataset, and analysis unit 226 is configured to perform analysis of the metrics (i.e., data warehouse metrics 202). Results can be sent to meaningful table 228 in data science and analysis stage 222-4 for a more streamlined vehicle (and traffic) analysis process.

[0114] In summary, this disclosure can be configured to significantly reduce the amount of data transferred (at scale) for telematics data strategies (e.g., by approximately 100 times). This can be done in ways that are not currently available in conventional systems. This disclosure provides implementations that can save significant amounts of money not only in terms of data transfer costs but also in terms of cloud processing (computing) costs. Even with the reduction in data, meaningful data is not lost but can be preserved in a way that allows cloud computing systems (e.g., server 16) to analyze data warehouse metrics 202 and perform analysis of all high-fidelity data that would otherwise require cloud storage. Furthermore, in addition to extracting metrics in situ within vehicles, the model can also run on high-fidelity data that is not available in conventional systems. In some implementations, the model may include ML models or other techniques or algorithms for learning through a training process, performing ML inference processes, retraining on demand, etc., which are not available in conventional logging systems. ML models running in conventional systems as part of operationally critical control / operation devices carry the risk of encountering inputs to which they have not yet been trained (breaking the model and impairing critical functionality). This disclosure enables data warehouse appliances to run as container groups in the log processing process with less training and less validation of models, due to their complete isolation from vehicle operation and functional safety dependencies.

[0115] As an example, the systems and methods of this disclosure can be incorporated into one or more vehicles (or a fleet of vehicles), whether internal combustion engine (ICE) vehicles, hybrid electric vehicles (HEVs), or electric vehicles (EVs). In other embodiments, the systems and methods of this invention can be incorporated into stationary storage devices, battery charging systems, and eVTOL, aviation, and hyperloop systems—any system that requires operation based on high-fidelity metrics and functional safety-related ECUs. The solutions of this invention also enable other systems to learn from complex products (e.g., batteries) at scale in a customer fleet in ways not available in conventional systems.

[0116] This disclosure achieves massive data volume reduction solely by transmitting extracted metrics via cellular systems (even when cached and using Wi-Fi). This disclosure also enables large-scale, high-fidelity data analytics. Because data can be processed at full fidelity on individual vehicles as described herein, the system can run all data science / analysis / ML applications on demand at scale on each vehicle without the prohibitive costs of the cloud. Furthermore, this results in a significant reduction in data processing costs, as processing data logs in cloud-based services can be very expensive. Additionally, leveraging the additional parallel processing features of this disclosure, only relevant data can be extracted in a timely manner.

[0117] This disclosure describes systems and methods for extracting vehicle data and essentially enabling some cloud computing services to be moved from the cloud to individual vehicles. In some embodiments, this disclosure may include processes performed before transmitting or storing large amounts of data and reducing the amount of such data to include only “important” or “useful” time-series datasets or metrics, thereby reducing the load on cloud computing servers.

[0118] Figure 14 This is a flowchart illustrating an embodiment of process 230 for extracting vehicle data. Process 230 may include steps of obtaining datasets from multiple sensors on the vehicle, as indicated in box 232, wherein these datasets may include vehicle-related metrics indicative of vehicle operation. Process 230 also includes extracting relevant data from these datasets to reduce the telematics load, as indicated in box 234. Additionally, process 230 includes wirelessly transmitting the relevant data to a remote server using an external interface. Specifically, the step of extracting relevant data (box 234) may be configured to preserve the remote server's ability to perform high-fidelity analysis on the relevant data.

[0119] Process 230 may also include storing the relevant data in a solid-state drive (SSD) or other persistent storage device after the step of extracting relevant data from these datasets (box 234). Additionally, the step of extracting relevant data (box 234) may include utilizing persistent memory and multiple nodes operationally separate from components used to perform motion functions in the vehicle, wherein each node may include random access memory (RAM) and a central processing unit (CPU).

[0120] In some implementations, the step of extracting relevant data (box 234) may include utilizing a) multiple metric extraction container groups arranged in parallel; b) orchestration container groups; c) decoding container groups for obtaining data frames or similar formats from log data and forwarding the data frames or similar formats to the multiple metric extraction container groups; d) collector container groups configured to receive useful metrics from the multiple metric extraction container groups; and / or e) persistent storage having one or more of a decoding (DBC) component, a decoded image component, a metric image component, a metric script component, and a main image component.

[0121] Process 230 may also include the step of causing an external interface to wirelessly transmit relevant data to a remote server via a cellular system. The remote server may be a cloud-based server communicating with the cellular system. In some cases, the relevant data may also include Global Positioning System (GPS) data received from one or more GPS satellites.

[0122] According to some implementations, process 230 may include steps of sensing or detecting vehicle characteristics related to one or more of the following: position, speed, direction, acceleration, battery usage, airbag deployment, propulsion use, throttle use, brake use, vehicle dashboard warnings, etc., and / or obtaining information related to traffic and road conditions from one or more of nearby vehicles and road signaling equipment.

[0123] Figure 15 This is a schematic diagram highlighting over-the-air (OTA) download situations under which different parts of the data warehouse disclosed herein can be updated. Generally, the DBC and decoded images can be updated during vehicle-wide OTAs. Measurement images and measurement scripts can be updated via cellular means, for example, outside of vehicle-wide OTAs. The master image can be updated during vehicle-wide OTAs. This is relevant because, unlike ECU solutions, the code can be dynamically changed even while the vehicle is operating. This is achieved through complete operational isolation of the data warehouse device / system. It also enables corrections to the measurement extraction scripts or updates related to which machine learning (ML) models are tested at any time, without being limited by the time / frequency the owner updates their vehicle. Therefore, the DBC and image files used for decoding / master functions can be updated during the vehicle-wide OTA process. Here, "image" refers to an OS image, not a photograph. It essentially includes the OS, any dependencies, built-in files / calibrations / settings, etc.

[0124] Although this disclosure has been illustrated and described with reference to various embodiments and examples, it will be apparent to those skilled in the art that other embodiments and examples may perform similar functions, achieve similar results, and / or provide other advantages. Modifications, additions, or omissions may be made to the systems, apparatus, and methods described herein without departing from the spirit and scope of this disclosure. All equivalent or alternative embodiments falling within the spirit and scope of this disclosure are thus contemplated and are intended to be covered by the following claims.

Claims

1. A system integrated into a vehicle, the system comprising: Electronic control unit; Sensor, the sensor being coupled to the electronic control unit; A data recording module, which is operable to generate full-fidelity data and communicate with an external server via an external interface; and A data processing device, coupled to the data recording module but isolated from the electronic control unit, comprising: Processing unit, and A memory device configured to store instructions, which, when executed, cause the processing unit to: Data is obtained from the data recording module. The data is processed to form a subset of the data, wherein the subset of data represents a reduced data load compared to the original data. The subset of the data is provided to the data recording module for transmission to the external server via the external interface; The data processing device is functionally separate from the vehicle's electronic control unit, operating functions, safety functions, and network. The processing of the data includes extracting container groups using multiple metrics arranged in parallel, and The data processing also includes using orchestration container groups and decoding container groups to obtain a predetermined format from the log data and forwarding the log data in the predetermined format to the plurality of metric extraction container groups.

2. The system of claim 1, wherein the subset of the data includes one or more of the following: metrics extracted from the data, results of test runs on the data, and selected portions of the data.

3. The system of claim 1, wherein the data processing device and the data recorder unit adapted to be coupled to the vehicle are further functionally separated.

4. The system of claim 1, wherein the instructions further cause the processing unit to store the subset of the data in a persistent storage device after processing the data.

5. The system of claim 1, wherein processing the data includes utilizing persistent storage and a plurality of nodes associated with the data processing device.

6. The system of claim 5, wherein each of the plurality of nodes includes random access memory (RAM) and a central processing unit (CPU).

7. The system of claim 1, wherein processing the data further comprises utilizing a collector container group configured to receive a plurality of metrics from the plurality of metric extraction container groups.

8. The system of claim 1, wherein processing the data further comprises utilizing persistent memory having one or more of a decoding component, a decoded image component, a measured image component, a measured script component, and a main image component.

9. The system according to claim 1, wherein the external interface includes one or more of a cellular interface, a wireless interface, and a near-field interface.

10. The system of claim 1, wherein the sensor is configured to detect vehicle features associated with one or more of the following: telematics, position, speed, direction, acceleration, braking, engine status, battery status, charging usage, airbag deployment, throttle usage, brake usage, equipment usage, equipment status, operational warnings, safety warnings, traffic conditions, road conditions, environmental conditions, and occupant status.

11. A method for a vehicle, the method comprising: At the data processing device, data is obtained from the data recording module, which is coupled to the vehicle's electronic control unit and sensors and is operable to generate full-fidelity data; The data is processed to form a subset of the data, wherein the subset of data represents a reduced data load compared to the data; and The subset of the data is provided to the data recording module of the vehicle for transmission to an external server via the vehicle's external interface; The data processing device is functionally separate from the vehicle's electronic control unit, operating functions, safety functions, and network. The data is processed using multiple metric extraction container groups arranged in parallel; as well as The data is processed using orchestration container groups and decoding container groups to obtain a predetermined format from the log data and to forward the log data in the predetermined format to the multiple metric extraction container groups.

12. The method of claim 11, wherein the subset of the data includes one or more of the following: metrics extracted from the data, results of test runs on the data, and selected portions of the data.

13. The method of claim 11, wherein the data processing device is further functionally separated from the data recorder unit adapted to be coupled to the vehicle.

14. The method of claim 11, further comprising storing the subset of the data in a persistent storage device after processing the data.

15. The method of claim 11, further comprising processing the data using persistent memory and a plurality of nodes associated with the data processing device.

16. The method of claim 15, wherein each of the plurality of nodes includes random access memory (RAM) and a central processing unit (CPU).

17. The method of claim 11, further comprising using a collector container group to process the data, the collector container group being configured to receive a plurality of metrics from the plurality of metric extraction container groups.

18. The method of claim 11, further comprising using persistent memory to process the data, the persistent memory having one or more of a decoding component, a decoded image component, a measured image component, a measured script component, and a main image component.

19. A non-transitory computer-readable medium comprising instructions stored in a memory and executed by a processing device to cause the processing device to perform the following steps: At the data processing device, data is obtained from the data recording module, which is coupled to the vehicle's electronic control unit and sensors and is operable to generate full-fidelity data; The data is processed to form a subset of the data, wherein the subset of the data includes one or more of the metrics extracted from the data, the results of test runs on the data, and selected portions of the data, wherein the subset of the data represents a reduction in data load compared to the data; as well as The subset of the data is provided to the data recording module of the vehicle for transmission to an external server via the vehicle's external interface; The data processing device is functionally separate from the vehicle's electronic control unit and operating functions, safety functions, and network. The data processing includes utilizing multiple metric extraction container groups arranged in parallel, and the data processing also includes using orchestration container groups and decoding container groups to obtain a predetermined format from log data and forward the log data to the multiple metric extraction container groups in the predetermined format.

20. The non-transitory computer-readable medium of claim 19, wherein the subset of said data includes one or more of metrics extracted from said data, results of test runs on said data, and selected portions of said data.

21. The non-transitory computer-readable medium of claim 19, wherein the data processing device is functionally separate from the electronic control unit and the operating functions of the vehicle, such that instructions for processing the data can be modified without affecting instructions associated with the operating functions of the vehicle.

Images