System, method, and device for configurable vehicle data collection

Abstract

The device may include a policy acquisition circuit configured to interpret vehicle policy data values ​​including external event trigger conditions. The device may include a policy processing circuit configured to generate parsed policy data including external event trigger conditions. The device may include a policy execution circuit configured to collect vehicle data from one or more vehicle endpoints in response to the parsed policy data.

Description

Technology Field Cross-reference regarding related applications

[0001] This application was filed on January 9, 2024, and claims priority to U.S. provisional application serial number 63 / 619,267 (SONA-0016-P01) titled “SYSTEM, METHOD, AND APPARATUS FOR HIGH CAPABILITY CONFIGURABLE VEHICLE DATA COLLECTION”.

[0002] This application was filed on March 17, 2023, and claims priority to U.S. patent application serial number 18 / 123,183 (SONA-0010-U01-C01-C05) titled “SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION”. This application is a continuation of this U.S. patent application.

[0003] U.S. application serial number 18 / 123,183, filed on September 8, 2021, is a continuation of U.S. patent application serial number 17 / 469,148 (SONA-0010-U01-C01) titled "SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION", claiming priority to this U.S. patent application serial number.

[0004] U.S. Application Serial No. 17 / 469,148, filed on March 8, 2021, is a continuation of U.S. Application Serial No. 17 / 195,589 (SONA-0010-U01), titled "SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION," and claims priority to this U.S. Application. Currently, U.S. Application Serial No. 17 / 195,589 was registered as U.S. Patent No. 11,538,287 on December 27, 2022.

[0005] Each of the aforementioned patent documents is incorporated herein by reference in its entirety. Background Technology

[0006] Vehicle communication networks are utilized to connect sensors, actuators, controllers, user interfaces, personal occupant devices, trailers, and communication devices throughout the vehicle. Recent trends are increasing the burden on these vehicle communication networks as more devices are connected, more data is transmitted between devices, lower latency is required to meet vehicle performance, safety, and emissions requirements, and vehicle features are added. Additionally, consumers expect increased connectivity, reduced driver burden, and features that increase the burden on vehicle communication networks. These trends are expected to continue and accelerate in the foreseeable future.

[0007] Traditional automotive communication networks (CAN, LIN, FlexRay, MOST, LVDS, etc.) suffer from numerous drawbacks and challenges. These automotive communication networks were developed to meet the specific challenges of the vehicle environment and were therefore developed separately from other networks such as computer local area networks, wide area networks, large-scale interconnection networks (e.g., the Internet), and wireless networks. Most automotive networks consist of a data link layer and an application layer, utilize robust and dedicated equipment such as Controller Area Network (CAN) buses, and employ dedicated or shared wiring between devices utilizing specific data protocols (e.g., J1939, OBD, etc.). Modern vehicles can have multiple network buses, specific commands and communications are available, and limited customization and data speeds are available. For example, CAN buses generally operate at a maximum of about 1 Mbps, while high-performance CAN buses operate at a maximum of about 10 Mbps. Additionally, CAN buses have latency exceeding 25 ms, and generally range from about 60 ms to 500 ms depending on configuration, traffic on the CAN, priority of specific messages, etc.

[0008] As the number of devices and the demand for data rates from them increase, traditional vehicle communication networks require the implementation of higher-performance buses. Because the automotive industry is a mass-production industry with very low tolerances for component failure, automakers use the same components for extended periods across a wide range of vehicles, including component sharing among manufacturers. Additionally, switching to nominally higher-performance components can lead to risks, incur integration costs, impose the burden of re-certification for a given application, or result in other undesirable consequences for the system. Therefore, even as vehicle communication networks transition to higher-capacity network configurations, it is desirable to keep network types isolated within the system and maintain a large number of legacy devices (e.g., CAN-compatible) in the system for a long time.

[0009] The collection of data from vehicles involves a number of additional challenges. For example, data collection operations are subject to regulatory and liability risks, particularly in cases where data collection may involve personal or personally identifiable information. Data collectors, including entities that may hold ownership or possession of sensitive data, are exposed to risk while retaining the data, for instance, in the event of accidental or malicious access to the data. With regard to collected vehicle data, large volumes of data may be collected, and there may be numerous purposes for collecting the data, which increases the risk compared to other general data storage applications. Therefore, to mitigate risk, it may be desirable to control data collection, storage, and access, and it may be more desirable to include verification of data access, partitioning of data when it is not in use, or other exclusions.

[0010] Data collection for vehicles is further complicated by the volume and type of data that must be communicated between the vehicle and external devices, where the vehicle's network system is limited by the constraints of mobile applications, high data rates, and costs and / or bandwidth limitations arising from large-scale data transmissions. Despite the foregoing, customer demand, market expectations, increasing requirements for the efficiency of vehicle operations, and the growing functional capabilities of data-related applications continue to increase the aggregated volume of data to be transmitted, the number of external applications utilizing the transmitted data, the number of purposes for which the data can be utilized, and the number of users or entities with legitimate needs for portions of the transmitted data. Additionally, as data-utilizing applications continue to increase in sophistication and capability, they increase the demand for data on limited available transmission resources and increase the cost and complexity of the logistical control and storage of the transmitted data. For example, higher capability route planning or motion algorithms related to vehicles, increased automation of vehicle functions, increased demand for predictive decisions and / or maintenance support, and an increase in media streams (both the number of media streams and the quality of said media streams) all lead to increased demand for data rates, the amount of stored data, and the number of entities or applications accessing the stored data.

[0011] The aforementioned complexities and other challenges have synergistic effects that cause the complexity of the vehicle data environment to be much greater than the sum of the individual contributions from each challenge.

[0012] As an example, as the number of entities or applications accessing data increases, the likelihood of individual data requests being duplicated increases—for instance, when multiple entities request the same or similar data. Furthermore, as the number of entities or applications accessing data increases, the likelihood of members of accessing groups sharing similar authorization levels increases, making data access for individual members of an entity or application group require data management.

[0013] In another example, regulations regarding sensitive data are increasing, which generally increases the data management requirements of systems, but also increases the likelihood that data management will be subject to multiple constraints at any given time, and / or the likelihood that it will be subject to constraints that change over time as regulations evolve.

[0014] In another example, the complex environment of currently known and transitioning vehicle network architectures—e.g., vehicles with mixed network types and / or partitioned networks—increases the complexity of data access for individual entities, and these entities, without specific aspects of the present disclosure, may need to determine request parameter specifications for specific data elements and update said request parameters as vehicle network architectures evolve. As the number of entities requesting data access increases, the aggregate cost for the automotive assistance market increases non-linearly, because each entity incurs a cost of tracking request parameter specifications. Additionally, the trajectory of additional entities requesting data access moves toward entities located further away from core automotive functions within the technical knowledge space; consequently, the complexity and specificity of vehicle and / or automotive applications—including in-vehicle network configurations, specific data descriptions, data request and communication protocols, and industry standards or practices for information presentation—become, on average, less known for each incremental new entity, thereby further increasing the cost volume function (e.g., the time cost to satisfy the desired data collection outcomes of a given entity, where the given entity may be an automotive manufacturer, and / or a vehicle market, a geographic market, and / or an industry such as the automotive industry, the passenger car industry, etc.). For example, consider the following conceptual cost volume function:

[0015] Cost = Number of Entities × Base Learning Cost × Transition Adaptation Cost × Data Trend Cost × Regulatory Adaptation Cost × Data Access / Storage Responsibility Cost

[0016] The described COST function is a non-restrictive conceptual example intended to illustrate how various challenges and complexities associated with currently known systems interact and synergize to increase the costs required to meet future data collection capabilities for automotive applications. The described cost parameters are not intended to include all costs associated with challenges existing in the automotive data collection industry or with currently known systems. The parameters may be averages or other complex functions, and the specific values ​​of particular parameters will generally not be known. Furthermore, the units of COST may be expressed in monetary value, as resources required to meet data collection targets over time (e.g., engineering time, computation time, etc.), or in other non-monetary units such as equivalent emissions, customer satisfaction, incurred risks, or public perception losses or gains.The number of entities parameter generally reflects the number of entities accessing vehicle data over time; the base learning cost reflects the costs for new entities to learn the details of data collection requirements and protocols for specific vehicles, vehicle types, markets, etc.; the transition adaptation cost trend reflects the costs of adapting to changing vehicle network configurations, including network types and configurations; the data trend cost reflects the increasing demand for data collection from relevant vehicles over time, including resulting functional consequences such as the inability to support data communication, storage, and desired applications, or the costs of improving data communication infrastructure; the regulatory adaptation cost reflects the costs associated with an increasing number of regulations, regulatory frameworks, and / or regulatory entities; and the data access / storage liability cost reflects costs incurred for data compliance and security, and / or losses resulting from data breaches, unauthorized use, etc.

[0017] Specific aspects of the present disclosure include controlling the routing of communications over a network, whether between separate devices on the network or between a device on the network and an external device. Specific aspects of the present disclosure include applying configurations and / or policies to controllers of a vehicle and facilitating communication between endpoints of a vehicle, including between endpoints on different networks or different network zones and between endpoints utilizing distinct data formats, data rates, communication protocols, etc. Specific aspects of the present disclosure include utilizing and managing a shared repository to support data collection and / or data sharing between endpoints.Without limitation to any aspect of the present disclosure, some tools that may be utilized to tactically implement specific operations of the present disclosure in combination with the present disclosure, and descriptions that may enhance understanding of some terms used herein (e.g., policy, endpoint, external device, network protocol, network type, etc.) may be found in one or more of the following U.S. patents or patent applications: U.S. Application No. 17 / 027,167 (SONA-0006-U01), filed September 21, 2020, titled SYSTEM, METHOD, AND APPARATUS TO SUPPORT MIXED NETWORK COMMUNICATIONS ON A VEHICLE; U.S. Application No. 17 / 027,187 (SONA-0007-U01), filed September 21, 2020, titled SYSTEM, METHOD, AND APPARATUS TO EXTRA VEHICLE COMMUNICATIONS CONTROL; U.S. Application No. 17 / 195,589 (SONA-0010-U01), filed on March 8, 2021, titled SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION; U.S. Application No. 17 / 833,614 (SONA-0012-U01), filed on June 6, 2022, titled SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION; and / or U.S. Application No. 18 / 244,147 (SONA-0015-U01), filed on September 8, 2023, titled SYSTEM, METHOD, AND APPARATUS TO EXECUTE VEHICLE COMMUNICATIONS USING A ZONAL ARCHITECTURE. Each of these applications is incorporated herein by reference in its entirety for all purposes.

[0018] Exemplary and non-limiting aspects of the present disclosure may be utilized wholly or in part with any one or more of the systems, devices, controllers, circuits, and / or procedures described above, and / or with any other aspects of the present disclosure, as described below. The following aspects are non-limiting and any one or more of them, or any one of them, may be utilized in a given embodiment.

[0019] An exemplary procedure includes actions to enhance trigger actions, wherein the trigger may be utilized as a decision element in any of the following features: triggering a data collection event; triggering a diagnostic; triggering an active or passive test action; triggering an automated vehicle response action; and / or triggering an update action. In certain embodiments, the trigger may form part of another action or function as an intermediate action within any action (e.g., utilized to pause or continue a parent action), including but not limited to within one of the listed types of actions.

[0020] Exemplary trigger enhancement actions include utilizing any type of external event within the trigger action, e.g., weather-based events, time of day, calendar events (e.g., holidays, weekdays, fiscal year events, etc.), and / or combining external events with specific knowledge about the vehicle and / or the vehicle's owner / driver (e.g., responding to the vehicle owner's birthday, normal trip events for the vehicle, estimates of the vehicle's possible destinations during a trip, etc.).

[0021] Exemplary trigger enhancement behaviors include utilizing logical vehicle groups for triggers, for example, applying a trigger to a group in response to a vehicle being part of a logical group. Without limitation, logical vehicle groups include vehicles that share the following aspects: vehicles utilizing a specific configuration, component, or feature; vehicles having an associated maintenance event, recall, or campaign; vehicles having a common manufacturer, bodybuilder, dealer, and / or OEM (original equipment manufacturer); vehicles having a common owner (e.g., fleet); vehicles having a common owner type (e.g., commercial, private, rental, first responder, government); vehicles having a common duty cycle (e.g., quantitative / statistical description of the duty cycle and / or categorical description of the duty cycle); and / or vehicles having common applications and / or functions (e.g., delivery, long-distance transport, first responder, commuting, etc.).

[0022] Exemplary trigger enhancement behaviors further include individualized triggers, for example, when a vehicle is part of a logical group for triggers. For example, trigger criteria may be based on logical groups and may include additional customizations that can be automatically applied to specific vehicles. Aspects of individualization may include, without limitation, the following: setting trigger criteria (e.g., thresholds for triggers adjusted to the characteristics of individual vehicles); adjusting data collected in response to triggers; formatting data in response to triggers; applying time windows (e.g., time windows used to determine triggers, and / or time windows during which triggers are activated or monitored); action durations (e.g., the duration of an action initiated in response to a trigger, and / or the amount of time for the action to be performed, for example, due to the dynamic characteristics of the vehicle); and / or configuration of actions (e.g., the ordering of actions, and / or parallel or serial operation of one or more actions). In certain embodiments, setting individualization parameters for a trigger includes determining the purpose of the trigger and determining the characteristics of vehicles within a logical group that may influence the purpose of the trigger. For example, an action to track fuel consumption may involve monitoring the consumption of a certain percentage of a vehicle's fuel, which may vary depending on the vehicle's fuel capacity. In another example, specific vehicle types or a specific vehicle history may indicate times of day when trigger monitoring and response actions are likely to be more effective. Thus, common situations may be treated as common trigger actions for a logical group, but may be tailored to specific vehicles within the group.In certain embodiments, trigger options may be configured for specific vehicles, such as prototype, engineering, or test vehicles (e.g., triggering parameters and / or trigger criteria), and these options may be unavailable for other types of vehicles (e.g., standard passenger car applications used by the customer).

[0023] Exemplary trigger enhancement behaviors allow for variable duration of the trigger, which may be commanded at the initial communication of the trigger to the vehicle. In certain embodiments, the variable duration of the trigger may be adjusted based on a logical vehicle group for the vehicle, and / or individualized trigger options for vehicles within the logical group. Exemplary variable duration options include, without limitation: a continuous trigger (e.g., continuously evaluating the trigger and performing a response action for a specified time period, during specific relevant operating conditions, and / or continuously, wherein the response action may include collecting and / or collecting data or capturing the occurrence of a trigger event); a one-time trigger (e.g., evaluating the trigger until a trigger event occurs and then stopping monitoring, which may include performing trigger response actions once); an n-based time trigger (e.g., evaluating the trigger until a selected number n of trigger events occur, which is selected for purposes such as verifying a specific operation, providing a statistically relevant event data set, or supporting comparisons between vehicles); Defined duration triggers (e.g., monitoring the trigger for X days; the duration may be time-based, utilization-based (e.g., over the next 1,000 miles, until 100 miles are driven under cruise control, until 10,000 hp-hr of energy is delivered to the powertrain, etc.), and / or based on specific operating conditions (e.g., until 10 start / stop cycles are performed)); and / or transient triggers (e.g., monitoring whenever another trigger condition is activated, which may result in intermittent and / or transient trigger evaluation). It may be noted that trigger actions are not mutually exclusive, and, for example, trigger evaluation may continue until the defined duration value is exceeded.It can be further understood that trigger actions can be performed in sequence, for example, by monitoring the vehicle's temperature whenever the vehicle is operating under different conditions (e.g., altitude, high power output, high ambient temperature, etc.).

[0024] An exemplary procedure includes an action of implementing a user interface for a user to input recipes (e.g., policies, automated vehicle responses, triggers, etc., which may be downloaded to the vehicle(s) for implementation or used as a template or starting point for any of the actions of the present invention), to set triggers (e.g., trigger evaluation conditions, and / or responses to trigger evaluation conditions), and / or to request policies or other active information from a vehicle (or group of vehicles) (e.g., obtaining a summary, overview, report, or detailed description of policies, triggers, automated actions, recipes, etc., that are active in the vehicle; the active information may be limited to triggers / policies / recipes / automated actions (TPRAs) that are actively monitored / monitored or actioned, and / or may include TPRAs that are monitored / monitored or actioned if other conditions are met—e.g., another active trigger being evaluated). In certain embodiments, inactive information may also be requested, for example, trigger actions that have been completed but remain in the system—for example, when collected data has not been transmitted out of the vehicle, thus trigger information may still be in the system even if no further action is taken.

[0025] Exemplary actions for implementing a user interface include allowing the user to select or create logical vehicle groups, determine the type of TPRA information to be reported, and provide a display of TPRA information that is searchable, sortable, filterable, etc., according to specific vehicles, vehicle characteristics, information regarding the TPRA (e.g., triggers that the evaluation returned event detection), etc. In certain embodiments, TPRA information on the user interface may be exported (e.g., to form a template or recipe for creating a new TPRA) and / or modified (e.g., when the modification of the TPRA initiates an update interface and populates the update with information based on the modification activity in the TPRA user interface). In certain embodiments, the user interface may utilize feature or function nicknames, allow all or part of a recipe to be brought into the creation part of another recipe, and allow the user to create and / or name recipes, etc.

[0026] An exemplary procedure includes actions to enhance data collection operations for a vehicle. An exemplary action includes providing a dedicated memory reservation for a data collection operation, for example, determining the amount of data to be collected for the operation (determined from a command action that causes data collection, such as a trigger, automated action, diagnostic action, test action, etc.), and reserving memory space, for example, a shared storage location, on a controller of the vehicle. The action of reserving memory space may be a specific allocation (for example, ensuring that specific memory locations remain available) or a non-specific allocation (for example, ensuring that sufficient memory remains available without necessarily allocating specific addresses for memory). In certain embodiments, the action for a dedicated memory reservation includes communicating to the controller(s) responsible for data collection the location where the collected data will be stored. In certain embodiments, the memory reservation may be distributed, for example, where one or more controllers are responsible for data collection, and / or where the data storage on the vehicle itself is a distributed data storage (for example, a logical data storage having parts at various memory locations on the vehicle).

[0027] Exemplary memory reservation operations include utilizing a shared memory reservation basket—for example, reserving memory for various data collection operations as a consolidated memory allocation to support various data collection operations. In the examples, the shared memory reservation basket may be a specific allocation or a non-specific allocation, and additionally or alternatively, the shared memory reservation basket may be strictly sufficient for all memory operations (e.g., 10 competing data collection operations each utilizing 10 MB; 100 MB is allocated to support these data collection operations), and / or statistically sufficient for memory operations (e.g., in an additional example, where less than 100 MB is allocated to support these data collection operations, e.g., 50 MB or 75 MB). In certain embodiments, memory reservation operations include determining a statistically sufficient allocation for memory operations, for example, supporting data collection for inversely correlated triggers (e.g., if trigger A occurs and commands the collection of data A, conditions for trigger B and the collection of the corresponding data B will not occur). In certain embodiments, the statistically sufficient allocation for memory operations may be performed using Bayesian estimates, which may be operated to determine specific probabilities for correlation and / or inverse correlation between triggers and / or other conditional data collection and storage operations (e.g., the occurrence of trigger A may make the occurrence of trigger B more or less probable).In certain embodiments, historical use of memory for various triggers, automated actions, diagnostics, and / or tests on the vehicle may be utilized, which includes correlating such usage patterns with other vehicle characteristics (e.g., owner, application, duty cycle, and / or any other vehicle aspects described in relation to logical vehicle groups without limitation). In certain embodiments, in-vehicle events such as the occurrence of fault codes, specific operating conditions, and changes in vehicle usage patterns may be utilized to determine and / or adjust the shared memory reservation basket. In certain embodiments, iterative enhancement algorithms, e.g., machine learning or artificial intelligence-based applications, may be utilized to set or adjust the shared memory reservation basket for a group of conditional data collection and storage actions.

[0028] In certain embodiments, a group of conditional data collection and storage operations correlated with a specific shared memory reserved basket may be coordinated, for example, to improve the likelihood that the basket size is correctly determined, to simplify the determination of the correct basket size, or to adjust the likelihood that the size of a given basket is correctly determined. For example, mission-critical conditional data collection and storage operations may be provided with dedicated memory storage resources and may be placed in a strictly sufficient shared memory reserved basket, and / or in a shared memory reserved basket having a high confidence value that the basket is statistically sufficient. In certain embodiments, shared storage within a basket may be prioritized based on the type of data, the requesting entity for the storage operation (e.g., related endpoint, flow, application, controller, etc.), the recency of the data, etc., and allows storage of at least high-priority data until, for example, the data can be moved outside the vehicle (e.g., to the cloud), until some data can be deleted (e.g., under data expiration and / or data lifecycle management operations), until some data can be compressed, and / or until additional storage can be allocated to the shared memory reserved basket.

[0029] Specific aspects that a user may utilize to determine how to group conditional data collection and storage operations include the following aspects: variability in the size of the data collected for an operation, and / or a statistical description thereof; the expected lifespan of the data collected within a shared memory reserved basket; additional processing to be performed on the collected data, the resulting size after processing, and the timing thereof; correlation or inverse correlation between operations, and / or certainty thereof; the effect of the distribution of operations among baskets (e.g., a reduction in uncertainty in one basket may increase or decrease uncertainty in other baskets, and the effect thereof may be greater or smaller than the effect on the allocated basket); and / or the availability of historical information regarding data collection and storage operations on the vehicle and / or other similar vehicles.

[0030] In certain embodiments, data collected according to conditional data collection and storage operations may be packaged, for example, in a file, in a discrete number of files, in dedicated memory locations, etc. In certain embodiments, the packaging may include one or more instances of conditional data collection operations, and / or each conditional data collection operation may be packaged individually. Accordingly, the embodiments of the present invention consider a one-to-one correlation between packages and data collection operations, a many-to-one correlation between packages and data collection operations, or a many-to-many correlation between packages and data collection operations. In certain embodiments, a package may be removed from a shared memory reserved basket (e.g., to simplify estimates of the statistical sufficiency of the baskets) and / or when a package is ready, a conditional data operation may be removed from a shared memory reserved basket (e.g., a conditional data operation not to be executed again). The use of packages for collected data can improve the management of shared memory allocations and provide ease in determining statistical information about vehicles (e.g., data waiting to be transmitted to the cloud; aggregating or describing data responding to specific triggers, diagnostics, tests, etc., potentially regarding groups of vehicles), and / or provide improved response times during limited transmission windows to the cloud, tools, etc. (e.g., when transmitting data outside the vehicle).

[0031] In certain embodiments, real-time data, flow logs, vehicle status values ​​(e.g., fault codes, errors, operational status parameters such as START, RUN, CRUISE, STOP, etc.), metadata (e.g., timestamps or other values ​​associated with conditional data collection operations), etc., may be captured and made available together with the collected data. In certain embodiments, such data may be packaged together with the collected data in package(s) created for the data.

[0032] In certain embodiments, for example, when collected data, packages, etc. are transmitted outside the vehicle, a memory buffer will be utilized to ensure smooth transmission operations and prevent repetitive transmission operations (e.g., when transmission of large data packages is interrupted).

[0033] In certain embodiments, transmission operations for collected data, packages, etc., may be classified, and contention for limited data storage and / or transmission resources may be resolved in response to the classification. For example, the classification of collected data to be stored or transmitted may be determined by a unique policy identifier for the collected data—for example, by a policy type for an associated policy that defines a conditional data collection operation. Additionally or alternatively, the data type of the collected data may be utilized for classification. Additionally or alternatively, entity characteristics for any associated entity may be utilized (e.g., the entity provides a policy, provides data, and / or utilizes data, wherein the entity may be an external entity such as an organization providing a policy, or an endpoint, flow, or application on a vehicle). For example, vehicle control data, data requested by a vehicle manufacturer, and / or data provided by a vehicle control endpoint may be classified as high-priority data. In certain embodiments, the classification of collected data and / or packages may be determined based on vehicle operating conditions—for example, in vehicle operating conditions where abundant memory and / or network communication resources are available, sensitive data such as audio-visual (AV) data may be high-priority data, and in other vehicle operating conditions such as during an update, and / or where network communication resources are limited, AV data may be low-priority data. In certain embodiments, the classification and / or priority of collected data and / or packages may be utilized to mediate resources in any manner, including, for example, allowing higher-priority data to always take precedence, utilizing a weighted priority method, or using round-robin (and / or weighted round-robin) scheduling of resources.

[0034] An exemplary procedure includes actions to enhance data collection operations for a vehicle by generating data elements that are passed between applications on the vehicle to support TPRA operations. For example, parameters commonly utilized by multiple TPRA operations may be provided in locations accessible to relevant endpoints on the vehicle, which can reduce the number of processing operations required to generate and store these parameters. For example, intermediate decisions for a TPRA operation may include comparing parameters, determining intermediate states, etc., and the exemplary procedure includes performing these decisions once and making the results available, which reduces redundant workload on the vehicle's controllers. In certain embodiments, the generated data elements may already exist in the vehicle, where common location operations reduce the workload on the controller providing the corresponding parameters. In certain embodiments, the generated data elements may not already exist in the vehicle but may appear from common processes occurring to perform various TPRA operations and may be parsed from the aggregation body of the TPRA operations. In certain embodiments, the procedure includes operations to simplify TPRA operations by taking into account generated data elements.

[0035] The exemplary procedure includes actions to enhance data collection operations for a vehicle by providing a flexible policy implementation for the vehicle. In certain embodiments, the policy may be configured to operate immediately (e.g., at runtime), at the next start event, and / or in response to a trigger condition. Policies operating in response to a trigger condition may utilize a flag value, wherein the flag value includes a known description of a policy trigger (e.g., "STARTUP", "HIGH POWER", etc.) that may be stored in the vehicle and / or standardized by a relevant entity (e.g., manufacturer, fleet owner, etc.). In certain embodiments, policies operating in response to a trigger condition may include the trigger condition within the policy. Without limitation to any other aspects of the present disclosure, exemplary and non-limiting policy implementations include one or more of: on-demand policies (e.g., terminated upon shutdown, after one execution, or after X executions), limited action policies (e.g., limiting actions to streaming, data capture, and / or data capture options), and / or continuous policies (e.g., continuous evaluation and action of a policy). In certain embodiments, each policy may be assigned a unique identifier (e.g., a unique ID assigned to the policy, and / or generated from policy data), and / or a policy-client unique identifier (e.g., a unique ID for the policy and the entity that supplied the policy, and / or generated from policy data and / or entity source data).

[0036] In certain embodiments, the operations described throughout this disclosure may be supported, coordinated, and / or modified according to a QoS for data transmission, and the QoS may include QoS parameters for entities on the vehicle (e.g., endpoints, controllers, flows, applications, circuits, etc.).

[0037] The exemplary procedure includes operations to enhance data collection operations and / or storage management operations, and includes operations to perform time-series data compression on collected data, packages, and / or any other stored data on the system. In certain embodiments, operations to perform delta-delta compression, sigma compression, and / or encoding compression—including combining one or more of these in certain embodiments—have demonstrated superior compression performance (e.g., based on compressed data size, compression processing time, compressed data integrity, and / or decompression processing time) for data collected in the embodiments of the present invention compared to previously known compression methods.

[0038] In certain embodiments, time series data may be compressed by including an operation to remove the time series field and / or an operation to separately compress the time series field. For example, a continuous time series field may be completely removed without data loss by tracking the series start time and the data increment time. For relatively continuous time series data, for example, a series containing gaps, significant compression may be achieved by storing a number of time series start time markers (e.g., corresponding to any discontinuities or lost data points). In certain embodiments, it may be permissible to fill the gaps with pseudo-data (e.g., interpolated data) to preserve time series continuity and / or fill with dead data (e.g., which may be marked or tagged). In certain embodiments, the data may be further compressed by encoding, for example, in the general situation where many data values ​​have the same value. Additionally or alternatively, sigma compression (or zero-peaking) may be applied where many data values ​​have repeating zeros. In certain embodiments, delta compression may be performed after applying any time series compression, encoding, and / or zero-peaking, and may be performed, for example, to enhance a large number of data points having a specific value (e.g., a value of 0).

[0039] In certain embodiments, compression operations may additionally or alternatively include leaving a portion of the data uncompressed, providing headers for the data, and / or providing a contextual view to a client of the data (e.g., to find and / or display data in a user interface for a user outside the vehicle) to facilitate, for example, query operations. For example, a portion of the data related to trigger operations may be left uncompressed to facilitate displaying and / or finding related data packages—e.g., to provide the user with a quick understanding of why the data package was captured. In certain embodiments, the collected data may be stored in chunks (determined, e.g., by time blocks, data size, the number of data features of interest within each chunk, etc.; wherein the number of features of interest may relate to events detected within the chunk, the slope of the data within the chunk, the inversion of data patterns within the chunk, etc.). In additional examples, a portion of each chunk may be left uncompressed, for example, to allow a user to quickly search for any events of interest regarding a vehicle within the data and to quickly perform limited decompression operations to evaluate specific data within the chunk. In certain embodiments, the data may be indexed, and / or the data chunks may be indexed. In certain embodiments, the chunking and / or indexing method may be configured by the user (e.g., by providing a policy to the vehicle).In certain embodiments, the chunking and / or indexing method is configured according to the diagnostic and / or fault tree analysis (FTA) (e.g., as a conditional data collection operation supporting the diagnostic and / or FTA) to allow for the configuration of powerful diagnostic and / or FTA operations that are compressed and formatted in a manner that enables the smooth collection of desired data from the vehicle under desired conditions and facilitates the rapid analysis supporting the diagnostic and / or FTA. Brief explanation of the drawing

[0040] FIG. 1 is a schematic diagram of an exemplary data collection system according to specific embodiments of the present disclosure.

[0041] FIG. 2 is a schematic diagram of an exemplary vehicle having aspects of a data collection system according to specific embodiments of the present disclosure.

[0042] FIG. 3 is a schematic diagram of an exemplary vehicle external device according to specific embodiments of the present disclosure.

[0043] FIG. 4 is a drawing of exemplary internal and / or external applications according to specific embodiments of the present disclosure.

[0044] FIGS. 5a and 5b illustrate schematic diagrams of exemplary vehicle network infrastructure for a vehicle according to specific embodiments of the present disclosure.

[0045] FIG. 6 is a schematic diagram of an exemplary edge gateway according to specific embodiments of the present disclosure.

[0046] FIG. 7 is a schematic diagram of an exemplary Ethernet switch according to specific embodiments of the present disclosure.

[0047] FIG. 8 is a schematic diagram of an exemplary Ethernet device according to specific embodiments of the present disclosure.

[0048] FIG. 9 is a schematic diagram of an exemplary user consent controller according to specific embodiments of the present disclosure.

[0049] FIG. 10 is a schematic diagram of an exemplary data collector controller according to specific embodiments of the present disclosure.

[0050] FIG. 11 is a schematic diagram of an exemplary first partition according to specific embodiments of the present disclosure.

[0051] FIG. 12 is a schematic diagram of an exemplary second partition according to specific embodiments of the present disclosure.

[0052] FIG. 13 is a schematic diagram of an exemplary cloud system according to specific embodiments of the present disclosure.

[0053] FIG. 14 illustrates an exemplary cloud system for retrieving selected data from a vehicle according to specific embodiments of the present disclosure.

[0054] FIG. 15 illustrates an exemplary schematic diagram of an operation including an operation for collecting data from a vehicle according to specific embodiments of the present disclosure.

[0055] FIG. 16 illustrates an exemplary procedure for separating response data for a vehicle data collection operation according to specific embodiments of the present disclosure.

[0056] FIG. 17 illustrates an exemplary procedure for separating response data for a vehicle data collection operation according to specific embodiments of the present disclosure.

[0057] FIG. 18 illustrates an exemplary system for retrieving selected data from a vehicle according to specific embodiments of the present disclosure.

[0058] FIG. 19 illustrates an exemplary procedure for identifying data according to specific embodiments of the present disclosure.

[0059] FIG. 20 illustrates an exemplary cloud system for preparing data collection policies according to specific embodiments of the present disclosure.

[0060] FIG. 21 illustrates an exemplary policy generator circuit according to specific embodiments of the present disclosure.

[0061] FIG. 22 illustrates an exemplary request interface according to specific embodiments of the present disclosure.

[0062] FIG. 23 illustrates an exemplary procedure for operating a request interface according to specific embodiments of the present disclosure.

[0063] FIG. 24 illustrates an exemplary system for supporting enhanced vehicle data collection.

[0064] FIG. 25 illustrates a device for providing an external event trigger policy.

[0065] FIG. 26 illustrates exemplary external event trigger conditions.

[0066] Figure 27 illustrates exemplary position values.

[0067] FIG. 28 illustrates an exemplary device for determining a target group of vehicles.

[0068] FIG. 29 illustrates exemplary shared vehicle attributes.

[0069] FIG. 30 illustrates an exemplary device for supporting policy creation.

[0070] FIG. 31 illustrates an exemplary user data collection interface.

[0071] Figure 32 illustrates exemplary normalized data parameters.

[0072] FIG. 33 illustrates an exemplary device for managing data collection and storage.

[0073] FIG. 34 illustrates an exemplary basketing method for allocating shared memory.

[0074] FIG. 35 illustrates exemplary components of a policy reporting circuit.

[0075] FIG. 36 illustrates an exemplary vehicle having a controller for managing data collection, storage, and data sharing.

[0076] FIG. 37 illustrates an exemplary device for managing data sharing and analysis.

[0077] FIG. 38 illustrates exemplary components of a data support circuit.

[0078] FIG. 39 illustrates an exemplary device for policy lifecycle management.

[0079] Figure 40 illustrates exemplary policy lifecycle description options. Specific details for implementing the invention

[0080] Without limitation to any other aspects of the disclosure, the aspects of the disclosure of this specification reduce and / or eliminate one or more of: the cost per entity added to the data collection system, the basic learning cost for new entities to implement applications utilizing the collected data, the cost of adapting to changing vehicle network configuration(s), the cost incurred to meet the increasing demand for data collection, the cost of adapting to a changing regulatory environment, and / or the cost of securing data, and / or the loss resulting from infringement or unauthorized use. Specific embodiments and / or aspects of this specification may address one or more of the described cost parameters. Specific embodiments and / or aspects of this specification may increase one or more given cost parameters, but nevertheless may be beneficial by reducing the overall cost function for target vehicles, vehicle types, entities, industries, etc. Specific embodiments and / or aspects of this specification may increase one or more given cost parameters, but may provide other benefits such as enhanced functionality. In certain embodiments, enhanced functionality may be achieved at an increased cost, but at a lower cost than conventionally known systems configured to achieve similar enhanced functionality.

[0081] For the purpose of enhancing understanding of the principles of the present disclosure, the embodiments illustrated in the drawings will now be described in the following written specification. It is understood that no limitation is intended to be made to the scope of the present disclosure. It is further understood that the present disclosure includes any changes and modifications to the illustrated embodiments and includes additional applications of the principles disclosed herein as are typically encountered by those skilled in the art to which the present disclosure pertains.

[0082] The present disclosure describes systems, methods, and apparatus for performing data collection operations related to a vehicle. Specific embodiments described herein refer to mixed vehicle networks on a vehicle. Exemplary mixed vehicle networks include one or more CAN buses used for communication of a number of devices, one or more Ethernet networks used for communication of a number of devices, and a network having communication from CAN to Ethernet and / or vice versa. Mixed networks are not limited to CAN and Ethernet and may, without limitation, include one or more of Local Interconnect Networks (LIN), FlexRay, Media-Oriented System Transmission (MOST), and / or Low Voltage Differential Signaling (LVDS). Currently available Ethernet networks are high-performance and have bandwidth classes of 100 Mbps to 25 Gbps and latency values ​​of 5 ms to 20 μs (0.02 ms). In specific embodiments, more than one Ethernet network (or zone) may exist and may include mixed-performance Ethernet networks. Additionally or alternatively, in certain embodiments, one or more networks present may include wireless networks such as WiFi networks (e.g., 802.11x standards such as a / b / g; n; and / or ac), mobile standard networks (e.g., 4G and / or 5G), Bluetooth communications, Universal Serial Bus (USB) connections, and / or fiber optic connections. The listed networks are non-limiting examples, and any type of network and / or communication protocol for mixed vehicle networks is considered herein.

[0083] In certain embodiments, the mixed vehicle network comprises one or more low-performance networks combined with one or more high-performance networks. The performance considered low-performance depends on the application, the number of devices communicating, the types of communication allowed in the network, and the network management available for the specific network and communication protocols utilized (e.g., registration, addition, or removal of devices, encryption of messages, customization of messages, etc.). In certain embodiments, the mixed vehicle network comprises more than one network, wherein at least two of the networks present present integration challenges. For example, one of the networks may allow only certain types of communications, require certain types of synchronous or asynchronous communications, allow only certain types of device connections, restrict the implementation of certain network topologies, or have other differences or limitations that make the use of a single network (or network type) across the entire vehicle undesirable or impractical.

[0084] The description in this specification utilizing extra-vehicle, extra-vehicle, and / or cloud-based interactions refers to any external network communications of the vehicle, including but not limited to wireless-based communications to external devices (e.g., mobile data, WiFi, and / or Bluetooth). Communications to external devices may be to general networks (e.g., via the Internet), WANs, LANs, mobile devices near the vehicle, and / or combinations thereof. The specific systems and procedures described in this specification particularly consider the runtime operations of the vehicle, such as external communications occurring during operational conditions in which the vehicle performs a mission (e.g., while moving, performing operations while stationary, etc.). The disclosure in this specification further considers communications that may occur during any period, including during vehicle downtime and / or during service events. The disclosure in this specification further considers communications that may occur via wired communication channels, such as when the vehicle network is communicating with a service tool, an on-board diagnostic (OBD) device, or other physically coupled device.

[0085] The description in this specification refers to vehicle applications as non-limiting examples for clarity of this description. However, the embodiments of this specification are applicable to other applications having similar problems and / or implementations. Without limitation to any other application, the embodiments of this specification are applicable to any application having multiple endpoints including multiple data sources, controllers, sensors, and / or actuators, may further include endpoints existing in separate or distributed network environments, and / or are applicable to applications having historical or legacy networking or communication systems that are transitioning to newer or newer or more capable networking or communication systems (within a given system, as a class of systems, and / or as an industry). Exemplary and non-limiting embodiments include one or more of: industrial equipment; robotic systems (including at least mobile robots, autonomous vehicle systems, and / or industrial robots); mobile applications (which may or may not be considered "vehicles") and / or manufacturing systems. It will be understood that specific features, aspects, and / or benefits of the present disclosure may be applicable to one or more of these applications and may not be applicable to others of these applications, and that the applicability of specific features, aspects, and / or benefits of the present disclosure may vary depending on the operating conditions, constraints, and cost parameters (e.g., operation costs, integration costs, operation costs, data communication and / or storage costs, service costs and / or downtime costs, etc.) of a particular application.Accordingly, where the present disclosure refers to vehicles, vehicle systems, mobile applications, industrial equipment, robot systems, and / or manufacturing systems, each of these is also considered herein and, as understood by those skilled in the art having the advantage of the present disclosure, may be applicable in certain embodiments or not applicable in certain other embodiments.

[0086] As used herein, flows should be understood broadly. Exemplary flows include related data groups (e.g., speed data, temperature data, audiovisual data, navigation data, etc.), related functions (e.g., among vehicle functions, service operations and / or external vehicle functions such as data collection, aggregations between related vehicles, and / or combinations thereof related for a specific system), related devices (e.g., door actuators), and / or related applications. As used herein, flows provide an organizational concept that can be utilized to associate specific data, specific endpoints, specific applications, and / or related functions of or separate from the vehicle. In specific embodiments, a controller may utilize flows to identify data sources, data destinations, permissions available to the flow, priority information associated with the flow, etc., to implement specific data regulation operations as described herein. In specific embodiments, the utilization of flows enables the controller to perform separate operations that may involve the same endpoints to support desired network management. For example, a vehicle speed management application may have a high priority, and a speedometer endpoint may be associated with the vehicle speed management application. In the example, if the vehicle speed is being communicated to support the vehicle speed management application, the controller applies a high priority to the vehicle speed message. However, if the vehicle speed is being communicated to support the travel planning flow (e.g., if the travel planning flow exists and does not have a high priority), the controller may apply a lower priority to the vehicle speed message.In an additional example, a failure of the vehicle controller, a portion of the network, or other abnormal conditions may result in the vehicle speed management application being migrated to another controller within the system, thereby communicating vehicle speed messages to support the vehicle speed management application (e.g., if a backup controller is located on a different network), and the controller may apply higher priority to the vehicle speed messages. By utilizing flows and applications to organize the components of the system, identical or similar information can be regulated in a differential manner by the controller to support various functions, which enables improvements in the performance and security of network regulation operations (e.g., reduction of unnecessary cross-network traffic and provision of information only when necessary) and supports additional functionality compared to conventionally known systems, such as redundancy support, distributed control, and granular cross-network messaging.

[0087] As utilized herein, a policy includes a description of the data to be collected, such as data parameters, collection rates, resolution information, and priority values ​​(e.g., ordering of data collection values ​​for selection in response to abnormal conditions where not all data collection parameters can be served). In certain embodiments, the policy further includes event information, which may be defined as parameter or quantitative-based events (e.g., a given data value exceeding a threshold) and / or categorical events (e.g., a specific fault code, operating condition or state, or vehicle location / jurisdiction occurring). In certain embodiments, the policy further includes event responses, such as data values ​​to be captured in response to an event occurrence, and / or other changes to the data collection method, such as increased or decreased data collection rates, changes in collected resolution, etc. In certain embodiments, the event response further includes a time frame associated with the occurrence of the event, for example, a time period after the occurrence of the event to utilize a controlled data collection method, and / or a time period prior to the occurrence of the event (e.g., utilizing a rolling buffer or other data collection operation to provide temporary information that can be captured after the event occurs). In certain embodiments, changes to the data collection method for the event may include a number of changes—e.g., changes over a period of time, additional changes based on the progression of the event (e.g., when the event severity worsens), and / or criteria for determining that the event has been resolved. In certain embodiments, changes to the data collection method may be implemented based on the event-related resolution of the same or another event, for example, until the next shutdown event of the vehicle, until a service technician resolves the event, or until a selected number of shutdown events have occurred.

[0088] In this specification, the use of a policy refers to a partial policy and / or a parsed portion of a policy, for example, an implicit policy to be implemented in response to a single data collection method from a single user, wherein one or more partial policies are aggregated, after which the full policy is prepared, verified, and communicated to the vehicle. In this specification, the use of a policy may refer to an unverified policy, for example, after a policy responding to multiple users is aggregated, where the verification operations of the policy have not yet been completed (e.g., before it is determined whether data collection implied by the policy can be performed). In this specification, the use of a policy may refer to a previously applied policy (e.g., a policy existing in the vehicle before an updated version of the policy is communicated to the vehicle or implemented in the vehicle). In this specification, the use of a policy may refer to an updated policy, for example, a verified policy that is waiting to communicate to the vehicle (102) or is being verified by the vehicle (102) (e.g., from the data collection controller (202)).

[0089] Without limitation to any other aspects of the present disclosure, exemplary embodiments of devices described throughout the present disclosure, including circuits, controllers, computing devices, modules, engines, configurable switches, configurable gateways, convergent network devices, managers, evaluators, generators, applications, and other similar terms, comprise: any sensor present in a vehicle and / or a communication coupling to such sensor (e.g., electrical interface, LIN interface, A / D processing of sensor signals, etc.); any actuator present in a vehicle and / or a communication coupling to such actuator (e.g., electrical interface, LIN interface, command interface to the actuator, feedback interface from the actuator, etc.); any controller and / or computing device on a vehicle, a cloud server, an external device, etc., comprising processing resources, storage resources, I / O resources, and / or communication resources; instructions stored on a computer-readable medium—in which the instructions are configured so that a computing device executing the instructions thereby performs one or more operations of the device—; and / or includes one or more direct (e.g., accessing a parameter from a controller's memory value or inserting a command value into a controller's memory value) or indirect (e.g., accessing a parameter on a vehicle's network zone, providing a command value to a controller on a vehicle's network zone, transmitting requests or commands to a vehicle's controller, accessing parameters, transmitting commands, and using an interface to configure features, sensors, actuators, and / or control actions) access to any one or more of these.

[0090] Descriptions of this specification referring to fault codes should be understood broadly and include operations based on the following: fault code values ​​(e.g., determined by control operations, provided by related devices such as sensors, actuators, etc., and / or determined from other parameters such as diagnostic algorithms, reasonableness checks, comparisons with other data values, etc.); fault counters (e.g., managing data used for fault determination, such as increasing or decreasing counters); diagnostic values ​​(e.g., outputs of diagnostic operations such as "PASS", "FAIL", "SUSPECT", etc., and / or intermediate values ​​that may indicate a preliminary indication of abnormal operation even when the diagnostic operation has not yet diagnosed a fault, and / or intermediate values ​​that may indicate a preliminary indication that the diagnostic operation is returning to normal even when the diagnostic operation has not yet determined that the abnormal operation has been resolved); and / or diagnostic trouble codes (e.g., as parameters used to indicate diagnostic events and / or states, which may be industry standard codes, proprietary codes, or any other diagnostic trouble codes).

[0091] Without limitation to any other aspects of the present disclosure, the term "vehicle operating condition" as used herein should be understood broadly and may include categorical and / or discrete values ​​such as state conditions (e.g., shutdown, moving, starting, idling, high-load operation, low-load operation, etc.). Additionally or alternatively, exemplary vehicle operating conditions may be quantitative and / or continuous values ​​such as power throughput levels, torque values, vehicle speed, etc.

[0092] Referring to FIG. 1, an exemplary system is disclosed having a vehicle (102) communicably coupled to an external device (104). The exemplary system includes external device(s) (104) communicably coupled to one or more user devices (106). For example, the vehicle (102) may include a mixed network having a plurality of data providing devices coupled to network(s) on the vehicle, for example, one or more devices coupled to a CAN network and one or more other devices coupled to an Ethernet network. The exemplary system allows users (e.g., application providers, fleet owners, manufacturers, customers, etc.) to access the external device (104) to configure data collection to be implemented from the vehicle (102) to the external device (104). In additional examples, the system allows access to at least a portion of the collected data for use in applications related to the vehicle. In certain embodiments, the system provides authorization controls for users and / or applications to ensure that data collection requests are properly made. In certain embodiments, the system provides data collection controls to ensure that requested data communications are achievable and consume achievable or reduced data communication resources. In certain embodiments, the system provides consent implementations to ensure that appropriate consent is provided (e.g., from the driver or owner of the vehicle) before the relevant data collection is performed. In certain embodiments, the system isolates specific vehicle information (e.g., data parameter names, communication protocol information, locations and / or ID values ​​of data providers in the vehicle's mixed network environment) from data requesters and / or users, thereby reducing the burden on data requesters and / or users to learn specific vehicle information or keep such information up to date.In certain embodiments, the system isolates stored data collected from a vehicle from a system that provides requested data to applications utilizing portions of the data. In certain embodiments, the system provides and / or provides integrated policy management that controls data collection parameters from multiple concurrent data requesters, or provides enhanced policy management controls to specific users, such as policy generators and / or policy controllers. In certain embodiments, the system provides enhanced policy generation and / or updates, thereby communicating with the user in a structured manner to provide high-level functionality descriptions to the user without requiring the user's knowledge of the specific vehicle and / or specific data utilized to support the corresponding high-level functionality. In certain embodiments, the system provides enhanced data communication with the vehicle in response to intermittent network access and / or intermittent network bandwidth availability to communicate requested data from the vehicle to an external device.

[0093] Referring to FIG. 2, an exemplary vehicle (102) is schematically illustrated having specific aspects of the data collection system described herein. The exemplary vehicle includes a data collection controller (202) configured to accept a policy from an external device (104) and to propagate functionality to internal devices to perform appropriate data collection in response to the policy. The exemplary data collection controller (202) further communicates the collected data to the external device (104) and / or manages communication in response to intermittent network availability and / or intermittent network bandwidth availability. Specific additional and / or more detailed operations of the data collection controller (202) are described in the part of the disclosure with reference to FIG. 5a, FIG. 5b, and FIG. 10.

[0094] An exemplary vehicle (102) further comprises an inter-network switch (204) communicably coupled to at least two networks on the vehicle (102). The exemplary inter-network switch (204) is directly coupled to a plurality of devices (or endpoints) (210) on a first network (or network zone) and, for example, is coupled to a second number of devices (or endpoints) (208) on a second network (or network zone) through communications with an edge gateway (206). Specific additional and / or more detailed operations of the inter-network switch (204) are described in the part of the disclosure referring to FIGS. 5A, FIGS. 5B, and FIGS. 7. Specific additional and / or more detailed operations of the devices (210) are described in the part of the disclosure referring to FIGS. 5A, FIGS. 5B, and FIGS. 8. Specific additional and / or more detailed operations of the edge gateway (206) are described in the part of the disclosure referring to FIGS. 5A, FIGS. 5B, and FIGS. 6.

[0095] An exemplary vehicle (102) further comprises a user consent controller (212) communicably coupled to a data collection controller (202) and / or an external device (104). In certain embodiments, the user consent controller (212) may be an in-vehicle device such as a vehicle display (e.g., a PAD or a console device), and / or the user consent controller (212) may be a mobile application (e.g., a user’s mobile device having a consent application that can operate thereon), a web-based application (e.g., a web application accessible to the user and associated with the vehicle (102)), and / or may include one or more of these. Specific additional and / or more detailed operations of the user consent controller (212) are described in the portion of the disclosure referring to FIGS. 5A, FIGS. 5B, and FIGS. 9. In the example of FIGS. 2, external communications (214) are illustrated, which may include communications to the external device (104). External communications (214) may be transmitted wirelessly (e.g., by communicating with a data collection controller (202) and / or a user consent controller (212) from an available transceiver on the vehicle), and / or transmitted via wired communication (e.g., a service tool, OBD device, etc. coupled to a network on the vehicle as a device (210) communicating with an inter-network switch (204).

[0096] Referring to FIG. 3, an exemplary out-of-vehicle device (104) is illustrated. The exemplary out-of-vehicle device (104) is schematically illustrated as an integrated device having managers and other components illustrated thereon to illustrate the interaction of the functional elements of the out-of-vehicle device (104). The out-of-vehicle device (104) may be a distributed device having aspects present in a number of controllers, transceivers, servers, etc. In certain embodiments, the out-of-vehicle device (104) may be implemented at least partially as a cloud-based device and utilize or communicate with web-based and / or cloud-based services, such as, for example, Amazon Web Services (AWS), Microsoft Azure web services, Cloudflare network services, etc. In certain embodiments, aspects of the out-of-vehicle device (104) may be separated and / or distributed across one or more services, dedicated servers, and / or computing devices. In the example of FIG. 3, the first partition (302) performs specific operations of the out-of-vehicle device (104) and interfaces with the second partition (304) which performs specific other operations of the out-of-vehicle device (104). The example of FIG. 3 illustrates a partition (306), and communications across the partition (306) may be configured to conform to interface specifications or other agreed or implemented communication methods.

[0097] An exemplary partition (302) includes a network manager (312) that performs load management functions and manages communication with the vehicle (102). An example of FIG. 3 illustrates policy communications (316), consent communications (314), and data communications (318) that communicate at least intermittently with the vehicle (102). The exemplary network manager (312) interfaces with the data communications (308) component and, for example, transmits received vehicle data to the data communications (308) component. The exemplary network manager (312) interfaces with the vehicle policy communications manager (310) and, for example, receives data collection policies, policy updates, or provides consent communications between the vehicle policy communications manager (310) and the vehicle (102). In certain embodiments, the vehicle policy communications manager (310) receives policies processed from the policy manager (330) (and / or the vehicle data request manager (342)) on the second partition (340) and determines the timing for making the policies available to the vehicle (102) and / or communicating the policies to the vehicle.

[0098] An exemplary vehicle data request manager (342) determines the data to be collected in response to a policy provided by a policy manager (330). In certain embodiments, the policy includes multiple data requests from users (e.g., devices (106) and / or internal applications (334)), and the vehicle data request manager (342) aggregates the requested data into a set of specific parameters for data collection that satisfies the data collection needs of all data requests within the policy. In certain embodiments, the policy manager (330) and / or the vehicle data request manager (342) perform policy verification to ensure that the given policy can be supported (e.g., whether the requesting user is authorized, whether the parameters are available in the vehicle, and / or whether aggregated data collection to satisfy the policy can be achieved within available bandwidth limits) before the vehicle data request manager (342) provides the data requests to the vehicle policy communications manager (310). In certain embodiments, the aggregated data collection set is stored in a data structure such as an XML structure, a JSON data structure, an HTML data structure, or another selected data structure. In certain embodiments, the aggregated data collection set containing the relevant data structure includes a policy to be transmitted to the vehicle (102). In certain embodiments, the data structure to be transmitted to the vehicle (102) includes, as part of the policy, other information such as event descriptions, priority information, and / or response information to abnormal conditions such as intermittent network availability.

[0099] The embodiments of the present disclosure provide systems, apparatuses, and methods for providing a service-oriented architecture (SOA) and the management of SOA features and functions. The SOA embodiments of this specification may support a number of types of services, such as data services and / or functional services. The SOA embodiments of this specification may support a number of types of service participants, including but not limited to manufacturers, original equipment manufacturers (OEMs), customers, drivers, owners, service personnel, fleet managers (e.g., service, dispatch, compliance, etc.), SOA service requesters, SOA service providers, and / or third-party applications. The embodiments of this specification may support SOA operations across a number of networks, including one or more vehicle networks, vehicle networks having mixed network types, external networks, and / or cloud-based networks. The embodiments of this specification may support a plurality of network protocols, and the plurality of network protocols may include network protocols for devices or participants as SOA service providers and / or SOA service requesters, and may include, for example, at least SOME / IP, MQTT, HTTP, CAN, LIN, FlexRay, MOST, TTP, and / or LVDS network protocols. The embodiments of this specification may support reliable, secure, and convenient SOA service implementations, including service discovery, recovery, maintenance, and / or updates for available services that are provided and / or provided or requested.

[0100] As utilized herein, an exemplary policy includes a policy provided by an external device that requests the vehicle to collect a data set for a defined period or a short period and to retransmit the data to an external device. The data may be retransmitted to the external device within a defined time period specified in the policy and / or according to a base time period for such policy actions, and may include retransmitting the data to the external device as soon as data collection is completed. An exemplary policy may be deleted, removed, or otherwise deemed completed after a data collection event and / or after a successive number of data collection events. Such a policy may be referred to as an ad hoc policy, a one-time policy (which may include one or more finite data collection events), an improvisational policy, a single-use policy, an emergency policy, etc. Exemplary uses of such policies include rapid response data collection (e.g., handling of emergency events; collection of information to prepare for updates, campaigns, or other planned changes for multiple vehicles; collection of data sets to train models or artificial intelligence components; and / or data collection under any circumstances where the use of the data is expected to be performed within a finite period and continuous data collection for the policy is not required).

[0101] As utilized herein, an exemplary policy comprises a policy provided by an external device requesting the vehicle to collect data sets over a long period and / or continuously, and the collected data is retransmitted to the external device periodically and / or intermittently at intervals that enable enhanced utilization of bandwidth by selecting and / or allowing compression operations on the data to reduce the volume of communicated data. The exemplary policy may be maintained for a defined period, maintained until removed by the external device, and / or maintained until an event occurs (e.g., as a research data collection operation, the event is configured to determine that the vehicle is no longer relevant to the research). Defined period and / or event parameters for deleting the policy may be defined within the policy. Exemplary uses of such policies include research projects, continuous improvement projects (e.g., development of diagnostic or predictive algorithms for vehicles or related groups of vehicles, continuous improvement of operational algorithms, etc.), continuous analysis projects (e.g., detecting trends, detecting changes within related groups of vehicles, and / or analyzing large data sets to verify that changes to related groups of vehicles have the expected effects), and / or projects where the time constant of the project output is longer than the data rates typically received from low-utilization data transmission operations. Such policies may be referred to as research policies, analysis policies, non-urgent data policies, etc.

[0102] As utilized herein, an exemplary policy includes a policy provided by an external device that requests the vehicle to collect a data set over a long period and, as data is collected, to transmit the data back to an external device of the vehicle in a streaming manner, into defined data blocks as each data block is collected. An exemplary policy may be maintained for a defined period, maintained until removed by the external device, and / or maintained until an event occurs (e.g., a change in an algorithm or process utilizing data, such as when the data utilized by the algorithm or process changes, when the algorithm or process is interrupted, or when the algorithm or process is replaced by an updated algorithm or process, etc.). Defined period and / or event parameters for deleting the policy may be defined within the policy. Exemplary uses of such a policy include real-time monitoring of vehicle conditions, implementation of diagnostic or predictive algorithms for a vehicle or a related group of vehicles, and / or projects where the time constant of the project output is sufficiently short that underutilized data transmission operations are insufficient to support the project or support the project at an acceptable performance level. Such a policy may be referred to as a real-time monitoring policy, an emergency data policy, an immediate data policy, etc.

[0103] The first partition (302) further includes a data store (320) which may be a raw data store that stores data provided by the data communications (308) component. The data store (320) keeps the data separated from the second partition (304) until the collected data is requested, thereby separating the risk arising from the data storage. For example, the first partition (302) may be controlled / controlled or operated by the first entity, and the second partition (304) may be controlled / controlled or operated by the second entity, and accordingly, the partition (306) separates the risk associated with the data storage. In certain embodiments, the data store (302) stores the data in an encrypted format, which may be further configured so that the first entity operating the first partition (302) cannot access the data values ​​of the stored data. In certain embodiments, the data storage (302) stores data associated with metadata values, such as vehicle information, timestamps, data category descriptions, etc., so that appropriate data can be supplied in response to a data request by the data request / processing (322) component.

[0104] An exemplary second partition (304) further includes a consent manager (332) that determines whether consent is required for data values ​​within a policy and communicates with a user consent controller and / or consent application (402) (see FIG. 12) to request and receive consent values. In certain embodiments, an application authorization data store (328) is used to store consent information, such as consent confirmations for current policies, pending policies, etc. The application authorization data store (328) may be further used to determine authorized policy aspects (e.g., data parameters, sampling rates, event values, and / or use case values) according to other authorization methods that are authorized and / or utilized by specific users, user roles, and applications (402).

[0105] An exemplary second partition (340) further includes a policy manager (330) that receives inputs from users and / or applications to determine requested policies, policy updates, policy changes, etc. In certain embodiments, the policy manager (330) interfaces with user devices (106), external applications (402), and / or internal applications (334) through an API engine (326) to determine requested data collection, events, priorities, etc., to be used to determine policies. In certain embodiments, a user or application may provide the requested policy to the policy manager (330) as a data structure, for example, a formatted data XML, JSON, HTML, or other data structure containing formatted descriptions of the requested policy elements.

[0106] In certain embodiments, the policy manager (330) provides a user interface to a user or application to provide rapid, convenient, and / or reliable formatting of policy requests. For example, the policy manager (330) interfaces with the application or user may provide a list of data elements available in the system, predetermined event values, and / or predetermined response values. In certain embodiments, the list may include interface elements such as drop-down lists, checkboxes, or other interfaces that allow for rapid selection of requested elements and ensure proper formatting of requested elements. In certain embodiments, user and / or application authorization of requested elements may be performed during the configuration or input of requested policy elements—for example, the policy manager (330) may hide unauthorized elements, display unauthorized elements in an alternative format (e.g., grayed out), and / or provide a warning or notification that unauthorized elements are included in the currently requested policy elements. In certain embodiments, the policy manager (330) may allow unauthorized elements in a policy request (and / or skip the pre-screening of authorization), and the policy manager (330) will refuse to create a policy based on a policy request if unauthorized elements still exist at the time of verifying the integrated policy for update (e.g., integrating multiple policy requests from various users and / or applications into an integrated policy). In certain embodiments, the policy manager (330) may notify a user or application (e.g., a policy generator, a policy controller, a super-user, etc.) of a failure to verify a policy request due to the inclusion of unauthorized data requests, excessive communication bandwidth requirements, or other reasons.In certain embodiments, the policy manager (330) can identify which element of the policy request caused the validation failure, and / or can provide options to the notified user or application, such as communication to the user or application that made the unauthorized request, or options to authorize the unauthorized request.

[0107] In certain embodiments, the operations of the policy manager (330) include compiling multiple policy requests from users and / or applications (internal or external) into a unified policy structure. In certain embodiments, the policy manager (330) (and / or vehicle data request manager (342)) may provide the unified policy structure as a superset of data requests (e.g., unifying data requests for a given parameter) and may further unify event requests and / or event responses if such unification can be consistent with achieving events and responses within individual policy requests. In certain embodiments, the policy manager (330) may include consideration of the data superset in determining event responses—for example, if an event requests data to be taken in response to the event, but the data is already being collected for another request within the policy, the event may be omitted and / or the collected data may be reduced in consideration of data availability.

[0108] In certain embodiments, the policy manager (330) includes actions to verify the integrated policy structure, for example, to ensure that users and / or applications are requesting only authorized data, to ensure that data parameters requiring consent are obtaining consent (and / or communicating consent requirements to the consent manager (332) for appropriate action), and / or to ensure that the vehicle's network bandwidth capabilities, the vehicle's data storage capabilities, or other parameters can satisfy the requirements of the integrated policy structure. In certain embodiments, the policy manager (330) maintains an updated "live" verification, for example, to verify potential integrated policy structures as policy requests are received from users and / or applications. In certain embodiments, the policy manager (330) performs verification upon request, for example, by a policy generator, which may be performed as a "build" of a policy or policy update. In certain embodiments, the policy manager (330) utilizes a default policy, for example, when the vehicle is first manufactured.

[0109] In certain embodiments, after the policy is verified, the policy manager (330) may communicate the policy to the vehicle policy communications manager (310) for communication with the vehicle (102). Additionally or alternatively, the policy manager (330) may communicate the policy to the vehicle policy communications manager (310) in response to a request from a policy generator, a super-user, or other authorized system user.

[0110] In certain embodiments, the policy manager (330) or other system components may access the policy data store (340), which may include GUI parameters such as previously verified policies, legacy policies, one or more default policies, and / or generic names for data elements, user role descriptions, application role descriptions (sets of event values, event responses, and / or data values ​​available based on application roles such as OEM, manufacturer, third party, etc.), exemplary event values ​​and / or event responses, and / or vehicle data (e.g., nominal bandwidth descriptions, stored information, etc.).

[0111] In certain embodiments, the policy manager (330) provides a high-level description to the user or application, which may be referred to as a "use case" in certain embodiments. A use case may include one or more data collection elements, such as a group of parameters to be collected, and / or may additionally include one or more associated events and / or event responses. The selection of a use case may be utilized to quickly configure a policy request having information that is predetermined accordingly. The use cases presented to the user may be stored in the data store (340) and / or may vary depending on the roles and / or authorizations of the user and / or application. In certain embodiments, the use cases may have identifiable or generic names, such as "routing application use case," "passenger car standard use case," "delivery vehicle use case," etc. The data store (340) may have available default use cases and / or may include use cases created or configured and / or made available by a policy generator, policy controller, super-user, etc. In certain embodiments, the user and / or application may have the ability to configure a policy request and store the request as a template, a standard group of data collection parameters, etc., as a use case for future implementation. In certain embodiments, the validation actions of the policy manager (330) may utilize the use case (e.g., utilizing a predetermined value regarding whether the use case is authorized or not authorized for a given vehicle, user, application, etc.), and / or the validation actions of the policy manager (330) may evaluate individual elements filled in response to the use case for validation. In certain embodiments, the data values ​​filled by the use case may be displayed to the user and / or application, or hidden from the user and / or application.

[0112] An exemplary second partition (304) further includes one or more internal applications (334) — applications created or implemented by, for example, an operating entity associated with the second partition (304). An exemplary second partition (304) further includes an application / user network manager (324), for example, which performs load balancing operations and uses a communication interface (338) to provide and / or receive communications from external applications. In certain embodiments, the application / user network manager (324) performs operations to implement a user interface or a graphical user interface with external users and / or applications.

[0113] An exemplary external device (104) implements consent communications (344), policy communications (346), and / or data communications (336) to manage communication between partitions (302, 304). The communications (344, 346, 336) may include standardized interfaces and / or protocols, for example, to enable a given partition (302, 304) to operate independently of updates or changes to other partitions.

[0114] The example in FIG. 3 illustrates two partitions (302, 304), but in certain embodiments, the vehicle device (104) may be an integrated device, and / or aspects of the partitions (302, 304) may have additional partitions, and / or have different distributions of components between the partitions.

[0115] Referring to FIG. 4, exemplary internal applications (334) and / or external applications (402) are illustrated. The present disclosure is not limited to the illustrated applications, and a given application may be provided as an internal application (334) or an external application (402). An example of FIG. 4 illustrates a plurality of user devices (106), which may be communicably coupled to a system via a network interface (406) that may include one or more aspects such as an internet connection, a mobile communication interface, a proprietary network interface, etc. A given user device (106) may interface with one or more applications (402), and a given application (402) may interface with one or more user devices (106). In certain embodiments, the application (402) may operate without an interfacing user device (106) (e.g., a data scraper, an AI component, etc.), and / or may operate while optionally interfacing with the user device (106) at certain times or operating conditions, and may operate independently of the user device (106) at other times or operating conditions.

[0116] Referring to FIGS. 5a and 5b, an exemplary vehicle network infrastructure for a vehicle (102) is schematically illustrated. The exemplary vehicle (102) includes an Ethernet switch communicating with a number of Ethernet-based devices (e.g., sensors, actuators, and / or controllers communicating with an Ethernet network), an edge gateway device (e.g., interacting with a second network such as a CAN or a second Ethernet network and providing parameters to a first network or an Ethernet network), a data collection controller, a number of Ethernet devices, and a user consent controller.

[0117] Referring to FIG. 6, an exemplary edge gateway (206) is illustrated. The exemplary edge gateway (206) includes a CAN data collection policy manager that receives data collection commands from a data collection controller. The CAN data collection policy manager directs the collection of CAN data from CAN devices (208) to support the data collection commands and provides Ethernet communication parameters to an Ethernet switch to support the data collection. The use of the edge gateway (206) supports mixed network operation and, in certain embodiments, allows an out-of-vehicle device (104) to operate without requiring knowledge of which devices exist on the CAN, Ethernet, or other networks. The exemplary edge gateway (206) further includes CAN processing components, such as a CAN IP component that interprets the CAN addresses of each CAN component (208), a CAN message receiver that interprets CAN messages and determines the data values ​​therein, and a CAN message filter that supports downsampling of CAN messages to reduce network traffic within the vehicle network while supporting policies, for example. For example, if parameters are provided over CAN at a rate of 20 ms but the policy requires only a 1 sec sampling rate for the parameters, the CAN message filter can remove excessive sampling of the message. In certain embodiments, other components may perform downsampling in addition to or instead of the CAN message filter. For example, an Ethernet switch and / or data acquisition controller may perform appropriate downsampling.The location of downsampling may vary depending on the details of the policy (e.g., if parameters may sometimes be sampled faster due to events, the CAN message filter may provide data at the highest rate that may be required, thereby causing another component to downsample when a higher rate is not required, and / or the CAN message filter may downsample appropriately based on the circumstances in response to events). An exemplary CAN gateway (206) further includes a CAN message capture, for example, to transmit and / or transmit CAN sampled data or to buffer CAN sampled data until it is transmitted. An exemplary CAN gateway further includes a CAN2Eth encapsulation component that encapsulates the captured CAN message into an Ethernet message (e.g., to include preceding and / or succeeding message data, and / or to package one or more CAN messages into a single Ethernet packet). An exemplary CAN gateway further includes an Eth IP component that communicates the encapsulated CAN messages to an appropriate address on an Ethernet network. In certain embodiments, messages are transmitted bidirectionally, for example, allowing a CAN data collection policy manager to receive appropriate parts of the current policy and an edge gateway to receive event data indicators (e.g., indicating that a given event has occurred). In certain embodiments, the mixed network may include network types different from the CAN-Ethernet mix and / or networks having distinct protocols (e.g., packet sizes, leading / shortening bits, etc.), wherein the edge gateway includes appropriate components accordingly.

[0118] Referring to FIG. 7, an exemplary Ethernet switch (204) is illustrated. The exemplary Ethernet switch (204) includes an Ethernet packet filter component and an Ethernet packet interceptor for, for example, performing downsampling and / or rejecting unnecessary packets (e.g., data responding to events provided by an Ethernet device and / or edge gateway during an operation period when no event is active). The exemplary Ethernet packet interceptor retrieves selected data from an Ethernet network. In certain embodiments, the Ethernet switch (204) performs operations such as port switching or other routing operations. The exemplary Ethernet switch (204) communicates with a data collection controller (202), an edge gateway (206), and one or more Ethernet devices (210).

[0119] Referring to FIG. 8, an exemplary Ethernet device (210) is illustrated. In certain embodiments, the Ethernet device (210) manages policy implementations associated with a specific device and utilizes an ECU policy manager (electronic control unit) that determines data transmission values ​​responding to the policy, including, for example, data rates, resolutions, and / or data responses to events. In certain embodiments, the ECU manager performs event detection (e.g., reads Ethernet parameters and determines whether an event is active). In certain embodiments, the ECU manager receives event statuses and manages only data transmission requirements responding to event statuses. The Ethernet device (210) further includes a data collector, which can downsample, adjust the resolutions of data values, and / or provide multiple data values ​​(e.g., provide multiple data values ​​within a packet and / or assign timestamps for later matching at a data collection controller (202) and / or an external device (104). An exemplary Ethernet device (210) further includes a data transmitter that provides packets to an Eth IP, wherein the Eth IP manages the addressing, transmission, and / or reception of the associated packets. The exemplary Ethernet device (210) may be associated with a specific component, for example, to control Ethernet communications that respond to policies for the associated component. Additionally or alternatively, the Ethernet device (210) may be part of a component (e.g., managing Ethernet communications for the component in addition to data collection aspects that support policies) and / or part of a controller associated with the component. The exemplary Ethernet device (210) communicates with an Ethernet network and / or an Ethernet switch (204).

[0120] Referring to FIG. 9, an exemplary user consent controller (212) is illustrated. The user consent controller (212) may be part of, and / or associated with, an in-vehicle user input device such as a console (e.g., a touchscreen interface) accessible to the vehicle driver. In certain embodiments, the user consent controller (212) may be omitted and / or may be in another part of the system, such as, an application for a mobile device, a web portal for a connected device, or another interface. For example, if the owner of the vehicle and / or associated data is separate from the driver, and / or for the driver's convenience, an alternative interface for consent communications may be provided. In one example, the driver utilizes a mobile device with an application installed to perform consent actions, and the consent action includes, for example, a login or authentication action confirming the association with the vehicle. In another example, an authorized owner or agent accesses the application or web portal—for example, a fleet manager having web-based access on a computing device and / or a mobile application associated with the vehicle. In certain embodiments, user consent may be provided for multiple vehicles within a single interface (e.g., a web application listing groups of vehicles) and / or as a single action (e.g., approving a policy update for a selected group of vehicles). In certain embodiments, a user consent application (e.g., see FIG. 4) may be used in conjunction with a user consent controller (212) or as an alternative to the user consent controller (212).

[0121] Referring to FIG. 10, an exemplary data collector controller (202) configured to have a plurality of components and to functionally execute the operations of the data collector controller (202) is schematically illustrated. The data collector controller (202) includes a vehicle OTA client (wireless communication) that receives policy updates, policies, and / or policy notifications from an out-of-vehicle device (104). The exemplary vehicle OTA client communicates the policies, policy updates, and / or policy notifications to a policy manager. In certain embodiments, policies may be provided from the out-of-vehicle device (104) via an MQTT broker (see FIG. 11), which causes the vehicle (102) to subscribe to policy updates and receive an immediate notification that an updated policy is available without requiring the entire policy to be communicated to the vehicle (102) until the vehicle (102) is in a condition to receive and / or implement the policy. In certain embodiments, the policy manager may download policy updates and store them for later implementation. In certain embodiments, the policy manager may order the download of the policy only when the vehicle (102) is in a condition to implement the policy (e.g., during shutdown operation, during normal operation, etc.).

[0122] An exemplary policy manager verifies the policy, and, for example, to ensure that the policy can be implemented, the policy manager (330) of the out-of-vehicle device (104) performs checks based on vehicle-specific information that may not be available. For example, if the policy requires data collection from a device where no policy exists, or requires network traffic that is not possible or otherwise does not comply with the requirements of the vehicle (on any network of the vehicle, through an Ethernet switch, or on some other component of the vehicle network), and / or requires a type of information that the vehicle (102) cannot provide (e.g., an unavailable sampling rate and / or resolution), the policy manager may reject the policy and / or provide a notification to the out-of-vehicle device (104) that the policy has been rejected. In certain embodiments, the policy manager may be configured to partially implement the policy, for example, to implement higher-priority data collection elements from one part of the policy and reject other lower-priority data collection elements, and / or replace a part of the currently implemented policy that has a lower priority than the higher-priority part of the updated policy. However, in certain embodiments The policy controller may be configured to accept or reject the new or updated policy as a whole. In certain embodiments, for example, if the policy manager cannot fully comply with the new or updated policy, the policy manager may be configured to communicate information regarding the partial implementation of the policy to the external device (104) (e.g., a flag indicating only partial compliance, and / or additional information such as which parameters are not being serviced, and / or the service level that is available or being provided instead).

[0123] In certain embodiments, the policy manager parses policy elements and communicates the relevant elements to policy managers across the system (e.g., to edge gateways, Ethernet switches, Ethernet devices, and / or other components having a data collection controller (202) as described below). An exemplary data collection controller (202) includes data receiver component(s) that receive data responding to a policy (and / or planned to respond when an event condition is detected) from an Ethernet network (e.g., by utilizing an Eth IP component) and / or from other components on the vehicle (102) (e.g., from a user consent controller). The data receivers provide the data to a preprocessing component, which can determine virtual sensor or modeled values, adjust data sample rates (e.g., perform filtering operations), adjust resolution values, etc. In certain embodiments, the preprocessing component may perform specific operations to support event detection, such as determining secondary state values ​​used to determine event states, or excluding or tagging data based on existing defect codes.

[0124] An exemplary data collection controller (202) includes a caching component that performs short-term data storage, for example, to allow parameter processing and / or to support information capture, such as rolling buffers, where an event can trigger short-term historical data recovery (e.g., a trigger indicating that historical data is desirable when an event is detected, such as an accident, component failure, etc.). The exemplary caching component may respond to commands from a cache controller, and the cache controller may receive parsed caching commands to support a policy and / or adjust caching operations in response to the current operating conditions of the vehicle (102). In certain embodiments, the size of the cache and / or other available storage may affect the ability of the data collection controller (202) to meet the requirements of the policy. For example, if a number of policy events provide significant consumption of cache memory, the policy manager may determine that the current configuration of the vehicle (102) cannot meet the policy. In certain embodiments, for example, multiple part numbers of cache components having distinct cache sizes exist within a group of vehicles, and / or vehicle-specific conditions exist (e.g., part of the cache memory is failed or otherwise unavailable), a policy manager having superior information about a specific vehicle compared to a policy manager (330) of an external device (104) may decide that a policy cannot be verified even if the policy manager (330) has approved the policy. In certain embodiments, a trigger condition evaluator receives parsed information representing event detection criteria from the policy manager, and the trigger condition evaluator determines which event conditions exist in response to the event detection criteria and cached and / or captured data.In certain embodiments, event detection may be performed in other components as described throughout this disclosure, such as in an edge gateway policy manager and / or an Ethernet device policy manager. In certain embodiments, the policy manager of the data collection controller (202) determines a device that has sufficient information available to perform the events detection operations and provides the parsed elements of the policy to the appropriate component. Accordingly, in certain embodiments, the trigger condition evaluator may refer to a status value indicating whether a given event condition has occurred, rather than performing direct detection of parameters used to determine whether an event has occurred. In certain embodiments, one device may perform primary event detection, and another component (e.g., a trigger condition evaluator) may perform secondary detection of the same event, providing a system that responds to detecting an event when, for example, the primary sensor indicating the event has failed but there is a backup sensor for detecting the occurrence of the event.

[0125] An exemplary data collection controller (202) includes a capture component that provides parameters for storage. In certain embodiments, the capture component responds to commands from a trigger condition evaluator, for example, commands indicating that a trigger condition (event) is active, and may retrieve additional information from a caching component to support the implementation of a policy (e.g., buffered values ​​available in the cache). An exemplary data collection controller (202) includes a storage component that stores captured data for transmission to an external device (104). An exemplary storage component utilizes non-volatile memory, such as flash memory, which allows stored data that is not transmitted in the event of a power loss event to be stored. An exemplary data collection controller (202) includes a storage controller that provides storage commands to a storage component to support the implementation of a policy and / or to support specific operating conditions of the vehicle (102), such as intermittent loss of network communication to an external device (104) and / or intermittent ability to communicate data to an external device (104) (e.g., when higher priority resources are utilizing available bandwidth, and / or when data communication limits exist, such as data plan limits). In certain embodiments, storage of data collection parameters is performed until the storage component is full, at which point some data is removed (e.g., oldest data, lowest priority data, and / or least utilized data). For example, if a first data element supports multiple policy requests and another data element supports only a single policy request, the storage controller may be configured to retain data that satisfies a higher proportion of available policy requests.In certain embodiments, data element responses to various policy requests may not be available in the data storage controller (202), and other criteria are utilized to determine which data will be removed or expired. In certain embodiments, some of the data to be removed may be additionally or alternatively compressed / compressed or summarized to reduce storage utilization. In certain embodiments, some of the data to be removed may be downsampled to reduce storage utilization. In certain embodiments, suitability for the compression, summarization, and / or downsampling of specific data elements (suitability may include the required consumption of processing power, the technical value of the data relative to the underlying data in the compressed, summarized, or downsampled format, or similar considerations) may be considered in determining commands from the storage controller in response to a full (or being filled) storage component. In certain embodiments, commands for compressing, summarizing, and / or downsampling data in response to a storage component that is full or being filled may be provided as part of a policy, and / or the policy may additionally include commands for techniques to be utilized for compressing, summarizing, and / or downsampling data when indicated. In certain embodiments, the policy may additionally include thresholds (e.g., storage value thresholds, time remaining until the storage is full, etc.) indicating when storage removal, compression, summarization, and / or downsampling operations are to be performed.

[0126] In certain embodiments, the storage controller is configured to support cache operations by utilizing a portion of the storage available in the storage component. In certain embodiments, the storage controller may be configured to determine the amount of storage available for use based on historical information, such as usage rates of the storage component over time and / or network availability for transmitting collected data to an external device (104). In certain embodiments, storage support for the caching component may be defined within a policy. In certain embodiments, storage support for the caching component may not be utilized. In certain embodiments, the availability of storage support for the caching component may be considered by the policy manager in operations that validate the policy.

[0127] In certain embodiments, the data collection controller (202) includes an encryption component configured to encrypt data to be transmitted to the out-of-vehicle device (104). In certain embodiments, the data collection controller (202) includes a compression component configured to compress data to be transmitted to the out-of-vehicle device (104). The compression may be lossy or lossless compression, and the compression type may be determined by the type of data, the technical value of the data after compression, and / or by policy. The data collection controller (202) further includes a transmission component configured to transmit the collected data to the out-of-vehicle device (104), and a transmission controller component for configuring the transmission, for example, supporting selected data protocols and mediating between competing transmission resources of the vehicle (102) (e.g., comparing relative data priorities for other transmission elements, scheduling transmissions according to data plans and vehicle operating conditions, and / or supporting virtual channels utilized in the transceiver). In certain embodiments, the transmitting controller responds to parsed elements of a policy representing data plan values ​​(which may differ between specific data elements — for example, when a first data element is associated with a first requester having a first data plan and a second data element is associated with a second requester having a second data plan), transmission priorities, and / or vehicle operation conditions associated with any of the above.

[0128] Referring to FIG. 11, an exemplary first partition (302) having a plurality of components configured to functionally execute the operations of the first partition (302) is illustrated. The exemplary first partition (302) includes a load balancing / proxy controller (312) (e.g., a network manager) configured to interact communically with a data collection controller (202). The exemplary load balancing / proxy controller (312) interacts by utilizing policy communications (1106), consent communications (1108), and data communications (1104) between the vehicle (102) and the out-of-vehicle device (104). The communications (1104, 1106, 1108) include primary data communications, authentications, confirmations, etc.

[0129] An exemplary first partition (302) further includes an http component (1102) configured to package received data into a selected data structure for storage (e.g., http in the example of FIG. 11). An exemplary first partition (302) further includes a data communications component (308) configured to package data for storage, and may further include an encryption engine for decrypting received data (e.g., utilizing a temporary vehicle key), a tokenization / anonymization component for replacing sensitive data recoverably with a token, and an encryption component for encrypting data with a master public key (e.g., where the data request / processing component (322) has a master private key), thereby preventing the first partition (302) from accessing the data values. In certain embodiments, the data communications component (308) associates the stored data with metadata so that a request from the data request / processing component (322) can be responded to with the corresponding data. An exemplary first partition (302) stores data in a raw data store (320) for access as authorized by internal applications (334) and external applications (402).

[0130] An exemplary first partition (302) further includes an MQTT broker that publishes an updated policy, thereby allowing subscribing devices (e.g., a data collection controller (202)) to receive notification that the updated policy is available. In certain embodiments, the first partition (302) may push the updated policies to a vehicle (102), and / or the vehicle (102) may periodically request whether the policy update is available, and / or request the policy updates in response to certain events (e.g., specific operating conditions, service events, network availability events, etc.).

[0131] Referring to FIG. 12, an exemplary second partition (304) includes a policy generator component (1202) for performing operations such as compiling, implementing, generating, and / or storing policies for use in a system, for example. In certain embodiments, the policy generator component (1202) is further configured to roll out policy updates, for example, to update policies for a small number of vehicles before sending policy updates to a larger number of vehicles. An exemplary second partition (304) further includes a data request / processing component (322) having a data processing engine that decrypts data received from the first partition (302) using a master private key, a reverse tokenization component that restores tokenized information within the received data, and an encryption component that re-encrypts the data with a temporary key for data sharing with an application and / or user device (if authorized) requesting the data. The example of FIG. 12 includes an internal application (334), such as a vehicle twin application operating for a corresponding vehicle (102), and a number of external applications (402), such as a vehicle twin dashboard, a third-party application (any type), a mobile application, a web-based application, a user consent application, and / or a policy generator user interface.

[0132] An exemplary second partition (304) further includes an application registration portal and application approval workflow component (total—1204) for interfacing with applications and proposed applications to ensure proper authorization and to enforce application standards, etc. The application registration portal and application approval workflow component (1204) further interacts (1206) with an application authorization database (328) to record application registrations and ensure authorization of applications accessing them.

[0133] Referring to FIG. 13, an exemplary cloud system (11400) for retrieving selected data from a vehicle and / or separating access to stored collected data and data is illustrated. The example in FIG. 13 is described as a cloud-based system (11400) for clarity of description to illustrate aspects of the present disclosure. However, operations of the system (11400) may additionally or alternatively be performed in any system configuration outside the vehicle. For example, operations may be performed wholly or partially by a service tool, a manufacturing tool, a computing device at least optionally coupled to the vehicle for communication, or other configurations described herein. The exemplary system includes an external device coupled to the vehicle using a cellular data connection, a WiFi connection, a physical port connection to the vehicle's network zone, a Bluetooth connection, and / or any other connection understood in the art, whether or not it is a cloud-based system. The operations of in-vehicle network zone connection devices, such as CES, CEG, and / or CND, enable a connection to any network zone of the vehicle to be utilized to receive, configure, and / or update policies to be implemented in the vehicle, and to transmit collected data. In certain embodiments, aspects of the system (11400) may be implemented in the cloud, and other aspects may be implemented on another external device.

[0134] An exemplary system (11400) includes a request interface (11402) configured to interpret a plurality of response action values ​​(11404) from an external device (11424). The response action values ​​(11404) include, without limitation, one or more of the following: data values ​​for collection (e.g., requested data to be collected from a vehicle); trigger conditions for conditional actions (e.g., data values ​​to be observed for characteristics indicating a trigger event, such as those determined by thresholds, processed responses such as a rate of change of value, triggers based on multiple values, status values ​​such as "ON", "OFF", "ACTIVE", and / or mode values ​​such as indications of operation mode, control operation status, etc.); time frames for data collection (e.g., calendar time; operation time relative to the vehicle; time-based amount of data to be collected—e.g., 3 minutes of data; time relative to event detection or trigger conditions, such as starting 5 minutes after the event, or 3 minutes of data prior to the event, etc.); Priority information to be attributed to any of the foregoings; sampling rates for data values; formatting for data values ​​(e.g., parameter units, bit depth, metadata descriptions, etc.); and / or data types to be associated with data values. In certain embodiments, response action values ​​(11404) may be provided by a user selection of pre-configured values—for example, the user may select "vehicle speed" to be included as a response action value (11404). In certain embodiments, aspects of response action values ​​(11404) that are not authorized for the user to request may be hidden from the user—for example, by not providing such values ​​to a user interface operating on an external device (11424).In certain embodiments, aspects of response action values ​​(11404) that are not authorized for the user to request may be annotated—e.g., with grayed-out text—to inform the user that such values ​​are generally available but are not available with the user's current permissions. In certain embodiments, aspects of response action values ​​(11404) are presented to the user, and authorization is enforced by a policy generator circuit (11406), for example by excluding values ​​from the final data collection policy (11408) and / or by excluding the entire set of response action values ​​(11404) from the final data collection policy (11408).

[0135] In the example of FIG. 13, the response action values ​​(11404) represent defining actions for data collection, trigger evaluation, and / or automatic actions of the vehicle, whereas the vehicle data requests (11422) represent requests to access the response vehicle data (11418) collected in response to the response action values ​​(11404). The terms used herein are exemplary and non-limiting.

[0136] Actions for creating a data collection policy (11408) having excluded values ​​may include a notification to the user that the requested response action values ​​(11404) are not authorized. In certain embodiments, a notification to the user that the requested response action values ​​(11404) are not authorized in response to a submission attempt by the user—for example, to allow the user to identify which aspects of the response action values ​​(11404) are preventing submission and to allow the user to adjust the response action values ​​(11404). In certain embodiments, a combination of these actions is utilized in an interface—for example, to completely hide some unauthorized parameters from the user (e.g., highly sensitive parameters available only to specific users) and to display some unauthorized parameters to the user. Additionally or alternatively, some parameters may be available in response to additional authorization—for example, an administrator or supervisory user of an entity may have authorization to authorize specific parameters as response action values ​​(11404), and another user of the entity requesting specific parameters may receive a notification requesting authorization, and / or the administrator or supervisory user may receive a notification that one or more of specific parameters have been requested. Additionally or alternatively, some parameters may be available based on a subscription, a specific version of a user interface (e.g., standard version versus premium version of a web portal, local application, mobile application, or similar), and the interface may prompt the user to acquire authorization features (e.g., subscription, or updated interface version), and / or notifications associated with the parameters may indicate the features required to access the parameters.In certain embodiments, certain parameters may be available based on access characteristics—e.g., insecure access to the interface and / or partial login operation to the interface (e.g., when a password has been entered but the second step of two-factor authentication has not been completed)—wherein the request interface (11402) may optionally hide parameters that are unavailable based on access characteristics and / or mark parameters as disabled in the interface.

[0137] In certain embodiments, the request interface (11402) is configured according to an external device, an associated entity, and / or a user type and user goal associated therewith. For example, the request interface (11402) for interaction with a vehicle owner and / or a third-party application developer may be simplified and may use selections from menus, utilize templates, and / or allow selection of data collection parameters with more limited capabilities. In another example, the request interface (11402) for interaction with a professional developer, such as a manufacturing entity or fleet owner, may include convenient interfaces and allow direct submission of completed policy data structures (e.g., HTML files, XML files, delimited files, binary files, etc.), or a combination thereof (e.g., building an initial data structure based on menu interactions and selections, and allowing access to the source file generated by this for direct editing and submission).

[0138] In certain embodiments, the user device (11424) for providing response action values ​​(11404) and the user device (11424) for providing vehicle data requests (11422) may be different devices and / or may have access to separate interfaces (11402). In certain embodiments, the first user providing response action values ​​(11404) and the second user providing vehicle data requests (11422) may be different users, users associated with different entities, and / or completely unrelated. For example, a third-party application developer may provide the response action values ​​(11404), and the vehicle data requests (11422) may be provided by the vehicle owner. In certain embodiments, multiple different users may have access to the response vehicle data (11418).

[0139] In the example of FIG. 13, the system (11400) is illustrated with a first cloud boundary to an external device (11424) and a second cloud boundary to a vehicle (11426), and the cloud system is located between them and includes a request interface (11402), a policy generator circuit (11406), a raw data management circuit (11416), and a cloud interface circuit (11412). In certain embodiments, one or more aspects of the cloud system, or all aspects of the cloud system, may be located separately from the cloud system, for example, the aspects may be located on the vehicle (11426), another external device, or a combination thereof. Additionally or alternatively, aspects of the cloud system (11400) may be provided as internet-based aspects, web portals, mobile applications, etc. An exemplary request interface (11402) includes more than one option for interfacing with a cloud system, such as a first interface operating as a web portal, another interface operating as a mobile application, another interface operating on a tool (e.g., service tool, manufacturing tool, etc.), and / or another interface on an external device (11424) operating a local application on the device. In certain embodiments, the capabilities available for interacting with the cloud system may vary depending on the interface used for interaction (e.g., a service tool having capabilities distinct from a mobile application), the entity associated with the user exercising the interface (e.g., a third-party application provider, manufacturer, dealer, vehicle owner, etc.), and / or the type of interaction with the cloud system (e.g., web portal access having capabilities distinct from a manufacturing tool directly coupled to the vehicle's network zone).Additionally or alternatively, interactions with the cloud system may utilize verification and / or authorization, for example, by exercising a login interface, or by utilizing encrypted communications between the cloud system and external devices, between the cloud system and the vehicle, and between components of the cloud system. In certain embodiments, cloud system components may be separate devices—including physically separate devices and / or logically separated devices. For example, the request interface (11402) may be implemented on a device (or group of devices) separate from the raw data management circuit (11416). In another example, a portion of the request interface (11402) may be at least partially included on an external device and / or on the vehicle.

[0140] An exemplary system (11400) includes a policy generator circuit (11406) that determines a data collection policy (11408) in response to response action values ​​(11404), and the data collection policy (11408) includes a vehicle data identifier (11410). In certain embodiments, the policy generator circuit (11406) compiles one or more response action values ​​(11404) from one or more users into a data collection policy (11408), for example, to generate a single compiled data structure representing the policy, and / or provides a plurality of distinct data structures representing the policy. In certain embodiments, the policy generator circuit (11406) checks for authorization of parts of the policy according to the entity, user, application, flow, etc., providing each part. In certain embodiments, the policy generator circuit (11406) checks the capability of the policy and determines, for example, whether the vehicle's data storage resources, processing resources, parameter availability, and / or transmission resources can service data collection or other operations in response to the policy. In certain embodiments, the policy manager on the vehicle further performs an authorization and / or capability check of the policy provided to the vehicle and, for example, provides a confirmation to the cloud interface circuit (11412) if the policy is accepted and provides a notification to the cloud interface circuit (11412) if the policy is rejected.

[0141] An exemplary cloud interface circuit (11412) — configured, for example, to access a vehicle — is configured to receive identified vehicle data (11414) collected in response to a data collection policy (11408). The vehicle data identifier (11410) may be specifically identifiable information regarding a vehicle — for example, a vehicle identification number (VIN), a serial number, a media access control (MAC) address from a designated controller of the vehicle, or something similar, and / or identifiable information that ensures the identified vehicle data (11414) can be matched to a vehicle and / or vehicle data request (11422). An exemplary vehicle data identifier (11410) includes a session identifier (e.g., identifying a data collection “session” and / or a data collection instance and linked to a block of collected data provided in response to a data collection policy (11408)) ― as a unique identifier attached to the vehicle data (11414) identified, for example, included in the data collection policy (11408), allowing identification of the response vehicle data (11418) separately from other information such as personal information regarding the vehicle owner, identification of a specific vehicle associated with the data, etc. In certain embodiments, the vehicle data identifier (11410) utilized in a specific data collection policy (11408) may vary depending on the type of policy (e.g., a continuous policy may utilize a first type of identifier, and a discrete and / or streaming policy may utilize a second type of identifier), and / or may vary depending on the importance of a particular system to keep identification information separate from the response vehicle data (11418).

[0142] An exemplary raw data management circuit (11416) stores at least a portion of the received identified vehicle data (11414), at least a portion of the identified vehicle data including response vehicle data (11418) and identification data (11420). The identification data (11420) may be the same as or different from the vehicle data identifier (11410). In certain embodiments, the response vehicle data (11418) may be encrypted separately from the identification data (11420), thereby enabling the raw data management circuit (11416) to provide the correct response vehicle data (11418) by comparing the relevant identification data (11420) without accessing the response vehicle data (11418). The separation of response vehicle data (11418) enhances the separation of the risk of data breaching, wherein improper access to a single aspect of the cloud system does not allow the response data (11418) to be matched with identification information such as owner name, specific vehicle, etc. Exemplary identification data (11420) includes metadata specific to a specific set of response action value(s) (11404).

[0143] An exemplary request interface (11402) interprets a vehicle data request (11422) and retrieves at least a portion of the response vehicle data (11418) from a raw data management circuit (11416) in response to the vehicle data request (11422). The exemplary request interface (11402) provides the retrieved data to an external device (11424).

[0144] An exemplary system (11400) includes response vehicle data (11418) encrypted using a first encryption key set and identification data (11420) encrypted using a second encryption key set. Accordingly, the raw data management circuit (11416) may be configured to identify response data for vehicle data requests (11422) without access to the response vehicle data (11418). In certain embodiments, the raw data management circuit (11416) may identify response data by utilizing a hash check or other operation. In certain embodiments, the encryption key for decrypting the response vehicle data (11418) does not exist in the cloud system (11400) and / or is unavailable to selected parts of the cloud system (11400) (e.g., unavailable to the raw data management circuit (11416)).

[0145] Referring to FIG. 14, an exemplary cloud system (11500) for retrieving selected data from a vehicle and / or separating access to stored collected data and data is schematically illustrated. The example in FIG. 14 is described as a cloud-based system (11500) for clarity of description to illustrate aspects of the present disclosure. However, the operations of the system (11500) may additionally or alternatively be performed in any system configuration outside the vehicle.

[0146] An exemplary system (11500) includes a collected vehicle data storage circuit (11502) that stores collected data (11504) from a vehicle, and an external data collection interface (11506) that optionally provides vehicle data collection request(s) (11508) from an external device to the vehicle, for example by processing the vehicle data collection request(s) (11508) into a policy data structure provided to the vehicle. The exemplary external data collection interface (11506) further provides at least a portion of the collected data (11504) stored from the collected vehicle data storage circuit (11502) in response to a vehicle data request (11510) from an external device. The exemplary system includes separating at least a portion of the stored collected data (11504) from an encryption key for at least a portion of the stored collected data (11504). Exemplary arrangements for separating an encryption key from at least a portion of the stored collected data (11504) include, without limitation to any other aspect of the present disclosure: encrypting the identification portion of the data separately from the payload portion of the data; identifying and / or verifying the payload portion of the data using a hash check; and / or identifying and / or verifying the payload portion using a separate identifier for the payload portion. An exemplary external data collection interface (11506) optionally provides the vehicle data collection request(s) (11508) to the vehicle by providing the vehicle data collection request(s) (11508) to the collected vehicle data storage circuit (11502) and / or to the policy generator circuit (11406) (e.g., see FIG. 13 and related description).

[0147] Referring to FIG. 15, an exemplary procedure (11600) for data collection operations from a vehicle is schematically illustrated. The exemplary procedure (11600) includes an operation (11602) of interpreting response action values ​​from an external device, and an operation (11604) of determining a data collection policy in response to the action values, wherein the data collection policy includes a vehicle data identifier. The exemplary procedure (11600) includes an operation (11606) of receiving identified vehicle data in response to the data collection policy, an operation (11608) of storing the received identified data and related identification data from the vehicle in response to the data collection policy, and an operation (11610) of interpreting a vehicle data request and retrieving at least a portion of the response data.

[0148] Referring to FIG. 16, an exemplary procedure (11700) for separating response data for a vehicle data collection operation from access to the response data is schematically illustrated. The exemplary procedure (11700) includes an operation (11702) of encrypting the response data using a first encryption key, and an operation (11704) of encrypting the identification data using a second encryption key. In certain embodiments, the identification data may not be encrypted. The exemplary procedure (11700) further includes an operation (11706) of storing the response data in a memory separate from the first encryption key, and an operation (11708) of retrieving the requested data using the second encryption key (and / or using the identification data).

[0149] Referring to FIG. 17, an exemplary procedure (11800) for separating response data for a vehicle data collection operation from access to the response data is schematically illustrated. The exemplary procedure (11800) includes an operation (11802) of encrypting the response data to store it in a first memory, an operation (11804) of interpreting a vehicle data request targeting at least a portion of the encrypted response data, and an operation (11808) of accessing the requested portions of the encrypted response data using an unencrypted identifier and / or a separately encrypted identifier.

[0150] Referring to FIG. 18, an exemplary system (11900) for retrieving selected data from a vehicle and / or separating stored collected data and access to the data is schematically illustrated. The exemplary system (11900) includes a raw data management circuit (11416) that stores response encrypted data (11418) collected in response to a data collection vehicle description (11408) (and / or policy), utilizing vehicle data (11902) provided by a vehicle that operates a data collection policy on the vehicle. The exemplary system (11900) includes an external data collection interface (11506) that provides at least a portion of the response encrypted data (11418) to an external device in response to a vehicle data request (11510). In the example of FIG. 18, the encryption key (11512) for the response encryption data (11418) is maintained separately from the raw data management circuit (11416), and, for example, separate identification data (11420) is utilized to determine parts of the response encryption data (11418) without decrypting the response encryption data (11418). In certain embodiments, either or both of the external data collection interface (11506) or the external device (11424) have access to the response data encryption key (11512), thereby allowing the external device (11424) to access the received data. In the example of FIG. 18, the disconnection between the response data encryption key (11512) and the raw data management circuit (11416) is explicitly shown for the purpose of explanation, but the response data encryption key (11512) may be stored in a separate device from the raw data management circuit (11416), regardless of whether it is a separate physical device or a separate logical device.

[0151] Referring to FIG. 19, exemplary and non-limiting examples of identification data (11420) are illustrated. The exemplary identification data (11420) includes one or more of the following: collected vehicle data metadata (12002), a data collection session identifier (12004), an identifier configured so that personally identifiable information (PII) does not exist (12006), and / or identification data (12008) correlated with consent (e.g., where a request interface (11402) and / or a policy manager on the vehicle provides a consent notification to an external device, wherein the consent notification includes consent for information presented in the identification data (11420).

[0152] Referring to FIG. 20, an exemplary cloud system for preparing data collection policies and collecting response data from a vehicle is schematically illustrated. The example of FIG. 20 is described as a cloud-based system (12100) for clarity of description to illustrate aspects of the present disclosure. However, the operations of the system (12100) may additionally or alternatively be performed in any system configuration outside the vehicle.

[0153] An exemplary system (12100) includes a request interface (11402) configured to interpret a vehicle data collection request (12110) for at least one identified vehicle, and a policy generator circuit (11406) that determines a data collection policy (11408) in response to the vehicle data collection request(s) (12110). An exemplary cloud interface provides the data collection policy (11408) to the vehicle, and a raw data management circuit stores at least a portion of the response vehicle data received from the vehicle (e.g., see FIG. 13).

[0154] An exemplary request interface (11402) is further configured to expose an application programming interface (API) (e.g., a data collection API (12102)) to an external device (12104, 12106, 12108). The API may include access to any selected operations, such as enabling a web portal, mobile application, tool, local application, etc., to operate an interface to select available data values ​​for collection, to construct a data structure including any aspect of the policy described herein, and / or to operate an interface to request response data (11418) after the collection operations. The exemplary request interface (11402) further interprets a vehicle data request (12112) and provides data retrieved from the response vehicle data (11418) in response to the vehicle data request (12112) to the external device. Data collection requests (12110) and / or vehicle data requests (12112) may be received based on interactions with a user interface provided to an external device(s), and / or in response to the exercise of an API (12102) by a user, an application operated by the user, etc. An exemplary policy generator circuit (11406) determines a data collection policy (11408) in response to data collection requests (12110) and / or in response to policy collection authorization value(s) (12120) and / or policy collection capability value(s) (12118).

[0155] Exemplary operations of a policy generator circuit (11406) for determining a policy capability value (12118) include determining the policy capability value (12118) in response to one or more of the following: a data storage size determined to support a vehicle data collection request; a transmission amount value determined to support a vehicle data collection request; a data availability value associated with a vehicle data collection request; or a data configuration value associated with a vehicle data collection request. Exemplary operations of a policy generator circuit include determining the policy capability value (12118) in response to a vehicle data collection request (12110) and at least one additional vehicle data collection request (12110), and optionally enabling at least one of the following in response to the policy capability value (12118): determining a data collection policy (11408), or including at least one of a vehicle data collection request (12110) or at least one additional vehicle data collection request (12110). The policy generator circuit (11406) further determines a policy capability value (12118) in response to at least one of the following parameters: a data storage size determined to support each of the vehicle data collection request (12110) and at least one additional vehicle data collection request (12110); a transmission amount value determined to support each of the vehicle data collection request (12110) and at least one additional vehicle data collection request (12110); a data availability value associated with each of the vehicle data collection request (12110) and at least one additional vehicle data collection request (12110); a data configuration value associated with each of the vehicle data collection request (12110) and at least one additional vehicle data collection request (12110); or a priority determination between the vehicle data collection request (12110) and at least one additional vehicle data collection request (12110) for any one or more of the above.

[0156] An exemplary policy generator circuit (11406) determines a policy authorization value (12120) in response to a vehicle data collection request (12110) and performs at least one of the following actions in response to the policy authorization value: optionally enabling the determination of a data collection policy (11408); or determining a data collection policy (11408) to support at least a portion of the vehicle data collection request (12110). A request interface (11402) is configured to provide at least one use case value (12116) to a user interface, each use case value (12116) includes a vehicle data collection template (12114), and determines a vehicle data collection request (12110) in response to responses from the user interface to the provided at least one use case value (12116). The request interface (11402) is further configured to determine at least one use case value in response to at least one of the following: an entity type associated with the user interface; an authorization value associated with the user interface; and previous data collection policies determined for users having shared characteristics determined for the user interface.

[0157] Referring to FIG. 21, an exemplary policy generator circuit (11406) is schematically illustrated. The exemplary policy generator circuit (11406) may be utilized in any system of the present specification and / or may perform the operations of the present specification related to determining, interpreting, and / or generating policies and / or data collection operations. The exemplary policy generator circuit (11406) determines a policy collection capability value (12118) in response to received data collection requests (12110). In certain embodiments, the policy generator circuit (11406) determines policy collection capability values ​​(12118) in response to the following capability considerations (12202): data storage support for servicing the policy, data transmission support for servicing the policy, data availability for supporting the policy (e.g., whether requested data values ​​are available), data formatting, processing, and / or configuration support for the policy (e.g., whether parameters can be provided as requested units, bit depth, sampling rates, response times, etc., including whether processing support resources for performing formatting and / or configuration operations on the collected data are available), resource rights associated with the request (e.g., whether an entity, flow, and / or application associated with the data collection request (12110) has sufficient rights to utilize support resources and / or has sufficient rights to consume support resources in an amount necessary to support the data collection request (12110)), and / or comparisons of priorities between requests (e.g., the entire policy including all requests If the capability value is exceeded, lower priority data collection requests (12110) may be excluded).

[0158] Referring to FIG. 22, an exemplary request interface (11402) that provides use case and / or template selections to external device(s) is schematically illustrated. The exemplary request interface (11402) may be utilized in any system of the present specification and / or may perform the operations of the present specification related to determining, interpreting, and / or generating policies and / or data collection operations, and / or receiving and processing data collection requests. The exemplary request interface (11402) determines a data collection template (12114) and / or a data collection use case (12116) to be provided to external devices (12104, 12106, 12108) on the interface, wherein the use case (12116) and / or template (12114) are selectable as a data collection request and / or modifyable to quickly configure the data collection request.An exemplary request interface (11402) determines data collection templates (12114) and / or data collection use cases (12116) in response to the following selection considerations (12302): the entity type associated with the request (e.g., providing useful use cases and / or templates based on the entity type—e.g., manufacturers, service organizations, application developers, dealers, vehicle drivers, vehicle owners, etc.); the authorization value associated with the external device interfacing (e.g., where users with similar authorization profiles may be more likely to seek similar data, and / or where users with similar authorization profiles can efficiently utilize the same templates and / or use cases due to duplication of available parameters); previous data collection policies and / or requests from the same user (and / or the same entity, the same external device, the same access location, etc.); and / or previous data collection policies and / or requests from other users having characteristics shared with the user (e.g., sharing stated objectives, entity types, authority values, and / or categorical choices, such as those made by the user, wherein the categorical choices may relate to the subject of data collection—location data, powertrain data, feature utilization data, etc.—and / or the intended use of the collected data—service features, efficiency features, driver convenience features, etc.).

[0159] Referring to FIG. 23, an exemplary procedure (12400) for operating a request interface to determine data collection requests and / or collected data access requests is schematically illustrated. The exemplary procedure (12400) includes an operation (12402) of exposing a data collection API to an external device, an operation (12404) of interpreting a vehicle data collection request in response to the execution of the API, and an operation (12406) of determining a data collection policy in response to a vehicle data collection request. The exemplary procedure (12400) includes an operation (12408) of providing a data collection policy to a vehicle, an operation (12410) of receiving collected response vehicle data in response to the data collection policy, and an operation (12412) of storing at least a portion of the response data. An exemplary procedure (12400) includes an action (12414) of interpreting a vehicle data request in response to the execution of an API, an action (12416) of retrieving at least a portion of stored data in response to the vehicle data request, and an action (12418) of providing the retrieved data to an external device.

[0160] Referring to FIG. 24, an exemplary system is illustrated that may be utilized with, and / or include all or part of, the embodiments and / or aspects described throughout the present disclosure. The exemplary system comprises a vehicle (2402) having a plurality of network zones (2404, 2406, 2408), each of which has a plurality of endpoints thereon. The endpoints may be controllers, sensors, actuators, computing devices, and / or any other components of the vehicle using network communications. The exemplary network zones (2404, 2406, 2408) may be physically separate networks, for example, networks on separate hardware backbones and / or hardware layers, and / or may include virtually separated networks utilizing shared hardware components. In the example of FIG. 24, for the purposes of the city, the network zone (2404) is a separate hardware network, and the network zones (2406, 2408) utilize the same network hardware but are virtual zones, allowing devices to share the network while keeping the devices separated for, for example, security, authentication, separation of control aspects, or any other reason. In the example of FIG. 24, the controller (2501) performs operations such as controlling and implementing data collection operations, and operations such as supporting shared memory allocation to support data collection and / or automation operations. The example of FIG. 24 is non-limiting, and the controller (2501) may be distributed across various endpoints, etc., but for clarity of description, it is depicted as a single device at a specific location. The exemplary controller (2501) is located on the same computing device as the convergence network device (CND) that facilitates communication between devices on the vehicle regardless of the device location (e.g., the network zone to which the device is connected and / or located).In certain embodiments, the CND may be located on any endpoint including an endpoint distinct from the controller (2501), where present, and / or may be distributed across more than one endpoint. An exemplary system may be coupled at least intermittently or optionally to a cloud server (e.g., a cloud platform (2412)), and / or coupled to other external devices (2410) such as tools (e.g., manufacturing tools, OEM tools, engineering tools, service tools, etc.), directly coupled to a device (e.g., a device coupled to an OBD port, via Bluetooth, or via WiFi, etc.), and / or coupled to a mini-cloud (e.g., a laptop, workstation, or similar device that enables the vehicle (2402) to connect to the mini-cloud in cases where a connection to the cloud is unavailable and / or undesirable, to enhance security for operations performed, such as engineering, manufacturing, service, or other operations, where it may be desirable to isolate from the cloud, the internet, or a wide area network, for example, a laptop, workstation, or similar device that provides specific support operations such as those provided by the cloud platform (2412), but where isolation from the cloud, the internet, or a wide area network may be desirable). In certain embodiments, any operations described herein in relation to the cloud system may be available, in whole or in part, additionally or alternatively, on a device outside the mini cloud (2410) and / or on any type of tool.

[0161] An exemplary system comprises user devices (2414, 2416) coupled to a cloud platform (2412), and enables the cloud platform (2412) to implement a user interface, e.g., a user data collection interface, a request interface, and / or any other interface that will be obvious to those skilled in the art to facilitate user interactions with any system or device described throughout this disclosure and / or described herein. In certain embodiments, access to the cloud platform (2412) may utilize a web portal, proprietary software, a mobile application, or something similar, wherein the user devices (2414, 2416) include suitable computing devices for accessing the interface, displaying aspects to the user, accepting user inputs, communicating inputs, and receiving communications from the cloud platform (2412). In certain embodiments, the cloud platform (2412) may support interactions using an application programming interface (API), and, for example, allow a user to interact with the cloud platform (2412) by utilizing any configured interface desired and / or set by an administrator, vehicle tool provider, or similar entity. Users (2418, 2420, 2422) may be any type of user, for example, a service technician, an engineer, a manufacturer, an OEM, a dealer, a bodybuilder, a fleet manager, a vehicle owner and / or a driver. In the example of FIG. 24, some users (2420, 2422) interact with the system through the cloud platform (2412), and some users (2418) interact with a tool or other device directly connected to the vehicle (2402).The embodiment of FIG. 24 illustrates a specific vehicle, but the system can interact with groups of vehicles (e.g., see FIG. 28 through 32 and related description) and potentially include a very large number of vehicles (e.g., all vehicles of a specific manufacturer).

[0162] Referring to FIG. 25, an apparatus for collecting vehicle data by utilizing events based on external parameters for a vehicle is illustrated. Without limitation to any other aspect of the present disclosure, external events include events determined based on arbitrary information rather than direct vehicle data. In certain embodiments, the external data may be available in whole or in part at the vehicle, for example, the ambient temperature of the vehicle may be detected at the vehicle but may be considered as external data for the vehicle. An exemplary apparatus includes a controller (2501) comprising a policy acquisition circuit (2502) configured to interpret a vehicle policy data value (2508) including an external event trigger condition (2510). A policy processing circuit (2504) is configured to generate parsed policy data (2516) including the external event trigger condition (2510). As used herein, the parsed policy data (2516) includes determining parts of a policy related to data collection operations, automation operations, and / or other information utilized to support the operations of the present specification. For example, the policy may include other information that is not required to be part of the data collection operations described herein, such as registering vehicle components or specifying relevant versions of the vehicle's hardware, firmware, and / or software. Additionally or alternatively, the data collection operations may utilize multiple endpoints distributed across different network zones, each endpoint utilizing which does not require (and may not be able to use) information regarding other endpoints, and thus the parsing operations determine information associated with each endpoint and, using the parsed policy data (2516), issue commands to each endpoint accordingly.In certain embodiments, endpoints may be supported by zone agents, software agents, etc., and accordingly, the policy execution circuit (2506) provides commands to such supporting agents to implement data collection and / or other communications, wherein some (or all) of the endpoints providing and / or utilizing information do not operate directly with the parsed policy data (2516), but rather respond to the parsed policy data (2516) through the actions of the supporting agents(s). The policy execution circuit (2506) is configured to collect vehicle data (2512) from one or more vehicle endpoints in response to the parsed policy data (2516). The collected data may be stored as stored collected data (2518) and / or communicated via external communications (2514). An authorization value (2520) may also be included in the vehicle policy data value.

[0163] As used herein, authorization values ​​may support a number of operations within this disclosure to ensure vehicle security and proper operation, and to ensure that certain data, such as mission-critical data, vehicle control data, and data including personally identifiable information (PII), is not observed or manipulated by users or devices that are not to access or manipulate such information. Authorization values ​​may be associated with a requesting user or device and / or a providing user or device. For example, an entity requesting data collection operations (e.g., a user providing vehicle policy data values) may have specific authorizations to access data, adjust data values, request specific operations (e.g., summaries of data, statistical analysis of data, etc.), utilize specific resources (e.g., restrictions on allowed network utilization, memory utilization, and / or processing utilization to support the requested operations), and / or view specific data elements (e.g., viewing the very existence of data values ​​and / or parameters). In certain embodiments, permissions may be related to the vehicle's current operating conditions and / or states — for example, the user may have increased permissions to reduce permissions during certain operating conditions (e.g., when total network utilization is low) and / or certain operating states (e.g., when the vehicle is in normal cruise operation).Authorization values ​​and associated permissions may be determined based on the user's identity, the entity associated with the user (e.g., a user associated with a vehicle manufacturer may have distinct permissions compared to a user associated with a dealer), the user's role (e.g., administrator, engineer, driver, and / or service user may have distinct permissions), and / or any metadata used to control access (e.g., user login type, subscription parameters, access time zones, etc., may all be used to adjust and / or apply authorization values). In certain embodiments, authorization values ​​may be compared with permissions associated with data providers—e.g., data provided by specific endpoints and associated with specific vehicle applications, flows, and / or features, and / or data associated with specific networks and / or network zones may be limited to vehicle policy data values ​​(2508) having sufficient authorization values ​​(2520) for such access. The authorization values ​​and implementations of this specification are not limiting.

[0164] Referring to FIG. 26, exemplary external event trigger conditions (2510) are described in more detail in non-limiting examples. The exemplary external event trigger conditions (2510) include traffic condition values ​​(2602) and allow the user to configure a policy for data collection based on traffic conditions (e.g., categorical traffic descriptions such as "congested" or "smooth" traffic based on quantitative values ​​such as vehicle throughput passing through a relevant location, the number of vehicles within a specified range, or similar). The external event trigger conditions (2510) can be utilized to determine data collection actions and / or to determine whether a policy is active. For example, the external event trigger conditions (2510) can be utilized to keep a policy in a deactivated state until a trigger condition is satisfied, and then the policy is activated, and accordingly, the policy may have additional trigger conditions associated with specific data collection, such additional trigger conditions, which are not monitored until the external event trigger conditions (2510) are satisfied. External event trigger conditions (2510) may be sequentially stepped, for example, a first condition related to weather may be the first step, and then a second step related to traffic may be utilized—for example, the policy may include a first trigger based on determining that it is nighttime, and then a second trigger condition that the weather is snowing before any additional conditions are confirmed as part of active policy data collection operations. Additionally or alternatively, any trigger conditions described herein, whether external event trigger conditions (2510) or vehicle-based trigger conditions, may be combined and utilized to determine whether the policy should be activated and to execute data collection operations in response.Stepped trigger determinations for activating policies for monitoring allow for more efficient operation of the system, for example, when monitoring during data collection can utilize significant processing resources to determine whether data collection conditions exist and to support data buffering, the policy activation conditions allow for the use of simplified and selective activation parameters where the objectives of data collection do not yet exist, thereby saving significant processing, memory utilization, and network communication resources until the vehicle is in a state where successful data collection is more likely to be available.

[0165] An exemplary external trigger condition (2604) is: a weather condition value (2604) (e.g., precipitation, rain, temperatures, presence and / or intensity of wind, outliers or abnormal weather compared to a baseline, etc.); a mission type value (2606) (e.g., commuting, errand trip, first responder mission, law enforcement mission, cargo transport, hot shooting, where the mission type may be a permanent value such as a first responder mission type for an ambulance, or a temporary value such as a commuting mission type based on vehicle location, time of day, previous driver behavior, etc.); a road condition value (2608) (e.g., quantitative values ​​such as road curvature description, road slope description, road shoulder description, speed limit value, road gradient, number of lanes, exit density and / or proximity, etc., and / or qualitative values ​​such as maintenance status, presence of road construction, designated high-risk road sections, etc.); Location values ​​(2610) (e.g., geography, jurisdiction, school district, etc., and see FIG. 27 and related description); and / or time-based external values ​​(2612) (e.g., time zone, calendar date, workday versus weekday, commute time value, time elapsed since the start of the trip, etc., relative time, and / or mileage, operation parameters (e.g., engine RPM, wheel RPM, fuel consumed and / or energy, etc.) and one or more of any other sequencing parameters.

[0166] Referring to FIG. 27, exemplary location values ​​(2610) are described in more detail and include various specific values ​​such as: a jurisdiction description (2702) (e.g., relevant country, state, city, etc., for regulating collection operations based on applicable laws and meeting required data monitoring regulations); an elevation value (2704) (e.g., allowing data collection operations under conditions of interest such as low ambient pressure conditions); a climate value (2706) (e.g., qualitative climate values ​​such as temperate, desert, or tropical, and quantitative values ​​such as average temperatures, wind, precipitation, or ambient sunshine); a season value (2708) (e.g., allowing data collection based on conditions of interest that may be related to the season, such as during a cold start operation, where the season may be weather-based, such as spring / summer / autumn / winter, and / or based on other conventions such as vacation season, tourist season, bison migration season, etc.); and / or settlement description (2710) (allowing for data collection based on factors such as urban environment, rural environment, population density values, vehicle density values, etc.). Examples of external event trigger conditions (2510) are non-limiting, and it can be seen that some potential external event trigger conditions may fall into multiple categories (e.g., school zone determination may be considered as road conditions or location values ​​depending on the convention used). The examples and names used in the examples are non-limiting cities to clarify aspects of the present disclosure.

[0167] Referring to FIG. 28, an exemplary cloud system is illustrated and includes a controller (2801) comprising a request interface (2802) configured to interpret at least one vehicle data collection description (2810) and a target vehicle description (2812). In the example of FIG. 28, user communications with the controller (2801) are illustrated on the left for convenience and clarity of explanation, and vehicle communications are illustrated on the right, but the communications are not limited and may come from any source. The policy generator circuit (2804) is configured to determine at least one vehicle policy data value (2508) in response to a vehicle data collection description (2810) and a target vehicle description (2812), so that the request interface (2802) allows the user to provide data to be collected, which includes any trigger conditions used for data collection operations and any trigger conditions (e.g., external event trigger conditions (2510) and / or policy trigger conditions (4001)—see FIG. 40, used to determine when a policy implementing data collection should be activated), and also allows the user to provide relevant vehicles for which data collection should be implemented (e.g., by providing relevant policies (2820) and / or commands to the relevant vehicles). The policy implementation circuit (2806) is configured to determine a target group (2814) of vehicles in response to a target vehicle description (2812) and to provide at least one vehicle policy data value (2508) to the group (2814) of vehicles. The cloud interface (2808) is configured to receive identified vehicle data (2816) (e.g., data collected from vehicles implementing the policy (2820)) and / or a warning response value (2818) (e.g., when a vehicle does not install or run the policy, and / or when the execution of the policy fails for any reason) in response to the vehicle policy data value (2508).The system may also process policies, commands, etc. (2820), for example, a cloud interface (2808) implements communications between the controller (2801) and the relevant vehicles identified in the target group (2814) of vehicles. In certain embodiments, the policy implementation circuit (2806) determines the target group (2814) of vehicles in response to the shared vehicle attribute (2902) (see FIG. 29), allowing the user to quickly determine the vehicles associated with the planned data collection operations. Additionally or alternatively, the user may select specific vehicles or specific vehicles, for example, by selecting vehicles from an available list and / or by providing an identifier for specific vehicles at the request interface (2802).

[0168] Referring to FIG. 29, additional details regarding exemplary shared vehicle attributes (2902) are illustrated. Exemplary shared vehicle attributes (2902) include vehicle configuration values ​​(2904) (e.g., vehicles having specific versions of firmware, software, installed versions, and / or any other identifier used to describe the configuration of the vehicles), vehicle component values ​​(2906) (e.g., targeting vehicles having specific sensors, actuators, transmissions, valves, etc.), vehicle feature values ​​(2908) (e.g., vehicles having features such as cruise control, ADAS, ABS, and / or specific versions of features), owner values ​​(2910) (e.g., specific owners, owner types, owner characteristics, etc.), manufacturer values ​​(2912), OEM values ​​(2914), fleet values ​​(2916), body builder values ​​(2918) (e.g., specific body builders, upfitters, third-party additional entities, and / or specific types of components, features, or specific applications such as emergency vehicles, performance vehicles, etc. Identifying types of such as those constituting the vehicles for the purpose), dealer value (2920), maintenance value (2922) (e.g., vehicles utilizing specific maintenance procedures and / or vehicles for which specific maintenance procedures have been performed or have not been performed during a selected time period), diagnostic value (2924) (e.g., vehicles for which specific diagnostics are available or not available, vehicles for which specific diagnostics have been performed and / or vehicles for which specific diagnostic results have been performed during a selected time period), recall value (2926) (e.g., vehicles subject to (or not subject to) a specific recall, and / or vehicles for which a specific recall has been performed or has not been performed), fault code value (2928) (e.g., vehicles for which a specific fault code is available, a specific fault code is activated, and / or vehicles for which a specific fault code has been activated within a selected time period), entity type value (2930) (e.g., based on categorical entity types such as manufacturer, OEM, dealer, etc.,and / or based on a functional type including aspects of a vehicle for which the entity is responsible and / or can access, for example), and vehicle type values ​​(2932) (e.g., commercial, passenger, rental, first counterpart, truck class, etc.). Exemplary shared vehicle attributes (2902) provide a number of levers for a user to quickly select a group of vehicles likely to be useful for organizing vehicles for various data collection purposes, and provide an implementation method for a user to quickly deploy policies for data collection, automation, monitoring, and data analysis to such vehicles.

[0169] Referring to FIG. 30, an exemplary cloud system is illustrated and includes a controller (2801) comprising a request interface (2802) configured to implement a user data collection interface (3002) and to interpret at least one vehicle data collection description (2810) (e.g., data values ​​to be collected, trigger conditions for data, priority of data collection, etc.) and a target vehicle description (2812) in response to user policy builder interactions (3004) with the user data collection interface (3002). A policy generator circuit (2804) is configured to determine at least one vehicle policy data value (2508) (e.g., a policy configured to implement data collection operations in the vehicle when processed by the vehicle's controller) in response to the vehicle data collection description (2810) and the target vehicle description (2812). The policy implementation circuit (2806) is configured to determine a group of vehicles (2814) in response to a target vehicle description (2812) and to provide at least one of vehicle policy data values ​​(2508) to the group of vehicles in response to user policy implementation interactions (3004) with a user data collection interface (3002) (e.g., building a collection recipe describing trigger conditions for the policy to be activated, trigger conditions for data to be collected while the policy is activated, and data to be collected; selecting and / or defining target vehicles; approving policy and / or vehicle selections; distributing the policy; and / or monitoring the policy distribution and / or collected data in response thereto). The cloud interface (2808) is configured to receive at least a portion of the identified vehicle data (2816) (e.g., data collected according to the policy) and / or a warning response value (2818) (e.g., a vehicle warning that the policy or a portion thereof cannot be implemented or will not be implemented) in response to the vehicle policy data value. The system can also handle policies, commands, etc. (2820), and / or any other communications with the vehicle.

[0170] Referring to FIG. 31, an exemplary user data collection interface (3002) is illustrated and includes a recipe library (3102) (e.g., basic data collection recipes, pre-built data collection recipes, previously stored data collection recipes, and / or recommended data collection recipes based on requests and / or interests indicated by the user), available data parameters (3104) (e.g., parameters available for data collection, which may include parameters within the user's authorization range and / or be filtered based on requests and / or interests indicated by the user), and a policy summary (3108). The exemplary policy summary (3108) displays information to the user indicating parameters intended for collection, triggers controlling policy activation and / or data collection actions, target groups of vehicles (2814), etc. In certain embodiments, a pending / active policy description (3110) may be presented in the policy summary (3108) to, for example, allow the user to easily identify whether the displayed policy (or any displayed policies) has been deployed and / or indicate aspects of the policy that must be completed before deployment. In certain embodiments, a pending / active trigger description (3112) may be presented in the policy summary (3108) to, for example, allow the user to easily view the trigger conditions of the policy (e.g., policy activation trigger conditions and / or data collection trigger conditions), and may further include an indication of how such trigger conditions will be satisfied in selected vehicles (e.g., confirming that the planned trigger method will operate as intended), and may also include a confirmation of whether the triggers are included in the policy or are pending for inclusion.In certain embodiments, a logical flowchart (3114) is illustrated in the policy summary (3108), allowing, for example, the user to easily identify the chain of actions for a complex triggering scheme and / or visualize the dependencies between the actions to be performed to execute the policy.

[0171] An exemplary user data collection interface (3002) includes a policy implementation status / monitoring (3118) display that allows the user to see which vehicles have received and / or acknowledged the policy, whether the policy has not yet been activated, whether it is activated, and / or whether the policy has been completed (e.g., if the policy is not activated but has already been executed). An exemplary user data collection interface (3002) includes a collected data view (3120) that allows the user to see which vehicles have collected data regarding the policy, and may further allow the user to view specific data regarding the vehicles, access summaries of the data, and access summaries of the policy implementation (e.g., how many vehicles have received and / or acknowledged the policy, how many vehicles have collected data regarding the policy, etc.). An exemplary user data collection interface (3002) includes a view of available data collection packages (3122) (e.g., data structures containing collected data, which may be identified and / or indexed—see FIG. 33 and related description). An exemplary user data collection interface (3002) includes components for implementation commands and / or states (3116)—e.g., enabling the user to approve and / or deploy policies.

[0172] Referring to FIG. 32, exemplary and non-restrictive normalized parameters (3104) are illustrated and may be utilized in a user data collection interface (3002) to improve accessibility to policy creation for a wide range of users. For example, the parameters displayed in the user data collection interface (3002) may use terms that are likely to be understood by the user. The exemplary and non-restrictive normalized parameters include one or more of manufacturer parameters (3202) (e.g., parameter names, resolutions, units, sampling rates, etc., specified by a specific manufacturer), industry standard parameters (3204) (e.g., specified by industry standards, customarily used in a specific industry, etc.), simplified parameters (3206) (e.g., parameter names and / or descriptions prepared for non-technical or general users, marketing or business personnel, consumer users, etc.), and / or user-defined parameters (3208) (e.g., parameter displays set by the user or by another user on behalf of the user, etc.). In certain embodiments, the user data collection interface (3002) may allow the user to reveal actual parameter attributes (e.g., where possible, indicate that some parameters may have multiple “actual” versions depending on the group of selected vehicles, in which case a set of common attributes may be displayed and / or multiple versions of attributes may be displayed) and / or allow the user to switch between different normalization methods for the parameters (globally, individually, and / or in selected groups).

[0173] Referring to FIG. 33, an exemplary device is illustrated and includes a controller (2501) comprising a policy acquisition circuit (2502) configured to interpret a vehicle policy data value (2508) including a data collection description (3302). A policy processing circuit (2504) is configured to generate parsed policy data (2516) corresponding to the data collection description and to determine a memory allocation value (3304) in response to the parsed policy data. In certain embodiments, the memory allocation value (3304) is an amount of memory, memory location(s), storage methods, lifecycle management for memory, etc., to support data collection operations according to the data collection description (3302). In certain embodiments, the memory allocation value (3304) considers an intermediate memory allocation for processing operations that can be utilized for storage to support data collection operations including storage of collected data, and / or triggers, performing data processing, and an estimated storage time (if applicable) until the collected data can be communicated to the cloud. In certain embodiments, the memory allocation value (3304) includes a memory allocation sufficient to perform all operations. In certain embodiments, the memory allocation value (3304) may be configured to support multiple policies and / or data collection operations and may be intelligently provided at a level less than 100% supporting all policies and / or operations simultaneously (e.g., see FIG. 37 and 38 and related description), which may result in a significant reduction in the memory required to support the data collection operations described herein.

[0174] The policy execution circuit (2506) is configured to collect vehicle data (2512) from one or more vehicle endpoints in response to parsed policy data (2516) and to store at least a portion of the collected vehicle data as stored collected data (2518) in response to a memory allocation value (3304) (e.g., at designated locations, formatting, applying designated prioritization and / or lifecycle management, applying designated compression operations, etc.). An exemplary policy reporting circuit (3306) is configured to generate a data collection package (3308) in response to the collected vehicle data and to perform at least one of storing the data collection package or communicating the data collection package (3308) through external communications (2514).

[0175] In certain embodiments, the data collection package (3308) provides a data structure that can be communicated and / or accessed by a user, and the data collection package (3308) includes all data collected for a policy, and / or all data collected for a specific triggered data collection event of the policy. An exemplary policy reporting circuit (3306) includes a package identifier together with the data collection package (3308) and identifies, for example, a policy including a vehicle policy data value (2508), which data collection action and / or which trigger of the policy was utilized to generate data. In certain embodiments, the package identifier is a unique identifier for the data collection package (3308) and is based, for example, on the requesting user and / or entity that provided the policy. In certain embodiments, the package identifier includes technical metadata for the data collection package (3308), such as, for example, timestamps for the start and / or end times of collection, vehicle operation conditions and / or vehicle states applicable at the time associated with the data collection package (3308), network utilization and / or available memory associated with policy operations, etc. In certain embodiments, the package identifier provides a convenient hook for indexing, identifying, sorting, filtering, and / or sharing the data collection packages (3308) for a user who monitors policies and / or data collected from policies.An exemplary policy reporting circuit (3306) may include at least a portion of flow logs within a package—e.g., logs related to network communications and / or their endpoints, and operations of specific flows in the vehicle during times related to the policy (e.g., during policy activation, trigger decisions, and / or data collection operations), which may enable the user to troubleshoot policy implementation, plan for improved implementation of future policies, determine whether problems appearing in the collected data are signals (e.g., types of problems intended to be identified by data collection) or noise (e.g., problems arising from policy implementation, e.g., excessive network utilization or memory, conflicts with vehicle operations, etc.), and / or provide inputs for machine learning, artificial intelligence, and / or other iterative improvement operations to improve the creation, distribution, and / or execution of policies, data collection operations, and / or automation operations over time. An exemplary policy reporting circuit (3306) includes a vehicle condition log within the package—e.g., active fault codes and / or fault counters, vehicle parameters such as operating status, power throughput, vehicle speed, etc., active diagnostics in the vehicle during times related to the policy, features, algorithms, applications, or a list of flows, etc., which can be used in a manner similar to the aspects described for the flow log described above.

[0176] Referring to FIG. 34, an exemplary shared memory allocation is schematically illustrated. The example in FIG. 34 is described in the context of multiple policies that are simultaneously active in a vehicle (or have at least some overlap in the active times for the policies), where the shared memory allocation is utilized to support the policies in a manner that allows for the efficient utilization of system resources to support policy operations.It will be understood that the concepts of shared memory allocation described herein may be utilized to support multiple data collection events from a single policy, for example, where a data collection package (3308) is prepared for each data collection event responding to a trigger, and / or prepared for multiple data collection events responding to triggers for a policy, but less than all of them (e.g., a policy triggering 20 individual collection events may utilize a single data collection package, 20 data collection packages, and / or multiple data collection packages—e.g., groups of 5), where prepared for all collection events for a given time period (e.g., hourly, daily, weekly, monthly, etc.) and / or sequencing parameters (e.g., per trip, per 1,000 miles, per 500 hp-hr of powertrain energy utilization, and / or any other sequencing parameters), the collection events may be grouped in principle into packages (e.g., having similar sizes and / or to support each package If prepared for providing collection packages utilizing a similar amount of processing power; providing sequentially sized collection packages to provide convenient and incremental analysis of data, such as three packages sized to include data of 1, 2, and 4 units each; and / or providing collection packages containing data sufficient to perform statistical analysis, such as frequency analysis, sample sizes of statistically significant data, etc., and / or packages linked to external parameters (e.g., completing packages before a meeting so that data can be analyzed in time before a quarterly business meeting, linking packaging timing to engineering deliverables, design dates for subsequent model years of vehicles, etc.).In certain embodiments, the basketing method for a given embodiment may be updated in response to changes in policies (e.g., a policy being added or removed by a user providing vehicle policy data values) and / or in response to the expiration or deactivation of a policy (e.g., expiration of a relevant time frame and / or sequencing parameter, completion of actions such as data collection for a policy, and / or occurrence of a deactivation trigger event for a policy). When the basketing method for a given embodiment is updated, any actions may be performed to transition to the updated basketing method, for example, previously collected data may be stored in a partial package and closed, communicated to the cloud, and included in the new basketing method (if applicable).

[0177] In certain embodiments, operations for combining policies for processing in this specification (e.g., using shared memory allocations, shared data packages, etc.) are referred to as supporting a basket of policies, where it will be understood that the combining unit may be collection events, trigger events, and / or automation operations rather than policies (e.g., supporting a basket of collection events, or more generally, supporting a basket of combining units). In certain embodiments, combining policies with data packages and / or shared memory allocations is referred to in the context of supporting a basket for appropriate memory allocation values, e.g., ensuring that memory utilization in a vehicle remains within the vehicle's capabilities, where it will be understood that the context of supporting the basket may relate to processing utilization and / or network utilization (e.g., ensuring that network utilization in a vehicle remains within the vehicle's capabilities).

[0178] It may be seen in this specification that operations supporting a basket of combination units (e.g., policies) provide substantial improvements, such as: improved resource utilization for data collection, policy distribution and implementation, and / or automation operations; higher reliability execution of operations on combination units; increased likelihood that operations on combination units will be performed within desired time frames; and / or allow greater system capability to support operations on combination units given fixed system resources (e.g., a given system can support a greater number of combination units and thus support a greater number of collection events, a greater amount of collected data, and / or an increased number of available automation operations). In certain embodiments, operations supporting a basket of combination units improve the ability and possibility to preserve system capability, for example, to meet QoS standards for base operations and / or to meet QoS standards for other operations within the system that compete with the system resources utilized to perform the base operations.

[0179] Referring again to FIG. 34, an exemplary policy processing circuit (2504) implements a basketing method for multiple policies (in the example, five policies) in a vehicle by determining a memory allocation value (3304) as a shared memory value to support a basket of policies. In the example of FIG. 34, the policy processing circuit (2504) determines a shared memory allocation 1 (3406) memory allocation value (3304) to support a first policy basket (3402), and determines a shared memory allocation 2 (3408) memory allocation value (3304) to support a second policy basket (3404). In certain embodiments, the policy processing circuit (2504) may utilize the same baskets (3402, 3404) to determine the data collection packages (3308) (e.g., the first policy basket (3402) is packaged into a single data collection package (3308)), but the policy processing circuit (2504) may utilize a separate basketing method for the data collection packages (3308) and / or omit the basketing method for the data collection packages (3308). In certain embodiments, the basketing method for the combined units may be performed by the policy processing circuit (2504), for example, when the basketing operations are implemented by the analysis of policies, applications, flows, and / or other aspects of the vehicle that can utilize memory, processing, and / or network resources. In certain embodiments, the basketing method for the combined units may be performed by the policy execution circuit (2506) and / or coordinated by the policy execution circuit (2506), for example, where the basketing operations are implemented or updated by the analysis of the actual execution and / or performance of policies, applications, flows, and / or other aspects of the vehicle that can utilize memory, processing, and / or network resources.In certain embodiments, the policy processing circuit (2504) and the policy execution circuit (2506) may repeatedly implement and / or adjust the basketing method(s) utilized as policies are added and removed, as data collection operations are resolved, and as the vehicle's performance changes over time.

[0180] An exemplary action for determining a basket method to support combined units may utilize trigger correlation analysis to determine, for example, correlations and / or anti-correlations between combined units (e.g., policies have trigger events for activations and / or data collection actions that are likely to occur simultaneously, and for actions that are unlikely to occur simultaneously and / or cannot occur simultaneously (e.g., data collection is based on mutually exclusive vehicle states)). Another exemplary action for determining a basket method to support combined units may utilize historical actions from base policies, triggers, automation actions, and / or data collection actions, and / or historical actions for offset policies, triggers, automation actions, and / or data collection actions, which can improve estimates of actual resource utilization to support combined units and / or determine correlations, anti-correlations, and / or dependencies between combined units. Another exemplary action for determining a basket method to support combined units may utilize underlying policies, triggers, automation actions, and / or historical actions from data collection actions from offset vehicles (or groups of offset vehicles), and / or historical actions regarding offset policies, triggers, automation actions, and / or data collection actions from offset vehicles (or groups of offset vehicles). Another exemplary action for determining a basket method to support combined units may utilize probabilistic analysis to determine resource utilization, to determine whether resource overrun will occur, and to determine shared memory allocation values ​​to support the basket of combined units.Exemplary and non-restrictive probabilistic analyses include Bayesian analysis, Monte Carlo analysis, fuzzy logic-based tuning of baskets and / or basket parameters, utilization of Poisson distributions of potential behaviors and / or disturbances, and / or operating a digital twin of at least some of the vehicle network, memory, and / or processing behaviors in the simulated operation of the vehicle over multiple trips to surface, for example, the utilization of resources and / or correlations / anti-correlations between combining units. In certain embodiments, probabilistic analysis may be performed over time using historical data as the vehicle continues to operate, for example, in the cloud. Additionally, probabilistic analysis may be performed using data from offset vehicles and / or offset combining units, which improves the performance of the system over time. The described operations for determining the basket method, for example, which aspects should utilize the shared data collection package (3308), shared memory allocation values ​​(3406, 3408), and / or be supported by the shared data collection package (3724) (see FIG. 37 and related description), are non-limiting, and in certain embodiments, various operations for determining the basket method may be combined and / or performed in sequence as the relevant data and / or support resources become available.

[0181] Without limitation to any other aspect of the present disclosure, as used herein, an offset vehicle is a vehicle distinct from the vehicle being considered, which shares aspects of the vehicle in a manner related to comparison. For example, a vehicle having the same hardware components as the current vehicle may be considered an offset vehicle for the purpose of decisions related to the analysis of the hardware components. In certain embodiments, offset vehicles may be determined according to principles similar to those of vehicles having shared vehicle attributes (2902) (see FIG. 29), but any other related determinations may also be applied. In certain embodiments, many vehicles have a corpus of readily available offset vehicles, such as vehicles sharing the manufacturer, model year, duty cycle, etc. In certain embodiments, a vehicle may be an offset vehicle for one purpose (e.g., when the shared characteristics of the vehicles are related to one purpose) but may not be an offset vehicle for a second purpose (e.g., when the shared characteristics of the vehicle are not related to the second purpose).

[0182] Without limitation to any other aspect of the present disclosure, an offset policy, trigger, automation action, and / or data collection action (or, combination unit) is a combination unit distinct from the combination unit being considered, and shares aspects of the combination unit in a manner related to comparison. For example, a first policy that utilizes the same endpoints as a second policy, collects a similar amount of data at a similar rate, and is based on trigger conditions similar to those of the second policy may be considered an offset policy for the second policy for the purpose of determining resource utilization and / or correlations with other policies. In another example, a first policy that utilizes the same endpoints as the second policy, collects a similar amount of data at a similar rate, but utilizes trigger conditions distinct from those of the second policy may be considered an offset policy for the second policy for the purpose of determining resource utilization, but may not be considered an offset policy for the second policy for the purpose of determining correlations with other policies. Examples are non-limiting cities.

[0183] Referring to FIG. 35, an exemplary policy reporting circuit (3306) is illustrated. The exemplary policy reporting circuit (3306) includes one or more processing components configured to support operations for creating data collection package(s) (3308) for storing, organizing, and / or communicating collected data. The exemplary policy reporting circuit (3306) includes a data collection package generator (3502) that creates a data collection package (3308) for collected data in response to each policy, a basket of policies, and / or a trigger event (e.g., a trigger event that activates a specific policy and / or activates a specific data collection event within a policy or otherwise activates it). The exemplary data collection package generator (3502) may further attach collected data to the data collection package (3308) and / or adjust the already created data collection packages (3308), for example, in response to adjustments in the basketing method associated with the data collection packages (3308). The data collection package (3308) may be stored in the vehicle, communicated to an external device, and / or made available to devices on the vehicle (e.g., endpoints, flows, applications, features, controllers, etc.) (e.g., see FIG. 37 and related description).

[0184] An exemplary policy reporting circuit (3306) includes a data collection package communicator (3504) that manages the communication of the data collection package (3308) and streams the data of the data collection package (3308) to an external device (e.g., a cloud server, a mini cloud, a connected tool, etc.) for example, at a selected time or according to vehicle operation conditions. In certain embodiments, the data collection package communicator (3504) performs actions according to a priority associated with the data collection package (3308), a priority associated with the requesting user or entity associated with the policy that initiated the data collection package (3308) (or parts thereof), and / or a priority associated with the source of the data or parts thereof within the data collection package (3308) (e.g., an endpoint, an application, a flow, a feature, etc.). In certain embodiments, the priority of the policy and / or the resulting data may be defined in the policy and may be limited to a priority range associated with the user or entity that creates and / or implements the policy.

[0185] An exemplary policy reporting circuit (3306) includes a data collection package storage (3506) component that manages the storage of a data collection package (3308) in a vehicle. For example, the data collection package storage (3506) component implements memory size and / or location aspects described in the associated memory allocation value (3304) and ensures that data structures, identifiers, indexing, compression, and technical metadata are applied to and stored in the data collection package (3308) and / or are referenced in and communicated with the data collection package (3308). In certain embodiments, specific compression aspects, such as time-series compression, iterative value compression, etc., may be applied to the data collection package (3308), and the data collection package storage (3506) component ensures that any data required to decompress the data package is stored in the data collection package (3308) and / or is referenced in and communicated with the data collection package (3308). In certain embodiments, the data collection package (3308) may include precursor data that can be utilized to regenerate a number of data sets — e.g., but not limited to: a raw data stream supporting a number of virtual sensors and / or various processed values, state determinations; a high sampling rate data stream supporting a number of requests for the data stream at different sampling rates; and / or a normalized data stream supporting a number of requests for functionally identical data in a distinct end format accessed by the requesting user based on the characteristics of the data from the requesting user (e.g., resolution, units, parameter names, etc.).In additional examples, redundancy management operations (e.g., by the data collection package redundancy management (3510) component) may provide a smaller data set that can be utilized to regenerate multiple requested data sets, wherein the smaller data set is stored and / or communicated as a data collection package (3308). In such embodiments, the data collection package storage (3506) component stores the smaller data set, and information sufficient to regenerate multiple requested data sets is stored in the data collection package (3308) and / or referenced in the data collection package (3308) and communicated with the data collection package (3308). In certain embodiments, information for regenerating requested data sets from a compressed data collection package (3308) (e.g., based on a smaller data set, a compressed data set, and / or precursor data), information sufficient to regenerate the requested data, and / or information for decompressing the data collection package (3308) may be communicated with the data collection package (3308) by referencing utilized operations and / or utilizing accepted conventions, which may further reduce the data stored and / or communicated to support the operations of the policy reporting circuit (3306).

[0186] An exemplary policy reporting circuit (3306) includes a streaming recovery management (3508) component that performs a streaming recovery operation in response to a interruption in communicating the data collection package (3308) to an external device. For example, communication operations may be interrupted for any reason, such as by a vehicle shutdown event, due to loss of network communications (which may be intermittent), due to increased activity on the network and / or external communication device (e.g., due to vehicle operations), and / or due to competing resource interest from higher priority communications. An exemplary streaming recovery operation includes utilizing a memory buffer to communicate the data collection package (3308), allowing a repetition of any lost data to be communicated after the communications are restored. In certain embodiments, for example, in the case of important data collection packages (3308) as defined in the policy, the streaming recovery operation includes formal confirmation of what information has been received (e.g., with the receiving external device), which causes the policy reporting circuit (3306) to resume communication of the data collection package (3308) while ensuring that the data is complete. In certain embodiments, the streaming recovery operation is performed optimistically, for example, assuming that the last communication to the data collection package (3308) has been received, and the policy reporting circuit (3306) resumes communication of the data collection package (3308) from the last transmitted message when communication is resumed.In certain embodiments, for example, when a memory buffer is not utilized and / or is not available, streaming recovery operations may include restarting the data collection package (3308), utilizing a pointer to the data collection package (3308) to track which parts have been transmitted, and / or canceling the communication of data (e.g., when the data collection package (3308) is unimportant and / or old, and / or when the data collection package (3308) is available in a partial form and most of the data collection package (3308) has been previously transmitted). In certain embodiments, applicable streaming recovery operations are considered as factors in determining the basketing method for the system, and / or iterative improvement operations for the basketing method further consider adjustments to the applicable streaming recovery operations for the baskets. In certain embodiments, the streaming recovery management (3508) component may additionally or alternatively form part of the policy execution circuit (2506) and / or support the policy execution circuit (2506).

[0187] An exemplary policy reporting circuit (3306) includes a data collection package redundancy management (3510) component configured to perform a redundancy management operation in response to determining that at least two policies in a vehicle have a shared collection data element. The shared collection data element may be a literal data redundancy (e.g., there are data values ​​identical to those stored in the data collection package and / or transmitted in response to each policy) or a raw data redundancy (e.g., the same raw data values ​​are the source of truth of at least part of the data collection package and / or transmitted in response to each policy—e.g., where the stored / transmitted data is determined from the same raw data and / or processed for resolution, units, etc.). Examples of shared collected data elements describe literal redundancy and raw data redundancy, but it will be understood that redundancy may be intermediate, for example, where data may undergo multiple processing operations, redundancy extends through multiple processing operations rather than all of them, and / or where data is precursor data for one or more of the supported policies. Redundancy management operations are considered to utilize raw data prior to any processing and / or utilize intermediate portions of data as pseudo-raw data for redundancy management operations. Redundancy management operations are described in the context of data collected for policies, but may be applied additionally or alternatively to any data collected by the system for any purpose, including intermediate data (e.g., utilized for trigger analysis). In certain embodiments, redundancy management operations may include coordinating basket methods (e.g., combining data from relevant policies into the same data collection package (3308) and / or stored collected data (2518)), so that data is stored and / or communicated only once.In the case of literal data redundancy, packaging shared data elements into the same data structure (e.g., within a package and / or stored data) is sufficient to reduce redundancy, and a reference to which aspects of the data collection package (3308) and / or stored collected data (2518) potentially respond to which policies of the basket is sufficient. In the case of raw data redundancy, redundancy management operations may include storing subsequent processing information for converting the redundant raw data into requested literal data that responds to the policy, and the subsequent processing information includes separate processing information for each policy that is a member of the redundancy group. Exemplary and non-restrictive processing includes upsampling or downsampling operations to be performed, unit conversions to be applied, resolution adjustments, virtual sensor parameters, etc. In certain embodiments, the subsequent processing information may be self-evident (e.g., differences in units) and / or may be communicated by referencing operations and / or utilizing accepted conventions (similar to the operations of the data collection package repository (3506) component described above). In certain embodiments, applicable redundancy management actions are considered as factors in determining the basketing method for the system, and / or iterative improvement actions for the basketing method additionally consider adjustments to the applicable redundancy management actions for the baskets. In certain embodiments, the data collection package redundancy management (3510) component may additionally or alternatively form part of the policy execution circuit (2506) and / or support the policy execution circuit (2506).

[0188] Referring to FIG. 36, a vehicle (3602) is illustrated as comprising a plurality of network zones, each network zone having a plurality of endpoints located thereon. The vehicle includes a controller (2501) and a convergence network device (CND). The network zones include a first network zone (3604), a second network zone (3606), and a third network zone (3608). The controller (2501) is configured to regulate communications between network zones and to manage data collection from endpoints within each network zone. In certain embodiments, endpoints on networks / zones communicate data values ​​to one another, wherein the provided and / or requested data may be continuous, intermittent, and / or request-based, and the data may be utilized synchronously (e.g., the data is expected to be contemporary data describing current operating conditions) or asynchronously (e.g., the data is utilized in a process such as long-term analysis, where the data does not need to be contemporary but may need to be time-ordered and / or high-rate data).

[0189] Referring to FIG. 37, the controller (2501) is illustrated as including a data support circuit (3702) configured to determine a shared data description (3710) containing vehicle data values. In embodiments, an automation description (3720) may also be provided. The vehicle data values ​​include data provided by potential data source endpoints (e.g., during normal operations, at least during specific operating conditions and / or upon request, where data is expected to be provided by potential data source endpoints) and data utilized by potential data destination endpoints (e.g., during normal operations, at least during specific operating conditions and / or upon request, where data is expected to be utilized by potential data source endpoints). The data processing circuit (3704) is configured to generate a data collection description (3712) in response to the shared data description and to determine a memory allocation value (3714) in response to the data collection description. In certain embodiments, the shared data description (3710) may be determined in response to the vehicle policy data value (2508), which essentially allows the user to define a shared data block that can be utilized by endpoints within the system.

[0190] The data collection description (3712) defines the parameters to be collected, any processing to be performed on the data before sharing with other endpoints, and the lifecycle of the stored data to support potential data destination endpoints. For example, the data processing circuit (3704) determines the data values ​​to be included in the shared data description (3710), how much data should be retained (e.g., 1 second of data, 30 seconds of data, etc., where the values ​​may vary depending on each data element and how they are provided and utilized by the system), and the memory allocation value (3714) to support the shared data. If processing is performed on the data according to the data collection description (3712), the memory allocation value (3714) will additionally consider any intermediate memory utilization to support such processing operations. A data collection execution circuit (3706) is configured to collect vehicle data (2512) from one or more endpoints in response to a data collection description (3712) and to store at least a portion of the collected vehicle data as stored collected data (3716) in response to a memory allocation value. A data sharing support circuit (3708) is configured to provide response data (3718) from the collected vehicle data (e.g., if the data is contemporary and available) or the stored collected vehicle data to a data destination endpoint. An optional data layer reporting circuit (3722) is configured to perform at least one of creating a data collection package (3724), storing the data collection package, or communicating the data collection package to an external device, for example, to allow a user to review the data collection description (3712), the memory allocation value (3714), and / or the stored collected data (3716) to diagnose, troubleshoot, and / or iteratively improve the operations of the shared data operations of the embodiment of FIG. 37.In certain embodiments, the data sharing support circuit (3708) may publish the data collection package (3724) as a service and / or automatically subscribe destination endpoints to the shared data to implement shared data operations without interfering with the operations of the vehicle. In certain embodiments, some or all of the data communicated between endpoints on the vehicle may be managed using the shared data description (3710).

[0191] Referring to FIG. 38, the data support circuit (3702) is illustrated as including various analysis components. An exemplary component includes a data collection support analysis (3802) which determines data collection responsibilities for endpoints on the vehicle, for example, to service policies or other data collection actions. An exemplary component includes an automation description support analysis (3804) component which determines data sharing and / or data collection responsibilities between endpoints on the vehicle to service automation actions that may be provided by policies, for example. An exemplary component includes a vehicle policy data value analysis (3806) component which determines shared data between endpoints and determines common data elements, etc., to support policies implemented in the vehicle. An exemplary component includes a network zone analysis (3808) which determines which messages are being transmitted on which networks, for example, repetitive communications, high-utilization messages, etc., which may be good candidates for inclusion in the shared data description (3710). An exemplary component includes a vehicle flow analysis (3810) component, which determines message traffic responding to flows on the vehicle, including, for example, the locations of endpoints that are the sources and destinations of communications to support the flow. The exemplary vehicle flow analysis (3810) component can determine whether communications to support the vehicle flow can be supported more efficiently and / or more reliably by utilizing a shared data description (3710) to centralize such communications and provide a common data repository (stored collected data (3716)).Additionally, utilizing the shared data description (3710) to support the operations of the vehicle flow can provide additional options for optimizing and / or iteratively enhancing the vehicle flow and / or resolving issues of the vehicle flow by providing the shared data as a data collection package (3724), allowing granular analysis of the data available to endpoints supporting the vehicle flow, and / or allowing post-processing of the operations of the vehicle flow. An exemplary component includes a vehicle application analysis component that operates similarly to the vehicle flow analysis (3810) component. An exemplary component includes a network zone analysis (3808) component, for example, determining message traffic in a network zone and determining whether the shared data description (3710) can support enhancements for the network zone (e.g., by allowing some communications to be moved to another network zone, by time-shifting some communications where permissible, and / or by reducing a number of communications from an endpoint where the destination can rarely utilize some or all of such communications). An exemplary component includes an endpoint analysis (3814). An exemplary component includes an asynchronous utilization analysis (3816) component, which determines message traffic that may be significantly time-shifted, for example, and is intended for long-term analysis that may be performed, for example, after a significant amount of time has passed since data was generated. Additionally, the asynchronous utilization analysis (3816) component can ensure that data is preserved with sufficient sampling rates, resolution, and sufficiently continuous data strings to support asynchronous operations. The exemplary components are non-limiting, and the classification of specific operations is a non-limiting example to illustrate aspects of the data support circuit (3702).The data support circuit (3702) is configured to determine a shared data description in response to analyses performed by these components and supports efficient data collection and sharing within the network zones of the vehicle. The examples of FIGS. 37 and 38 provide a hidden data layer that can be utilized to significantly improve the ability to diagnose and solve problems in the vehicle and / or to perform network management and configuration, and long-term iterative improvements to underlying control algorithms operating at vehicle endpoints.

[0192] Referring to FIG. 39, the device is illustrated and includes a controller (2501) comprising a policy acquisition circuit (2502) configured to interpret a vehicle policy data value (2508) including a data collection trigger condition (3902). A policy processing circuit (2504) is configured to generate parsed policy data (2516) including a data collection trigger condition and a policy lifecycle description (3904). A policy execution circuit (2506) is configured to collect vehicle data (2512) from one or more vehicle endpoints in response to the parsed policy data. The collected data is stored as stored collected data (2518) and may be communicated via external communications (2514). A policy reporting circuit (3306) is configured to generate a data collection package (3308) in response to the collected vehicle data. An authorization value (2520) may also be included in the vehicle policy data value. A memory allocation value (3304) is determined in response to the parsed policy data.

[0193] Referring to FIG. 40, an exemplary policy lifecycle description (3904) is described in more detail, including a policy trigger condition (4001) and an on-demand policy lifecycle (4002). The policy trigger condition (4001) may include any type of trigger condition and / or analysis to determine when the policy should be activated after installation, and may include an external event trigger condition (2510). An exemplary on-demand policy lifecycle (4002) includes: monitoring a data collection trigger condition until the next vehicle shutdown (4004) (e.g., the policy is immediately activated and deactivated at the next vehicle shutdown); monitoring a data collection trigger condition until a single data collection event (4006) is performed (e.g., the policy is immediately activated and deactivated after the data collection trigger occurs and the data collection action is performed); and / or one or more of monitoring data collection trigger conditions until a selected number of data collection events (4008) are performed (e.g., the policy is immediately activated and deactivated after a specified number of collection events, wherein the data collection trigger may be applicable every time before collection, or all collection events may follow a single occurrence of the data collection trigger). An exemplary policy lifecycle description (3702) includes a start sequencing parameter (4010) (e.g., start at 10:00 AM, start one hour after the next trip starts, start 10 seconds after the vehicle speed reaches 30 mph, etc., wherein the sequencing parameter may be time-based and / or any other sequencing parameter described herein); a stop sequencing parameter (4012) (e.g., a time and / or other sequencing parameter defining a stop time for collection); and / or a sequencing parameter window (4014) (e.g., a start / stop time or other sequencing parameter). The exemplary actions are non-limiting and intended to illustrate aspects of the present disclosure.

[0194] As used herein, the terms mission, vehicle mission, or other similar terms should be understood broadly. As utilized herein, mission refers to any one of: primary function; intended function; critical function; and / or minimum possible function (e.g., function required for operations to be considered normal and / or acceptable for allowing continued operation). For example, the vehicle mission may vary depending on the vehicle's current operating conditions and / or the vehicle's intended use. For example, the vehicle mission may include the ability to provide propulsion and / or propulsion operations, and may further include performance descriptions such as minimum available output, torque, and / or vehicle speed (e.g., these may be equal to or lower than the rated values ​​of such items). In another example, the mission may be the ability to provide power and / or functionality for the vehicle's system—e.g., lighting, communication operations, holding operations, cabin environment operations, etc. In certain embodiments, some level of operation of the vehicle or component may be available, wherein the vehicle or component may not be capable of performing the mission—for example, propulsion operation is available but is below acceptable performance characteristics for the vehicle. In certain embodiments, mission-related aspects may not affect the performance of the vehicle but may nevertheless be essential to the mission—for example, the loss of airbag function, ABS function, etc. may not impede the operation of the mission (e.g., propulsion operation), but may nevertheless be considered essential to the mission for the vehicle to continue operating in an acceptable manner.It may be understood that the mission of a vehicle, component, control action, or similar thing may vary depending on the context of the vehicle, including design considerations, the purpose of the vehicle, policies and / or preferences of entities associated with the vehicle (e.g., fleet owners, vehicle owners, regulatory bodies, etc.), the geographical location of the vehicle, and / or the terrain location of the vehicle (e.g., current elevation, gradient, road type, etc.). A data value or other feature may be essential to and / or mission-related to mission performance in a first vehicle but not in a second vehicle, and / or may be so at a first time for a given vehicle but not at a second time for a given vehicle. A person skilled in the art who has the benefits of this disclosure and information ordinarily available regarding vehicles and their components can easily determine whether a data value, control action, component, or other element of a system is essential to and / or mission-related to mission performance. Specific considerations for determining whether data values, control actions, components, or other elements of a system are essential to and / or mission-related to mission performance include, without limitation: the class of the vehicle, the intended use of the vehicle, quality of service requirements associated with the vehicle, warranty descriptions of the vehicle or its components, the expected duty cycle for the vehicle, the geographical area of ​​operation of the vehicle, the terrain area of ​​operation of the vehicle, regulatory requirements associated with the vehicle, and / or policy considerations associated with the vehicle.

[0195] The exemplary trigger evaluation operations in this specification support any type of analysis or decision operations, including at least: basic logical operators (e.g., AND, OR, numeric comparisons, etc.); nested logical expressions with appropriate formatting (e.g., ((X > 5 && Y < 10) || Z != 100) && P < 0.05); mathematical functions (e.g., arithmetic, exponentiation, trigonometric functions, modulo, gamma, etc.); and / or complex data transformation functions over a data range (e.g., median; mean; standard deviation; map; reduce; min / max; bucketing; filtering; consolidation; differentiation; and / or frequency analysis operations). Additionally or alternatively, trigger evaluation operations may be ordered, looped, and / or executed in parallel.

[0196] Exemplary and non-limiting procedures for performing enhanced data collection, advanced triggering methods related to data collection and / or automation operations, and supporting operations for data collection are described below. The described procedures may be performed wholly or partially by any of the systems, circuits, computing devices, or other components described throughout this disclosure. A given system may utilize any one or more of the procedures wholly or partially, and the described procedures provide examples for performing specific operations described in this disclosure.

[0197] An exemplary procedure includes an action of interpreting a vehicle policy data value containing an external event trigger condition, an action of generating parsed policy data containing the external event trigger condition, and an action of collecting vehicle data from one or more vehicle endpoints in response to the parsed policy data. Exemplary and non-restrictive external event trigger conditions include one or more of a traffic condition value, a weather condition value, and / or a road condition value.

[0198] In additional examples, the procedure includes an action of collecting vehicle data in response to an authorization value associated with a vehicle policy data value. Exemplary and non-restrictive authorization values ​​may correspond to the request entity, vehicle type value, and / or data type value of the collected data for the vehicle policy data value. The authorization value may represent the authorization of the requester to collect data, or the authorization required for the type of data (or specific data elements) being collected.

[0199] Exemplary external event trigger conditions include location values, wherein the procedure further includes an action to collect vehicle data in response to the location values. Exemplary and non-restrictive location values ​​include jurisdiction descriptions, elevation values, climate values, and / or season values. Exemplary locations include settlement descriptions. Exemplary external event trigger conditions include mission type values, wherein the procedure further includes an action to collect vehicle data in response to the mission type values.

[0200] In some aspects, the techniques described in this specification relate to methods, and the location values ​​include descriptions of jurisdictional areas.

[0201] Another exemplary procedure includes the action of interpreting at least one vehicle data collection description and a target vehicle description, the action of determining at least one vehicle policy data value in response to at least one vehicle data collection description and a target vehicle description, and the action of determining a group of vehicles in response to a target vehicle description. The exemplary procedure further includes the action of providing at least one vehicle policy data value to a group of vehicles (and / or providing modified versions of the vehicle policy data value to selected vehicles in a group of vehicles), and the action of receiving identified vehicle data and / or warning response values ​​in response to at least one vehicle policy data value.

[0202] In additional examples, the action of determining a group of vehicles is performed in response to shared vehicle attributes. Exemplary and non-restrictive shared vehicle attributes include vehicle configuration values, vehicle part values, and / or vehicle feature values. Additionally or alternatively, exemplary and non-restrictive shared vehicle attributes include owner values, manufacturer values, OEM values, fleet values, body builder values, and / or dealer values. Additionally or alternatively, exemplary and non-restrictive shared vehicle attributes include maintenance values, diagnostic values, recall values, and / or fault code values. Additionally or alternatively, exemplary and non-restrictive shared vehicle attributes include associated entity type values ​​and / or vehicle type values.

[0203] Another exemplary procedure includes an action of implementing a user data collection interface, an action of interpreting at least one vehicle data collection description and a target vehicle description in response to user policy builder interactions with the user data collection interface, and an action of determining at least one vehicle policy data value in response to at least one vehicle data collection description and a target vehicle description. The exemplary procedure further includes an action of determining a group of vehicles in response to a target vehicle description, and an action of providing at least one of the vehicle policy data values ​​to a group of vehicles in response to user policy implementation interactions with the user data collection interface.

[0204] In some aspects, the techniques described herein relate to a method, further comprising displaying a recipe library in a user data collection interface and interpreting at least one vehicle data collection description in response to user interactions with the recipe library.

[0205] In additional examples, the procedure includes an action of displaying at least one normalized data parameter in a user data collection interface. Exemplary and non-restrictive normalized data parameters include one or more of manufacturer parameters, industry standard parameters, simplified parameters, and / or user-defined parameters.

[0206] In additional examples, the procedure includes an action of displaying a policy summary in the user data collection interface. Exemplary and non-restrictive policy summaries include: an active recipe description, a pending recipe description, an active trigger description, a pending trigger description, and / or one or more logical flow diagrams associated with at least one vehicle data collection description.

[0207] In additional examples, the procedure includes the action of receiving at least a portion of identified vehicle data in response to at least one vehicle policy data value, and / or the action of receiving a warning response value in response to at least one vehicle policy data value. Additional exemplary procedures include the action of updating a policy summary in a user data collection interface in response to the received data and / or the received warnings.

[0208] An exemplary procedure includes the operation of interpreting a vehicle policy data value including a data collection description, the operation of generating parsed policy data corresponding to the data collection description, the operation of determining a memory allocation value in response to the parsed policy data, the operation of collecting vehicle data from one or more vehicle endpoints in response to the parsed policy data, and the operation of storing at least a portion of the collected vehicle data in response to the memory allocation value.

[0209] In an additional example, the procedure includes a memory allocation value as a fixed value determined in response to parsed policy data, and / or determines the memory allocation value in response to an authorization value associated with the vehicle policy data value.

[0210] In additional examples, the procedure includes a memory allocation value as a dynamic value determined in response to parsed policy data, and / or determines the memory allocation value in response to an authorization value associated with the vehicle policy data value. An exemplary procedure includes a vehicle policy data value comprising at least one policy among a plurality of policies, and determines the memory allocation value as a shared memory value to support a basket of policies selected from the plurality of policies. The shared memory value to support the basket of policies may allow for a smaller memory allocation to support all policies within the basket and is determined by the following operations: a probabilistic operation in response to parsed policy data for each policy within the basket; adjusting the shared memory value in response to a trigger correlation analysis for the policies within the basket; analyzing historical data collection operations in a vehicle having a controller performing the procedure (wherein the historical data collection operations relate to identical policies, offset policies, and / or individual collection or processing modes of identical policies or offset policies—e.g., for determining intermediate memory support values); Analyzing historical data collection operations in an offset vehicle; and / or selecting a basket distribution of policies by utilizing any one or more of the foregoings. An exemplary procedure includes an operation to adjust shared memory values ​​using historical data collection operations in a vehicle and / or an offset vehicle, including adjusting the basket distribution of policies and / or adjusting memory allocation values.

[0211] In additional examples, the procedure includes the action of creating a data collection package in response to collected vehicle data, and the action of performing at least one of storing the data collection package or communicating the data collection package to an external device. An exemplary procedure includes including a package identifier with the data collection package. Exemplary and non-limiting package identifiers include one or more of: an identifier for a policy including a vehicle policy data value; an identifier for a trigger of a policy including a vehicle policy data value; or technical metadata for the package. An exemplary procedure includes the action of including at least a portion of a flow log in the package, and / or the action of including a vehicle condition log in the package.

[0212] In additional examples, the procedure includes an action to perform a streaming recovery action in response to an interruption of communicating a data collection package to an external device. Exemplary and non-limiting streaming recovery actions include: buffering at least a portion of the data collection package; determining whether a portion of the data collection package has been transmitted (and / or assuming that a communicated portion has been transmitted); and / or resuming a streaming action for the data collection package after communications and / or vehicle actions have been restored.

[0213] In additional examples, the procedure includes the action of creating a separate data collection package for each trigger occurrence of a selected trigger of a policy containing vehicle policy data values. Additionally or alternatively, the procedure includes the action of attaching newly collected data to a previously existing data collection package in response to a selected trigger occurrence. Additionally or alternatively, the procedure includes the action of preparing a data collection package after one or more trigger occurrences, and the action of creating separate data collection packages for additional trigger occurrences and / or attaching additional data collection values. In certain embodiments, the data collection package contains all data for the policy (e.g., waiting until the policy is no longer active before preparing and communicating the data collection package). In certain embodiments, the data collection package is not communicated out of the vehicle, but is instead held in memory to be available to a user connecting to the vehicle and / or a user providing a request for the data to be communicated out of the vehicle.

[0214] In additional examples, the procedure includes an action to perform a redundancy management action in response to determining that two (or more) policies have a shared data element. The shared data element may be literal data redundancy (e.g., the existence of data values ​​identical to those stored in a data collection package and / or transmitted in response to each policy) or raw data redundancy (e.g., the existence of original sources where identical raw data values ​​exist in at least a portion of the data collection package and / or transmitted in response to each policy—e.g., the stored / transmitted data is determined from the same raw data and / or processed, such as for resolution, units, etc.). In certain embodiments, the determination of raw data redundancy may be more efficient for the purposes of collecting, storing, and / or transmitting data, but additional processing power may be utilized to determine that the same raw data values ​​are the original sources of the response data for each policy. Accordingly, embodiments of this specification may utilize redundancy management, and in the case of embodiments utilizing it, redundancy management may be applied to literal data redundancy, raw data redundancy, or both (e.g., depending on data type, operations performed to convert between literal data and raw data, memory utilization, network utilization, or processing utilization being limiting factors and / or causing cost and / or complexity of the system, etc.). Additionally, the utilization of redundancy management may vary depending on the operating conditions of the vehicle (e.g., operating conditions that increase network traffic may change the utilization of redundancy management), and / or the state of vehicle components (e.g., available memory and / or current memory utilization). In certain embodiments, redundancy management may be utilized to limit data collection values ​​actually collected, data collection values ​​stored, and / or data collection values ​​transmitted out of the vehicle.

[0215] An exemplary procedure includes an action of determining a shared data description containing vehicle data values. In the example, each of the vehicle data values ​​is a data value provided by a potential data source endpoint (e.g., during runtime, the data value may be provided or may be provided by the data source endpoint) and / or a value based on such data values. In additional examples, each of the vehicle data values ​​is utilized by a potential data destination endpoint (e.g., during runtime, the data value may be utilized by the data destination endpoint during at least certain operational conditions or states). The exemplary procedure further includes an action of generating a data collection description in response to the shared data description and determining a memory allocation value in response to the data collection description. The exemplary procedure further includes an action of collecting vehicle data from endpoints in response to the data collection description, and an action of storing at least a portion of the collected vehicle data in response to the memory allocation value. The exemplary procedure further includes an action of providing response data from the collected data and / or stored data to the data destination endpoint. The exemplary procedure provides ease of data sharing between endpoints, reduces the knowledge required to configure endpoints to utilize available data, and allows for ease of data management operations to determine, for example, how much data is utilized in the system, how often data is utilized, and which endpoints utilize the data.The exemplary procedure simplifies data availability for asynchronous features (e.g., destination endpoints can utilize data in batches, after a delay period, etc.), which enables the system to provide sufficient data storage to support asynchronous data utilization without excessive design and / or without imposing additional capabilities, such as additional buffering memory storage, on destination endpoints and / or controllers performing operations for destination endpoints. The exemplary procedure creates a type of hidden data layer accessible to endpoints to allow for rapid system design and / or rapid and highly reliable system updates. In certain embodiments, the shared data description is determined to support specific operations that utilize data sharing between endpoints as described in the specification for such operations, such as determining the shared data description in response to automation descriptions and / or vehicle policy data values. In certain embodiments, the shared data description is determined based on an analysis of operations, utilizing, for example, code analysis, empirical observation of network traffic, endpoint communications, etc. Exemplary actions include determining a shared data description by performing one or more of the following actions: analyzing vehicle applications, analyzing vehicle flows, analyzing one or more network zones of a vehicle, and / or analyzing one or more endpoints (e.g., tracing source and / or destination messages for endpoints to determine parameters utilized by / or utilized by endpoints or sourced from endpoints).

[0216] In an additional example, utilization by potential data destination endpoints is asynchronous utilization, where the determination of the shared data description is performed in response to an analysis of the asynchronous utilization (e.g., time offsets, frequency with which asynchronous operations are performed, amount of data between collected data and asynchronous operations, and / or any required time relationship, etc.).

[0217] In additional examples, the procedure includes an action of generating a data collection package in response to collected and / or stored vehicle data. The generated data collection package may be stored / stored or communicated to an external device. The data package may include any aspects described in the present disclosure, such as a package identifier; the data package may be published as a service on the vehicle; endpoints (and / or flows, applications, or features) may subscribe to the data package; and / or the procedure may include actions of automatically publishing the data package from source endpoints and subscribing destination endpoints to the data package to implement shared data description actions.

[0218] In some aspects, the techniques described herein relate to a method and further include generating a data collection package in response to at least one of collected vehicle data or stored collected vehicle data. Without limitation to any other aspects of the disclosure, exemplary package identifiers include: an identifier for an automation description used to determine a shared data description; an identifier for a vehicle policy data value used to determine a shared data description; an analysis description for an analysis used to determine a shared data description; or one or more of technical metadata for the package.

[0219] An exemplary procedure includes an action of interpreting a vehicle policy data value including a data collection trigger condition, an action of generating parsed policy data including a data collection trigger condition and a policy lifecycle description, and an action of collecting vehicle data from one or more vehicle endpoints in response to the parsed policy data. Exemplary and non-limiting policy lifecycle descriptions include a policy trigger condition, wherein the procedure further includes an action of initiating monitoring of the data collection trigger condition in response to the policy trigger condition. An exemplary policy lifecycle description includes an on-demand policy lifecycle and includes monitoring the data collection trigger condition by performing the following actions: monitoring the data collection trigger condition until the next vehicle shutdown; monitoring the data collection trigger condition until a single data collection event is performed in response to the data collection trigger condition; and / or monitoring the data collection trigger condition until a selected number of data collection events are performed in response to the data collection trigger condition. An exemplary policy lifecycle description includes a start time (or start sequencing parameter), a stop time (or stop sequencing parameter), and / or a time window (or sequencing parameter window). Time and / or sequencing parameter values ​​can be used as absolute and / or relative values.

[0220] The methods and systems described herein may be distributed in part or wholly through a machine having computer-readable instructions, program codes, a computer, computing device, processor, circuit, and / or server executing the instructions, and / or may include hardware configured to functionally execute one or more operations of the methods and systems of this specification. As used herein, the terms computer, computing device, processor, circuit, and / or server (“computing device”) should be understood broadly.

[0221] An exemplary computing device comprises any type of computer that is accessible to instructions stored on a non-transient computer-readable medium and accessible to the computer via communication, and the computer performs operations of the computing device when executing the instructions. In certain embodiments, such instructions themselves constitute the computing device. Additionally or alternatively, the computing device may be a separate hardware device, one or more computing resources distributed across hardware devices, and / or may include aspects such as logic circuits, embedded circuits, sensors, actuators, input and / or output devices, network and / or communication resources, any type of memory resources, any type of processing resources, and / or hardware devices configured to respond to conditions determined to functionally execute one or more operations of the systems and methods of this specification.

[0222] Network and / or communication resources include, without limitation, local area networks, wide area networks, wireless, the Internet, or any other known communication resources and protocols. Exemplary and non-limiting hardware and / or computing devices include, without limitation, general-purpose computers, servers, embedded computers, mobile devices, virtual machines, and / or emulated computing devices. A computing device may be a distributed resource included as an aspect of multiple devices, and may be included as a set of interoperable resources for performing the described functions of the computing device, so that the distributed resources function together to perform the operations of the computing device. In certain embodiments, each computing device may be on separate hardware, and / or one or more hardware devices may include more than one aspect of the computing device, for example, logically partitioned aspects of separately executable instructions and / or sets of executable instructions stored on the device, some aspects constituting part of one of the first computing devices and some aspects constituting part of one of the other computing devices.

[0223] A computing device may be a server, client, network infrastructure, mobile computing platform, static computing platform, or part of another computing platform. A processor may be any type of computing or processing device capable of executing program instructions, codes, binary instructions, etc. A processor may be any variant such as a signal processor, digital processor, embedded processor, microprocessor, or co-processor (mathematical co-processor, graphics co-processor, communication co-processor, etc.), or may include such a component, which may directly or indirectly facilitate the execution of stored program code or program instructions. Additionally, a processor may enable the execution of multiple programs, threads, and codes. Threads may be executed concurrently to improve the performance of the processor and facilitate the concurrent operation of applications. As an implementation, the methods, program codes, program instructions, etc. described herein may be implemented in one or more threads. A thread may generate other threads to which associated priorities are assigned; and the processor may execute these threads based on priorities or any other order based on instructions provided in the program code. The processor may include memory for storing methods, codes, instructions, and programs as described herein and elsewhere. The processor may access a storage medium through an interface capable of storing methods, codes, and instructions as described herein and elsewhere. A storage medium associated with the processor for storing methods, programs, codes, program instructions, or other types of instructions executable by a computing or processing device may include, but is not limited to, one or more of CD-ROMs, DVDs, memory, hard disks, flash drives, RAM, ROM, caches, etc.

[0224] The processor may include one or more cores capable of improving the speed and performance of the multiprocessor. In embodiments, the processor may be a dual-core processor, a quad-core processor, other chip-level multiprocessor, etc., combining two or more independent cores (referred to as dies).

[0225] The methods and systems described herein may be deployed, in part or wholly, through a machine executing computer-readable commands on a server, client, firewall, gateway, hub, router, or other such computer and / or networking hardware. Computer-readable commands may be associated with a server including variations such as a file server, print server, domain server, internet server, intranet server, and secondary server, host server, distributed server, etc. A server may include one or more of memories, processors, computer-readable transient and / or non-transient media, storage media, ports (physical and virtual), communication devices, and interfaces that can access other servers, clients, machines, and devices via wired or wireless media. The methods, programs, or codes described herein and elsewhere may be executed by a server. Additionally, other devices required for the execution of the methods described in this application may be considered as part of the infrastructure associated with the server.

[0226] The server may provide interfaces to other devices, including, without limitation, clients, other servers, printers, database servers, print servers, file servers, communication servers, distributed servers, etc. Additionally, such combination and / or connection may facilitate the remote execution of commands over a network. Networking of some or all of these devices may facilitate the parallel processing of program code, commands, and / or programs at one or more locations without going beyond the scope of disclosure. Furthermore, all devices connected to the server via an interface may include at least one storage medium capable of storing methods, program code, commands, and / or programs. A central repository may provide program commands to be executed on different devices. In such an implementation, a remote repository may function as a storage medium for methods, program code, commands, and / or programs.

[0227] Methods, program code, instructions, and / or programs may be associated with a client, which may include file clients, print clients, domain clients, internet clients, intranet clients, and other variations such as secondary clients, host clients, distributed clients, etc. The client may include one or more of memories, processors, computer-readable transient and / or non-transient media, storage media, ports (physical and virtual), communication devices, and interfaces that can access other clients, servers, machines, and devices via wired or wireless media. The methods, program code, instructions, and / or programs described herein and elsewhere may be executed by the client. Additionally, other devices required for the execution of the methods described in this application may be considered as part of the infrastructure associated with the client.

[0228] The client may provide an interface to other devices, including, without limitation, servers, other clients, printers, database servers, print servers, file servers, communication servers, distributed servers, etc. Additionally, such combination and / or connection may facilitate the remote execution of methods, program code, instructions, and / or programs over a network. Networking of some or all of these devices may facilitate the parallel processing of methods, program code, instructions, and / or programs at one or more locations without departing from the scope of this disclosure. Furthermore, all devices connected to the client via an interface may include at least one storage medium capable of storing methods, program code, instructions, and / or programs. A central repository may provide program instructions to be executed on different devices. In such an implementation, a remote repository may function as a storage medium for methods, program code, instructions, and / or programs.

[0229] The methods and systems described herein may be deployed partially or wholly through network infrastructures. Network infrastructure may include elements such as computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices, and other active and passive devices, modules, and / or components known to those skilled in the art. Computing and / or non-computing device(s) associated with network infrastructure may include storage media such as flash memory, buffers, stacks, RAM, ROM, etc., apart from other components. The methods, program codes, instructions, and / or programs described herein and elsewhere may be executed by one or more of the network infrastructure elements.

[0230] The methods, program codes, instructions, and / or programs described herein and elsewhere may be implemented on a cellular network having a plurality of cells. The cellular network may be a Frequency Division Multiple Access (FDMA) network or a Code Division Multiple Access (CDMA) network. The cellular network may include mobile devices, cell sites, base stations, repeaters, antennas, towers, etc.

[0231] The methods, program code, instructions, and / or programs described herein and elsewhere may be implemented on or through mobile devices. Mobile devices may include navigation devices, cell phones, mobile phones, mobile personal digital assistants, laptops, palmtops, netbooks, pagers, e-book readers, music players, etc. These devices may include, apart from other components, storage media such as flash memory, buffers, RAM, ROM, and one or more computing devices. Computing devices associated with mobile devices may be capable of executing methods, program code, instructions, and / or programs stored thereon. Alternatively, mobile devices may be configured to execute instructions in cooperation with other devices. Mobile devices may interface with servers and communicate with base stations configured to execute methods, program code, instructions, and / or programs. Mobile devices may communicate over peer-to-peer networks, mesh networks, or other communication networks. Methods, program code, instructions, and / or programs may be stored on a storage medium associated with a server and executed by a computing device embedded within the server. A base station may include a computing device and a storage medium. The storage device may store methods, program code, instructions, and / or programs executed by computing devices associated with the base station.

[0232] Methods, program codes, instructions, and / or programs may be stored and / or stored or accessed on machine-readable ephemeral and / or non-ephemeral media, which include: computer components, devices, and recording media that hold digital data used for computing for a period of time; semiconductor storage known as random access memory (RAM); mass storage for generally more permanent storage, such as optical discs and forms of magnetic storage, such as hard disks, tapes, drums, cards, and other types; processor registers, cache memory, volatile memory, non-volatile memory; optical storage such as CDs and DVDs; removable media such as flash memory (e.g., USB sticks or keys), floppy disks, magnetic tapes, paper tapes, punch cards, standalone RAM disks, Zip drives, removable mass storage, offline, etc.; It may include other computer memories such as dynamic memory, static memory, read / write storage, variable storage, read-only, random access, sequential access, location addressable, file addressable, content addressable, network-attached storage, storage area networks, barcodes, magnetic ink, etc.

[0233] The specific operations described herein include interpreting, receiving, and / or determining one or more values, parameters, inputs, data, or other information (“receiving data”). Operations of receiving data include, without limitation: receiving data via user input; receiving data via any type of network; reading a data value from a memory location communicating with a receiving device; utilizing a default value as the received data value; estimating, calculating, or deriving a data value based on other information available to the receiving device; and / or updating any of these in response to a later received data value. In specific embodiments, the data value may be received by a first operation and may be updated later by a second operation as part of receiving the data value. For example, the first receiving operation may be performed when communications are interrupted, intermittent, or broken, and the updated receiving operation may be performed when communications are restored.

[0234] Specific logical groups of operations in this specification, e.g., methods or procedures of this disclosure, are provided to illustrate aspects of this disclosure. The operations described in this specification are described and / or illustrated in a schematic manner, and operations may be combined, separated, reordered, added, or removed in a manner consistent with the disclosure of this specification. While the context of the description of operations may require an order of one or more operations and / or an order of one or more operations may be explicitly disclosed, the order of operations is to be understood broadly, and it is understood that any equivalent group of operations to provide equivalent results of operations is specifically considered in this specification. For example, where a value is used in one operation step, the determination of the value may be required prior to that operation step in certain contexts (e.g., where a time delay of data for an operation to achieve a specific effect is important), but may not be required prior to that operation step in other contexts (e.g., where the use of a value from a previous execution cycle of operations is sufficient for such purposes). Accordingly, the sequence of operations and groups of operations as described in specific embodiments are explicitly considered herein, and the reordering, subdivision, and / or different groups of operations in specific embodiments are explicitly considered herein.

[0235] The methods and systems described herein can convert physical and / or intangible items from one state to another. The methods and systems described herein can also convert data representing physical and / or intangible items from one state to another.

[0236] The methods and / or processes and steps described above may be realized in hardware, program code, instructions, and / or programs, or any combination of hardware and methods, program code, instructions, and / or programs suitable for a particular application. Hardware may include a dedicated computing device or a specific computing device, a specific aspect or component of a specific computing device, and / or an array of hardware components and / or logic circuits for performing one or more operations of the method and / or system. Processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors, or other programmable devices, together with internal and / or external memory. Processes may also, or instead, be implemented in an application-specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices configured to process electronic signals. It will be further understood that one or more processes may be realized as computer executable code executable on a machine-readable medium.

[0237] Computer executable code can be generated using a structured programming language such as C, an object-oriented programming language such as C++, or any other high-level or low-level programming language (including assembly languages, hardware description languages, and database programming languages ​​and techniques) that can be stored, compiled, or interpreted to be executed on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and computer-readable instructions, or any other machine capable of executing program instructions.

[0238] Accordingly, in one aspect, each of the methods and combinations thereof described above may be implemented in computer-executable code that performs the steps when executed on one or more computing devices. In another aspect, the methods may be implemented in systems that perform the steps, which may be distributed across devices in various ways, or all functionality may be integrated into a dedicated standalone device or other hardware. In another aspect, means for performing the steps associated with the processes described above may include any of the hardware and / or computer-readable instructions described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.

[0239] Although the present disclosure has been made in connection with specific embodiments that have been illustrated and described in detail, various modifications and improvements will be readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present disclosure are not limited by the examples of the foregoing and should be understood in the broadest sense permissible by law.

Claims

Claim 1 A device comprising: a policy acquisition circuit configured to interpret a vehicle policy data value including an external event trigger condition; a policy processing circuit configured to generate parsed policy data including the external event trigger condition; and a policy execution circuit configured to collect vehicle data from one or more vehicle endpoints in response to the parsed policy data. Claim 2 In paragraph 1, the device, wherein the external event trigger condition includes a traffic condition value. Claim 3 In claim 1, the device, wherein the external event trigger condition includes a weather condition value. Claim 4 In claim 1, the device, wherein the external event trigger condition includes a road condition value. Claim 5 A device according to claim 1, wherein the policy execution circuit is further configured to collect vehicle data in response to an authorization value associated with the vehicle policy data value. Claim 6 In paragraph 5, the authorization value corresponds to: a request entity for the vehicle policy data value; a vehicle type value; or at least one of the data type value of the collected vehicle data, the device. Claim 7 A device according to claim 1, wherein the external event trigger condition includes a position value, and the policy execution circuit is further configured to collect vehicle data in response to the position value. Claim 8 In paragraph 7, the above location value is a device including a description of the jurisdiction area. Claim 9 In paragraph 7, the above position value includes an altitude value, a device. Claim 10 In paragraph 7, the above location value is a device including a climate value. Claim 11 In paragraph 7, the above position value includes a seasonal value, a device. Claim 12 In paragraph 7, the above location value is a device including a settlement description. Claim 13 A device according to claim 1, wherein the external event trigger condition includes a mission type value, and the policy execution circuit is further configured to collect vehicle data in response to the mission type value. Claim 14 A cloud system comprising: a request interface configured to interpret at least one vehicle data collection description and a target vehicle description; a policy generator circuit configured to determine at least one vehicle policy data value in response to the at least one vehicle data collection description and the target vehicle description; a policy implementation circuit configured to determine a group of vehicles in response to the target vehicle description and to provide at least one of the at least one vehicle policy data value to the group of vehicles; and a cloud interface configured to receive at least a portion of identified vehicle data in response to the at least one vehicle policy data value or at least one warning response value in response to the at least one vehicle policy data value. Claim 15 In paragraph 14, the cloud system, wherein the policy implementation circuit is further configured to determine a group of said vehicles in response to shared vehicle attributes. Claim 16 In paragraph 15, the shared vehicle attribute comprises: at least one of a vehicle configuration value, a vehicle part value, or a vehicle feature value, in a cloud system. Claim 17 In paragraph 15, the shared vehicle attribute comprises: at least one of an owner value, a manufacturer value, an OEM (original equipment manufacturer) value, a fleet value, a body builder value, or a dealer value, in a cloud system. Claim 18 In paragraph 15, the shared vehicle attribute comprises: at least one of a maintenance value, a diagnostic value, a recall value, or a fault code value, in a cloud system. Claim 19 In paragraph 15, the cloud system wherein the shared vehicle attribute comprises at least one of an associated entity type value or a vehicle type value. Claim 20 A cloud system comprising: a request interface configured to implement a user data collection interface and interpret at least one vehicle data collection description and a target vehicle description in response to user policy builder interactions with the user data collection interface; a policy generator circuit configured to determine at least one vehicle policy data value in response to the at least one vehicle data collection description and the target vehicle description; and a policy implementation circuit configured to determine a group of vehicles in response to the target vehicle description and provide at least one of the at least one vehicle policy data value to the group of vehicles in response to user policy implementation interactions with the user data collection interface. Claim 21 A cloud system according to claim 20, wherein the request interface is further configured to display a recipe library to the user data collection interface and to interpret the at least one vehicle data collection description in response to user interactions with the recipe library. Claim 22 In paragraph 20, the cloud system is further configured such that the request interface displays at least one normalized data parameter to the user data collection interface. Claim 23 In paragraph 22, the above at least one normalized data parameter comprises: at least one of a manufacturer parameter, an industry standard parameter, a simplified parameter, or a user-defined parameter, in a cloud system. Claim 24 In paragraph 20, the cloud system, wherein the policy generator circuit is additionally configured to display a policy summary on the user data collection interface. Claim 25 In paragraph 24, the above policy summary comprises: an active recipe description; a pending recipe description; an active trigger description; a pending trigger description; or at least one of a logical flow diagram associated with at least one vehicle data collection description, a cloud system. Claim 26 A cloud system according to claim 24, further comprising a cloud interface configured to receive at least one of: at least a portion of vehicle data identified in response to at least one vehicle policy data value; or at least one of a warning response value in response to at least one vehicle policy data value. Claim 27 In paragraph 26, the cloud system is further configured such that the policy generator circuit updates the policy summary in response to at least some of the received identified vehicle data or at least one of the received warning response values. Claim 28 A device comprising: a policy acquisition circuit configured to interpret a vehicle policy data value including a data collection description; a policy processing circuit configured to generate parsed policy data corresponding to the data collection description and to determine a memory allocation value in response to the parsed policy data; and a policy execution circuit configured to collect vehicle data from one or more vehicle endpoints in response to the parsed policy data and to store at least a portion of the collected vehicle data in response to the memory allocation value. Claim 29 In paragraph 28, the device, wherein the memory allocation value is a fixed value determined in response to the parsed policy data. Claim 30 In paragraph 29, the device is further structured such that the policy processing circuit determines the memory allocation value in response to an authorization value associated with the vehicle policy data value. Claim 31 In paragraph 30, the authorization value corresponds to: a request entity for the vehicle policy data value; a vehicle type value; or at least one of the data type value of the collected vehicle data, the device. Claim 32 In paragraph 28, the device, wherein the memory allocation value is a dynamic value determined in response to the parsed policy data. Claim 33 In paragraph 32, the device is further structured such that the policy processing circuit determines the memory allocation value in response to an authorization value associated with the vehicle policy data value. Claim 34 In paragraph 33, the authorization value corresponds to: a request entity for the vehicle policy data value; a vehicle type value; or at least one of the data type value of the collected vehicle data, the device. Claim 35 In paragraph 32, the vehicle policy data value includes one of a plurality of policies, and the policy processing circuit is further structured to determine the memory allocation value as a shared memory value for supporting a basket of policies including selected plurality of policies among the plurality of policies. Claim 36 In paragraph 35, the device is configured such that the policy processing circuit determines the shared memory value by utilizing a probabilistic operation in response to parsed policy data for each of the baskets of policies. Claim 37 In paragraph 36, the device is further configured such that the policy processing circuit adjusts the shared memory value in response to trigger correlation analysis. Claim 38 In paragraph 36, the device is further configured such that the policy processing circuit adjusts the shared memory value in response to historical data collection operations in the vehicle defining the device. Claim 39 In paragraph 36, the device is further configured such that the policy processing circuit adjusts the shared memory value in response to historical data collection operations in at least one offset vehicle. Claim 40 A device according to claim 28, further comprising a policy reporting circuit configured to generate a data collection package in response to the collected vehicle data, and to perform at least one of storing the data collection package or communicating the data collection package to an external device. Claim 41 In paragraph 40, the device is further configured such that the policy reporting circuit includes a package identifier together with the data collection package. Claim 42 In paragraph 41, the device comprises: an identifier for a policy including the vehicle policy data value; an identifier for a trigger of the policy including the vehicle policy data value; or at least one of technical metadata for the package. Claim 43 In paragraph 40, the above policy reporting circuit is further configured to include at least a portion of the flow log in the package, the device. Claim 44 In paragraph 40, the above policy reporting circuit is additionally configured to include a vehicle condition log in the above package, the device. Claim 45 In paragraph 40, the device is further configured such that the policy reporting circuit performs a streaming recovery operation in response to the interruption of communicating the data collection package to an external device. Claim 46 In paragraph 45, the above policy reporting circuit is additionally configured to utilize a memory buffer to perform the above streaming recovery operation, the device. Claim 47 In paragraph 40, the device is further configured such that the policy reporting circuit generates a separate data collection package for each trigger occurrence of a selected trigger of a policy containing the vehicle policy data value. Claim 48 In paragraph 40, the device is further configured such that the policy reporting circuit attaches newly collected data to a previously existing data collection package in response to a selected trigger of a policy including the vehicle policy data value. Claim 49 In paragraph 28, the vehicle policy data value includes one of a plurality of policies; and the policy execution circuit is further configured to perform a redundancy management operation in response to determining that at least two of the policies have a shared collection data element. Claim 50 In paragraph 49, the device wherein the shared collected data element includes literal data duplication. Claim 51 In paragraph 49, the device, wherein the shared collected data element includes raw data duplication. Claim 52 In paragraph 49, the memory allocation value is a dynamic value determined in response to the parsed policy data, and the policy processing circuit is further structured to determine the memory allocation value in response to the redundancy management operation, the device. Claim 53 In claim 28, the vehicle policy data value comprises one of a plurality of policies; further comprises a policy reporting circuit configured to perform at least one of generating a data collection package in response to the collected vehicle data, storing the data collection package, or communicating the data collection package to an external device; and the policy reporting circuit further configured to perform a redundancy management operation in response to determining that at least two of the policies have a shared collected data element. Claim 54 In paragraph 53, the device wherein the shared collected data element includes literal data duplication. Claim 55 In paragraph 53, the device, wherein the shared collected data element includes raw data duplication. Claim 56 As a system, a vehicle having multiple network zones — each network zone having multiple endpoints located thereon — a data support circuit configured to determine a shared data description including vehicle data values ​​— said vehicle data values ​​are: A data value provided by a potential data source endpoint of the plurality of endpoints, or a data value based on data provided by the potential data source endpoint of the plurality of endpoints; or Data values ​​utilized by potential data destination endpoints of the aforementioned plurality of endpoints A system comprising at least one of the following: a data processing circuit configured to generate a data collection description in response to the shared data description and to determine a memory allocation value in response to the data collection description; a data collection execution circuit configured to collect vehicle data from one or more of the plurality of endpoints in response to the data collection description and to store at least a portion of the collected vehicle data in response to the memory allocation value; and a data sharing support circuit configured to provide response data from at least one of the collected vehicle data or the stored collected vehicle data to a data destination endpoint. Claim 57 In paragraph 56, the system is further configured such that the data support circuit determines the shared data description in response to the automation description. Claim 58 In paragraph 56, the system is further configured such that the data support circuit determines the shared data description in response to the vehicle policy data value. Claim 59 In paragraph 56, the system is further configured such that the data support circuit determines the shared data description in response to the analysis of the vehicle application. Claim 60 In paragraph 56, the system is further configured such that the data support circuit determines the shared data description in response to an analysis of the vehicle flow. Claim 61 In paragraph 56, the system is further configured such that the data support circuit determines the shared data description in response to an analysis of at least one of the plurality of network zones. Claim 62 In paragraph 56, the system is further configured such that the data support circuit determines the shared data description in response to an analysis of at least one of the plurality of endpoints. Claim 63 In paragraph 56, the system, wherein utilization by at least one of the potential data destination endpoints includes asynchronous utilization. Claim 64 In paragraph 63, the system is further structured such that the data support circuit determines the shared data description in response to the analysis of the asynchronous utilization. Claim 65 In paragraph 56, the system is further configured such that the data sharing support circuit generates a data collection package in response to at least one of the collected vehicle data or the stored collected vehicle data. Claim 66 A system according to claim 65, further comprising a data layer reporting circuit configured to perform at least one of storing the data collection package or communicating the data collection package to an external device. Claim 67 In paragraph 66, the system is further configured such that the data layer reporting circuit includes a package identifier together with the data collection package. Claim 68 In paragraph 67, the package identifier comprises: an identifier for an automation description used to determine the shared data description; an identifier for a vehicle policy data value used to determine the shared data description; an analysis description for an analysis used to determine the shared data description; or at least one of technical metadata for the package, the system. Claim 69 In paragraph 65, the system is further configured such that the data sharing support circuit is configured to publish the data collection package as a service. Claim 70 In paragraph 69, the system is further configured such that the data sharing support circuit is configured to subscribe at least one of the potential data destination endpoints to the service. Claim 71 A device comprising: a policy acquisition circuit configured to interpret a vehicle policy data value including a data collection trigger condition; a policy processing circuit configured to generate parsed policy data including the data collection trigger condition and a policy lifecycle description; and a policy execution circuit configured to collect vehicle data from one or more vehicle endpoints in response to the parsed policy data. Claim 72 In paragraph 71, the above policy lifecycle description includes a policy trigger condition, and the policy execution circuit starts monitoring the data collection trigger condition in response to the policy trigger condition, the device. Claim 73 In paragraph 71, the above policy lifecycle description is a device including an on-demand policy lifecycle. Claim 74 A device according to claim 73, wherein the policy execution circuit is configured to monitor the data collection trigger condition by performing at least one of the following in response to the on-demand policy lifecycle: monitoring the data collection trigger condition until the next vehicle shutdown; monitoring the data collection trigger condition until a single data collection event is performed in response to the data collection trigger condition; or monitoring the data collection trigger condition until a selected number of data collection events are performed in response to the data collection trigger condition. Claim 75 In paragraph 71, the above policy lifecycle description includes a start time, and the policy execution circuit is configured to monitor the data collection trigger condition in response to the start time, the device. Claim 76 In paragraph 71, the above policy lifecycle description includes a pause time, and the policy execution circuit is configured to monitor the data collection trigger condition in response to the pause time, the device. Claim 77 In paragraph 71, the above policy lifecycle description includes a time window, and the policy execution circuit is configured to monitor the data collection trigger condition in response to the time window, the device.

Images