JP2023516760A - Systems, methods and apparatus for managing vehicle data collection - Google Patents

Abstract

A vehicle data collection and management device including a remote access execution circuit, a property transformation circuit, a parameter acquisition circuit, a remote operation circuit, and a parameter adjustment circuit. A remote access execution circuit interprets the remote access request values including the requested vehicle property and/or vehicle function values. The property conversion circuit determines property request values responsive to requested vehicle properties and/or actuator command values responsive to vehicle function values. A parameter acquisition circuit interprets the vehicle parameter values according to the property request values. A remote operation circuit provides actuator command values to the vehicle network zone endpoint. A parameter adjustment circuit generates vehicle property data from the vehicle parameter values in response to the property request values. The vehicle property data corresponds to requested vehicle properties. A remote access execution circuit transmits the vehicle property data to the requesting device. [Selection drawing] Fig. 147

Description

(Cross reference to related application)
This application is based on U.S. Provisional Patent Application No. 62/986,444 (SONA-0004-P01), entitled "SYSTEM, METHOD AND APPARATUS FOR IMPLEMENTING CONFIGURABLE DATA COLLECTION FOR A VEHICLE," filed March 6, 2020; U.S. Provisional Patent Application No. 63/024,383 (SONA-0005-P01), entitled "SYSTEM, METHOD AND APPARATUS FOR IMPLEMENTING CONFIGURABLE DATA COLLECTION FOR A VEHICLE," filed May 13, 2020, and December 2020; Claims priority to U.S. Provisional Patent Application No. 63/123,531 (SONA-0009-P01), entitled "SYSTEM METHOD AND APPARATUS FOR IMPLEMENTING CONFIGURABLE DATA COLLECTION FOR A VEHICLE," filed May 10 .

This application is based on U.S. patent application Ser. claiming priority to and is a continuation-in-part application thereof.

U.S. Application Serial No. 17/027,167 is the following provisional application:
U.S. Application No. 62/903,462 entitled SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK, filed September 20, 2019 (SONA-0001-P01);
U.S. Application No. 62/911,249 entitled "SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK," filed October 5, 2019 (SONA-0002-P01);
U.S. Application No. 62/911,248 (SONA-0003-P01), entitled "SYSTEM, METHOD AND APPARATUS FOR CLOUD-BASED INTERACTIONS WITH A MIXED VEHICLE NETWORK," filed October 5, 2019; No. 63/024,383 (SONA-0005-P01), filed May 13 and entitled "SYSTEM, METHOD AND APPARATUS TO TEST AND VERIFY A VEHICLE NETWORK".

This application claims priority to U.S. patent application Ser. and is a continuation-in-part application thereof.

U.S. Application No. 17/027,187 is the following provisional application:
U.S. Application No. 62/903,462 entitled SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK, filed September 20, 2019 (SONA-0001-P01);
U.S. Application No. 62/911,249 entitled "SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK," filed October 5, 2019 (SONA-0002-P01);
U.S. Application No. 62/911,248 (SONA-0003-P01), entitled "SYSTEM, METHOD AND APPARATUS FOR CLOUD-BASED INTERACTIONS WITH A MIXED VEHICLE NETWORK," filed October 5, 2019; No. 63/024,383 (SONA-0005-P01), filed May 13 and entitled "SYSTEM, METHOD AND APPARATUS TO TEST AND VERIFY A VEHICLE NETWORK".

All of the above patent documents are incorporated herein by reference in their entirety.

Vehicle communication networks are utilized to connect sensors, actuators, controllers, user interfaces, rider personal devices, trailers, and communication devices throughout the vehicle. Recent trends include more devices being connected, more data being passed between devices, low latency requirements to meet vehicle performance, safety and emissions requirements, and additional vehicle features. are increasing the burden on these vehicle communication networks. In addition, consumers expect features that increase connectivity, reduce the burden on drivers, and increase the strain on vehicle communication networks. These trends are likely to continue and accelerate in the future.

Conventional vehicle communication networks (CAN, LIN, FlexRay, MOST, LVDS, etc.) suffer from several drawbacks and challenges. These vehicular communication networks have been developed to address the unique challenges of the vehicular environment and, accordingly, include computer local area networks, wide area networks, massively interconnected networks (e.g., the Internet), and wireless networks. has evolved independently of other networks such as Most vehicle networks consist of a data link layer and an application layer, utilizing robust and dedicated equipment such as the Controller Area Network (CAN) bus to support specific data protocols (e.g. J1939, OBD, etc.). It has dedicated or shared wiring between the devices it utilizes. Modern vehicles may have multiple network buses, with specific commands and communications available, limiting the customization and data rates available. For example, CAN buses typically operate at a maximum of about 1 Mbps, and high capacity CAN buses operate at a maximum of about 10 Mbps. In addition, CAN buses experience high latencies, typically around 60 ms to 500 ms, in excess of 25 ms, depending on configuration, traffic on the CAN, priority of particular messages, and the like.

As the number of devices and data rate demands from the devices increase, conventional vehicle communication networks require higher performance bus implementations. Because the automobile industry is a mass production industry with very little tolerance for component failure, automobile manufacturers use the same parts for long periods of time and across a wide range of vehicles, including sharing parts between manufacturers. Additionally, changing to a nominally more capable part may introduce risk, integration costs, the burden of recertification for a given application, or have other undesirable effects on the system. Thus, even as vehicle communication networks migrate to higher performance network configurations, keeping network types separate within the system and maintaining a large number of legacy devices (e.g., CAN compatible) within the system over time. is desirable.

Collecting data from vehicles presents even more challenges. For example, data collection operations are subject to regulatory and liability risks, particularly with respect to data collection that may include personal or personally identifiable information. Data collectors, including entities that may own or possess sensitive data, are at risk while in possession of the data, for example, in the event of inadvertent or malicious access to the data. With respect to collected vehicle data, there is a large amount of data collected, there may be many purposes for data collection, and there is increased risk compared to other common data storage applications. Accordingly, it may be desirable to control the collection, storage, and access of data to reduce risk, as well as verifying data access, partitioning or otherwise excluding data when it is not used. , and the like.

Vehicle data collection is further complicated by the amount and type of data that must be communicated between the vehicle and external devices, where the vehicle's network system is subject to mobile application limitations, costs and/or high data rates. and limited by bandwidth constraints caused by large data transfers. Even considering the above, customer demands, market expectations, increasing demands for more efficient vehicle operations, and increasing functional capabilities of data-related applications will continue to increase the total amount of data transferred, The number of applications, the number of purposes for which data can be utilized, and the number of users or entities that legitimately need some of the transferred data continues to grow significantly. Moreover, data-utilizing applications continue to grow in sophistication and sophistication, increasing data demands on limited transfer resources and increasing the cost and complexity of transferring data logistics and storage. For example, more capable routing or operational algorithms for vehicles, increased automation of vehicle functions, increased demand for predictive determinations and/or maintenance support, and increased media streams (both the number of media streams and their quality). all increase the demands on data rates, the amount of data stored, and the number of entities or applications accessing the stored data.

The aforementioned complexities and other issues have a synergistic effect, making the complexity of the vehicle data environment even greater than the sum of the individual contributions from each issue.

As an example, an increase in the number of entities or applications accessing data increases the likelihood that individual data requests will be duplicated, for example, with multiple entities requesting the same or similar data. Moreover, as the number of entities or applications accessing data increases, members of the accessing groups share similar authority levels such that data access for individual members of the entity or application group requires data management. Possibilities increase.

Another example is increasing regulations on sensitive data, which generally increases the data management requirements of systems, but data management may be subject to multiple constraints at any given time, and/or changes also increase the likelihood that the constraints will change over time.

As yet another example, the complex environment of currently known vehicle network architectures and transitioning vehicle network architectures, such as vehicles with mixed network types and/or split networks, reduces the complexity of data access for individual entities. Without certain aspects of this disclosure, it would be necessary to determine required parameter specifications for particular data elements, and to update these required parameters as the vehicle network architecture evolves. there is a possibility. Given the increasing number of entities requesting data access, the total cost to the automotive support market increases non-linearly as each entity bears the cost of tracking the required parameter specifications. Furthermore, the trajectory of additional entities requesting data access is towards entities located more distant in the technical knowledge space from the core functionality of the vehicle, and accordingly the in-vehicle network configuration, specific data descriptions, data The complexity and idiosyncrasies of vehicles and/or automotive applications, including requirements and communication protocols, industry standards or conventions for presenting information and the like, are on average lesser known with each incremental new entity. is disappearing, further increasing the cost volume function (e.g., the cost over time for a given entity to meet the desired data collection deliverable, where the given entity is an automobile manufacturer, and/or or vehicle market, geographic market, and/or industry such as the automotive industry, passenger car industry, etc.). For example, consider the following hypothetical cost-volume function:

COST = number of entities * base learning cost * transition cost trajectory adaptation * data trajectory cost * regulation adaptation cost * data access/storage responsibility cost

The described COST function demonstrates how the various challenges and complexities of currently known systems interact and synergize to increase the cost of meeting future data collection capabilities for vehicle applications. It is a non-limiting hypothetical example showing The cost parameters listed are not intended to cover all costs associated with the challenges present in the automotive data collection industry or presently known systems. Parameters can be mean values or other complex functions, and the value of a particular parameter is generally not known specifically. In addition, the unit of COST is the monetary value, equivalent emissions, customer satisfaction, the risk incurred, the loss of social perception or It can be expressed as another non-monetary unit such as profit, etc. The number of entities parameter generally reflects the number of entities accessing vehicle data over time; the basic learning cost is the number of entities a new entity will need to meet specific vehicle, vehicle type, market, and other data collection requirements and protocol specifications. transition cost trajectory adaptation reflects the cost of adapting to changes in vehicle network configuration, including network types and mechanisms; data trajectory cost reflects data communication, storage, and desired Reflects increased demand for data collection from relevant vehicles over time, including consequent functional consequences such as the inability to support applications or the cost of hardening data communication infrastructure; reflecting costs associated with increased numbers, increased number of regulatory frameworks, and/or increased number of regulatory bodies; and data access/storage liability costs incurred for data compliance and security. and/or losses incurred due to data breaches, misuse and the like.

An exemplary apparatus includes a policy acquisition circuit configured to interpret a vehicle policy data value including a driver information description; policy processing circuitry configured to generate parsed policy data including a collection description; and collecting vehicle data from one or more endpoints of at least one network zone of the vehicle in response to the parsed policy data. and a policy enforcement circuit configured to:

Certain additional aspects of exemplary apparatus are described below, any one or more of which can be present in a particular embodiment. The one or more endpoints include endpoints located on at least two network zones of the vehicle. Driver information descriptions include descriptions of vehicle data collected based on driver characteristics. The policy enforcement circuitry is further configured to interpret driver information corresponding to the current driver of the vehicle and collect vehicle data in response to comparing the driver characteristics with the driver information corresponding to the current driver of the vehicle. . The driver information description contains a description of the monitoring data of the driver of the vehicle. The driver information description further includes a description of driver monitoring data based on driver characteristics. The driver information description further includes a trigger condition, and the policy enforcement circuit is further configured to further collect vehicle data in response to the trigger condition. The trigger state includes at least one state selected from the following: event detection state; driver characteristic value; driver classification value; or driver performance value. Collected vehicle data also includes determination of event occurrences in response to trigger conditions.

An exemplary apparatus includes policy acquisition circuitry configured to interpret a vehicle policy data value that includes a device state description; policy processing circuitry configured to generate parsed policy data including collection descriptions; and vehicle data from one or more endpoints of at least one network zone of the vehicle in response to the parsed policy data. a policy enforcement circuit configured to collect.

Certain additional aspects of exemplary devices are described below, any one or more of which can be present in a particular embodiment. The one or more endpoints include endpoints located on at least two network zones of the vehicle. Device state descriptions include descriptions of vehicle data collected based on at least one of device fault values or device diagnostic values. The device state description includes a description of monitoring data of the vehicle's devices. Vehicle data collection includes description of device monitoring data based on at least one of device fault values or device diagnostic values. A device corresponds to at least one of a device fault value or a device diagnostic value. The device includes a device other than the device corresponding to at least one of the device fault value or the device diagnostic value. The monitor data description includes at least one data value selected from data values consisting of a fault state value, a fault count value, a diagnostic parameter value, a fault confirmation value, a diagnostic confirmation value, a fault median value, or a diagnostic median value. The description of monitored data includes monitored data for a device other than the device corresponding to at least one of the device fault value or the device diagnostic value.

An exemplary apparatus includes policy acquisition circuitry configured to interpret vehicle policy data values including endpoint performance descriptions, and vehicle data collection descriptions responsive to, and at least partially based on, the vehicle policy data values. policy processing circuitry configured to generate parsed policy data; and responsive to the parsed policy data to collect vehicle data from one or more endpoints of at least one network zone of the vehicle. and a configured policy enforcement circuit.

Certain additional aspects of exemplary devices are described below, any one or more of which can be present in a particular embodiment. The one or more endpoints include endpoints located on at least two network zones of the vehicle. The endpoint performance description includes a first data value collected in response to the target endpoint being in a first state and a second data value collected in response to the target endpoint being in a second state. data values. The target endpoint in the first state includes the first vehicle configuration and the target endpoint in the second state includes the second vehicle configuration. The target endpoint in the second state includes the target endpoint determined to be in the non-nominal state. The non-nominal condition includes at least one condition selected from the conditions consisting of a failure condition, a fault condition, a non-responsive condition, or a no communication condition. A target endpoint in a first condition includes a first target endpoint configuration and a target endpoint in a second condition includes a second target endpoint configuration. The first data value includes data collected from the first endpoint group and the second data value includes data collected from the second endpoint group. The first endpoint group and the second endpoint group include at least one different data value for collection. The first endpoint group and the second endpoint group include at least one different endpoint.

An exemplary apparatus includes policy acquisition circuitry configured to interpret vehicle policy data values including location description values; policy processing circuitry configured to generate parsed policy data including collection descriptions; and vehicle data from one or more endpoints of at least one network zone of the vehicle in response to the parsed policy data. a policy enforcement circuit configured to collect.

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The location description values include at least one description selected from descriptions consisting of geographic location values; jurisdictional values; relative location values; or defined geographic area values. The policy enforcement circuitry is further configured to coordinate collection of vehicle data in response to the location description value. The policy enforcement circuitry is further configured to prevent collection of at least a portion of the vehicle data in response to the location description value. The policy enforcement circuitry is further configured to initiate collection of at least a portion of the vehicle data in response to the location description value. The policy enforcement circuitry is further configured to adjust the format of at least a portion of the vehicle data in response to the location description value. The policy enforcement circuitry is further configured to modify the collected parameters in response to the location description values. The policy enforcement circuitry is further configured to add or modify metadata to at least a portion of the vehicle data in response to the location description value. The policy enforcement circuitry is further configured to adjust a priority associated with at least a portion of the vehicle data as a function of the location description value. Priorities include in-vehicle data storage priority. Priority includes transmission priority. The priorities include in-vehicle transmission priorities corresponding to at least one network zone of the vehicle.

An exemplary apparatus includes a policy acquisition circuit configured to interpret vehicle policy data values including vehicle status data; policy processing circuitry configured to generate parsed policy data including a collection description; and collecting vehicle data from one or more endpoints of at least one network zone of the vehicle in response to the parsed policy data. and vehicle data transmission circuitry configured to transmit at least a portion of the collected vehicle data according to the data type of the collected vehicle data.

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The data types include at least one data type selected from control data types, diagnostic data types, performance data types, monitoring data types, or aggregate data types. The policy enforcement circuitry is further configured to coordinate the collection of vehicle data according to the data type of the collected vehicle data. The policy enforcement circuitry is further configured to prevent collection of at least a portion of the vehicle data depending on the data type of the collected vehicle data. The policy enforcement circuitry is further configured to initiate collection of at least a portion of the vehicle data depending on the data type of the collected vehicle data. The policy enforcement circuitry is further configured to adjust the format of at least a portion of the vehicle data according to the data type of the collected vehicle data. The policy enforcement circuitry is further configured to adjust a priority associated with at least a portion of the vehicle data as a function of the location description value. Priorities include in-vehicle data storage priority. Priority includes transmission priority. The priorities include in-vehicle transmission priorities corresponding to at least one network zone of the vehicle. The vehicle data transmission circuitry is further configured to adjust the priority associated with at least a portion of the vehicle data according to the data type of the vehicle data collected. Priorities include in-vehicle data storage priority. Priority includes transmission priority. The priorities include in-vehicle transmission priorities corresponding to at least one network zone of the vehicle. The policy enforcement circuitry further includes: endpoints providing relevant vehicle data; endpoints requesting relevant vehicle data; entities requesting relevant vehicle data; depending on at least one of the relevant application, the flow associated with the endpoint providing the relevant vehicle data, the flow associated with the request for vehicle data, or the indicated data type provided in the vehicle policy data value of the vehicle data. , is configured to determine the data type of the collected vehicle data.

An exemplary apparatus includes a policy acquisition circuit configured to interpret vehicle policy data values including vehicle status data; policy processing circuitry configured to generate parsed policy data including collection descriptions; and vehicle data from one or more endpoints of at least one network zone of the vehicle in response to the parsed policy data. policy enforcement circuitry configured to collect; vehicle data transmission circuitry configured to transmit at least a portion of the collected vehicle data; and vehicle configured to interpret vehicle status data collection change values. status data adjustment circuitry, wherein the policy enforcement circuitry is further configured to adjust vehicle data collection in response to the vehicle status data collection change value; at least one of being further configured to coordinate transmission of at least a portion of the vehicle data collected according to the value.

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The vehicle status data conditioning circuit is further configured to interpret the vehicle status data collection change value as a function of the operating conditions of the vehicle. The vehicle status data conditioning circuit is further configured to interpret the vehicle status data collection change value in response to an event occurrence. The vehicle status data conditioning circuit further determines a fault condition value, a fault count value, a diagnostic parameter value, a fault verification value, a diagnostic verification value, a fault mean value, or a diagnostic mean value. is configured to determine event occurrence by performing at least one action selected from the actions of: The vehicle status data further includes a trigger condition, and the vehicle status data conditioning circuit is further configured to determine event occurrence in response to the trigger condition. The trigger condition includes at least one condition selected from the conditions consisting of an event detection condition, a vehicle status value, or a vehicle operating condition value. The vehicle status data conditioning circuit is further configured to interpret the vehicle status data collection change value as a function of the location description value. The location description values include at least one description selected from descriptions consisting of geographic location values, jurisdictional values, relative location values, or defined geographic region values. Policy enforcement circuitry prevents collection of at least a portion of the vehicle data in response to the location description value in response to the vehicle status data collection change value. Policy enforcement circuitry initiates collection of at least a portion of vehicle data in response to the location description value in response to the vehicle status data collection change value. Policy enforcement circuitry adjusts the format of at least a portion of the vehicle data in response to the location description value in response to the vehicle status data collection change value. Policy enforcement circuitry adjusts the priority associated with at least a portion of the vehicle data in response to the location description value in response to the vehicle status data collection change value. Priorities include in-vehicle data storage priority. Priority includes transmission priority. The priorities include in-vehicle transmission priorities corresponding to at least one network zone of the vehicle. Vehicle data transmission circuitry adjusts the priority of at least a portion of the vehicle data collected responsive to the location description value responsive to the vehicle status data collection change value.

An exemplary apparatus includes a policy acquisition circuit configured to interpret vehicle policy data values including vehicle status data and update a data collection policy in response to the vehicle policy data values; a policy processing circuit configured to generate parsed policy data including a vehicle data collection description based at least in part on the updated data collection policy; policy enforcement circuitry configured to collect vehicle data from one or more endpoints of at least one network zone; and vehicle data transmission circuitry configured to transmit at least a portion of the collected vehicle data. ,including.

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The data collection policy includes a built-in policy, the vehicle policy data value includes either a factory policy or a downloaded policy, and the policy acquisition circuit further determines the data collection policy as a function of the vehicle policy data value. It is configured to update the data collection policy by replacing it with the policy. The data collection policy includes a built-in policy, the vehicle policy data value includes either a factory policy or a downloaded policy, and the policy acquisition circuit further converts the built-in policy to a policy determined in response to the vehicle policy data value. and update the data collection policy by replacing the data collection policy with the update policy. The data collection policy includes a factory policy, the vehicle policy data value includes a downloaded policy, and the policy acquisition circuit further replaces the data collection policy with a policy determined according to the vehicle policy data value, Configured to update data collection policies. The data collection policy includes a factory policy, the vehicle policy data value includes a downloaded policy, and the policy acquisition circuit further adds a matching portion of the factory policy to the policy determined in response to the vehicle policy data value. is configured to update the data collection policy by generating an update policy and replacing the data collection policy with the update policy. The policy acquisition circuit is further configured to update the data collection policy by appending to the data collection policy the requested policy determined according to the vehicle policy data value. The policy acquisition circuit further includes a data collection event for the collected vehicle data in response to the added request policy, a data transmission event for the collected vehicle data in response to the added request policy, a policy cancellation value provided by the external device, a vehicle policy. modifying the data collection policy by removing the added request policy in response to at least one of a change in the subscription status of the entity providing the data values or a change in the authorization status of the entity providing the vehicle policy data values; configured to update. The vehicle policy data value further includes a trigger condition, and the policy enforcement circuit is further configured to collect vehicle data in response to the trigger condition.

An exemplary apparatus includes policy acquisition circuitry configured to interpret a vehicle policy data value including at least one requested vehicle property; a parameter acquisition circuit configured to interpret a plurality of vehicle parameter values (each of the plurality of provisioning endpoints being on at least one network zone of the vehicle); and at least a portion of the plurality of vehicle parameter values. wherein at least a first portion of the stored at least some of the plurality of vehicle parameter values comprises at least a first portion of the stored vehicle parameter values and a parameter storage circuit stored on a different storage endpoint than the associated portion of the provisioning endpoint for.

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The parameter storage circuitry is further configured to selectively store at least some of the plurality of vehicle parameter values on a single storage endpoint. The apparatus further includes a storage management circuit configured to determine a parameter transmission schedule for the stored vehicle parameter values, the parameter storage circuit storing at least a portion of the plurality of vehicle parameter values according to the parameter transmission schedule. It is further configured to selectively store. The apparatus further includes storage management circuitry configured to determine a parameter expiration schedule for the stored vehicle parameter values, the parameter storage circuitry generating at least one of the plurality of vehicle parameter values according to the parameter expiration schedule. It is further configured to selectively store the portion. The parameter storage circuit further deletes at least some of the stored vehicle parameter values, summarizes at least some of the stored vehicle parameter values, and compresses at least some of the stored vehicle parameter values. or adjusting a reserved memory amount associated with at least some of the stored vehicle parameter values in response to the parameter expiration schedule. The parameter storage circuitry further performs determining a reserved memory amount associated with at least a portion of the plurality of vehicle parameter values and selectively storing at least a portion of the plurality of vehicle parameter values in response to the reserved memory amount. is configured to The parameter storage circuitry further determines an amount of data collected to support at least a portion of the plurality of vehicle parameter values, to support trigger evaluation associated with at least a portion of the plurality of vehicle parameter values. determining the amount of data collected or determining transmission latency values associated with at least some of the plurality of vehicle parameter values; configured to determine the amount. The parameter storage circuit is further configured to determine the amount of reserved memory as a function of priority values associated with at least some of the vehicle parameter values. The priority value includes onboard data storage priority. The priority value includes transmission priority. A priority value includes a priority associated with the endpoint providing at least a portion of the vehicle parameter value. The priority value includes a priority associated with endpoints requesting at least some of the vehicle parameter values. The priority value includes a priority associated with the entity requesting at least some of the vehicle parameter values. The priority value includes a priority associated with the application requesting at least some of the vehicle parameter values. The priority value includes a priority associated with an application associated with the endpoint requesting at least some of the vehicle parameter values. A priority value includes a priority associated with a flow requesting at least some of the vehicle parameter values. The priority value includes a priority for the flow associated with the endpoint requesting at least some of the vehicle parameter values.

An exemplary apparatus includes a container acquisition circuit configured to interpret a plurality of container application values each including an application operable on a vehicle endpoint, and an authorization associated with each of the plurality of container application values. a container security circuit configured to interpret a value; and a container policy configured to interpret a plurality of container application values according to the container policy and authorization values associated with each of the plurality of container application values. a container orchestration circuit configured to determine operating parameters for each.

Certain additional aspects of exemplary devices are described below, any one or more of which can be present in a particular embodiment. Each of the plurality of container application values includes an image of the associated container application. The container policy further includes an execution order of at least one of the plurality of container application values, a data dependency description of at least one container application value of the plurality of container application values, or a container of at least one of the plurality of container application values. a priority value of an application value; The container orchestration circuitry is further configured to distribute multiple container application values to multiple endpoints of the vehicle. The container orchestration circuitry is further configured to distribute multiple container application values to balance the workload of multiple controllers including multiple endpoints. The container orchestration circuitry is further configured to distribute the multiple container application values according to the workload of the multiple controllers, including the number of endpoints. The container orchestration circuit is further configured to distribute multiple container application values to balance network communication loads of multiple network zones of the vehicle. The container orchestration circuitry is further configured to distribute multiple container application values according to network communication loads of multiple network zones of the vehicle. The container security circuitry is further configured to determine authorization values in response to authorizations associated with entities providing each of the plurality of container application values. The container security circuitry is further configured to determine authorization values in response to authorizations associated with operation of each of the plurality of container application values. The container security circuitry is further configured to determine authorization requirements as a function of input data values for each of the plurality of container application values. The container security circuitry is further configured to determine authorization requirements as a function of output data values of each of the plurality of container application values. The container security circuitry is further configured to determine authorization requirements as a function of actuator command values for each of the plurality of container application values. The container security circuitry is further configured to determine authorization requirements as a function of memory support values for each of the plurality of container application values. The memory support value includes an installed memory support value. The memory support values include operating memory support values. The container security circuitry is further configured to determine authorization requirements as a function of processing support values for each of the plurality of container application values. The container acquisition circuitry is further configured to interpret the additional container application values, and the container orchestration circuitry is further configured to update the plurality of container application values and operational parameters for the additional container application values in response to the additional container application values. configured to The container orchestration circuitry is further configured to distribute the added container application value to selected endpoints of the vehicle depending on the selected endpoint's ability to execute the added container application value. . The container orchestration circuitry is further configured to modify the distribution of multiple container application values across multiple endpoints of the vehicle in response to the added container application values. The container retrieval circuitry is further configured to interpret an enable value for at least one of the plurality of container values, and the container orchestration circuitry is further configured to determine an operating parameter in response to the enable value. The container orchestration circuitry is further configured to interpret vehicle operating conditions and to determine operating parameters as a function of the vehicle operating conditions. The container orchestration circuitry is further configured to interpret the vehicle configuration values and determine operating parameters as a function of the vehicle configuration values.

An exemplary apparatus includes an automatic action circuit configured to interpret an automatic action value including an automatic action description for a vehicle; and a trigger description value responsive to the automatic action value, the trigger description value being: an automation manager circuit including a trigger condition value and a trigger response value; a trigger evaluation circuit configured to determine the occurrence of a trigger event as a function of the trigger condition value and the at least one vehicle data value; a trigger execution circuit configured to execute the trigger response with the trigger execution circuit.

Certain additional aspects of exemplary devices are described below, any one or more of which can be present in a particular embodiment. The trigger response is at least one action selected from performing a data collection action, providing an actuator command value, or enabling operation of a preconfigured function on the vehicle's controller. including. The triggering response includes providing a high priority response to at least a portion of the triggering response. A high priority response includes sending the selected data value to the external device. A high priority response includes providing a high priority actuator command value. Automatic action values include selection from a number of preset automatic action values. The automation manager circuit is further configured to determine an authorization value associated with the automatic action value and selectively determine the trigger description value as a function of the authorization value. The automation manager circuit is further configured to determine the trigger explanation value as a permanent value. The automation manager circuit is further configured to determine the trigger description value as a restricted execution value. The automation manager circuit is further configured to maintain the vehicle's receiver in the selected power mode during selected operating conditions of the vehicle. The automation manager circuit is further configured to maintain at least one controller of the vehicle in the selected power mode during selected operating conditions of the vehicle. The automation manager circuit is further configured to maintain at least one controller of the vehicle in the selected power mode depending on the content of the trigger description value.

An exemplary apparatus includes policy acquisition circuitry configured to interpret vehicle policy data values including at least one requested vehicle property; a parameter acquisition circuit configured to interpret a plurality of vehicle parameter values (each of the plurality of provisioning endpoints being on at least one network zone of the vehicle) in response; and selecting at least a portion of the collected vehicle data. a vehicle data transmission circuit configured to transmit automatically.

Certain additional aspects of exemplary devices are described below, any one or more of which can be present in a particular embodiment. The vehicle data transmission circuitry is further configured to selectively transmit at least a portion of the collected vehicle data by selecting transmission intervals for at least a portion of the collected vehicle data. The vehicle data transmission circuitry is further adapted to transmit the interval provided in the vehicle policy data value, the interval responsive to the priority of at least some of the collected vehicle data, and the resources for transmitting at least some of the collected vehicle data. The transmission interval is configured to select the transmission interval as a function of at least one of the following: an interval as a function of the availability description, an interval as a function of past transmission availability of the vehicle, or an operational state of the vehicle. The vehicle data transmission circuitry is further configured to selectively transmit at least a portion of the collected vehicle data by selecting bandwidth utilization for at least a portion of the collected vehicle data. The vehicle data transmission circuitry further determines bandwidth utilization provided in the vehicle policy data value, bandwidth utilization corresponding to a priority of at least a portion of the collected vehicle data, transmission resources for at least a portion of the collected vehicle data. bandwidth utilization corresponding to the availability description for the vehicle, an interval corresponding to the past transmission availability of the vehicle, or an operational state of the vehicle. The vehicle data transmission circuitry is further configured to selectively transmit at least some of the collected vehicle data by selecting a transmission interval depending on a data type of at least some of the collected vehicle data. there is The vehicle data transmission circuitry is further configured to selectively transmit at least a portion of the collected vehicle data in response to vehicle operational effects of the transmission operation. The vehicle data transmission circuitry is further configured to selectively transmit at least a portion of the collected vehicle data depending on the power usage impact of the transmission operation. The vehicle data transmission circuitry is further configured to selectively transmit at least a portion of the collected vehicle data in response to the data transmission capacity value. The data transmission capacity values are data transmission capacity associated with a time interval, data transmission capacity associated with an entity associated with at least a portion of collected vehicle data, data transmission capacity associated with an access point name, at least a portion of collected vehicle data. from a value consisting of the data transmission capacity for flows associated with the At least one selected data transmission capacity value is included. The vehicle data transmission circuitry is further configured to selectively transmit at least a portion of the collected vehicle data according to currently available transmission types. The vehicle data transmission circuitry is further configured to selectively transmit at least a portion of the collected vehicle data by selecting a data transmission chunk size for at least the portion of the collected vehicle data. The data transmission chunk size includes at least one of individual message size or single transmission flow size. The vehicle data transmission circuitry further determines the transmission chunk size provided in the vehicle policy data value, the transmission chunk size for priority of at least some of the collected vehicle data, and the availability for transmission resources for at least some of the collected vehicle data. The transmission chunk size is configured to select a transmission chunk size depending on at least one of a transmission chunk size corresponding to the description, a transmission chunk size corresponding to past transmission availability for the vehicle, or an operational state of the vehicle. The vehicle transmission circuitry is further configured to coordinate selective transmission of at least a portion of the collected vehicle data in response to a successful parameter of the transmission operation. The vehicle transmission circuitry is further configured to coordinate selective transmission of at least a portion of the collected vehicle data in response to quality of service parameters for transmission operations.

An exemplary apparatus is a remote access enforcing circuit configured to interpret a remote access request value from a requesting device, the remote access request value including at least one requested vehicle property. A circuit, a property conversion circuit configured to determine a property request value in response to at least one requested vehicle property, and a parameter configured to interpret a plurality of vehicle parameter values in response to the property request value. and a parameter adjustment circuit configured to generate vehicle property data from a plurality of vehicle parameter values corresponding to at least one requested vehicle property in response to a property request value; The circuitry is further configured to send the vehicle property data to the requesting device.

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The apparatus is a converged network device (CND) configured to coordinate communications between a first network zone having a first network endpoint and a second network zone having a second network endpoint and at least some of the plurality of vehicle parameter values are generated by each of the first network endpoint and the second network endpoint. wherein the remote access request value includes a vehicle function value and the property conversion circuit is further configured to determine an actuator command value in response to the vehicle function value; remote operating circuitry configured to provide to the The apparatus is configured to coordinate communications between a first network zone having a first network endpoint and a second network zone having a second network endpoint and including a vehicle network zone. a integrated network device (CND), the first network endpoint providing at least a portion of the plurality of vehicle parameter values, and the second network endpoint including an actuator responsive to the actuator command value. The property conversion circuit further determines the actuator command value as a sequence of actuator commands corresponding to a diagnostic test operation, determines the actuator command value as a sequence of actuator commands corresponding to a remote control operation, or determines the actuator command value as a sequence of actuator commands corresponding to a remote control operation. determining as at least one actuator command corresponding to the function value, the actuator command value being determined by performing at least one operation selected from the operations; The apparatus further includes an additional plurality of endpoints distributed across at least the first network zone and the second network zone, each of the additional plurality of endpoints receiving at least a portion of the plurality of vehicle parameter values. offer. The apparatus further includes an additional plurality of endpoints distributed across at least the first network zone and the second network zone, each additional plurality of endpoints including a corresponding actuator, each actuator command Depending on at least part of the value. Remote access request values include policies. The policy is a requesting device authorization value, a data collection description including at least one requested vehicle property, a trigger description value including a trigger state and a trigger response value, wherein the parameter acquisition circuit selects a plurality of trigger description values according to the trigger description value. At least one value selected from a trigger description value, or a policy priority value, further configured to generate at least a portion of vehicle property data further from the vehicle parameter value. Remote access request values include policies. The policy is a trigger description value including a requesting device authorization value, a trigger state and a trigger response value, and the remote motion circuit further provides an actuator command value in response to the trigger description value, and a policy priority It includes at least one value selected from the group consisting of degree values.

An exemplary apparatus is a vehicle event graphical user interface (GUI) configured to interpret a trigger description value from a user, the trigger description value including a trigger state; A request circuit configured to determine a response action value, the response action value transmitted in response to a trigger condition or a vehicle data identifier configured to identify vehicle data captured in response to the trigger condition. configured to receive a request circuit including at least one of the alert execution descriptions and at least one of at least a portion of the identified vehicle data or an alert response value determined in response to the alert execution descriptions. including a cloud interface;

Certain additional aspects of exemplary devices are described below, any one or more of which can be present in a particular embodiment. The GUI is configured to display one vehicle use case template of the plurality of vehicle use case templates in response to template selection. The GUI is configured to display a portion of the plurality of vehicle usage template identifiers, the GUI determining the portion based on at least one of the authorization value and the location value. The position value corresponds to at least one of a device position and a vehicle position. The GUI is configured to display the plurality of vehicle usage template identifiers, and the GUI is configured to indicate that some of the plurality of vehicle usage template identifiers are unavailable based on the vehicle data collection parameter values. be. The GUI is configured to display a vehicle usage template including multiple vehicle data identifiers based on the authorization values. The alert response values include at least one of alert criteria, alert type, alert content, and alert location. The request circuitry is configured to reject the trigger description values as a function of the vehicle data collection parameter values. A vehicle data collection parameter value indicates that the identified vehicle data cannot be captured by the vehicle. The trigger description value includes a plurality of trigger conditions including the trigger condition, and the identified vehicle data will be captured in response to the plurality of trigger conditions. Multiple trigger conditions use multiple vehicle data types.

An exemplary method includes operating a user device including a vehicle graphical user interface, a request circuit, and a cloud interface; interpreting trigger description values including trigger conditions from a user; Determining an action value, wherein the response action value is at least one of a vehicle data identifier configured to identify vehicle data to be captured in response to a trigger condition or an alert execution description sent in response to a trigger condition. and receiving at least a portion of the identified vehicle data or at least one of an alert response value determined in response to the alert execution description.

Certain additional aspects of exemplary methods are described below, any one or more of which may be present in a particular embodiment. displaying a portion of the plurality of vehicle use template identifiers; and, responsive to template selection, displaying one vehicle use case template of the plurality of vehicle use case templates. displaying a plurality of vehicle usage template identifiers; and indicating that some of the plurality of vehicle usage template identifiers are unavailable based on vehicle data collection parameter values, the vehicle data collection parameter values indicates that the received vehicle data cannot be captured by the vehicle. Displaying a vehicle use case template including a plurality of vehicle data identifiers based on the authorization values. Eliminating trigger description values depending on vehicle data collection parameter values.

An exemplary cloud system comprises: a request interface configured to interpret multiple response action values; and a policy creator circuit configured to determine a data collection policy in response to the multiple response action values. , the data collection policy includes a vehicle data identifier, a trigger evaluation data identifier configured to identify trigger evaluation data, and a trigger condition to be evaluated in response to the identified trigger evaluation data; and , a cloud interface configured to receive at least one of at least a portion of the vehicle data identified in response to the data collection policy, or an alert response value in response to the data collection policy.

Certain additional aspects of exemplary cloud systems are described below, any one or more of which may be present in a particular embodiment. Storing a plurality of vehicle use case templates and configured to provide one of the plurality of vehicle use case templates in response to a user device request and in response to at least one of authorization values or location values. Template storage circuit. The plurality of responsive action values includes a plurality of evaluated collection parameter values corresponding to the common vehicle data source, and the policy creator circuit responds to the plurality of evaluated collection parameter values to generate the evaluated collection parameter values of the data collection policy. is configured to determine The plurality of evaluation collection parameter values includes a plurality of different frequencies, and the evaluation collection parameter includes frequencies configured to collect vehicle data from the common vehicle data source based on the plurality of different frequencies. The data collection policy includes a plurality of vehicle data identifiers and a plurality of trigger policies including a plurality of trigger conditions evaluated based on trigger evaluation data identified by the plurality of trigger evaluation data identifiers. A verification circuit configured to eliminate one of the plurality of response action values in response to determining the execution parameter value. A verification circuit determines the execution parameter value by determining that the vehicle data identified by the excluded response action value cannot be captured by the vehicle. An authorization circuit configured to tag a data collection policy according to an authorization value, the authorization value authorizing a source of one of the plurality of response action values to receive the identified vehicle data. indicates that it is not a first partition including a request interface, a policy creator circuit, and a cloud interface; a vehicle data storage circuit configured to store vehicle data identified from a vehicle; and a vehicle identified in response to the vehicle data request. A second partition including a second cloud interface configured to provide data to the first cloud interface. The identified vehicle data is encrypted while being stored with the vehicle data storage circuitry, and the first partition is configured to decrypt the identified vehicle data stored with the vehicle data storage circuitry. do not have. The second partition includes vehicle data query circuitry configured to store metadata corresponding to the identified vehicle data and to provide vehicle data query results in response to the metadata.

An exemplary method includes operating a cloud system including a request interface, a policy creator circuit, and a cloud interface; interpreting a plurality of response action values; and formulating a data collection policy in response to the plurality of response action values. determining, wherein the data collection policy includes a vehicle data identifier, a trigger evaluation data identifier configured to identify trigger evaluation data, and a trigger condition to be evaluated in response to the identified trigger evaluation data; and receiving at least a portion of the identified vehicle data responsive to the data collection policy or at least one of an alert response value responsive to the data collection policy.

An exemplary vehicle is a cloud interface configured to interpret data collection policies from a remote device, the data collection policies configured to identify trigger evaluation data to be evaluated in response to trigger conditions. a cloud interface including a trigger evaluation data identifier; a policy update circuit configured to determine a collected verification value in response to the identified trigger evaluation data and vehicle data collection parameters; and a trigger evaluation circuit configured to receive the vehicle communication system.

Certain additional aspects of exemplary vehicles are described below, any one or more of which may be present in a particular embodiment. The vehicle communication system includes a policy manager circuit configured to parse the data collection policy according to the collection verification value. The trigger evaluation circuit is configured to determine a trigger event occurrence responsive to the trigger condition, and the vehicle communication system determines at least one of vehicle data identified responsive to the trigger event occurrence or an alert response value responsive to the trigger event occurrence. a transmitter circuit configured to provide a The alert response values include at least one of alert criteria, alert type, alert content, and alert location. The data collection policy includes a vehicle data identifier configured to identify the identified vehicle data. The collected verification value indicates that the vehicle is configured to provide trigger evaluation data. A policy manager circuit is configured to encrypt the data collection policy and replace the previous data collection policy with the data collection policy depending on the collection verification value. The vehicle communication system ceases executing the data collection policy in response to at least one of the updated authorization value and the updated location value.

An exemplary apparatus is a parameter acquisition circuit configured to interpret a vehicle parameter value and a property conversion circuit configured to interpret a property request value, the property request value being a requested vehicle property and a parameter adjustment circuit configured to generate vehicle property data from vehicle parameter values in response to a property request value, the vehicle property data corresponding to the requested vehicle property. and including.

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The apparatus further comprises claimant verification circuitry configured to determine an entity authorization value as a function of and at least partially based on the property claim value; and to transmit vehicle property data as a function of the entity authorization value. and a configured vehicle property providing circuit. The apparatus further includes a subscription circuit configured to add the requesting entity to the subscriber data list in response to the property request value, the vehicle property providing circuit providing the vehicle property data to the requesting entity in response to the subscriber data list. configured to send to The apparatus further includes vehicle property provision circuitry configured to transmit vehicle property data in response to the property request. a converged network device (CND) configured to coordinate communication between a first network zone having a first vehicle sensor and a second network zone having a second vehicle sensor; vehicle parameters; A value is generated by at least one of the first vehicle sensor and the second vehicle sensor. Parameter acquisition circuitry configured to interpret a plurality of vehicle parameter values; Parameter adjustment circuitry configured to generate vehicle property data from the plurality of vehicle parameter values; A vehicle parameter value is provided from a first vehicle sensor and a second vehicle parameter value of the plurality of vehicle parameter values is provided from a second vehicle sensor. The first network zone and the second network zone are of different types. Vehicle parameter values correspond directly to requested vehicle properties. The vehicle parameter values include at least one of vehicle speed values, prime mover speed values, prime mover torque values, user-actuated vehicle property values, or vehicle position values. Vehicle parameter values include network utilization values for the vehicle network zone, raw network messages from the vehicle network zone, network addresses of endpoints on the vehicle network zone, memory storage descriptions of the vehicle's controller, controller area network (CAN) It includes at least one of a value from an endpoint, a value from an endpoint on a local interconnect network (LIN), or an intermediate control value. The requested vehicle properties include at least one of component temperature values, sensor raw values, component velocity values, or actuator feedback values. The requested vehicle properties include at least one of driveline component speed values, drive shaft speed values, drive shaft torque values, gear selection values, battery health values, battery state of charge values, or battery power throughput values. . The parameter adjustment circuit is configured to generate virtual vehicle property values from the two one or more vehicle parameter values in response to the property request values, the vehicle property data including virtual vehicle property values. The virtual vehicle property values include at least one of vehicle speed values, power efficiency values, event occurrence values, or a list of previous vehicle positions. The virtual vehicle property value is at least one of an estimated temperature value, an estimated pressure value, an effective temperature value, an effective pressure value, a heat transfer coefficient value, a component life remaining value, a component time to maintenance value, or a diagnostic counter value. including one. The virtual vehicle property values include at least one of a list of one or more user-actuated characteristics, average vehicle runtime values, or estimated vehicle operating cost values. Vehicle property data is in a different format than vehicle parameter values.

An exemplary method includes the steps of interpreting a vehicle parameter value; interpreting a property request value that at least partially defines a requested vehicle property; and generating vehicle property data corresponding to the vehicle properties.

Certain additional aspects of exemplary methods are described below, any one or more of which may be present in a particular embodiment. The method further includes determining an entity authorization value as a function of the property request value and based at least in part on the property request value; and transmitting vehicle property data as a function of the entity authorization value. The method further includes adding the requesting entity to the subscriber data list in response to the property request value, and transmitting vehicle property data in response to the subscriber data list. The method further includes transmitting vehicle property data in response to the property request. The method further comprises coordinating communication between a first network zone having a first vehicle sensor and a second network zone having a second vehicle sensor; and generating vehicle parameter values by at least one of the vehicle sensors. Interpreting the vehicle parameter values includes interpreting a plurality of vehicle parameter values, and generating vehicle property data is based, at least in part, on the plurality of vehicle parameter values and the plurality of vehicle parameter values. A first vehicle parameter value of the plurality of vehicle parameter values is provided from a first vehicle sensor and a second vehicle parameter value of the plurality of vehicle parameter values is provided from a second vehicle sensor. The first network zone and the second network zone are of different types. Vehicle parameter values correspond directly to requested vehicle properties. The vehicle parameter values include at least one of vehicle speed values, prime mover speed values, prime mover torque values, user-actuated vehicle characteristic values, or vehicle position values. Vehicle parameter values include network utilization values for the vehicle network zone, raw network messages from the vehicle network zone, network addresses of endpoints on the vehicle network zone, memory storage descriptions of the vehicle's controller, controller area network (CAN) It includes at least one of a value from an endpoint, a value from an endpoint on a local interconnect network (LIN), or an intermediate control value. The requested vehicle properties include at least one of component temperature values, sensor raw values, component velocity values, actuator feedback values. The requested vehicle properties include at least one of a driveline component speed value, a drive shaft speed value, a drive shaft torque value, a gear selection value, a battery health value, a battery state of charge value, or a battery power handling capacity value. include. The parameter adjustment circuit is configured to generate virtual vehicle property values from the two one or more vehicle parameter values in response to the property request values, the vehicle property data including virtual vehicle property values. The virtual vehicle property values include at least one of vehicle speed values, power efficiency values, event occurrence values, or a list of previous vehicle positions. The virtual vehicle property values include at least one of a list of one or more user-actuated characteristics, average vehicle runtime values, or estimated vehicle operating cost values. Vehicle property data is in a different format than vehicle parameter values.

An exemplary method includes, at a first vehicle, interpreting a first property request value that at least partially defines a requested vehicle property; generating first vehicle property data corresponding to the requested vehicle property from the first plurality of vehicle parameter values for the first vehicle; interpreting the second property request value; and, in the second vehicle, corresponding to the requested vehicle property from the second plurality of vehicle parameter values of the second vehicle in response to the second property request value. and generating second vehicle property data.

Certain additional aspects of exemplary methods are described below, any one or more of which can be present in a particular embodiment. The first vehicle property data and the second vehicle property data are substantially the same. The first property requirement value and the second property requirement value are substantially the same. The method further includes generating a first plurality of vehicle parameter values via a first vehicle sensor and a second vehicle sensor, the first vehicle sensor being a first network of the first vehicle. a third vehicle sensor and a second vehicle sensor located on a second network of the first vehicle, the first network being of a different type than the second network; generating a second plurality of vehicle parameter values via four vehicle sensors, the third vehicle sensor being located on a third network of the second vehicle, the fourth vehicle sensor being the second vehicle sensor; located on a fourth network of the two vehicles, the third network being of a different type than the fourth network, at least one of the first and second networks Different from at least one of the third and fourth networks. The method further includes generating a first plurality of vehicle parameter values via a first vehicle sensor located on a first network of the first vehicle; and a second network of the second vehicle. generating a second plurality of vehicle parameter values via a second vehicle sensor positioned thereon, the second network being of a different type than the first network.

An exemplary apparatus includes: policy acquisition circuitry configured to interpret vehicle policy data values including at least a portion of a vehicle policy; , a policy processing circuit configured to generate parsed policy data including one or more vehicle sub-policies of the vehicle policy; and vehicle data from one or more vehicle sensors in response to the parsed policy data. and a policy enforcement circuit configured to collect the

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The policy processing circuitry is further configured to determine a vehicle policy type value from the vehicle policy data value, the type value being at least one of a passive policy or an active policy. The policy enforcement circuitry is further configured to passively collect vehicle data responsive to the type value being a passive policy. The policy enforcement circuitry is further configured to: actively collect vehicle data responsive to the type value being an active policy. The policy enforcement circuit is further configured to send a start collection command value for actively collecting vehicle data. The policy enforcement circuitry is further configured to generate vehicle property values for actively collecting vehicle data based at least in part on the collected vehicle data. The policy enforcement circuitry is further configured to send query values for actively collecting vehicle data. The apparatus further includes a memory device configured to store the collected vehicle data. The apparatus further includes a Converged Network Device (CND) configured to coordinate communications between a first network zone and a second network zone, the first network zone comprising one or more A first one of the vehicle sensors is included, and the second network zone includes a second one of the one or more vehicle sensors. The first network zone and the second network zone are of different types. The policy enforcement circuitry is further configured to delegate collection of vehicle data to the one or more vehicle controllers via transmitting at least a portion of the parsed policy data to the one or more vehicle controllers. . The apparatus further includes collected data acquisition circuitry configured to interpret vehicle data collected by one or more vehicle controllers. The apparatus further includes a collected data providing circuit configured to transmit the collected vehicle data.

An exemplary method includes the steps of interpreting a vehicle policy data value including at least a portion of a vehicle policy; generating parsed policy data including the above vehicle sub-policies; and collecting vehicle data from one or more vehicle sensors in response to the parsed policy data.

Certain additional aspects of exemplary methods are described below, any one or more of which may be present in a particular embodiment. The method further includes determining a type value of the vehicle policy from the vehicle policy data value, the type value being at least one of a passive policy or an active policy. Collecting vehicle data includes passively collecting vehicle data according to the type value. Collecting vehicle data includes actively collecting vehicle data in response to the type value. Actively collecting vehicle data includes transmitting a start collection command value. Actively collecting vehicle data includes generating vehicle property values based at least in part on the collected vehicle data. Actively collecting vehicle data includes transmitting query values. The method further includes coordinating communication between the first network zone and the second network zone, wherein the first network zone controls the first of the one or more vehicle sensors. and the second network zone has a second one of the one or more vehicle sensors. The first network zone and the second network zone are of different types. Collecting vehicle data includes delegating collection of vehicle data to one or more vehicle controllers by transmitting at least a portion of the parsed policy data to one or more vehicle controllers. . The method further includes interpreting vehicle data collected by one or more vehicle controllers. The method further includes transmitting the collected vehicle data.

An exemplary apparatus is an integrated network device configured to coordinate communications between a first network zone having a first network endpoint and a second network zone having a second network endpoint CND), wherein the plurality of vehicle parameter values are generated by a first network endpoint and a second network endpoint; and a parameter acquisition configured to interpret the plurality of vehicle parameter values. circuitry, property conversion circuitry configured to interpret property request values including at least some of the requested vehicle properties, and, in response to the property request values, to generate vehicle property data from a plurality of vehicle parameter values. wherein the vehicle property data corresponds to the requested vehicle property.

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The apparatus further includes a parameter providing circuit configured to transmit vehicle property data. The first network zone and the second network zone are of different types. A first network zone includes a controller area network (CAN). The first and second network endpoints are vehicle sensors. A plurality of vehicle parameter values directly correspond to requested vehicle properties. The plurality of vehicle parameter values includes at least one of a vehicle speed value, a prime mover speed value, a prime mover torque value, a user-actuated vehicle characteristic value, or a vehicle position value. The plurality of vehicle parameter values includes a vehicle network zone network utilization value, a raw network message from the vehicle network zone, a network address of an endpoint on the vehicle network zone, a memory storage description of the vehicle's controller, a controller area network (CAN). It includes at least one of a value from an endpoint above, a value from an endpoint on a local interconnect network (LIN), or an intermediate control value. The requested vehicle properties include at least one of component temperature values, sensor raw values, component velocity values, or actuator feedback values. The requested vehicle properties include at least one of driveline component speed values, drive shaft speed values, drive shaft torque values, gear selection values, battery health values, battery state of charge values, or battery power throughput values. . The parameter adjustment circuit is configured to generate virtual vehicle property values from the two one or more vehicle parameter values in response to the property request values, the vehicle property data including virtual vehicle property values. The virtual vehicle property values include at least one of vehicle speed values, power efficiency values, event occurrence values, or a list of previous vehicle positions. 289. The apparatus of claim 288, wherein the virtual vehicle property values comprise at least one of a list of one or more user-actuated features, average vehicle runtime values, or estimated vehicle operating cost values. The vehicle property data is in a different format than the plurality of vehicle parameter values.

An exemplary method comprises coordinating communication between a first network zone having a first network endpoint and a second network zone having a second network endpoint, wherein a plurality of vehicle parameters interpreting a plurality of vehicle parameter values; and property request values that at least partially define requested vehicle properties. and, in response to the property request values, generating vehicle property data corresponding to the requested vehicle property from the plurality of vehicle parameter values.

Certain additional aspects of exemplary methods are described below, any one or more of which may be present in a particular embodiment. The method further includes transmitting vehicle property data. The first network zone and the second network zone are of separate types. A first network zone includes a controller area network (CAN). The first network endpoint and the second network endpoint are vehicle sensors. A plurality of vehicle parameter values directly correspond to requested vehicle properties. The plurality of vehicle parameter values includes at least one of a vehicle speed value, a prime mover speed value, a prime mover torque value, a user-actuated vehicle characteristic value, or a vehicle position value. The plurality of vehicle parameter values includes a vehicle network zone network utilization value, a raw network message from the vehicle network zone, a network address of an endpoint on the vehicle network zone, a memory storage description of the vehicle's controller, a controller area network (CAN). It includes at least one of a value from an endpoint above, a value from an endpoint on a local interconnect network (LIN), or an intermediate control value. The requested vehicle properties include at least one of component temperature values, sensor raw values, component velocity values, actuator feedback values. The requested vehicle properties include at least one of a driveline component speed value, a drive shaft speed value, a drive shaft torque value, a gear selection value, a battery health value, a battery state of charge value, or a battery power handling capacity value. include. The parameter adjustment circuit is configured to generate virtual vehicle property values from the two one or more vehicle parameter values in response to the property request values, the vehicle property data including virtual vehicle property values. The virtual vehicle property values include at least one of vehicle speed values, power efficiency values, event occurrence values, or a list of previous vehicle positions. The virtual vehicle property values include at least one of a list of one or more user-actuated characteristics, average vehicle runtime values, or estimated vehicle operating cost values. The vehicle property data is in a different format than the plurality of vehicle parameter values.

An exemplary apparatus includes parameter acquisition circuitry configured to interpret vehicle parameter values, property conversion circuitry configured to interpret property request values that at least partially define requested vehicle properties, and a parameter adjustment circuit configured to generate, in response to the property request value, modified vehicle parameter data corresponding to the requested vehicle property from the vehicle parameter values.

Certain additional aspects of exemplary devices are described below, any one or more of which can be present in a particular embodiment. The modified vehicle parameter data includes virtual vehicle property values. The virtual vehicle property values are based at least in part on two or more vehicle parameter values. The parameter adjustment circuitry includes formatting circuitry configured to format the vehicle parameter values into the desired format of the requested vehicle property such that the modified vehicle parameter data has the desired format. The desired format is based at least in part on the network protocol. The desired format is based at least in part on storage of vehicle parameter values on non-transitory computer-readable media. The desired format is based at least in part on the compression standard. The parameter adjustment circuit converts one or more units of the vehicle parameter value to one or more desired units of the requested vehicle property such that the modified vehicle parameter data has the desired one or more units. a unit conversion circuit configured to convert to . The parameter adjustment circuitry includes sampling circuitry configured to adjust the sampling rate of the vehicle parameter values to the desired sampling rate of the requested vehicle property such that the modified vehicle parameter data has the desired sampling rate. A sampling circuit is configured to upsample the vehicle parameter value. A sampling circuit is configured to downsample the vehicle parameter value.

An exemplary method includes the steps of interpreting a vehicle parameter value; interpreting a property request value that at least partially defines a requested vehicle property; and generating modified vehicle parameter data corresponding to the vehicle properties.

Certain additional aspects of exemplary methods are described below, any one or more of which can be present in a particular embodiment. Generating the modified vehicle parameter data includes generating virtual vehicle property values, the modified vehicle parameter data including the virtual vehicle property values. The virtual vehicle property values are based at least in part on two or more vehicle parameter values. The method further includes formatting the vehicle parameter values into the desired format of the requested vehicle property such that the modified vehicle parameter data has the desired format. Formatting the vehicle parameter values includes generating network protocol packets configured to transmit the vehicle parameter values. Formatting the vehicle parameter values includes modifying the vehicle parameter values for storage on the non-transitory computer-readable medium. Modifying the vehicle parameter values includes compressing the vehicle parameter values. The method further includes adding one or more units of the vehicle parameter value to the desired unit or units of the requested vehicle property, such that the modified vehicle parameter data has the desired unit or units. , including the step of converting to The method further includes adjusting the sampling rate of the vehicle parameter values to the desired sampling rate of the requested vehicle property such that the modified vehicle parameter data has the desired sampling rate. Adjusting the sampling rate of the vehicle parameter values includes upsampling the vehicle parameter values. Adjusting the sampling rate of the vehicle parameter values includes downsampling the vehicle parameter values.

An exemplary apparatus includes parameter acquisition circuitry configured to interpret a plurality of vehicle parameter values and parameter and a parameter storage circuit configured to store the adjusted vehicle parameter values in one or more cache devices.

Certain additional aspects of exemplary devices are described below, any one or more of which can be present in a particular embodiment. The parameter adjustment circuit is further configured to determine a storage position value, the parameter storage circuit is further configured to store a plurality of adjusted vehicle parameter values in response to the storage position value, one or more cache device is installed in the vehicle. Each of the one or more cache devices onboard the vehicle is associated with a different controller than the controller associated with the other of the one or more cache devices. The parameter adjustment circuit is further configured to determine a storage position value, the parameter storage circuit is further configured to store a plurality of adjusted vehicle parameter values in response to the storage position value, one or more is located outside the vehicle. One or more cache devices are based at least in part on a network cloud-based storage system. The parameter adjustment circuit is further configured to determine a storage location value; the parameter storage circuit is further configured to adjust a plurality of data on the first cache device of the one or more cache devices according to the storage location value; storing a first portion of the vehicle parameter values and a second portion of the adjusted plurality of vehicle parameter values on a second cache device of the one or more cache devices; Mounted on the vehicle, the second cache device is located outside the vehicle. The parameter adjustment circuit is further configured to generate an expiration value for the plurality of vehicle parameter values configured to trigger selective expiration of the plurality of vehicle parameter values in the one or more cache devices. there is The parameter storage circuitry is further configured to send the expiration value to one or more cache devices. The parameter storage circuit is further configured to selectively expire the plurality of vehicle parameter values according to the expiration time value. An expiration value is a time value that corresponds to a period of time during which multiple vehicle parameter values are stored in one or more caches. The apparatus further includes policy acquisition circuitry configured to interpret a vehicle policy data value that includes at least a portion of a vehicle policy, and the parameter adjustment circuitry further generates an expiration value as a function of the vehicle policy data value. is configured as The parameter adjustment circuit is further configured to determine type values for the plurality of vehicle parameter values and to generate an expiration date value responsive to the type values. The type value corresponds to at least one of engine data, control data, mission critical data, drive status data, or drive operation data. The type value corresponds to at least one of a vehicle status value, a vehicle mode value, a diagnostic value, or a fault value. The parameter adjustment circuit is further configured to adjust the plurality of vehicle parameter values via compressing the plurality of vehicle parameter values. The parameter adjustment circuit is further configured to adjust the multiple vehicle parameter values through summarizing the multiple vehicle parameter values.

An exemplary method includes the steps of interpreting a plurality of vehicle parameter values; adjusting the plurality of vehicle parameter values for storage in one or more cache devices; or storing in two or more cache devices.

Certain additional aspects of exemplary methods are described below, any one or more of which may be present in a particular embodiment. The method further includes determining a storage location value, wherein storing the adjusted plurality of vehicle parameter values is responsive to the storage location value, and wherein the one or more cache devices are mounted on the vehicle. ing. Each of the one or more cache devices onboard the vehicle is associated with a different controller than the controllers associated with the other of the one or more cache devices. The method further includes determining a storage location value, wherein storing the adjusted plurality of vehicle parameter values is responsive to the storage location value, wherein the one or more caching devices are external to the vehicle. are placed. One or more cache devices are based at least in part on a network cloud-based storage system. The method further comprises determining a storage position value, wherein storing the adjusted plurality of vehicle parameter values comprises: responsive to the storage position value, a first of the adjusted plurality of vehicle parameter values; storing a second portion of the adjusted plurality of vehicle parameter values in a second cache device of the one or more cache devices; storing in the cache device, wherein the first cache device is mounted on the vehicle and the second cache device is located outside the vehicle. The method further includes generating an expiration value for the plurality of vehicle parameter values configured to trigger selective expiration of the plurality of vehicle parameter values in one or more cache devices. 350. The method of claim 350, further comprising transmitting the expiration value to one or more cache devices. The method further includes selectively revoking the plurality of vehicle parameter values according to the expiration value. An expiration value is a time value that corresponds to a period of time during which multiple vehicle parameter values are stored in one or more caches. The method further includes interpreting a vehicle policy data value that includes at least a portion of a vehicle policy, wherein generating an expiration time value for the plurality of vehicle parameter values is responsive to the vehicle policy data value. The method further includes determining a type value for the plurality of vehicle parameter values. The step of generating expiration values for the plurality of vehicle parameter values is responsive to the type values. The type value corresponds to at least one of engine data, location data, vehicle environment data, or infotainment console data. Adjusting the plurality of vehicle parameter values includes compressing the plurality of vehicle parameter values. Adjusting the plurality of vehicle parameter values includes summarizing the plurality of vehicle parameter values.

The exemplary vehicle is configured to identify a trigger condition, a vehicle data identifier configured to identify vehicle data captured in response to the occurrence of a trigger event, and trigger evaluation data captured in response to the trigger condition. a policy manager circuit configured to interpret the data collection policy including the trigger evaluation data identifier; and to provide a raw vehicle data stream including the trigger evaluation data stream and the identified vehicle data stream in response to the data collection policy. a vehicle communication system including an endpoint configured to;

Certain additional aspects of exemplary vehicles are described below, any one or more of which may be present in certain embodiments. A filtering circuit configured to determine a trigger evaluation data stream of the raw vehicle data stream according to the trigger evaluation data identifier and to provide a trigger evaluation data stream. A filtering circuit is configured to determine an identified vehicle data stream in response to the vehicle data identifier. sampling a trigger evaluation data stream according to a sampling parameter of a data collection policy; normalizing a trigger evaluation data value format; or determining a trigger evaluation data aggregation parameter according to multiple trigger conditions of a data collection policy. vehicle data processing circuitry configured to perform at least one of: A rotating buffer circuit configured to store a rotating time window of trigger evaluation data, the rotating buffer circuit determining the rotating time window in response to a trigger condition. A rotational buffer circuit is configured to store a second rotational time window of the identified vehicle data stream in accordance with a data collection policy. The rotating buffer circuit is configured to store a first rotating time window of the trigger evaluation data stream in response to a trigger condition, the trigger evaluation circuit using the first rotating time window to evaluate the trigger condition. and configured to determine the occurrence of a trigger event accordingly. A vehicle data storage circuit configured to store identified vehicle data of the identified vehicle data stream in response to a trigger event occurrence and a data collection policy, wherein at least a portion of the identified vehicle data comprises: Occurs before the trigger event occurs. A cloud interface configured to provide identified vehicle data of the identified vehicle data stream in response to the occurrence of a trigger event and transmission parameter values of the data collection policy. A cloud interface configured to provide alert response values in response to the occurrence of a trigger event, the alert response values including at least one of alert criteria, alert type, alert content, and alert location. The trigger evaluation circuit is configured to simultaneously evaluate multiple trigger conditions of the data collection policy, and the trigger evaluation circuit is configured to determine occurrence of the trigger event in response to the multiple trigger conditions.

An exemplary method comprises the steps of operating a vehicle including a vehicle communication system including a policy manager circuit and an endpoint; and the policy manager circuit determining data collection policies including trigger conditions, vehicle data to be captured in response to trigger event occurrences. and a trigger evaluation data identifier configured to identify the trigger evaluation data captured in response to a trigger condition; providing a raw vehicle data stream including the trigger evaluation data stream and the identified vehicle data stream.

Certain additional aspects of exemplary methods are described below, any one or more of which can be present in a particular embodiment. The vehicle communication system includes a filtering circuit, and the method includes determining, with the filtering circuit, a trigger evaluation data stream of the raw vehicle data stream responsive to the trigger evaluation data identifier. Determining, with a filtering circuit, the vehicle data stream identified according to the vehicle data identifier. The vehicle communication system includes vehicle data processing circuitry, and the method includes sampling a trigger evaluation data stream according to a sampling parameter of a data collection policy, normalizing a trigger evaluation data value format, or performing a plurality of data collection policies. and processing the trigger evaluation data including at least one of determining trigger evaluation data aggregation parameters in response to the trigger status of the. The vehicle communication system includes a rotating buffer circuit, and the method comprises determining, with the rotating buffer circuit, a rotating time window in response to a trigger condition; and storing, with the rotating buffer circuit, the rotating time window of trigger evaluation data. including. A rotational buffer circuit is configured to store a second rotational time window of the identified vehicle data stream in accordance with a data collection policy. The vehicle communication system includes a rotating buffer circuit and a trigger evaluation circuit, the method comprising storing, in the rotating buffer circuit, a first rotating time window of the trigger evaluation data stream in response to a trigger condition; and the trigger evaluation circuit. and determining occurrence of the trigger event in response to evaluating the trigger condition using the first rotating time window. The vehicle communication system includes vehicle data storage circuitry, and the method includes storing, in the vehicle data storage circuitry, identified vehicle data for identified vehicle data streams in response to a triggering event occurrence and a data collection policy. At least a portion of the vehicle data included and identified occurred prior to the occurrence of the trigger event. The vehicle communication system includes a cloud interface, and the method provides, at the cloud interface, identified vehicle data of the identified vehicle data stream in response to the occurrence of a triggering event and transmission parameter values of the data collection policy. including. The vehicle communication system includes a cloud interface, and the method includes providing, at the cloud interface, an alert response value in response to the occurrence of a triggering event, the alert response value including alert criteria, alert type, alert content, and including at least one of the alert locations; The trigger evaluation circuit is configured to simultaneously evaluate multiple trigger conditions of the data collection policy, and the trigger evaluation circuit is configured to determine occurrence of the trigger event in response to the multiple trigger conditions.

An exemplary vehicle includes a policy manager circuit configured to interpret a data collection policy including a trigger condition and a trigger evaluation data identifier, and configured to capture a trigger evaluation data stream in response to the trigger evaluation data identifier and trigger condition. and a vehicle data interface configured to receive the trigger evaluation data stream.

Certain additional aspects of exemplary vehicles are described below, any one or more of which may be present in certain embodiments. A plurality of endpoints including a first endpoint communicatively coupled to an Ethernet switch, at least some of the plurality of endpoints responsive to a data collection policy for trigger evaluation data values of the trigger evaluation data. configured to capture The endpoint is communicatively coupled to multiple networks that are configured to communicate using multiple communication protocols, and the endpoint may collect trigger assessment data from multiple networks, depending on the data collection policy. Configured to capture trigger evaluation data values. The data collection policy includes a plurality of trigger evaluation data identifiers configured to identify trigger evaluations evaluated by a plurality of trigger conditions of the data collection policy, the trigger evaluation data identifiers being controller area network (CAN) messages; Multiple data types are supported, including at least two of CAN signals, Ethernet packets, vehicle location, vehicle status, and diagnostic trouble codes. Capturing a trigger evaluation data stream includes receiving a trigger evaluation data stream from a data source communicatively coupled to the endpoint or requesting a trigger evaluation data stream from a data source communicatively coupled to the endpoint. at least one of the steps.

The exemplary vehicle includes a policy manager circuit configured to interpret a data collection policy including a vehicle data identifier and a trigger configured to define a trigger condition; determine occurrence; determine trigger event end; determine data capture window in response to trigger event occurrence, trigger event end and data collection policy; capture identified vehicle data in response to data capture window and vehicle data identifier and a trigger evaluation circuit configured to:

Certain additional aspects of exemplary vehicles are described below, any one or more of which may be present in a particular embodiment. The trigger evaluation circuit determines the occurrence of a trigger event by evaluating the trigger evaluation data with a trigger condition, the trigger condition being met or unsatisfied by the trigger evaluation data and a current value. Define relationships. The evaluation data includes at least one of vehicle condition, vehicle status, vehicle operating mode, or vehicle discrete event. The identified vehicle data is generated by the vehicle prior to the occurrence of the triggering event and stored using a rotating buffer circuit. The data collection policy includes a plurality of trigger conditions, each of the plurality of trigger conditions corresponding to one of a plurality of trigger evaluation data values. A trigger evaluation circuit determines the occurrence of a trigger event in response to at least two of the plurality of trigger conditions. The multiple trigger evaluation data values correspond to multiple data types including at least two of controller area network (CAN) messages, CAN signals, Ethernet packets, vehicle location, vehicle status, and diagnostic trouble codes. The trigger evaluation data includes virtual sensor values derived from multiple vehicle data values. The data capture window ends after a delay following the end of the event trigger, depending on the data collection policy. The data collection policy includes multiple trigger conditions with multiple trigger types, the multiple trigger types being signal triggers, vehicle status triggers, timing triggers, schedule triggers, geofence triggers, error triggers, environment triggers, or user input. Include at least two of the triggers. Determining occurrence of the trigger event is based on a first portion of a plurality of trigger conditions, the first portion having a first trigger having a first trigger type and a second trigger type. and a second trigger. Determining the end of the trigger event is based on a second portion of the plurality of triggers, the second portion comprising a first trigger having a first trigger type and a second trigger having a second trigger type. 2 triggers.

An exemplary apparatus includes policy acquisition circuitry configured to interpret a data collection policy including at least one requested vehicle property; a parameter acquisition circuit configured to interpret at least one vehicle parameter value in response to a property request value; and selectively extracting at least one vehicle parameter value in response to a data collection policy. a parameter providing circuit configured to transmit.

Certain additional aspects of exemplary devices are described below, any one or more of which may be present in a particular embodiment. The data collection policy further includes a policy type, and the parameter acquisition circuit is further configured to interpret at least one vehicle parameter value in response to the policy type. The policy type includes a persistent policy, and the parameter acquisition circuit is further configured to persistently evaluate the data collection policy for data gathering operations. The policy type includes an on-demand policy, and the parameter acquisition circuit is further configured to cease evaluation of the data collection policy for data collection operations upon satisfying a data collection cycle of the data collection policy. The policy acquisition circuit is further configured to delete the data collection policy in response to the parameter acquisition circuit stopping evaluating the data collection policy. The policy acquisition circuitry is further configured to delete the data collection policy in response to the parameter provision circuitry transmitting at least one vehicle parameter value corresponding to the data collection policy. The policy type includes at least one type selected from download policy; factory policy; and built-in policy. The policy acquisition circuit is further configured to enforce the downloaded policy, if any. The policy acquisition circuitry is further configured to ignore factory and built-in policies if downloaded policies are present. The policy acquisition circuitry is further configured to enforce the conforming portion of the factory policy, if one exists. The policy acquisition circuit is further configured to enforce the factory policy if present and the downloaded policy if not present. The policy acquisition circuitry is further configured to ignore built-in policies. The policy acquisition circuitry is further configured to enforce the conforming portion of the built-in policy, if present. The data collection policy further includes transmission description values corresponding to the at least one requested vehicle property. The transmission description value includes at least one value selected from a transmission priority value, a data storage description, a network zone usage description, or an access point name (APN) value. The data collection policy further includes data configuration values, and the policy processing circuit is further configured to determine property request values in response to the data configuration values. The data collection policy further includes a trigger data description. A data collection policy further includes a policy priority value. The policy priority values include at least one priority value selected from values consisting of a data collection priority value, a data storage priority value, or a transmission priority value. The policy acquisition circuit is further configured to determine a policy capability value and selectively enable the data collection policy in response to the policy capability value. The data collection policy includes a policy lifecycle description, and the policy acquisition circuitry is further configured to selectively enable the data collection policy in response to the policy lifecycle description. A policy lifecycle description includes a policy start time; a policy end time; a trigger data description containing collection criteria values for the data collection policy; the amount of data captured under the data collection policy; or the number of triggering events for which data is captured under the data collection policy.

An exemplary cloud system includes a request interface configured to interpret multiple response action values from an external device and a policy author configured to determine a data collection policy in response to the multiple response action values. a policy creator circuit, wherein the data collection policy includes a vehicle data identifier; a cloud interface configured to receive vehicle data identified in accordance with the data collection policy; and the received identified vehicle data. a raw data manager circuit configured to store at least a portion of the request interface, wherein at least a portion of the identified vehicle data includes the response vehicle data and the identification data; is further configured to interpret the vehicle data request, obtain at least a portion of the responsive vehicle data from the raw data manager circuit in response to the vehicle data request, and provide the obtained data to the external device.

Certain additional aspects of exemplary cloud systems are described below, any one or more of which may be present in a particular embodiment. The response vehicle data is encrypted using a first encryption keyset and the identification data is encrypted using a second encryption keyset. The request interface is further configured to utilize at least one key of the second set of encryption keys to obtain at least a portion of the response vehicle data. The keys of the first encryption keyset are not stored on the cloud system. The identification data includes metadata specific to multiple response action values.

An exemplary cloud system is a raw data manager circuit configured to store collected data from a vehicle, the stored collected data encrypted using a first encryption keyset a raw data manager circuit including a payload portion and an identification portion encrypted using a second encryption keyset; and requesting from the raw data manager circuit using only the second encryption keyset. a request interface configured to pass the requested portion of the stored collected data to the external device.

Certain additional aspects of exemplary cloud systems are described below, any one or more of which may be present in a particular embodiment. The raw data manager circuit is further configured to determine the requested portion of the stored collected data in response to comparing the identified portion to the vehicle data requested value. The raw data manager circuit is further configured to determine the requested portion of the stored collected data in response to a hash check operation performed on the requested portion of the stored collected data.

An exemplary system includes a collected vehicle data storage circuit configured to store collected data from the vehicle; selectively providing vehicle data collection requests from external devices to the vehicle; an external data collection interface configured to selectively provide at least a portion of the stored collected data from the collected vehicle data storage circuit in response to at least a portion of the stored collected data and the stored collected data; and means for separating a cryptographic key for at least a portion of

Certain additional aspects of exemplary systems are described below, any one or more of which may be present in a particular embodiment. The external data collection interface is further configured to selectively provide the vehicle data collection request to the vehicle by providing the vehicle data collection request to the collection vehicle data storage circuit.

An exemplary cloud system includes a request interface configured to interpret a vehicle data collection request for at least one identified vehicle and a policy configured to determine a data collection policy in response to the vehicle data collection request. a creator circuit, a cloud interface configured to provide a data collection policy to at least one identified vehicle and receive responsive vehicle data from the at least one identified vehicle, and at least a portion of the responsive vehicle data. and a raw data management circuit configured to store:

Certain additional aspects of exemplary cloud systems are described below, any one or more of which may be present in a particular embodiment. The request interface is further configured to expose an application programming interface (API) to external devices and interpret vehicle data collection requests in response to invocation of the API. The request interface interprets vehicle data requests from external devices in response to API invocations, obtains at least a portion of the responsive vehicle data from the raw data manager circuit in response to the vehicle data requests, and communicates the obtained data to the external device. further configured to provide. The request interface is further to interpret a vehicle data request from the external device, obtain at least a portion of the responsive vehicle data from the raw data manager circuit in response to the vehicle data request, and provide the obtained data to the external device. It is configured. The request interface is configured to interpret at least one additional vehicle data collection request for the at least one identified vehicle, and the policy creator circuit is configured to interpret the vehicle data collection request and the at least one additional vehicle data collection request. Further configured to determine a data collection policy accordingly. The policy creator circuitry is further configured to determine a policy capability value in response to the vehicle data collection request and selectively enable data collection policy determination in response to the policy capability value. The policy author circuit determines a data storage size determined to support the vehicle data collection request, a transmission volume value determined to support the vehicle data collection request, a data availability value associated with the vehicle data collection request, or Further configured to determine the policy capability value in response to at least one parameter selected from parameters comprising data configuration values associated with the vehicle data collection request. The cloud system comprises: the policy creator circuit determining a policy capability value in response to the vehicle data collection request and the at least one additional vehicle data collection request; determining a data collection policy in response to the policy capability value; It is further configured to selectively enable at least one of including at least one of the data collection request or the at least one additional vehicle data collection request. The policy creator circuit further stores a data storage size determined to support each of the vehicle data collection request and the at least one additional vehicle data collection request, each of the vehicle data collection request and the at least one additional vehicle data collection request. a transmission volume value determined to support; a data availability value associated with each of the vehicle data collection request and the at least one additional vehicle data collection request; data regarding each of the vehicle data collection request and the at least one additional vehicle data collection request; A parameter consisting of a configuration value or determining a priority between both data collection requests and at least one additional vehicle data collection request for one or more of any one or more of the vehicle data collection requests and at least one additional vehicle data collection request. is configured to determine a policy capability value as a function of at least one parameter selected from; The cloud system comprises: a policy author circuit determining policy authorization values in response to vehicle data collection requests; is further configured to perform at least one action selected from the actions consisting of determining a data collection policy that supports at least a portion of The request interface is configured to provide at least one use case value to the user interface, each use case value including a vehicle data collection template, and in response to a response from the user interface to the provided at least one use case value. determines vehicle data collection requests. The requesting interface further includes the entity type associated with the user interface, the permission values associated with the user interface, and the previously determined data collection policies for the user with the shared characteristics determined for the user interface. is configured to determine at least one use case value in response to at least one of

An exemplary system is a policy manager configured to interpret at least two policy requests, each policy request including a data collection description, the policy manager interpreting data corresponding to each of the data collection descriptions. a policy manager further configured to compile a policy according to a superset of the collected values; a data collection controller located on the vehicle and communicatively coupled to the policy manager; a data collection controller configured to collect data from at least two vehicle networks of; a data communication component communicatively coupled to the data collection controller, wherein at least one of the collected data from the data collection controller; and a data requesting component communicatively coupled to the data communication component and the requesting application, configured to receive the portion and store at least a portion of the collected data in a data store. a data requesting component configured to selectively request at least a portion of the stored data in response to a data request from the requesting application and to provide the selectively requested data to the requesting application. .

Certain additional aspects of exemplary systems are described below, any one or more of which may be present in a particular embodiment. The data communication component is further configured to tokenize at least a portion of the collected data and encrypt at least a portion of the collected data with a master public key prior to storage. The data requesting component is further configured to decrypt the requested data with the master private key and detoken the requested data prior to selectively providing the requested data to the data application. The policy manager is further configured to provide a user interface to one of the user or the policy creation application and interpret at least one of the at least two policy requests in response to interaction with the user interface. . The policy manager further interprets the use case value selection in response to the interaction with the user interface and, in response to the use case value selection, makes at least one of the at least two policy requests in response to the interaction with the user interface. configured to interpret. The policy manager is further configured to provide at least two use case alternatives to the user interface and to interpret the user case value selection in response to selection via the user interface of at least one of the at least two use case alternatives. It is

1 is a schematic diagram of an exemplary data collection system in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary vehicle having aspects of a data collection system in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary out-of-vehicle device according to certain embodiments of the present disclosure; FIG. FIG. 4 is a diagram of exemplary internal and/or external applications according to certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary vehicle network infrastructure for a vehicle in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary vehicle network infrastructure for a vehicle in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary edge gateway according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary Ethernet switch, according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary Ethernet device, according to certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of an example user consent controller, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of an exemplary data collection controller, in accordance with certain embodiments of the present disclosure; FIG. FIG. 4A is a schematic diagram of an exemplary first partition, according to certain embodiments of the present disclosure; FIG. 4B is a schematic diagram of an exemplary second partition, in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary data collection system in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary automation manager, in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary implementation for an integrated IDS manager (ECU) according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary shared storage controller, in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 is a schematic diagram of another exemplary data collection system, in accordance with certain embodiments of the present disclosure; FIG. 4 is a diagram of an exemplary workflow according to certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary containerized application environment, according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary architecture implementation for a container-based application on a vehicle, according to certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of another exemplary architecture implementation for container-based applications on vehicles, in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 is a schematic illustration of exemplary details of a container in accordance with certain embodiments of the present disclosure; 1 is a diagram of a container networking implementation according to certain embodiments of the present disclosure; FIG. FIG. 4 is a diagram of an exemplary AUTOSAR adaptation feature state group, in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an example functional flow for enforcing container policies, in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary implementation of a container manager in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary apparatus for enforcing driver behavior and/or monitoring-based policies for a vehicle, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of an exemplary driver information description, in accordance with certain embodiments of the present disclosure; FIG. 4 is a flow chart illustrating an exemplary procedure for collecting data in response to a driver information description in accordance with certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary procedure for performing collection actions in response to vehicle policy data values and/or driver information descriptions in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary apparatus for providing data collection actions in response to vehicle policy data values in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of an exemplary monitoring data description, according to certain embodiments of the present disclosure; FIG. 4 is a flow chart illustrating an exemplary procedure for implementing policies in response to fault and/or diagnostic values for devices within a vehicle system in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary apparatus for providing data collection actions in response to vehicle policy data values, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of an exemplary endpoint performance description, according to certain embodiments of the present disclosure; FIG. 4 is a flowchart illustrating exemplary procedures for performing operations for adjusting data collection in response to endpoint performance descriptions, in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary apparatus for providing data collection operations in response to location description values in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary location description values according to certain embodiments of the present disclosure; FIG. 4 is a flow chart illustrating an exemplary procedure for adjusting data collection depending on location description values, in accordance with certain embodiments of the present disclosure; FIG. 4 is an illustration of example operations including adjusting collection of vehicle data depending on location description values, in accordance with certain embodiments of the present disclosure; FIG. 4 is an illustration of exemplary operations including initiation of vehicle data collection in accordance with certain embodiments of the present disclosure; FIG. 4 is a diagram of example operations including operations to prevent collection of vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a diagram of example operations including adding or modifying metadata of collected vehicle data, in accordance with certain embodiments of the present disclosure; FIG. 5 is an illustration of example operations including adjusting priority values for at least some of the collected vehicle data, in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary apparatus for data collection operations according to certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary vehicle status data in accordance with certain embodiments of the present disclosure; FIG. 4 is a flowchart illustrating an exemplary procedure for scheduling data collection according to data type of collected data, in accordance with certain embodiments of the present disclosure; 4 is a schematic diagram of exemplary operations including operations for coordinating collection of vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including operations for initiating collection of vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including operations to prevent collection of vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of example operations including operations for adding and/or modifying metadata of collected vehicle data, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including operations for adjusting priority values of collected vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a flowchart illustrating an exemplary procedure for scheduling data collection according to data type of collected data, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of an example operation including determining a data type based on a provisioning endpoint of collected data, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including determining data types based on request endpoints for collected data, in accordance with certain embodiments of the present disclosure; 4 is a schematic diagram of exemplary operations including determining data types based on a requesting entity for collected data, in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 is a schematic diagram of exemplary operations including determining data types based on applications associated with endpoints providing collected data, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including determining data types based on flows associated with endpoints requesting collected data, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including determining data types based on flows associated with endpoints providing collected data, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including determining a data type based on an application associated with an endpoint requesting collected data, in accordance with certain embodiments of the present disclosure; 4 is a schematic diagram of exemplary operations including determining data types based on data types indicated in a policy, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary collected data priority values, in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of exemplary in-vehicle data storage priorities in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary transmission priorities in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary in-vehicle transmission priorities in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary apparatus for providing data collection operations in response to vehicle status data, in accordance with certain embodiments of the present disclosure; FIG. 4 is a flow chart illustrating an exemplary procedure for dynamically configuring vehicle data collection in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating an exemplary procedure for determining vehicle status data collection change values in accordance with certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary procedure including acts for determining an event occurrence and determining vehicle status data collection changes in response to the event occurrence, in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating an exemplary procedure including operations for determining location description values and operations for determining vehicle status data collection modification values, in accordance with certain embodiments of the present disclosure; 4 is a schematic diagram of exemplary operations including coordinating collection of vehicle data, in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary operation including initiation of vehicle data collection in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary operation including preventing collection of vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of example operations including adding and/or modifying metadata of collected vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including adjusting priority values of collected vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including coordinating transmission of collected vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including coordinating data storage of collected vehicle data in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic illustration of exemplary operations including coordinating formatting and/or processing of collected vehicle data in accordance with certain embodiments of the present disclosure; FIG. 4 is a flow chart illustrating an exemplary procedure for dynamically configuring vehicle data collection in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including determining event occurrences in response to fault data, in accordance with certain embodiments of the present disclosure; 4 is a schematic diagram of exemplary operations including determining event occurrence in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including determining event occurrence in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including monitoring trigger evaluation data to determine event occurrence based on trigger status and trigger evaluation data, in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary apparatus for implementing data collection utilizing policy hierarchy, in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an example apparatus that utilizes multiple policy types to perform vehicle data collection operations or other operations in accordance with certain embodiments of the present disclosure; FIG. 4 is a flowchart illustrating exemplary procedures for implementing policy enforcement on a vehicle, in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating exemplary procedures for implementing policy enforcement on a vehicle, in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary utilized policy hierarchy in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 is a schematic diagram of another exemplary utilized policy hierarchy, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of another exemplary utilized policy in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of another exemplary utilized policy in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating an exemplary procedure for updating data collection policies in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating exemplary procedures for implementing a policy hierarchy in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating exemplary procedures for implementing a policy hierarchy in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary apparatus that utilizes shared storage for collected data to perform data collection operations, in accordance with certain embodiments of the present disclosure; FIG. 4 is a flow chart illustrating an exemplary procedure for selectively storing collected data parameters on a vehicle, in accordance with certain embodiments of the present disclosure; 4 is a schematic diagram of exemplary operations including operations of determining a parameter transmission schedule for stored parameters and operations of selectively storing at least some of the vehicle parameter values, in accordance with certain embodiments of the present disclosure; FIG. . 4 is a schematic diagram of exemplary operations including operations of determining a parameter expiration schedule for stored parameters and operations of selectively storing at least some of the vehicle parameter values, in accordance with certain embodiments of the present disclosure; FIG. . An example including an act of determining a reserved memory amount for a stored parameter and an act of selectively storing at least a portion of the vehicle parameter values in response to the reserved memory amount, in accordance with certain embodiments of the present disclosure. 1 is a schematic diagram of a mechanical operation; FIG. 4 is a schematic diagram of an example operation including deleting at least some of the stored vehicle parameter values, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic illustration of exemplary operations including summarizing at least some of the stored vehicle parameter values, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including adjusting reserved memory amounts associated with stored vehicle parameters, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of an example operation including compressing at least some of the stored vehicle parameters, in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of example operations including determining the amount of data collected to support vehicle parameter values in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of example operations including determining the amount of data collected to support trigger evaluations related to vehicle parameter values in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of example operations including determining transmission latency values associated with vehicle parameter values in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary operations including determining priority values associated with vehicle parameter values, in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary apparatus for performing data collection operations implementing data collection policies in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an example data collection policy, according to certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of exemplary transmission description values in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of example policy priority values in accordance with certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of an example policy lifecycle description, in accordance with certain embodiments of the present disclosure; FIG. 4 is a flow chart illustrating an exemplary procedure for collecting data according to policy in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an exemplary cloud system, according to certain embodiments of the present disclosure; FIG. 1 illustrates an example cloud system for obtaining selected data from a vehicle, in accordance with certain embodiments of the present disclosure; FIG. 1 is an exemplary schematic diagram of operations including data collection operations from a vehicle in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 illustrates an exemplary procedure for isolating response data for vehicle data collection operations in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an exemplary procedure for isolating response data for vehicle data collection operations in accordance with certain embodiments of the present disclosure; 1 illustrates an exemplary system for retrieving selected data from a vehicle, in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 illustrates an exemplary procedure for identifying data, in accordance with certain embodiments of the present disclosure; 1 illustrates an example cloud system for creating data collection policies in accordance with certain embodiments of the present disclosure; FIG. [0014] Figure 4 illustrates an exemplary policy creator circuit in accordance with certain embodiments of the present disclosure; FIG. 12 depicts an exemplary request interface in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an exemplary procedure for operating a request interface in accordance with certain embodiments of the present disclosure; 1 is an exemplary schematic diagram for operating a container-based implementation of one or more control aspects of a vehicle in accordance with certain embodiments of the present disclosure; FIG. 1 is an exemplary schematic diagram for operating a container-based implementation of one or more control aspects of a vehicle in accordance with certain embodiments of the present disclosure; FIG. 1 is an exemplary schematic diagram for operating a container-based implementation of one or more control aspects of a vehicle in accordance with certain embodiments of the present disclosure; FIG. 1 is an exemplary schematic diagram for operating a container-based implementation of one or more control aspects of a vehicle in accordance with certain embodiments of the present disclosure; FIG. 1 is an exemplary schematic diagram for operating a container-based implementation of one or more control aspects of a vehicle in accordance with certain embodiments of the present disclosure; FIG. 1 is an exemplary schematic diagram for operating a container-based implementation of one or more control aspects of a vehicle in accordance with certain embodiments of the present disclosure; FIG. 4 is an exemplary schematic diagram providing automated vehicle operation based on data values in accordance with certain embodiments of the present disclosure; FIG. 4 is an exemplary schematic diagram providing automated vehicle operation based on data values in accordance with certain embodiments of the present disclosure; FIG. 4 is an exemplary schematic diagram providing automated vehicle operation based on data values in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 is an exemplary schematic diagram for performing data collection operations in accordance with certain embodiments of the present disclosure; FIG. 3 is an exemplary schematic diagram for vehicle data transmission operations with a cloud system and/or an external device, in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an exemplary procedure for managing vehicle transmission operations in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an exemplary procedure for selectively transmitting collected data according to selected transmission intervals, in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an example procedure for selectively transmitting collected data according to selected bandwidth utilization, in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an example procedure for selectively transmitting collected data according to the data type of the collected data, in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an exemplary procedure for selectively transmitting collected data depending on the vehicle operational impact of the transmission operation in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an exemplary procedure for selectively transmitting collected data depending on the power usage impact of transmission operations in accordance with certain embodiments of the present disclosure; [0014] Figure 4 illustrates an exemplary procedure for selectively transmitting collected data depending on a data transmission capacity value, in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an exemplary procedure for selectively transmitting collected data according to currently available transmission types, in accordance with certain embodiments of the present disclosure; [0014] Figure 4 illustrates an exemplary procedure for selectively transmitting collected data according to a selected data transmission chunk size, in accordance with certain embodiments of the present disclosure; [0014] Figure 4 illustrates an example procedure for selectively transmitting collected data depending on success parameters of a transmission operation, in accordance with certain embodiments of the present disclosure; [0014] Figure 4 illustrates an example procedure for selectively transmitting collected data according to a quality of service value for a transmission operation, in accordance with certain embodiments of the present disclosure; 1 is an exemplary schematic diagram for performing remote assistance operations on a vehicle in accordance with certain embodiments of the present disclosure; FIG. 1 is an exemplary schematic diagram of a cloud system in communication with a vehicle, in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 illustrates an exemplary procedure for performing remote actions on a vehicle in accordance with certain embodiments of the present disclosure; FIG. 4 illustrates an exemplary procedure for performing operations on a vehicle, including remote assistance operations, in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an apparatus for collecting and/or managing vehicle data according to certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of another apparatus for collecting and/or managing vehicle data according to certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of another apparatus for collecting and/or managing vehicle data according to certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of another apparatus for collecting and/or managing vehicle data according to certain embodiments of the present disclosure; FIG. 4 is a flowchart illustrating a method for collecting and/or managing vehicle data, according to certain embodiments of the present disclosure; Figure 156 is another flowchart illustrating the method of Figure 155, in accordance with certain embodiments of the present disclosure; Figure 156 is another flowchart illustrating the method of Figure 155, in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating another method for collecting and/or managing vehicle data, in accordance with certain embodiments of the present disclosure; 159 is another flowchart illustrating the method of FIG. 158, in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an apparatus for data collection policy capture and execution according to certain embodiments of the present disclosure; FIG. 4 is a schematic diagram of another apparatus for capturing and enforcing data collection policies in accordance with certain embodiments of the present disclosure; FIG. 162 is another schematic illustration of the apparatus of FIG. 161, in accordance with certain embodiments of the present disclosure; FIG. 162 is another schematic illustration of the apparatus of FIG. 161, in accordance with certain embodiments of the present disclosure; FIG. 162 is another schematic illustration of the apparatus of FIG. 161, in accordance with certain embodiments of the present disclosure; FIG. 4 is a flow chart illustrating a method for data collection policy capture and enforcement in accordance with certain embodiments of the present disclosure; Figure 166 is another flowchart illustrating the method of Figure 165, in accordance with certain embodiments of the present disclosure; Figure 166 is another flowchart illustrating the method of Figure 165, in accordance with certain embodiments of the present disclosure; Figure 166 is another flowchart illustrating the method of Figure 165, in accordance with certain embodiments of the present disclosure; Figure 166 is another flowchart illustrating the method of Figure 165, in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an apparatus for data collection in a mixed network environment, according to certain embodiments of the present disclosure; FIG. FIG. 4 is a schematic diagram of another apparatus for data collection in a mixed network environment, according to certain embodiments of the present disclosure; 4 is a flowchart illustrating a method for data collection in a mixed network environment according to certain embodiments of the present disclosure; FIG. 173 is another flowchart illustrating the method of FIG. 172 in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an apparatus for data collection process management according to certain embodiments of the present disclosure; FIG. FIG. 4 is a schematic diagram of another apparatus for data collection process management according to certain embodiments of the present disclosure; 176 is another schematic illustration of the apparatus of FIG. 175 in accordance with certain embodiments of the present disclosure; FIG. 176 is another schematic illustration of the apparatus of FIG. 175 in accordance with certain embodiments of the present disclosure; FIG. 4 is a flowchart illustrating a method for data collection process management according to certain embodiments of the present disclosure; 179 is another flowchart illustrating the method of FIG. 178, in accordance with certain embodiments of the present disclosure; 1 is a schematic diagram of an apparatus for data storage management according to certain embodiments of the present disclosure; FIG. 181 is another schematic illustration of the apparatus of FIG. 180, in accordance with certain embodiments of the present disclosure; FIG. 4 is a flowchart illustrating a method for data storage management according to certain embodiments of the present disclosure; 183 is another flow chart illustrating the method of FIG. 182 in accordance with certain embodiments of the present disclosure; 183 is another flow chart illustrating the method of FIG. 182 in accordance with certain embodiments of the present disclosure; 183 is another flowchart illustrating the method of FIG. 182, in accordance with certain embodiments of the present disclosure; 183 is another flowchart illustrating the method of FIG. 182, in accordance with certain embodiments of the present disclosure; 1 is a box diagram illustrating an exemplary user device in accordance with certain embodiments of the present disclosure; FIG. 4 is a flowchart illustrating an exemplary user device-based data collection process in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating an exemplary user device-based data collection process in accordance with certain embodiments of the present disclosure; 1 is a box diagram illustrating an example cloud system in accordance with certain embodiments of the present disclosure; FIG. 4 is a flow chart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure; 1 is a box diagram illustrating an exemplary vehicle in accordance with certain embodiments of the present disclosure; FIG. 4 is a flowchart illustrating exemplary vehicle-based data collection in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating exemplary vehicle-based data collection in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating exemplary vehicle-based data collection in accordance with certain embodiments of the present disclosure; 4 is a flowchart illustrating exemplary vehicle-based data collection in accordance with certain embodiments of the present disclosure; 1 is a box diagram of an exemplary vehicle in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 is a box diagram of an exemplary data collection controller in accordance with certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary data collection process in accordance with certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary data collection process in accordance with certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary data collection process in accordance with certain embodiments of the present disclosure; 1 is a box diagram of an exemplary vehicle in accordance with certain embodiments of the present disclosure; FIG. FIG. 4 is a box diagram of an exemplary data collection controller in accordance with certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary data collection process in accordance with certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary data collection process in accordance with certain embodiments of the present disclosure; 4 is a flow chart illustrating an exemplary data collection process in accordance with certain embodiments of the present disclosure;

Without limiting any other aspects of the present disclosure, aspects of the disclosure herein provide a cost per entity added to the data collection system, a new cost to implement the application that utilizes the collected data Entity base learning costs, adaptation costs to changes in vehicle network configuration, costs incurred to meet increased demand for data collection, costs to adapt to changing regulatory environment, and/or data and/or violations or Any one or more of the costs of protecting against losses incurred for unauthorized use are reduced and/or eliminated. Certain embodiments and/or aspects of the disclosure herein may address one or more of the cost parameters listed. Certain embodiments and/or aspects of the disclosure herein may increase one or more given cost parameters, but nevertheless target vehicle, vehicle type, entity, industry, Benefits can be gained by reducing the overall cost function for others. Certain embodiments and/or aspects of the disclosure herein may increase one or more given cost parameters, but may provide other benefits, such as improved functionality. In certain embodiments, the functional improvements may be achieved at increased cost, but at a lower cost than previously known systems configured to achieve similar functional improvements.

For the purposes of promoting an understanding of the principles of the disclosure, embodiments illustrated in the drawings and described herein below will now be described. It is understood that no limitation of the scope of the disclosure is thereby intended. This disclosure includes any changes and modifications to the illustrative embodiments, and includes further applications of the principles disclosed herein that would ordinarily occur to those skilled in the art to which this disclosure pertains. It is further understood.

The present disclosure describes systems, methods, and apparatus for performing data collection operations related to vehicles. Certain embodiments described herein relate to mixed vehicle networks on vehicles. An exemplary mixed vehicle network is one or more CAN bus(es) with multiple devices communicating over the CAN bus(es) and one or more Ethernet networks with multiple devices communicating over the Ethernet network. Including networks and networks having communications leading from CAN to Ethernet and/or vice versa. Mixed networks include, but are not limited to CAN and Ethernet, Local Interconnect Network (LIN), FlexRay, Media Oriented System Transport (MOST), and/or Low Voltage Differential Signaling (LVDS). Any one or two or more of Currently available Ethernet networks are highly capable, with bandwidth ratings between 100 Mbps and 25 Gbps and latency values between 5 ms and 20 μs (0.02 ms). In certain embodiments, there may be more than one Ethernet network (or zone), and may include mixed-capability Ethernet networks. Additionally or alternatively, in certain embodiments, the one or more networks present are wireless networks such as WiFi networks (e.g., 802.11x standards such as a/b/g; n; and/or ac). It may include networks, mobile standard networks (eg, 4G and/or 5G), Bluetooth communications, Universal Serial Bus (USB) connections, and/or fiber optic connections. The networks described are non-limiting examples, and any type of network and/or communication protocol is contemplated herein for mixed vehicle networks.

In certain embodiments, a mixed vehicle network includes one or more low capacity networks combined with one or more high capacity networks. Capabilities that are considered low capability are the applications, the number of devices in communication, the types of communication allowed on the network, and the network management available (e.g., device registration) for the specific network and communication protocol being utilized. , add or delete, message encryption, message customization, etc.). In certain embodiments, a mixed vehicle network includes two or more networks, and at least two of the networks present integration challenges. For example, one of the networks may only allow certain types of communication, require certain types of synchronous or asynchronous communication, allow only certain types of devices to connect, implement certain network topologies, and or have other differences or limitations that make the use of a single network (or network type) across the vehicle undesirable or impractical.

Descriptions herein that utilize off-vehicle, non-vehicle, and/or cloud-based interactions do not limit wireless-based communications (e.g., mobile data, WiFi, and/or Bluetooth) to external devices; Relates to any external network communication of the vehicle. Communication to external devices can be over a general network (eg, over the Internet), WAN, LAN, mobile devices in close proximity to the vehicle, and/or combinations thereof. Certain systems and procedures described herein may be used during run-time operation of the vehicle, e.g. It specifically contemplates external communications that occur in The disclosure herein further contemplates communications that may occur during any period of time, including during vehicle downtime and/or during service events. The disclosure herein further provides communication that may occur over a wired communication channel, such as when a vehicle network is communicating with a service tool, on-board diagnostic (OBD) instrument, or other physically coupled device. intend to

This specification will refer to vehicle applications as a non-limiting example and for the sake of clarity. However, embodiments herein are applicable to other applications with similar challenges and/or implementations. Without limiting other applications, embodiments herein are applicable to any application having multiple endpoints, including multiple data sources, controllers, sensors, and/or actuators, which , endpoints residing in different or distributed network environments, and migration to newer and/or more capable networking or communication systems (within a given system, as a class of systems, and/or as an industry). It can further include applications that have legacy or legacy networking or communication systems that can be used. Exemplary and non-limiting embodiments include: industrial equipment; robotic systems (including at least mobile robots, autonomous vehicle systems, and/or industrial robots); good) and/or manufacturing system. Certain features, aspects, and/or advantages of the disclosure may be applicable to any one or more of these applications, and may not be applicable to other of these applications, and , application of certain features, aspects, and/or advantages of the present disclosure may vary depending on the operating conditions, constraints, and cost parameters (e.g., operating costs, integration costs, operational costs, data communication and/or storage costs, service costs, etc.) of a particular application. costs and/or downtime costs, etc.). Thus, whether the disclosure relates to vehicles, vehicle systems, mobile applications, industrial devices, robotic systems, and/or manufacturing systems, each of these is also contemplated herein and benefits of the disclosure. may be applicable in certain embodiments and may not be applicable in other certain embodiments, as will be understood by those skilled in the art.

Flow as utilized herein should be understood broadly. Exemplary flows include related groups of data (eg, speed data, temperature data, audiovisual data, navigation data, etc.), related groups of functions (eg, during vehicle functions, outside the vehicle such as service operations and/or data collection). functions, aggregation between related vehicles, and/or combinations thereof that are relevant for a particular system), related groups of devices (eg, door actuators), and/or related groups of applications. Flows, as used herein, provide an organizational concept that can be used to associate specific data, specific endpoints, specific applications, and/or related functionality on or off the vehicle. In certain embodiments, the controller utilizes the flow to identify data sources, data destinations, permissions available for the flow, priority information associated with the flow, etc., where it performs specific data conditioning operations. be able to. In certain embodiments, the use of flows allows the controller to perform separate operations that may involve the same endpoints to support desired network management. For example, a speed management application may have a high priority and a speedometer endpoint may be associated with the speed management application. In this example, the controller applies high priority to the vehicle speed message if the vehicle speed is being communicated to support a vehicle speed management application. However, if vehicle speed is being communicated to support the trip plan flow (e.g., if a trip plan flow exists and does not have a high priority), the controller applies a low priority to the vehicle speed message. be able to. As a further example, failure of a vehicle controller, part of the network, or other out-of-nominal condition may result in a transition of the vehicle speed management application to another controller in the system, thereby causing the vehicle speed management application to If the vehicle speed message is communicated to support (eg, if the backup controller is on another network), the controller may apply high priority to the vehicle speed message. The use of flows and applications to orchestrate the components of the system allows the same or similar information to be differentially adjusted by the controllers to support different functions, increasing the performance of network-adjusted operations. and enable improved security (e.g., reducing unnecessary cross-network traffic and providing information only when needed), and previously known features such as redundancy support, distribution control, and granular cross-network messaging. Support additional functions to the system.

As utilized herein, a policy may include data parameters, collection rates, resolution information, priority values (e.g., data for selection depending on non-nominal conditions where all data collection parameters are not serviceable). contains a description of the data to be collected, such as ordering the collected values. In certain embodiments, the policy further includes event information, which can be parametric or quantitative based events (eg, a given data value exceeds a threshold) and/or categorical events (eg, a particular fault code, operating condition or state, or vehicle location/jurisdiction occurs). In certain embodiments, the policy further includes data values captured in response to the occurrence of an event, and/or other changes in the data collection scheme, such as increasing or decreasing the data collection rate, changing the collection resolution, or the like. contains event responses for In certain embodiments, the event response is a time frame related to the event occurrence, e.g., a period of time after the event using a coordinated data collection scheme, and/or a period of time preceding the or use other data collection operations to provide temporal information that can be captured after an event occurs). In certain embodiments, changing the data collection scheme for an event involves multiple changes, e.g., over a period of time, further changes based on the progression of the event (e.g., if the severity of the event worsens), and/or Or it can include criteria for determining that an event has been cleared. In certain embodiments, the change in data collection scheme may be performed on the same or different events, e.g., until the vehicle's next shutdown event, until a service technician clears the event, until a selected number of shutdown events have occurred, etc. event-related clearing of the event.

The use of policy herein may refer to a partial policy, such as an implicit policy that would be enforced in response to a single data collection scheme from a single user; After one or more partial policies are aggregated, they are created, verified, and communicated to the vehicle. The use of policies herein means that, for example, after policies corresponding to multiple users have been aggregated, the policy validation operations have not yet been completed (e.g., determining whether the data collection implied by the policies can be performed). before it is done) can refer to an unverified policy. The use of policy herein may refer to a previously applied policy (e.g., a policy that existed on the vehicle before an updated version of the policy was communicated to and/or implemented on the vehicle). can. Usage of policy herein refers to an updated policy, e.g., a verification policy with which communication to the vehicle 102 is pending and/or confirmed by the vehicle 102 (e.g., from the data collection controller 202). can be done.

Referring to FIG. 1, an exemplary system is disclosed having a vehicle 102 communicatively coupled to an off-vehicle device 104 . The exemplary system includes off-vehicle 104 devices communicatively coupled to one or more user devices 106 . For example, vehicle 102 may have a plurality of data providing devices coupled to a network on the vehicle, eg, having one or more devices coupled to a CAN network and one or more other devices coupled to an Ethernet network. can include a mixed network with The exemplary system allows users (eg, application providers, fleet owners, manufacturers, customers, etc.) to access the off-vehicle device 104 and configure data collection performed on the off-vehicle device 104 from the vehicle 102 . do. In a further example, the system enables access to at least a portion of the collected data for use in vehicle-related applications. 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/or reduce data communications resource consumption. In certain embodiments, the system provides for consent enforcement to ensure that proper consent (e.g., consent from the vehicle operator or owner) is provided before relevant data collection is performed. . In certain embodiments, the system retrieves information from data requesters and/or users of specific vehicle information (e.g., data parameter names, communication protocol information, data provider locations and/or ID values in a vehicle mixed network environment). It provides decoupling, thereby relaxing data requesters and/or users from having to learn and/or maintain updates to specific vehicle information. In certain embodiments, the system provides for separating the stored data collected from the vehicle from the system that provides the requested data to applications that utilize some of the data. In certain embodiments, the system controls data collection parameters from multiple concurrent data requesters and/or provides enhanced policy management control to specific users, such as policy creators and/or policy controllers. Provides integrated policy management for In certain embodiments, the system provides enhanced policy creation and/or updating, whereby the system provides policy information regarding specific vehicles and/or specific data used to support corresponding high-level functions. It communicates with a user in a manner configured to provide a high level functional description to the user without requiring knowledge from the user. 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 request data from the vehicle to off-vehicle devices. .

Referring to FIG. 2, an exemplary vehicle 102 is schematically depicted with certain aspects of the data collection system described herein. The exemplary vehicle includes a data collection controller 202 configured to accept policies from off-vehicle devices 104, propagate functionality to on-board devices according to the policies, and perform appropriate data collection. The example data collection controller 102 also communicates the collected data to the off-vehicle device 104 and/or manages communication depending on intermittent network availability and/or intermittent network bandwidth availability. Certain further and/or more detailed operations of the data collection controller 202 are described in the portions of this disclosure that refer to FIGS. 5 and 10. FIG.

Exemplary vehicle 102 further includes an inter-network switch 204 communicatively coupled to at least two networks on vehicle 102 . Exemplary inter-network switch 204 is directly coupled to devices 210 on a first network and to devices 208 on a second network, eg, via communication with edge gateway 206 . be done. Certain further and/or more detailed operations of the inter-network switch 204 are described in the portions of this disclosure that refer to FIGS. 5 and 7. FIG. Certain further and/or more detailed operations of device 210 are described in the portion of this disclosure that refers to FIGS. 5 and 8. FIG. Certain further and/or more detailed operations of edge gateway 206 are described in the portions of this disclosure that refer to FIGS. 5 and 6. FIG.

Exemplary vehicle 102 further includes a user consent controller 212 communicatively coupled to data collection controller 202 and/or off-vehicle device 104 . In particular embodiments, user consent controller 212 may be an in-vehicle device such as a vehicle display (eg, PAD or console device) and/or user consent controller 212 may be a mobile application (eg, running on it). user's mobile device with possible consent application), a web-based application (eg, a web application accessible to the user and associated with the vehicle 102), and/or two or more of these. Certain further and/or more detailed operations of user consent controller 212 are described in the portions of this disclosure that refer to FIGS. 5 and 9. FIG. The example of FIG. 2 depicts external communications 214 , which may include communications to off-vehicle devices 104 . External communications 214 can be passed wirelessly (e.g., communicating with data collection controller 202 and/or user consent controller 212 from available transceivers on the vehicle) and/or wired communications (e.g., service tools, such as an OBD device, coupled to the network on the vehicle as a device 210 communicating with the inter-network switch 204, for example.

Referring to FIG. 3, an exemplary off-vehicle device 104 is depicted. The exemplary off-vehicle device 104 is depicted schematically as an integrated device with a manager and other components drawn to illustrate the interaction of the functional elements of the off-vehicle device 104 . Off-vehicle device 104 may be a distributed device having aspects that reside in multiple controllers, transceivers, servers, or the like. In certain embodiments, off-vehicle device 104 is at least a cloud-based device that utilizes or communicates with web-based and/or cloud-based services such as, for example, Amazon Web Services (AWS), Microsoft Azure web services, Cloudflare network services. Can be partially implemented. In certain embodiments, aspects of off-vehicle device 104 may be separated and/or distributed across two or more services, dedicated servers, and/or computing devices. In the example of FIG. 3 , a first partition 302 performs certain operations of off-vehicle device 104 and interfaces with a second partition 304 that performs certain other operations of off-vehicle device 104 . In the example of FIG. 3, partition 306 is depicted, where communications across partition 306 may be configured to interface specifications or other agreed or implemented communication schemes.

The exemplary partition 302 includes a network manager 312 that performs load management functions and manages communications with the vehicle 102 . The example of FIG. 3 depicts policy communications 316 , consent communications 314 , and data communications 318 that are at least intermittently communicated with vehicle 102 . The example network manager 312 interfaces with the data communications 308 component to pass received vehicle data to the data communications 308 component, for example. The example network manager 312 interfaces with the vehicle policy communication manager 310 to receive, for example, data collection policies, policy updates, and/or provide consent communication between the vehicle policy communication manager 310 and the vehicle 102 . In certain embodiments, the vehicle policy communication manager 310 receives the processed policy from the policy manager 330 (and/or from the vehicle data request manager 342) on the second partition 304 and makes the policy available to the vehicle 102; and/or determining when to communicate the policy to the vehicle.

The example vehicle data request manager 342 determines the data to be collected according to policies provided by the policy manager 330 . In certain embodiments, a policy includes multiple data requests from a user (eg, device 106 and/or internal application 334), and vehicle data request manager 342 aggregates the requested data into all data within the policy. Aggregate to a specific parameter set for data collection that meets the data collection needs of the request. In particular embodiments, the policy manager 330 and/or the vehicle data request manager 342 perform policy validation and validate a given policy before the vehicle data request manager 342 provides the data request to the vehicle policy communication manager 310. Ensure that it can be supported (eg, that the requesting user is authorized, the parameters are available on the vehicle, and/or that aggregate data collection that satisfies the policy can be achieved within available bandwidth limits). In particular embodiments, the aggregated data collection set is stored in a data structure such as an XML structure, JSON data structure, HTML data structure, or other selected data structure. In certain embodiments, an aggregated data collection set containing related data structures includes the policy sent to vehicle 102 . In certain embodiments, the data structures sent to vehicle 102 may include other information as part of the policy, such as event descriptions, priority information, and/or information in response to off-nominal conditions such as intermittent network availability. including.

Embodiments of the present disclosure provide a service-oriented architecture (SOA) and systems, apparatus, and methods for providing management of SOA features and functions. SOA embodiments herein may support multiple types of services, such as data services and/or functional services. SOA embodiments herein include, but are not limited to, manufacturers, OEMs, customers, operators, owners, service personnel, fleet managers (eg, service, dispatch, compliance, etc.), SOA service requesters, SOA It is possible to support multiple types of service participants, including service providers and/or third party applications. Embodiments herein can support SOA operation over multiple networks, including one or more vehicle networks, vehicle networks with mixed network types, external networks, and/or cloud-based networks. be. Embodiments herein provide at least SOME/IP, MQTT, HTTP, CAN, LIN, FlexRay, MOST, TTP, and/or Multiple network protocols can be supported, including the LVDS network protocol. Embodiments herein support the implementation of reliable, secure and convenient SOA services, including service discovery, restoration, maintenance and/or updates to available services that are provided and/or requested. It is possible to

An example policy utilized herein is a policy provided by an external device that requires the vehicle to collect a data set over a defined or short period of time and return the data to the external device. include. Data can be sent back to the external device within the defined time period set forth in the policy and/or according to the default time period for such policy action, and sent to the external device as soon as data collection is complete. Can include sending back data. An exemplary policy may be deleted, removed, or otherwise considered complete after a data collection event and/or after a number of consecutive data collection events. Such policies may be referred to as ad-hoc policies, one-time policies (which may include one or more finite data collection events), impromptu policies, single-use policies, emergency policies, or the like. . Examples of the use of such policies include rapid response data gathering (e.g. information gathering, modeling or artificial intelligence configuration to prepare for emergency event actions, updates, campaigns, or other planned changes to multiple vehicles). Data under any circumstances where collection of datasets and/or use of data for training elements is expected to be performed within a finite period of time and ongoing data collection for policies is not desired. collection).

Exemplary policies utilized herein include policies provided by external devices that require the vehicle to collect data sets over time and/or on an ongoing basis, where the collected data sent back to the external device periodically and/or intermittently at intervals that can improve bandwidth utilization by selecting a time and/or that allow compression operations on the data to reduce the amount of data communicated. ing. Exemplary policies may be retained for a defined period of time, retained until deleted by an external device, and/or an event (e.g., a research data collection operation where the event indicates that the vehicle is no longer associated with research). ) occurs. A defined time period and/or event parameters for deleting a policy can be defined within the policy. Exemplary uses of such policies include research projects, continuous improvement projects (e.g., development of diagnostic or prognostic algorithms for vehicles or groups of related vehicles, continuous improvement of operational algorithms, etc.), ongoing analytical projects (e.g., , trends, changes in related groups of vehicles, and/or analyzing large data sets to verify that changes to related groups of vehicles have the expected effect) and/or project output Including projects where the time constant is long relative to the data rate normally received from low utilization data transmission operations. Such policies may be referred to as research policies, analytical policies, non-urgent data policies or the like.

An exemplary policy utilized herein collects a data set over a long period of time for a vehicle, and as the data is collected, in defined data blocks, and as each data block is collected: Includes policies provided by external devices requesting data to be sent back to the vehicle and/or streamed. Exemplary policies are retained for a defined period of time, retained until deleted by an external device, and/or triggered by an event (e.g., data utilized by an algorithm or process changes, algorithm or process is discontinued). the algorithm or process is replaced by an updated algorithm or process, or the like) occurs. Defined time periods and/or event parameters for deleting a policy can be defined within the policy. Exemplary uses of such policies include real-time monitoring of vehicle conditions, implementation of diagnostic or predictive algorithms for vehicles or related groups of vehicles, and/or the time constant of project output is such that a low utilization data transmission operation prevents a project from Include projects that are too short to support or not long enough to support the project with acceptable performance. Such policies may be referred to as real-time monitoring policies, urgent data policies, immediate data policies or the like.

The first partition 302 further includes a data store 320, which can be a raw data store that stores data provided by the data communication 308 component, the data store 320 being stored in the second partition until collected data is requested. It keeps the data separate from the partitions 304, thereby segmenting the risks arising from the data storage. For example, a first partition 302 can be controlled and/or operated by a first entity and a second partition 304 can be controlled and/or operated by a second entity such that partition 306 segment the risks associated with data storage. In particular embodiments, data store 302 stores data in an encrypted format, which is further configured such that a first entity operating first partition 302 cannot access the data values of the stored data. can do. In particular embodiments, the data store 302 is associated with metadata values such as vehicle information, timestamps, data category descriptions, etc. so that the appropriate data can be supplied in response to data requests by the data request/processing 322 component. stored data.

The exemplary second partition 304 determines whether consent to data values within the policy is required and communicates with the user consent controller 312 and/or the consent application 402 (see FIG. 12) to request and receive consent values. It further includes a consent manager 332 that In certain embodiments, application authorization data store 328 is utilized to store consent information such as consent confirmations for current policies, pending policies, or the like. Application authorization data store 328 may also be configured in accordance with policy aspects (e.g., data parameters, sampling rates, event value, and/or use case value).

The exemplary second partition 330 further includes a policy manager 330 that receives input from users and/or applications to determine requested policies, policy updates, policy changes, or the like. In particular embodiments, policy manager 330 interfaces with user device 106, external application 402, and/or internal application 334 via API engine 326 to collect requested data utilized in determining policy. , determine events, priorities, etc. In particular embodiments, a user or application may write a requested policy into a data structure, such as a formatted data XML, JSON, HTML, or other data structure containing a formatted description of the requested policy elements. can be provided to policy manager 330 as

In particular embodiments, policy manager 330 provides a user interface to a user or application to provide a quick, convenient, and/or reliable format for policy requests. For example, a policy manager 330 interfacing with an application or user can provide a list of data elements available in the system, given event values, and/or given response values. In certain embodiments, the list includes interface elements such as drop-down lists, checkboxes, or other interfaces that allow quick selection of the requested element and ensure proper formatting of the requested element. be able to. In particular embodiments, user and/or application authorization of requested elements may be performed during construction or input of requested policy elements, e.g. Hide, display unauthorized elements in an alternate format (e.g., gray out), and/or provide an alert or notification that unauthorized elements are now included within a requested policy element. can be done. In certain embodiments, policy manager 330 may allow unauthorized elements to policy requests (and/or omit approval pre-screening), where it validates consolidated policies for updates. (e.g., aggregating multiple policy requests from various users and/or applications into a unified policy) if there are still unauthorized elements present, preclude creating a policy based on the policy request. In certain embodiments, policy manager 330 may notify a user that verification of a policy request has failed due to containing an unauthorized data request, due to excessive communication bandwidth requirements, or for other reasons. Or an application (eg, policy creator, policy controller, superuser, or the like) can be notified. In particular embodiments, policy manager 330 can identify which element of a policy request caused a validation failure and/or notify a notified user or application that a user or application making an unauthorized request may communication to, options to authorize unauthorized requests, or the like.

In particular embodiments, the operation of policy manager 330 includes compiling multiple policy requests from users and/or applications (internal or external) into an integrated policy structure. In certain embodiments, policy manager 330 (and/or vehicle data request manager 342) provides an aggregate policy structure as a superset of data requests (eg, aggregate data requests for a given parameter) and these Event requests and/or event responses can be further integrated if the integration operations of can be made consistent with achieving events and responses within individual policy requests. In particular embodiments, policy manager 330 may include consideration of data supersets in determining event responses, e.g., an event requires data to be taken in response to the event, but the data is already collected for another request in the policy, the event may be omitted and/or data collected may be reduced to account for data availability.

In particular embodiments, policy manager 330 has consent available for data parameters that require consent, for example, to ensure that users and/or applications are only requesting authorized data. (and/or communicate consent requirements to the consent manager 332 for appropriate action), and/or if the vehicle's network bandwidth capabilities, vehicle data storage capabilities, or other parameters are includes the act of validating the integrated policy structure to ensure it can meet the requirements of In particular embodiments, policy manager 330 maintains updated "live" validation, for example, validating potential integrated policy structures as policy requests are received from users and/or applications. In particular embodiments, policy manager 330 performs validations on demand, eg, by policy authors, which can be performed as a “build” of a policy or policy update. In certain embodiments, policy manager 330 utilizes default policies, for example, when a vehicle is first manufactured.

In certain embodiments, after the policy is verified, policy manager 330 may communicate the policy to vehicle policy communication manager 310 for communication to vehicle 102 . Additionally or alternatively, policy manager 330 may communicate policies to vehicle policy communication manager 310 in response to requests from policy authors, superusers, or other authorized system users.

In certain embodiments, the policy manager 330 or other system component has access to a policy data store 340, which includes previously validated policies, legacy policies, one or more default policy and/or data element common names, user role descriptions, application role descriptions (e.g., set of event values, event responses, and/or data available based on application roles such as OEM, manufacturer, third party, etc.) value), exemplary event values and/or event responses, and vehicle data (eg, nominal bandwidth description, storage information, etc.).

In particular embodiments, policy manager 330 provides a high-level description to a user or application, which in particular embodiments can be referred to as "use cases." A use case can include one or more data collection elements, such as a group of parameters to be collected, and/or can further include one or more associated events and/or event responses. A selection of use cases can thereby be used to rapidly construct policy requests with given information. The use cases presented to the user can be stored in the data store 340 and/or can depend on the roles and/or authorizations of the user and/or application. In particular embodiments, a use case may have an identifiable or common name, such as "routing application use case," "passenger car standard use case," "transportation vehicle use case," or the like. The data store 340 can have default use cases available and/or use cases created or configured and/or made available by policy authors, policy controllers, superusers, or the like. can contain. In certain embodiments, users and/or applications have the ability to construct policy requests and store them as use cases for future implementation as templates, baseline groups of data collection parameters, or the like. be able to. In particular embodiments, policy manager 330 validation operations may utilize use cases (e.g., for a given vehicle, user, application, or the like, whether the use case is allowed or allowed). and/or the verification operation of policy manager 330 can evaluate individual elements implemented depending on the use case for verification. In particular embodiments, data values implemented by a use case can be displayed to the user and/or application or hidden from the user and/or application.

The exemplary second partition 304 further includes one or more internal applications 334 , eg, applications created or implemented by operational entities associated with the second partition 304 . The exemplary second partition 304 further includes an application/user network manager 324 that, for example, performs load balancing operations and provides communications to and/or receives communications from external applications using the communications interface 338. include. In particular embodiments, application/user network manager 324 performs operations to implement user interfaces or graphical user interfaces with external users and/or applications.

The example off-vehicle device 104 implements consent communication 344, policy communication 346, and/or data communication 336 to manage communication between partitions 302,304. Communications 344, 346, 336 may include standardized interfaces and/or protocols, eg, to allow a given partition 302, 304 to operate independently of updates or changes to other partitions.

Although the example of FIG. 3 depicts two partitions 302, 304, in certain embodiments off-vehicle device 104 may be an integrated device and/or aspects of partitions 302, 304 may include additional It is possible to have partitions and/or a different distribution of components between partitions.

Referring to FIG. 4, exemplary internal application 334 and/or external application 402 are depicted. The present disclosure is not limited to the illustrated applications and a given application may be provided as internal application 334 or external application 402 . The example of FIG. 4 shows a plurality of user devices 106 that can be communicatively coupled to the system via network interface 406, which can include one or more aspects such as Internet connectivity, mobile communication interfaces, proprietary network interfaces, and the like. is drawing 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 can operate without an interfacing user device 106 (e.g., data scraper, AI component, etc.) and/or can interact with the user device 106 at certain times or operating conditions. It can optionally interface and operate and operate independently of the user device 106 at other times or operating conditions.

5A and 5B, an exemplary vehicle network infrastructure for vehicle 102 is schematically depicted. The exemplary vehicle 102 includes an Ethernet switch, an edge gateway device (eg, a CAN or second Ethernet network, etc.) that communicates with multiple Ethernet-based devices (eg, sensors, actuators, and/or controllers that communicate with an Ethernet network). second network and provide parameters to the first network or Ethernet network), a data collection controller, a plurality of Ethernet devices, and a user consent controller.

Referring to FIG. 6, an exemplary edge gateway 206 is depicted. The exemplary edge gateway 206 includes a CAN data collection policy manager that receives data collection commands from the data collection controller. The CAN data collection policy manager directs CAN data collection from CAN devices 208 to support data collection commands and provides Ethernet communication parameters to Ethernet switches to support data collection. Utilization of edge gateway 206 supports mixed network operation, and in certain embodiments, off-vehicle devices 104 operate without requiring knowledge of which devices are present on CAN, Ethernet, or other networks. make it possible to The exemplary edge gateway 206 further includes a CAN IP component that interprets the CAN address of each CAN component 208, a CAN message receiver that interprets CAN messages to determine data values, and a CAN message receiver that interprets CAN messages to determine data values, and, for example, a It includes CAN processing components, such as CAN message filters that support downsampling of CAN messages to reduce network traffic within the vehicle network. For example, if a parameter is provided over CAN at a rate of 20 ms, but the policy only requires a 1 second sampling rate for the parameter, the CAN message filter can remove over-sampling of the message. In certain embodiments, other components may perform downsampling in addition to or instead of CAN message filters. For example, Ethernet switches and/or data collection controllers can perform appropriate downsampling. The position of the downsampling can depend on the policy specification (e.g., if a parameter is likely to be sampled faster due to an event, the CAN message filter may need the highest data can be provided at a rate, allowing another component to down-sample when a high rate is not needed, and/or the CAN message filter can respond to events and down-sample appropriately based on circumstances. can be sampled). The example CAN gateway 206 further includes CAN message capture, for example, passing CAN sampling data and/or buffering CAN sampling data until it is passed. The exemplary CAN gateway further includes a CAN2Eth Encap component, which encapsulates captured CAN messages into Ethernet messages (e.g., including preceding and/or following message data and/or CAN message data). packaging one or more into a single Ethernet packet). The exemplary CAN gateway further includes an Eth IP component that delivers encapsulated CAN messages to appropriate addresses on the Ethernet network. In certain embodiments, the message enables, for example, the CAN data collection policy manager to receive the appropriate portion of the current policy, and the edge gateway to detect event data indicators (e.g., more than a given event occurred). ), and the like. In certain embodiments, a mixed network may include network types different from the CAN-Ethernet mix and/or may include networks with different protocols (eg, packet size, leading/trailing bits, etc.). It is possible, therefore, that the edge gateway contains the appropriate components.

Referring to FIG. 7, an exemplary Ethernet switch 204 is depicted. The exemplary Ethernet switch 204 may, for example, perform downsampling and/or extract unnecessary packets (eg, data in response to events provided by Ethernet devices and/or edge gateways during periods of operation when events are not active). and an Ethernet packet interceptor. An exemplary Ethernet packet interceptor obtains selected data from an Ethernet network. In particular embodiments, Ethernet switch 204 performs operations such as port switching or other routing operations. An exemplary Ethernet switch 204 communicates with data collection controller 202 , edge gateway 206 , and one or more Ethernet devices 210 .

Referring to FIG. 8, an exemplary Ethernet device 210 is depicted. In certain embodiments, Ethernet device 210 utilizes an ECU policy manager (electronic control unit) that determines data transmission values according to policies, including, for example, data rate, resolution, and/or data response to events. , manages the enforcement configuration of policies associated with a particular device. In certain embodiments, the ECU manager performs event detection (eg, reading Ethernet parameters and determining if an event is active). In certain embodiments, the ECU manager receives event status and manages only data transmission requirements according to event status. Ethernet device 210 further includes a data collector that down-samples, adjusts the resolution of data values, and/or processes multiple data values (eg, in-packet and/or data collection controller 202 and/or off-vehicle device 104). ) can be provided for later matching in . Exemplary Ethernet device 210 further includes a data transmitter that provides packets to the Eth IP, which manages addressing, transmission, and/or reception of associated packets. Exemplary Ethernet device 210 can be associated with a particular component, eg, to control Ethernet communications according to policies for the associated component. Additionally or alternatively, the Ethernet device 210 can be part of a component (e.g., manages Ethernet communications for a component that can participate in data collection aspects that support policies), and /or may be part of a controller associated with the component. Exemplary Ethernet device 210 is in communication with Ethernet network and/or Ethernet switch 204 .

Referring to FIG. 9, an exemplary user consent controller 212 is depicted. The user consent controller 212 may be part of and/or associated with an onboard user input device such as a vehicle operator accessible console (eg, a touch screen interface). In certain embodiments, user consent controller 212 may be omitted and/or another user interface of the system, such as an application for mobile devices, a web portal or other interface for connected devices, or the like. can exist in parts. For example, where the vehicle and/or related data are owned by a different operator and/or for the operator's convenience, alternative interfaces may be provided for consent communication. In one example, the operator utilizes a mobile device with an installed application to perform the consent action, for example with a login or authentication action confirming the association with the vehicle. In another example, an owner or agent with authority accesses an application or web portal, such as a fleet manager with web-based access on a computing device and/or mobile application associated with the vehicle. In certain embodiments, user consent is provided within a single interface (e.g., a web application listing a group of vehicles) and/or a single action (e.g., approving a policy update for a selected group of vehicles). ) for multiple vehicles. In certain embodiments, a user consent application (see, eg, FIG. 4) may be used in combination with or as an alternative to user consent controller 212 .

Referring to FIG. 10, an exemplary data collector controller 202 having multiple components and configured to functionally perform the operations of the data collector controller 202 is schematically depicted. ing. Data collector controller 202 includes a vehicle OTA client (over the air) that receives policy updates, policies, and/or policy notifications from off-vehicle device 104 . An exemplary vehicle OTA client communicates policies, policy updates, and/or policy notifications to the policy manager. In certain embodiments, the policy may be provided from the off-vehicle device 104 through an MQTT broker (see FIG. 11), allowing the vehicle 102 to subscribe to policy updates, allowing the vehicle 102 to receive and/or Or, without requiring the full policy to be communicated to the vehicle 102 until it is ready to implement, it allows immediate receipt of notification that an updated policy is available. In certain embodiments, the policy manager can download policy updates and store them for later implementation. In certain embodiments, the policy manager may only command a policy download when the vehicle 102 is in a state to enforce the policy (eg, during shutdown operation, steady state operation, or the like).

The exemplary policy manager can validate the policy and perform checks based on vehicle-specific information, for example, which may not be available to the policy manager 330 on the off-vehicle device 104, to ensure that the policy is enforced. For example, if the policy requires data collection from non-existent devices, network traffic that is not practicable or does not comply with vehicle requirements (either on any network of the vehicle, through an Ethernet switch, or on some of the vehicle networks). at other components) and/or request a type of information that the vehicle 102 cannot provide (e.g., sampling rate and/or resolution not available), the policy manager will eliminate the policy and/or Or a notification can be provided to the off-vehicle device 104 that the policy has been removed. In certain embodiments, the policy manager can be configured to partially implement a policy, e.g., implement higher priority data collection elements from some of the policies and implement other lower priority data collection elements from some of the policies. and/or replace parts of the currently implemented policy that have a lower priority than the high priority parts of the updated policy. However, in certain embodiments, the policy controller may be configured to either accept or reject new or updated policies as a whole. In certain embodiments, for example, if the Policy Manager is unable to fully comply with a new or updated policy, the Policy Manager may provide information about the partial implementation of the policy (e.g., a flag indicating only partial compliance). .

In certain embodiments, the policy manager parses the policy elements and passes relevant elements to the policy manager throughout the system (e.g., edge gateways, Ethernet switches, Ethernet devices, and/or data collection as described below). to other components with the controller 202). The example data collection controller 202 collects policy-based data (and/or or planned as a response when an event condition is detected). A data receiver provides data to a preprocessing component, which determines virtual sensor or modeled values, adjusts data sample rates (e.g., performs filtering operations), resolution values can be adjusted, and the like. In certain embodiments, the preprocessing component supports event detection, such as determining secondary state values that inform event state determination, rejecting or tagging data based on fault codes present, or the like. You can perform a specific action that

The example data collection controller 202 includes a cache component that performs short-term data storage, e.g., enables parameter processing, and/or events are short-term historical data recovery (e.g., when an event is detected). Support the capture of information such as rolling buffers that can trigger events (triggers indicating accidents, component failures, or the like), where historical data is desirable. An exemplary cache component can respond to commands from a cache controller, receive parsed cache instructions to support policies, and/or depending on the current operating state of vehicle 202 . Cache behavior can be adjusted. In certain embodiments, the size of cache and/or other available storage may impact the ability of data collection controller 202 to meet policy requirements. For example, if a large number of events in a policy result in significant cache memory consumption, the policy manager may determine that the current configuration of vehicle 202 cannot satisfy the policy. In certain embodiments, for example, multiple part numbers of cache components with different cache sizes exist within a group of vehicles and/or vehicle-specific conditions (e.g., part of the cache memory fails). or otherwise unavailable) exists, the policy manager with higher level information about the particular vehicle to the policy manager 330 on the off-vehicle device 104 may request the policy if the policy manager 330 approves the policy. can be determined to be unverifiable. In certain embodiments, the trigger state evaluator receives parsed information indicative of event detection criteria from the policy manager, and the trigger state evaluator determines which trigger state evaluator depends on the event detection criteria and the cached and/or retrieved data. Determine if an event condition exists. In particular embodiments, event detection may be performed in other components as described throughout this disclosure, such as in the edge gateway policy manager and/or in the Ethernet device policy manager. In certain embodiments, the policy manager of data collection controller 202 determines which devices have sufficient information available to perform event detection operations and configures the parsed elements of the policy appropriately. provide to the element. Thus, in certain embodiments, the trigger condition evaluator indicates whether a given event condition has occurred rather than performing direct detection of the parameters used to determine whether an event has occurred. You can refer to the state value. In certain embodiments, one device can perform primary event detection and another component (e.g., a trigger condition evaluator) can perform secondary detection of the same event, e.g. , a system that responds to detect an event when a primary sensor indicating the event has failed but a backup sensor detects the occurrence of the event.

The exemplary data collection controller 202 includes an acquisition component that provides parameters for storage. In certain embodiments, the ingest component responds to commands from, for example, a trigger condition evaluator indicating that a trigger condition (event) is active, and retrieves additional information from the cache component to support policy enforcement. (eg, buffering values available in the cache). The example data collection controller 202 includes storage components that store captured data for transmission to the off-vehicle device 104 . Exemplary storage components utilize non-volatile memory, such as FLASH memory, to allow storage data that has not been transmitted to be stored upon power loss. Exemplary data collection controllers 202 include storage controllers that provide storage commands to storage components, support policy enforcement, and/or prevent intermittent loss of network communication to off-vehicle devices 104 and/or intermittent ability to communicate data to off-vehicle devices 104 (e.g., when higher priority resources are utilizing available bandwidth and/or when data communication limitations such as data plan restrictions exist); of vehicle 202 specific operating conditions. In certain embodiments, the storage of data collection parameters is performed until the storage component is full, at which point some of the data is purged (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 retains data that satisfies a higher percentage of the available policy requests. can be configured to In certain embodiments, data element correspondences to various policy requests are not available at data storage controller 202, and other criteria are utilized to determine which data is purged or expired. be. In certain embodiments, some of the purged data may additionally or alternatively be compressed and/or summarized to reduce storage utilization. In certain embodiments, some of the purged data may be downsampled to reduce storage utilization. In certain embodiments, the amenability of a particular data element to compression, summarization, and/or downsampling (amenability is defined as the required consumption of processing power, the compression, summarization, or downsampling of data relative to the underlying data). or similar considerations) may be taken into account in determining commands from the storage controller in response to full (or full) storage components. In certain embodiments, commands to compress, summarize, and/or downsample data depending on the storage component being full or filling may also be provided as part of the policy and/or the policy may , may include instructions regarding techniques to be used for compressing, summarizing, and/or downsampling the data when displayed. In certain embodiments, the policy further defines thresholds (e.g., storage value thresholds, time remaining before storage is full, etc.) that indicate when storage purge, compaction, summarization, and/or downsampling operations are performed. can contain.

In certain embodiments, the storage controller is configured to support caching operations by utilizing a portion of the storage available on the storage component. In certain embodiments, the storage controller determines the amount of available storage based on historical information such as storage component utilization over time and/or network availability for transferring collected data to off-vehicle device 104 . It can be configured to make more decisions. In certain embodiments, cache component storage support may be defined within a policy. In certain embodiments, storage support for cache components may not be utilized. In certain embodiments, the availability of storage support for cache components can be considered by the policy manager in the operation of validating policies.

In certain embodiments, data collection controller 202 includes an encryption component configured to encrypt data transmitted to off-vehicle device 104 . In certain embodiments, data collection controller 202 includes a compression component configured to compress data transmitted to off-vehicle device 104 . Compression can be lossy or lossless, and the compression type can be determined according to the type of data, the descriptive value of the data after compression, and/or can be determined by policy. Data collection controller 202 mediates between transmitting components configured to transmit collected data to off-vehicle device 104 and competing transmission resources of vehicle 102, e.g., to support the selected data protocol. for example, comparing relative data priorities to other transmitting elements, data planning, scheduling transmissions according to vehicle operating conditions, and/or configuring transmissions to support virtual channels utilized by transceivers. element. In certain embodiments, the transmit controller determines that the data plan values (which can differ between specific data elements, e.g., the first data element is associated with the first requestor having the first data plan, the first 2 data elements associated with a second requestor having a second data plan), transmission priority, and/or vehicle operating conditions associated with any of the above. It is possible.

Referring to FIG. 11, an exemplary first partition 302 is depicted having multiple components configured to functionally perform the operations of the first partition 302 . The exemplary first partition 302 includes a load balancing/proxy controller 312 (eg, network manager) configured to communicatively interact with the data collection controller 202 . The example load balancing/proxy controller 312 interacts using policy communications 1106 , consent communications 1108 , and data communications 1104 between the vehicle 102 and off-vehicle devices 104 . Communications 1104, 1106, 1108 include primary data communications, authentication, confirmation, and the like.

The exemplary first partition 302 further includes an http component 1102 configured to package received data into a selected data structure (eg, http in the example of FIG. 11) for storage. The exemplary first partition 302 further includes a data communication component 308 configured to package the data for storage such that the data values received are not accessible to the first partition 302 . , a tokenization/anonymization component that reversibly replaces sensitive data with tokens, and an encryption component that encrypts data with a master public key (e.g. , the data request/processing component 322 has a master secret key). In particular embodiments, data communication component 308 associates metadata with stored data so that requests from data request/processing component 322 can be answered with corresponding data. Exemplary first partition 302 stores data in raw data storage 320 for access as authorized by internal application 334 and external application 402 .

The exemplary first partition 302 further includes an MQTT broker that publishes the updated policy so that subscribing devices (eg, data collection controller 202) receive notification that the updated policy is available. to In certain embodiments, the first partition 302 can push updated policies to the vehicle 202 and/or the vehicle 202 can periodically request whether policy updates are available. and/or request policy updates in response to certain events (eg, certain operating conditions, service events, network availability events, etc.).

Referring to FIG. 12, the exemplary second partition 304 includes a policy creator component 1202 for performing operations such as compiling, implementing, creating, and/or storing policies for utilization in the system. include. In particular embodiments, policy creator component 1202 is further configured to publish policy updates, for example, updating policies to a few vehicles before sending policy updates to more vehicles. The exemplary second partition 304 includes a data request/processing component 322 having a data processing engine that utilizes a master private key to decrypt incoming data from the first partition 302, and tokenization information within the incoming data. and an encryption component to re-encrypt the data with the temporary key (if authorized) for sharing the data with the application and/or user device requesting the data. . The example of FIG. 12 includes an internal application 334, such as a vehicle twin application running on the corresponding vehicle 202, a vehicle twin dashboard, a third party application (of any type), a mobile application, a web-based application, and a number of external applications 402 such as a user consent application and/or policy creator user interface.

An exemplary second partition 304 includes an application registration portal and application approval workflow components that interface with applications and proposed applications to ensure proper authorization, enforce application standards, and the like. (generally 1204). The application registration portal and application approval workflow component 1204 also interacts with the application authorization database 328 to record application registrations and ensure authorization of access to applications. Although authorization communication 1206 is depicted in the example of FIG. 13, authorization communication can be sent between other components of second partition 304 than the one depicted.

In certain embodiments, one or more of the data stores described herein are utilized to store raw vehicle messages and data, including metadata or data to identify the data at selected times. Other information, such as vehicle identification, timestamps, identifiers for data, and/or data, and/or data, for one or more of the purposes described herein, for the system to access the contents of the raw data store at selected times. Any other information that makes the content of the raw data store available can also be included. Raw data refers to vehicle data that is stored locally on the vehicle (eg, for a selected period of time) and communicated off-vehicle at the time the data is presented, such as from the data collection controller 202 (see FIG. 2). can do. In certain embodiments, data such as compressed data, downsampled data, summarized data, aggregated data or similar data can be at least partially processed and still constitute raw data as described herein. be able to. In certain embodiments, data can be meaningfully processed, for example, data determined from models, virtual sensors, or the like, and still constitute raw data as described herein. For example, the outputs of virtual sensors or models describing basic vehicle parameters such as vehicle speed, ambient air temperature, or the like are stored as raw data for use by applications 402, 334 (see, eg, FIG. 4). can do. Descriptions that utilize raw data include data utilized in such a manner as provided by the vehicle and/or data utilized in such a manner as presented to the application 402, 334 as available base vehicle parameters. be able to. A given data value (e.g. vehicle position) may be treated as raw data for a particular system and/or purpose and not for another system and/or purpose. be.

Embodiments of the present disclosure provide systems, apparatus, and methods for providing container management, including operating and managing container runtime operations for embedded environments such as mobile applications. Exemplary operations include providing container management for mobile applications with two or more networks on the vehicle and/or mixed networks on the vehicle. Embodiments herein provide virtual network construction and configuration, intra-container communication, and inter-container communication. Embodiments herein provide container registry, deployment and orchestration. Embodiments herein provide for container monitoring, restoration and/or updating. Embodiments herein provide dynamic configuration of configurable edge gateways (e.g., interfacing to CAN networks, LVDS networks, electrical signaling zones, etc.), dynamic data collection from edge networks, dynamic Provides programming/configuration of reduced latency cross-network communications using signal-to-service mapping and/or communication engines or other implementation circuitry or controllers.

Embodiments of the present disclosure provide systems, devices, and methods for operating and/or managing vehicle automation features and/or functions. Embodiments herein add vehicle automation features and/or functions without coding (e.g., algorithm development, compilation, and/or updating of computer readable instructions, operating system modifications, and/or firmware updates). Allow for deployment, configuration and/or updating. Embodiments herein provide an index of automated recipes, interactions with operators, and/or applications that further interface with operators, owners, service personnel, manufacturers, fleet personnel, and/or OEMs. enables the addition, deployment, configuration, and/or updating of vehicle automation features using Embodiments herein support managing, initiating, and/or updating flexible triggers for vehicle automation features and/or functions, and executing vehicle automation features and/or functions.

Embodiments of the present disclosure provide systems, devices, and methods for managing and/or operating vehicle remote control enhancements. Embodiments herein enable reduced latency and/or latency-free vehicle-to-external network communication, for example, utilizing low-power persistent vehicle-to-cloud communications. Embodiments herein enable a wide range of control functions for customer support, customer service, business analytics, manufacturer/OEM application differentiation, consumer applications, customized features, and/or aftermarket features. . Embodiments herein provide enhanced remote control implementations utilizing programmable complex control procedures with enhanced capabilities for secure access to vehicle networks, devices, endpoints, and/or flows. and access to ancillary aspects to enable implementation of enhanced capabilities features (e.g., the ability to determine support vehicle status, conditions, etc., and/or to ensure mission functions are not impeded). enable.

Embodiments of the present disclosure provide systems, apparatus, and methods for consistent implementation of an intrusion detection system (IDS) across a network of mobile applications, all networks and/or a selected subset of networks of mobile applications. can further include integrated implementations over Embodiments of the present disclosure are implementations of IDSs for mobile applications that have external connectivity and data communications and/or the ability to operate at least partially on external devices (e.g., fleet computing devices, cloud servers, etc.). further includes Embodiments of the present disclosure include IDS implementations for Ethernet, CAN, and/or vehicle cloud IDS. Embodiments of the present disclosure generate and/or communicate incident reports, data logs, activity/response descriptions, and/or alerts and are utilized in incident reports, data logs, activity/response descriptions, and/or alerts. including generating data that Embodiments of the present disclosure provide incident reports, data logs, activity/response descriptions, and/or alerts to onboard devices, offboard devices, and/or selected entities (e.g., operators, owners, fleet personnel, manufacturers, OEMs). , service personnel, monitoring applications or services, etc.) to selected devices and/or communication flows. Embodiments herein include operations that implement rule-based incident responses to IDS operations. Embodiments herein include dynamic configuration and/or updating of IDS operations.

Embodiments of the present disclosure provide systems, apparatus, and methods for management and/or operation of shared network storage for mobile applications having multiple data storage devices associated with and/or multiple data storage devices. It can further include that the devices are distributed across at least two networks for mobile applications and/or across a network of mixed networks. Embodiments include unified storage shared by multiple applications, flows, processors, circuits, endpoints, devices, services, and the like. Embodiments herein provide network file system access to network endpoints, devices, applications, and/or flows of mobile applications. Embodiments herein provide overlaid database services for shared stored data and/or portions thereof. Embodiments herein provide selected encryption schemes for shared stored data, including at least encryption of stored data. Embodiments herein provide authentication, access control, and auditing of shared network storage operations, including at least scheduled operations according to policies, authorization of participating devices, and others. Embodiments herein provide at least policy enforcement, data retention schemes, and/or Provides data lifecycle management for shared storage data, including prioritization.

Implementations of the present disclosure are provided as a service-oriented architecture (SOA), faster development, code reuse, reduced complexity, and easier deployment. OEMs benefit from reduced development costs, improved time to market, reduced warranty costs, and reduced recall costs. Customer benefits include vehicles with more features, post-purchase feature upgrades, reduced inconvenience due to warranty and/or recall related work, and the like. SOA, as used herein, means that devices, endpoints, applications, and/or flows publish the availability of services (e.g., available data values, actuator actions, and/or functionality) (e.g., service provider ) and subscribe (eg, service requester) or otherwise request available services. Services can be selectively published (eg, only to subscribers with sufficient authorization and/or only by providers with sufficient authorization). Services can have separate permissions on both the publishing and requesting side, e.g., owners, manufacturers, OEMs, bodybuilders, fleet operators, third party applications, etc. to publish and/or request services. has separate permission for Service providers and/or requestors may be on-board or off-board.

Today, conventionally known vehicle functions are implemented as mission-specific monolithic code that is tightly coupled with underlying middleware, operating system, and specific controller (e.g., ECU) hardware. SOA architecture allows data or functions provided by existing applications across networks, regardless of which ECU they reside on, which network they are associated with, the underlying hardware, OS, middleware, and programming language used. can be reused by new applications. The use of SOAs decouples control logic from sensor data and actuators, allowing applications and control functions to be ported to different ECUs. SOA also allows adding/removing both service providers and consumers based on performance, cost trade-offs, and system changes (e.g., operating conditions, permission changes, subscription changes, etc.). , can be enabled/disabled, thereby improving the expandability of the functions of the entire system. In addition, the use of SOA allows feature timing to be decoupled from manufacturing events or dealer preparation events, as features can be easily added or removed when they are available.

The exemplary SOA supports the use of the AUTOSAR ARA::COM compliant API interface and also includes extensions thereof. Exemplary properties of the ARA::COM module without extensions include utilizing a distributed architecture (e.g., each service provider and requester manages offers, discovery, connections, and interactions with peers); Correspondingly, there is no readily available method to monitor or control service management activities such as discovery, publishing, subscribing, service start/stop, and/or debugging, diagnostic or analysis activity reporting. Lack of central management results in extra network traffic, unavailability of network-to-network services, the requirement for each device to individually adapt to changes in services, and a lack of authorization schemes or security for publishing and/or subscribing to services. . Furthermore, under ARA::COM many aspects of the service interface must be statically defined (eg service ID, IP address, port number, etc.) before or during the compilation operation. Therefore, changing any of the static values requires modifying and recompiling the code, which is cumbersome and error prone. Furthermore, the static local registry of a given ECU in different applications across mobile applications can get out of sync due to various error conditions, and recovery from such situations can take a long time and fail completely. However, this can result in extensive downtime to reconfigure the vehicle's ECU, mission failure, and/or expensive service operations.

Exemplary embodiments include a centralized controller for implementing a service-oriented software infrastructure for mobile applications (eg, SOA). Exemplary functions include central management of all services (and/or all managed services) within a vehicle using policies maintained and deployed from the cloud. In certain embodiments, all or part of the policy may be maintained and/or deployed from an external device coupled to the vehicle such as a service tool, OBD device, or the like. In certain embodiments, all or part of the policy is coupled via a cloud, web application, hardware connection (e.g., USB cable, OBD port coupling, etc.), and/or another connection such as a WiFi or Bluetooth connection. can be maintained and deployed from a user device that can In certain embodiments, the ability and/or permission to update and/or deploy policies is determined by the updating entity (e.g., manufacturer, service, owner, warranty enforcer, etc.) and/or access type (e.g., cloud, web application, hardware connection, etc.). Exemplary policies define parameters such as service parameters, service access permissions, and/or service connection modes. The exemplary centralized controller implements dynamic updates to policies, which add, update, delete, enable, enable, and update service providers, requesters, service parameters, specific subscriptions, and/or public parameters for services. and/or can be disabled. In certain embodiments, a centralized controller may, at least in part, support policies that utilize static configuration (eg, cloud connectivity is not available or is not currently available). In certain embodiments, the centralized controller is configured to provide policy information and is stored in a memory location (e.g., flash memory) separate from the OS, boot, or other operational sectors of the centralized controller. It stores policies in a data structure that can be used to update parameters without disrupting basic operations. In certain embodiments, the separation of policy information may be physical (eg, separate memory storage devices) and/or logical (eg, memory addresses separated from the base operating address). In certain embodiments, storage of policy information may be implemented in whole or in part as a shared network storage operation.

An exemplary centralized controller provides service visibility to the cloud or external tools. For example, a centralized controller may determine and/or store service maps of all services provided and/or consumed on the vehicle. Specific service maps shared with requesting devices can be configured according to requester permissions (e.g., clear views for manufacturers, service entities, fleet owners, security officers, compliance officers, etc.) . An exemplary centralized controller determines logs of major service activities in the vehicle (eg, adding or removing services, changing subscriptions, changing data providers to services, etc.). Activities that are primary service activities may differ depending on the requester and/or the purpose for which the activity log is used, and accordingly the content of the log is determined and/or determined depending on the requesting device and/or entity. or can be adjusted. Additionally or alternatively, log sharing and/or the content of the shared log can be configured according to the requestor's permissions. Activity logs can be used for debugging, diagnostics, auditing, compliance decisions, or other purposes.

Exemplary modes of service connection are full service discovery, publish/subscribe data, and full dynamic connection; no service origination, but publish/subscribe data provided, and partially dynamic connection; Includes no publish, no publish/subscribe data, and static connections. In certain embodiments, the mode applied to a service connection may be configured according to the service connection's permissions and/or may be utilized in response to non-nominal behavior (e.g., the service connection may be fully Even if authorized for service discovery, if service discovery failure occurs, the centralized controller will provide partial dynamic connectivity as a fallback action, and further fallback action if publication/subscription data retrieval fails. may provide a static connection as ).

An exemplary centralized controller operates the SOA manager as a predefined service provider that all endpoints can trust (eg, consistent network addresses, etc.). Dynamic behavior is managed through storage of configuration information, including policy information. If the SOA manager determines that an error exists (e.g., an endpoint appears to move, goes missing, or becomes available intermittently), the SOA manager updates the configuration information and service connection state. Respond to non-nominal conditions such as query and restore.

The exemplary centralized controller performs security operations for service connections, such as requesting identity credentials from service endpoints, before enabling service connections. The exemplary centralized controller operates a security engine having stored information defining certificate generation, storage, and verification. The exemplary SOA manager allows or blocks service connections and/or specific actions on service connections based on policies, configuration information, and permissions associated with service endpoints. Policy information can be dynamically updated.

An exemplary centralized controller includes an SOA manager that runs extensions on top of selected APIs, such as ARA::COM modules, and also acts as a service provider. The SOA manager configures, controls and monitors service-oriented communications in vehicles based on policy and configuration information. The exemplary centralized controller further includes a SOA PLUGIN SDK that includes a library for use by any application participating in SOA communication, the library function communicating with the SOA manager to determine control information and implement control; Report status and activity to the SOA manager. The exemplary SOA PLUGIN SDK further includes tools to modify the generated client proxy and server skeleton code to support dynamic configuration of service parameters.

Referring to FIG. 13, an exemplary system outlines a centralized controller (ECU), SOA manager, SOA PLUGIN, and communication between vehicle controllers (e.g., ECU, ADAS) and external devices (e.g., cloud). is drawn in a realistic manner. The depicted endpoints (eg, ECU, ADA) are shown as client or server applications for purposes of explanation. It will be appreciated that a given application can be a client, a server, or both, depending on services, vehicle operating conditions, and the like. IVN" is the in-vehicle network layer, which can be a physical layer (e.g., multiple physical endpoint connections and network hardware), a logical layer (e.g., Ethernet network ports or virtual ports), or a combination thereof. The IVN can include mixed networks, such as Ethernet and CAN networks, and one or more networks can interface with the SOA manager using configurable edge gateways or other interface devices. It will be understood.

An exemplary centralized controller includes an AUTOSAR adaptive communication management module (eg, including IPC, SOMEIP, and/or other protocol bindings), a SOA manager integrated with the ARA::COM module, and a SOA PLUGIN library and code generation. Including tools.

An exemplary centralized controller includes a SOA manager located in the vehicle's controller, which runs on a separate ARA::COM module and includes a SOA PLUGIN library and code generation tools.

Embodiments of the present disclosure provide the ability to provide frequent feature upgrades, additions or deletions of features, and personalized configuration of features for mobile applications. Exemplary embodiments enable customized vehicle behavior by providing simple and flexible automation capabilities. Exemplary embodiments include interfaces and integration tools that enable developers and users to quickly and easily create custom workflows that manipulate vehicle functions based on user input and vehicle status.

Exemplary embodiments allow users to create custom trigger action rules for automating vehicle environments, enabling previously unavailable in-vehicle features. For example, embodiments herein can control cabin temperature, lighting, infotainment, seats, windows, Includes customer control of adjustment of sunroof, cabriolet top, driving modes, and/or any other actuator or vehicle interface.

Exemplary systems can trigger actions (e.g., voice commands; operator input values such as from applications, personal devices, vehicle operator inputs, and/or vehicle display inputs; vehicle operating conditions; detected events; a centralized controller with an automation manager that determines customized actions, including combinations of An exemplary automation manager monitors vehicle status to determine if a trigger action has occurred and commands customized actions in response to the occurrence of the trigger action. In certain embodiments, the automation manager may limit the execution of customized actions depending on vehicle conditions (e.g., an "open door" command to open the driver's door may limit conditions such as zero vehicle speed). (which can be implemented by a user providing customized behavior, which can be implemented elsewhere in the system). In certain embodiments, interaction with certain actuators (eg, direct vehicle start commands) may be prohibited and/or require additional approval or permission. In certain embodiments, an interaction with a particular actuator (e.g., a vehicle start command) may embody a request to a vehicle application or flow rather than a direct command of an on-board actuator (e.g., when the vehicle (If you have an automatic start function available on top, this would require the implementation of the automatic start function (rather than providing a direct command to the vehicle starter), the customized operation would require the implementation of the automatic start function). It may have different permissions than those associated with the direct command.
In certain embodiments, customized operational data, such as configuration information, is stored in memory storage on the system. In certain embodiments, the automation manager accesses a configuration entity (e.g., owner, operator, manufacturer, third-party application provider, etc.) based on and/or authorized and/or as part of customized operations. The configuration of the customized motion is restricted according to the data elements that are requested and/or the permissions associated with the actuators that are commanded.

Example operations are described below to describe some of the types of operations that can be supported by embodiments of the present disclosure. Exemplary operations are non-limiting, an exemplary automation manager responds to any input that may be provided as data parameters stored in network communications and/or computer readable media, any response that can be commanded to any actuator in the system, including actuators under the control of another controller (e.g., vehicle display, system speaker, vehicle powertrain, etc.) be.

Exemplary customized actions include setting passenger seat heating in response to the driver tapping the driver seat heating switch twice to set passenger seat heating. An exemplary action is to return the driver's seat heating switch to control driver's seat heating after a short delay (eg, a few seconds). In this exemplary operation, passenger seat heating can be conveniently set from the driver's side.

Exemplary customization actions include configuring multiple vehicle aspects in response to a command such as "Hey car, start my morning commit." By way of example, set vehicle aspects may include tuning the radio to a selected station and volume, setting a pre-selected navigation destination (e.g. office), vehicle performance mode (e.g. fuel economy mode), , setting the driver seat position (e.g., forward/reverse, height, tilt, lumbar support, etc.), and/or setting HVAC parameters (e.g., selected cabin temperature) can be done. In certain embodiments, the customized behavior may be based on ambient or external traffic, such as utilizing different radio stations depending on the day of the week, adjusting HVAC settings based on ambient temperature, or adjusting navigation based on the number of people in the vehicle. Further interactions can be included based on conditions.

Exemplary customized actions include actions to configure multiple vehicle aspects in response to system conditions, such as a vehicle approaching a driver's home at night. In the example, the customized behavior could be to dim the headlights, turn down the radio, turn on the lights, send a message to the home automation system to open the garage door, turn the side mirrors on as the car enters the garage. Enforce the stored workflow. In certain embodiments, the proximity of a vehicle to a driver's home at night can be determined by any action, such as determining from GPS coordinates or interacting directly with the home automation system's network.

Exemplary customized actions include actions that configure multiple vehicle aspects, such as coded hard buttons on a vehicle display. navigating the climate control system, utilizing multiple button presses, and/or visibility may be impaired (e.g. vehicle is dark) and/or the driver may find and concentrate on the relevant knob. setting the vehicle's HVAC system to the desired temperature in response to the coded hard buttons without turning the associated knob when it is undesirable to turn attention to doing so.

An exemplary automation manager (or vehicle automation manager) allows users to create arbitrary trigger action rules that can be executed on a vehicle, such as by a centralized controller. For example, a user can create a trigger action rule to automatically turn on high beam headlights when there is no oncoming traffic while driving at night. A description of an example general flow of customized operation includes the following.

Users access an app on their mobile phone or web browser and use it to create custom trigger action rules or enable predefined ones created by OEMs.

Trigger action rules are sent to the cloud, and activated trigger action rules are aggregated as "recipes" on the cloud side.

The cloud pushes recipes to vehicles (eg, stores configuration information related to customization operations) through a vehicle update controller (VUC).

When the trigger evaluation engine receives the latest recipe, it analyzes each rule in the recipe and executes each rule in a controlled and isolated manner.

Accounting data (such as the number of times trigger action rules were executed, trigger event detections, trigger event data, and/or events that triggered actions but were suppressed based on operating conditions) are sent back to the cloud, where, for example, , phone app and/or other monitoring applications.

It can be seen that the vehicle automation manager allows users to enrich their vehicle experience without having to wait through feature request, approval and update processes. The exemplary vehicle automation manager further enables users to leverage their own creativity and/or the creativity of third party application providers to implement improved vehicle interactions. Additionally, vehicle brand owners (e.g., manufacturers or OEMs) or other sponsors or responsible parties may provide updates or features to many users, or even specific users, more quickly and/or more frequently. Trigger action rules can be enforced for

As an example, a vehicle automation manager (VAM) receives recipes from the cloud as input and executes trigger action rules within the recipes. Each trigger action rule consists of a trigger, a condition, and an action. Triggers are inputs to the rule including signals from the CAN bus, time, location, diagnostic status, vehicle status, video/audio, driving logs, and the like. Depending on the condition, it takes the input value of the trigger and determines if a certain condition is met.

Conditions are written using custom syntax to express complex logical conditions such as multi-value AND/OR logic, comparators, advanced utility functions to calculate sums/averages/standard deviations, etc. If the condition is met, the corresponding action is performed and/or requested (although it may be blocked due to operational conditions, etc.). Actions can include invoking a service in the SOA or sending a CAN signal to a CAN ECU.

Referring to FIG. 14, an exemplary automation manager is depicted schematically and located on a centralized controller. In the example of FIG. 14, the VUC receives recipes (and/or configuration information describing customized behavior) from the cloud using MQTT/HTTP/WebSockets or the like. The VAM controls vehicle automation based on recipes, a lexical engine that parses the recipes, and a rules engine that orchestrates rule execution using a trigger evaluation engine and a task execution engine (and/or a trigger execution engine). including. Automation manager actions such as FIG. 14 may be vehicle automated actions, event triggered actions, remote control actions, and/or created by manufacturers, OEMs, fleet owners, vehicle owners, vehicle operators, and/or third parties. It can include any configurable action taken in response to an application, function, trigger, or other automation application.

An exemplary trigger evaluation engine takes triggers as input and evaluates trigger states based on trigger values. The trigger value can come from any network, such as a CAN bus, for example, using a configurable edge gateway that adjusts routing tables to dynamically retrieve signal values. In addition, it is also possible to obtain values from other Ethernet ECUs through the SOA, from other modules on the centralized controller (such as diagnostic servers), or from raw video/RADAR/LiDAR streams over Ethernet. A centralized controller may coordinate data collection performed for customization operations with other aspects of the system, such as data collection operations for other purposes, and/or with multiple trigger data parameters that utilize at least some of the same trigger data parameters. customization operations, thereby reducing redundant requests for the same data parameter. In certain embodiments, data collection may be a separate action that may additionally be based on trigger conditions, and/or data collection may be performed as a customized action.

In the example of FIG. 14, a trigger manager (eg, as an automation/remote manager in the example of FIG. 14) manages triggers from various trigger-related clients, such as vehicle automation, remote control, and/or data collection trigger flows. . The example of FIG. 14 further includes a data listener that receives data related to triggers, such as CAN bus; Ethernet packets (including EthCC packets with status information such as vehicle position); DET errors, RDBI data, failures diagnostic manager that provides codes, etc.; system manager (such as provides vehicle power status information); time manager (such as provides current time value); and/or vehicle such as any other information such as from the SOA. can be obtained from any location in the

In the example of FIG. 14, the data cache stores data for condition evaluation including, for example, buffered data, intermediate parameters, and the like.

In the example of FIG. 14, the condition evaluation runtime is the engine that evaluates conditions based on the trigger values in the cache and, depending on the evaluation, determines whether the trigger conditions are satisfied. Conditional evaluation supports any type of analysis or decision operation, including at least the following: basic logical operators (e.g., AND, OR, numeric comparisons, etc.); suitable formats (e.g., (X> 5 && Y<10)||Z!=100) &&P<0.05); mathematical functions (e.g. arithmetic, exponential, trigonometric, modular, gamma, etc.), and/or complex data transformation functions over data ranges (e.g. , median, mean, standard deviation, map, average, min/max, bucket, filtering, integration, derivation, and/or frequency analysis operations, etc.).

In the example of FIG. 14, the task execution engine executes actions defined in the action catalog (eg, actuators coordinated according to customized behavior). Example and non-limiting actions include turning on lights, turning on and/or adjusting HVAC, turning on ignition, and the like. Embodiments of the present disclosure are reachable through any network, including actuators provided on two or more networks (e.g., Ethernet for one actuator and CAN for the other actuator). Any actuator can be accessed. In certain embodiments, an action may be a request to act on an actuator (e.g., to another controller that has direct control of the actuator), an action that requests execution of a published service, and/or contains actions with complex interactions that can also exist in
For example, actions may include adjusting the surrounding environment for the current user, which may, for example, determine the current user's identity, her preferences, and adjust the environment such as seat position, HVAC settings, radio channels, etc. Coordination can include interacting with multiple controllers and/or flows.

In certain embodiments, the automation manager advertises one or more customized actions as a service (e.g., may be selectable by the requestor of the customized action, even if defined in policy). good, etc.). In certain embodiments, automation manager components, circuits, controllers, and/or engines are shared in whole or in part with other managers, such as a remote control manager, and/or when a trigger event occurs, for example. to determine whether specified data groups and trigger logic (e.g., passed from other managers to the automation manager) indicates (e.g., determined by the condition evaluation runtime) and/or is implemented ( provided by other managers (e.g., passed as action requests from other managers to the automation manager), e.g., operated by the task execution engine to move actuators and/or provide appropriate commands to other controllers. APIs, library calls, or other interaction interfaces can be used to respond to other managers to perform the actions taken.

Implementations of the present disclosure provide rapid development and deployment of customizable behaviors, automated implementation without coding and/or compilation requirements, access to customizations for customers, third-party applications, aftermarket suppliers, etc., etc. . Implementations of the present disclosure provide ease of implementation of customizable behavior even when data providers and/or actuators are distributed across two or more network types, and providers for customizable behavior can be It is not necessary to have knowledge of the current configuration of your network.

Embodiments of the present disclosure provide the ability to perform remote control operations for mobile applications. Remote control actions for specific functions can be hard-coded into the ECU software—for example, simple engine start/stop actions, door lock/unlock actions, window and/or sunroof open/close actions, etc. It is action. However, post-production additions or changes to such functionality require code changes and verification, which may involve one or more ECUs participating in the remote functionality, and/or Requalification of software builds on those ECUs may be included. Embodiments of the present disclosure are capable of configuring remote control operations for mobile applications at any point in the vehicle's lifecycle, and also allow configuring, updating, and fixing remote operations included at the time of manufacture. is. Additionally or alternatively, where a more robust remote control implementation as described in this disclosure exists, previously hard-coded features may be implemented as dynamic functions as described herein. can do.

An exemplary system for performing remote control and configuration operations includes operating a mobile application controller in a powered mode during shutdown vehicle operating conditions. In certain embodiments, controllers performing remote control operations have granular power control of centralized controllers and/or other ECUs on the vehicle, powering only those controllers needed to perform remote control operations. providing operation of those controllers and associated hardware components (e.g., boards, chips, cores, voltages, clocks, etc.) in a low power state in which remote control commands and configuration requests can be received. . In certain embodiments, the remote control manager force determines that a vehicle shutdown operation is active and leaves aspects of the vehicle hardware energized in response to remote control commands and/or configuration requests. In certain embodiments, the remote control manager powers down controllers and hardware not required for remote control commands and/or configuration requests in response to a vehicle shutdown operation. An exemplary remote control manager receives remote control operation and/or configuration requests, wakes up the necessary controllers or hardware to perform the requested function, and then powers down the vehicle controller or hardware. return to state.

Exemplary actions of the remote control manager to perform vehicle shutdown actions include:
- Turn off all controllers except ECUs and cellular modems that are set to perform remote control functions;
- Shut down all applications and processes in the ECU except those required to perform remote control functions;
- Shut down all but one core of the ECU and reduce the ECU clock frequency to e.g. the minimum allowed value;
・Determine if any of the following are running, and if not, initiate one of the following (the combination of cloud support and functional/performance testing will determine which of these is best for your particular application): is indicated;
- long polling requests;
an event request sent from the server;
- WebSocket request;
- or HTTP/2 Server Push Request - Put the cellular modem into low power mode so that it can receive messages from the server;
• Exemplary actions of the remote control manager in response to received remote control requests include:
- Process message requests and, based on the requests, do one or more of the following;
Put the cellular modem into normal power mode;
- Increase the ECU clock frequency to a normal level (and/or a level sufficient to allow remote control operation, which may be lower than the clock frequency required for normal vehicle operation);
- activate all cores (and/or a selected subset of cores) of the ECU;
Launching applications (e.g. controllers, circuits, etc.) necessary to execute the request (e.g. trigger evaluation engine, task execution engine, etc.);
- Turning on enough controllers, such as actuator controllers, other ECUs, etc., to provide the control action corresponding to the remote control request (Ethernet switch, configurable edge gateway, etc.);
• Execute a remote control request.

Upon completion of a remote control request, which can include feedback (e.g., acknowledgments, success indicators, failure values, etc.) regarding actions to service the remote control request, an exemplary remote control manager provides Return the vehicle to the state of the vehicle or another vehicle status specified in the request.

An exemplary remote control manager monitors battery levels. In response to the battery state of charge falling below a threshold, the remote control manager can take action according to policy and/or configuration information. For example, the remote control manager can wake up the ECU and cellular modem and send messages to external devices (e.g., cloud, web applications, user devices such as smart phones) to alert the user of the status. In certain embodiments, depending on the policy, the remote control manager activates the vehicle's prime mover and drives the battery to a second threshold (e.g., a selected amount above the first threshold and/or fully charged). state) can be charged. In certain embodiments, the remote control manager shuts down the vehicle and provides remote control support in response to the battery charge dropping to a first threshold or another charge value (e.g., below the first threshold). To disable. In certain embodiments, the user is prompted to wake up the vehicle, e.g., to recharge the battery, and/or in response to a message sent when the state of charge of the battery drops below a first threshold. can be requested. In certain embodiments, depending on policy and/or user input, the remote control manager keeps remote functions active below a first threshold.

Exemplary systems include remote control commands that include command values that request operation of remote control functions (e.g., from activating a customized response and/or user selecting an application-configured response). It includes a centralized controller with a remote control manager that determines the operation. An exemplary remote control manager activates the necessary controllers to perform the remote control functions and performs the functions upon command. In certain embodiments, the remote control manager accesses a trigger evaluation engine and a task execution engine (eg, as part of the vehicle automation component of the vehicle as depicted in FIG. 14) to determine the state of the vehicle. (e.g., no obstructions to windows or doors to be closed, no people in close proximity to the vehicle prior to starting, etc.) and/or perform functions to be performed as remote control actions to decide. In certain embodiments, the remote control manager includes or accesses a trigger evaluation engine and/or task execution engine separate from other components of the system. Thereby, the remote control manager performs the remote control operation and/or determines that all or part of the remote control operation cannot be performed or is unlikely to be performed. Customized remote control actions, similar to the customized actions described above, can be provisioned as part of a policy and/or in configuration information. In certain embodiments, the remote control manager can limit the performance of remote control actions depending on vehicle status. In certain embodiments, interaction with certain actuators may be prohibited and/or require additional authorizations or authorizations. In certain embodiments, an interaction with a particular actuator (e.g., a vehicle start command) may embody a request to a vehicle application or flow rather than a direct command of an on-board actuator (e.g., when the vehicle (If you have an auto-start function available on top, this would require a customized action to implement the auto-start function rather than providing a direct command to the vehicle's starter), which is a direct command of the underlying actuators. may have different permissions than those associated with

In certain embodiments, customized remote control operational data is stored in memory storage on the system, such as along with configuration information and/or as part of policies. In certain embodiments, the automation manager accesses based on permissions and/or authorizations of configuration entities (e.g., owners, operators, manufacturers, third-party application providers, etc.) and/or as part of customized operations. Restrict the configuration of customized motions according to the permissions associated with the commanded data elements and/or the commanded actuators.

Example operations are described below to describe some of the types of remote control operations that can be supported by embodiments of the present disclosure. Exemplary operations are non-limiting, an exemplary remote control manager responds to any input that may be provided as data parameters stored in network communications and/or computer readable media, Any response can be commanded to any actuator in the system, including actuators under the control of another controller in the system (e.g., vehicle display, system speaker, vehicle powertrain, etc.). It is

An exemplary operation includes receiving a customer configuration for a scheduled accommodation, where the remote control operation is performed at the scheduled time (e.g., 7:00 am) on a selected day (e.g., weekday). , includes activating the HVAC system to selected conditions (eg, selected temperature and/or use of defrost to keep windows clear). In certain embodiments, customers operate using applications (e.g., third-party applications), using cloud or web-based interfaces, and/or using applications provided by manufacturers, dealers, etc. can be configured. In certain embodiments, the operator selects recipes for remote control actions (e.g., including prompts to set certain parameters and/or only instructions or approvals to turn features on or off). be able to). In certain embodiments, the operator builds customized remote control actions, which may be based, for example, on customized action features present in the vehicle, available in recipes, and/or executed. It can be constructed entirely by a user interacting with an interface that allows inputs such as the action to be taken, any conditions to apply, and any threshold settings.

Exemplary operations include an EV Disabled Grid Compensation Mode, whereby the electric vehicle is electrically coupled to the grid and the electricity provider utilizes the vehicle's two-way charger (e.g., leveling power demand spikes). to do). In certain embodiments, the EV invalid grid compensation mode may include scheduling (e.g., time of day, vehicle charging target, day of the week, associated pairs thereof, etc.) and/or toggle on or off (e.g., function can be turned on long term when the operator goes on vacation).

An exemplary operation is that the remote control manager activates the vehicle in a selected sequence, such as using the HVAC to bring the cabin air to a desired temperature and then activating the heated steering wheel and/or heated seat features. Including responding to progressive preconditioning commands to heat the chamber.

Exemplary actions include the step of the remote control manager responding to a user preference request and vehicle settings (e.g., steering column position, ambient light color, interior/dash light intensity, UI/UX style selection, etc.) in response to the user preference request. and adjusting the

Exemplary actions include vehicle management settings (e.g., valet mode, borrowed vehicle mode, modes set for the parent owner's children when driving the vehicle, etc.), vehicle speed limits, location limits (e.g., , geofence perimeter 500m from the launch position, restriction with a defined area such as city limits, and/or outside a defined area such as state borders, another city limit, total distance from the launch position, etc.) To reduce, include vehicle management. Application limits for vehicle management settings can be either actual application limits (e.g., maximum speed, performance values, etc.) or notification limits (e.g., typically geographic limits can be implemented as notification limits rather than stop limits). , and a notification is sent to the owner and/or selected device when vehicle management setting limits are exceeded (and/or tested at actual application limits, etc.).

Exemplary operations include, for example, a security mode requesting data from a camera, microphone, vehicle display, dashboard, etc. upon request of the security mode. In certain embodiments, a user may select one or more devices (e.g., particular cameras and/or locations in or relative to a vehicle) to stream video and/or Can receive snapshots. In certain embodiments, the security mode allows for data requests from devices communicatively coupled to the vehicle, such as security cameras of a home security system in communication with the vehicle (e.g., the customization operations described above). reference).

Exemplary actions include, for example, personalized actions such as playing "Happy Birthday to You" and/or activating the cabin lights when the driver enters the vehicle on his birthday. Additionally or alternatively, the personalized action may be, for example, playing a selected song or playlist on a given calendar date, day of the week, etc.; calendar function), reminding the driver of anniversaries, etc., and/or reminding the driver of scheduled stops (e.g., picking up groceries when entering the vehicle to return home from work). can be any type of operation, such as

An example and non-limiting remote control action is to use complex conditions (e.g., CAN data, location, time, date, etc.). Examples and non-limiting remote control actions include scheduled sequences of multiple actions including determining conditions when the first scheduled action is completed and the next action is to be performed.

Examples and non-limiting remote control actions include performing one or more actions such as: sending a note to the operator, displaying the note on the vehicle display, and/or announcing the note on the speaker. take snapshots from one or more cameras and send to operators and/or requesters; provide third-party services (e.g., mobile refueling, vehicle services and/or delivery companies) with access to vehicle location and door status; Allow, but under certain conditions (e.g., at selected times of the day, until the completion of an event, and/or depending on the proximity of a third-party service to the vehicle) the vehicle, controller, to initiate activation actions such as head units, to react to environmental changes by defrosting the vehicle (e.g., in response to frost accumulation, determination of ambient temperature, etc.), and/or for diagnostic purposes. (e.g., running active diagnostic tests while the operator is away from the vehicle to reduce the test's impact on vehicle mission).

Exemplary remote control actions include prerequisites, tasks, and/or status reports. Preconditions may be vehicle status, CAN signals, Ethernet packets, information stored on a computer-readable medium (e.g., log information, trip information, and/or other vehicle information), time and/or date, location, etc., can be configured as complex logical expressions, and can be configured based on multiple conditions. Tasks include actions that can be performed using CAN signals, Ethernet packets, or other network communications, and include at least any of the actions described under Customized Operations above. The status report includes confirmation information, confirmation that an action has been performed and/or notification that an action has not been performed, relevant data, confirmation data, usage data for remote control actions, and the like. The content of the status report may vary depending on the recipient and/or requestor of the status report - for example, an operator may receive a simple status report confirming an operation, a service representative may Manufacturers may receive more detailed status reports that include parameters for to aggregate reliability data while still allowing data storage and aggregation). The existence and/or content of prerequisites, tasks, and/or status reports can be provided and/or updated by user input, policy, and/or configuration information.

The exemplary remote control solution supports combinations of different elements of remote control requests, eg, as reflected in the exemplary code snippets for requests.
If (preCondition1 is true) {
do(Task1);
report(Status1);
If (preCondition2 is true) {
do(Task2);
report(Status2);
do(Task3);
report(Status3);
......

An example remote control solution supports specifying the final vehicle status (the state the vehicle should return to) after all remote control functions (driving state, cabin settings, charging state, etc.) are complete. This vehicle status may be different than the vehicle status at the time the request was received. They are also configurable and programmable like tasks.

Referring again to FIG. 14, an exemplary remote control manager is depicted schematically, which in some embodiments is part of a centralized controller, although the remote control manager can be a separate device and/or Or it can be located on another device. The interface to the CAN controller can be done via a configurable edge gateway. In this example, the task execution engine and trigger evaluation engine are depicted as separate and dedicated to the remote control manager only for clarity of this description. The task execution engine and/or the trigger evaluation engine can be located in whole or in part on another device or controller, such as the automation manager, and can be shared between the remote control manager and the automation manager, and /or the remote control manager and automation manager may each have separate trigger evaluation engines and/or task execution engines (if present).

An exemplary system includes an integrated intrusion detection system (IDS) manager configured to provide integrated vehicle-side security of data, operational control, and network access. The integrated IDS manager can further include cloud-side or external vehicle access detection as described herein. As more cars become connected and more applications and services gain legitimate access to vehicles, the attack surface increases. Worse, “bad actors” can steal personal information or intellectual property, use ransomware to extort money, disrupt vehicle operation, and hack into vehicle infrastructure. I'm starting to turn my attention to.

A network firewall is a basic requirement for network security. Layer 5-7 "proxy" firewalls add more protection, but are still insufficient to defend against advanced attacks. Intrusion detection systems can identify suspicious activity that looks like genuine activity by a trusted entity. However, using multiple IDS solutions from different vendors in different parts of the network makes it difficult to provide consistent and complete security throughout the system. A single integrated IDS solution is most effective as it provides complete visibility into all internal, incoming and outgoing traffic, allowing you to examine data flows throughout the system and correlate seemingly unrelated events. . In vehicles, this includes monitoring various network traffic such as CAN, Ethernet, Wi-Fi traffic, and traffic over cellular modems.

OEMs benefit from enhanced security features, faster response to intrusions, and higher customer loyalty. Customers benefit from safer vehicles and personal data protection.

Example operations are described below to illustrate some of the types of operations that can be supported by embodiments of the present disclosure. Example actions are non-limiting, and an example integrated IDS manager can detect intrusive actions that access or attempt to access a network in accordance with any aspect of the present disclosure.

An exemplary integrated IDS manager monitors DNS, HTTP, and HTTPS accesses from any endpoint in the vehicle, allowing ECUs to download malicious software packets and/or to external servers over secure connections. It is possible to detect ECUs in vehicles infected with ransomware and/or spyware that initiate uploads of private or proprietary data to the vehicle. In this embodiment, by maintaining traffic visibility to the integrated IDS manager (such as a centralized controller), problems can be detected quickly and communication with external rogue servers can be blocked.

The exemplary integrated IDS manager enables emergency software updates to ECUs, for example, to patch vulnerabilities observed by investigators, third parties, and/or during operation. The integrated IDS manager also allows communications from vulnerable ECUs to be monitored and blocked or mitigated until the vulnerability is corrected. In an example, a vulnerability may be found in a mission-critical ECU or another ECU in the vehicle and the vulnerability may be exploited to access the mission-critical ECU. In an embodiment, central management of network communications provides better mitigation behavior for vulnerabilities, faster implementation of updates to a single location (e.g. centralized controller), and configuration files, policy information, certificate information, etc. Can be stored outside of the base operating system, allowing many updates without significant downtime to perform updates and/or validate or recertify ECUs when major software builds are otherwise required make it possible to implement

An exemplary integrated IDS manager detects incoming communications requesting vehicle propulsion system access, which may be over the CAN bus (eg, from a rogue operator over a cellular network). An exemplary integrated IDS manager detects attacks, prevents requested access to the CAN bus, and/or provides alerts to customers and/or monitoring services.

An exemplary integrated IDS manager has configurable detection information such as the number of communication requests, and the configurable detection information is stored as configuration information separate from the basic operation of the integrated IDS manager. Thus, the integrated IDS manager's detection parameters can be updated dynamically and without extended downtime for implementation, allowing quick and convenient adjustment of detection thresholds (e.g., lowering thresholds to increase sensitivity, and/or increase the threshold to reduce false positive detections).

From a technical point of view, a centralized intrusion detection system, where signals/packets and messages are analyzed and processed at the same place, can detect potential attack vectors early and build a safer and more secure vehicle environment. is fundamental to

An example integrated IDS manager provides mechanisms and policies for inspecting traffic within the vehicle and traffic entering and exiting the vehicle. Internal traffic consists of in-vehicle Ethernet data and CAN data.

Internal traffic inspection Detects malfunctioning, modified and/or malicious ECUs Detects anomalies in vehicle functions and provides context External traffic inspection Inspects outgoing and incoming traffic, unconfigured protocols Inspects incoming and outgoing traffic protocols such as DNS and HTTP to identify user behavior and detect suspicious behavior and policy violations, etc. Inspects HTTPS headers for domain access and certificate violations

An exemplary integrated IDS manager uses protocol analysis, signature-based, and anomaly-based techniques to detect intrusions. The integrated IDS will have the ability to securely send alerts based on the settings. Alerts are used to initiate further actions, such as terminating a connection or notifying relevant users or services. Also, anomalies can be logged and the logs can be used for further analysis.

Referring to FIG. 15, an implementation for the Integrated IDS Manager (ECU) is schematically depicted. The integrated IDS manager can operate with any type of network traffic, including at least Ethernet traffic, CAN data, and/or external traffic. In an example, a configurable edge gateway provides CAN traffic to ports of an Ethernet network, e.g., as encapsulated CAN messages, which include processed payload data, added frame data (e.g., time stamps or other metadata), with CAN frame data included or removed, and/or with processed CAN frame data. In certain embodiments, the CAN exporter provides compressed metadata to the integrated IDS manager to save bandwidth.

An exemplary integrated IDS manager parses three types of traffic (eg, in the Packet Parsing block). Examples of packet parsing blocks include parsers for Ethernet, IP, ARP, ICMP, TCP, UDP, HTTP, HTTPS, DNS, CAN, EthXX protocols. Either protocol can be supported as needed. An example integrated IDS manager includes a protocol analysis block that checks for protocol error and violation flags. Protocol violations can be caused by ECU misconfiguration or malicious intent, and if detected by this block, intrusions can be effectively detected. An example of a violation that protocol analysis can detect is an invalid TCP flag combination caused by a portscan application running on the ECU.

An example of an integrated IDS manager is a connection management block that analyzes security vulnerabilities at the connection level. The definition of "connection" depends on the protocol considered. Connection management maintains associations of various connections such as:
・Ethernet/VLAN (Source MAC, Destination MAC, VLAN ID)
・IP (source, destination address, protocol)
・TCP/UDP (source, destination address, source port, destination port, protocol)

A connection database is maintained to keep track of all connections. Metadata and statistics collection performs analysis and updates the connection database. Each time a new connection is detected it is added to the connection database and packet statistics are updated. Statistics are only updated for all subsequent packets of a given connection. Any metadata extracted from the packet is also added to the connection database. For example, the state of a TCP connection is metadata held in the TCP connection's connection database. TCP reassembly, if necessary, is done as part of this block.

The signature-based detection block performs signature-based detection checks for known attacks by examining data with known signatures or rules for known attacks. Rules are executed on a per-packet basis and also at the connection level. For example, DNS packets exceeding 512 bytes are illegal. The signatures are configured or optimized for vehicle traffic and are designed to target and detect vehicle-related attacks. These will have low memory usage.

The anomaly-based detection block operates on the communication when well-defined rules are not available and/or as a plausibility check, and is used primarily for unknown violations. A traffic baseline is maintained using traffic patterns (learned from data or using ethDB), and deviations from the baseline trigger violations. A feedback scheme is used to learn from detection results and reduce false positives.

The log and alert management block records detected events. Some of the events will result in alerts depending on the severity and/or frequency of the event. An example alert contains selected information about the event, such as:
・Time stamp ・ID
・Importance level ・Protocol-CAN/Ethernet/IP/TCP/UDP/EthCC
・Protocol-specific ID
Data A complete log of all events in the system is kept in non-volatile memory and can be sent to the cloud, service tools and/or OBD port on request. Logs are sent via secure HTTPS.
• Integrated IDS Manager provides configuration services to allow remote clients to control IDS functions. Examples of configuration options include:
Enable or disable the IDS function Set the severity of various events to generate alerts sent to the IDS function remote collector Set rules for signature-based IDS Inclusion or exclusion of specific data sets in intrusion detection Aspects of the integrated IDS manager can be implemented externally, such as a cloud application, and/or the cloud application or other external application can selectively communicate with the integrated IDS manager to: More than one function can be supported.
• Manage IDS policies on a given vehicle • Collect IDS alerts from a given vehicle and (potentially) pass them to a selected location (eg, Security Operations Center (SOC)) for further processing.
• Provide secure access to alerts, send events and notifications to relevant stakeholders, and prompt further action.

The integrated IDS example also inspects external traffic. External traffic is traffic entering or exiting a vehicle. A firewall acting on this traffic can block all connections based on rules, but firewalls are limited by rules. Although vehicle networks are static and rules are easy to develop, it is possible that one of the ECUs (e.g. any controller, processor and/or computing device on the vehicle) could become infected with some intrusive software. , which may result in:

An infected ECU may connect to an authorized server and waste bandwidth on external network connections.

Infected ECUs and software can overwhelm cloud servers and launch DDoS attacks on the servers.

Software controls the vehicle and can be subject to ransomware-like attacks.

It can install spyware, collect in-vehicle data, and compromise occupants' privacy.

The operation of the firewall is rule-based and we do not see any unusual patterns of behavior. The IDS and firewall integration functions are complementary and both functions are essential to ensure the highest level of security.

In the medium to long term, it is conceivable that vehicles will provide services such that vehicle traffic accesses servers outside the network, so monitoring external traffic will be extremely important in such scenarios.

Table 1
Integrated IDS data/metadata example

The table above lists some of the data and metadata items collected and maintained by various protocols for intrusion detection. This table is not exhaustive and elements can be configured depending on the protocol and type of intrusion detected.

The amount of data in vehicles is growing exponentially as OEMs enhance their vehicles with advanced features and rich content. Such data needs to be temporarily or long term stored in the vehicle before being consumed or transmitted elsewhere. Unfortunately, in traditional E/E architectures, memory is embedded in the ECU and generally not accessible by other ECUs, making data sharing, protection and storage difficult. Centralized and/or distributed shared storage allows centralization of vehicle functions and hardware resources, reducing the complexity and cost of storing larger amounts of data, reducing redundancy of stored data, etc. can be reduced.

Shared network storage enables new solutions such as more efficient data collection, storage and sharing by in-vehicle apps and services, more effective data security and backup, and OTA (over the air). OEMs can benefit from lower overall memory costs, improved security and performance, and increased revenue and profits from new high-value applications and services. Customers can benefit from new data-rich features (e.g. Sentry Mode), flexible content downloads for entertainment, personal storage options (e.g. personal photos) and reduced input costs to the vehicle.

An exemplary operation of a shared storage controller is provided for illustrative purposes.

An exemplary shared storage controller includes storing vehicle status information, such as camera footage of cameras associated with the vehicle, which may be stored in a rolling data buffer. The contents of the buffer may be stored on demand (e.g., the customer receives notification that her parked car has been hit and may include prompting the customer to store the data). storage) and/or according to an event detection rule (eg, a rule indicating to store a camera data buffer in response to an impact detection while parking, etc.). In an embodiment, the customer can then obtain (and/or provide to insurers, police, etc.) data, including video recordings minutes before the impact.

An exemplary shared storage controller includes storing configuration information for ECUs in the system, eg, images of software installation updates for head units. In an example, if an ECU fails an update and the customer indicates that the vehicle's behavior is preferable to another attempt at that time, the ECU with the failed update can be reverted to a previous installation and has the update. The image is stored for installation at a later time.
In certain embodiments, the shared storage controller can delete the image with the update after a successful installation after the update for the ECU.

Exemplary shared storage controllers may, for example, store media (e.g., movie , games, music, audiobooks, etc.). In an embodiment, a request for downloaded media can be made using a user device (eg, mobile device, web application, etc.) and/or vehicle display such as a head unit. In an embodiment, passengers can then watch movies, play games, or otherwise access media without being interrupted by slow or intermittent cellular connections and/or without incurring cellular download costs. It is possible to access In an embodiment, the shared storage controller may delete downloaded media after a selected period of time based on available space, based on rules provided in configuration information and/or policies ( For example, rolling out old or least used media to make space for additional downloads, etc.).

An exemplary shared storage controller caches data for external communication, eg, collected data according to policies, event detection, and/or data collection requests, and communicates the data at a later time. Therefore, external data communication may be used, for example, to allow more efficient use of cellular communication, to take advantage of opportunistic advanced connections such as WiFi, and/or intermittent data interruptions (e.g., through tunnels). can be time-shifted to manage In certain embodiments, cached data is deleted after a later communication and/or if the cache is filled before the data is communicated, according to data priority, policy, or other considerations. can be deleted. In certain embodiments, configuration information, rules, and/or policies may compress, summarize, and/or compress certain data values to reduce data storage when the complete data cannot be communicated before the cache is filled. /or to indicate that it should be processed in some other way. In certain embodiments, unused other available data space, such as media storage space, stored configuration information space, or other available data space disclosed herein, is used for collecting data. All or part may be utilized prior to deletion, for example, to allow temporary growth of the data collection cache.

An exemplary shared storage controller stores driving behavior, vehicle performance, settings, environmental data, etc., for example, to support learning behavior to match the customer's driving style and/or to improve the performance of the ADAS system. provides storage for learning systems where large amounts of data are stored to collect and analyze In an embodiment, data can be stored until a low cost transmission network such as WiFi becomes available.

By using shared network storage, new ECU software can be further abstracted from the underlying hardware, enabling a unified architecture where vehicle applications run on a small number of high performance ECUs.

Embodiments of the present disclosure include additional user-provided memory such as secure centralized vehicle memory (optionally via expansion slots) and/or USB drives (both cost-effective and highly flexible) , including architecture. This allows the user, in embodiments, to store large amounts of data accessible from multiple sources, which may be via in-vehicle networks, external networks, and/or other interfaces.

Referring to FIG. 16, an exemplary shared storage controller is depicted, which in the example of FIG. 16 is depicted interfacing with an ECU (although the given embodiment may include multiple ECU, and/or the shared storage controller may be located in whole or in part on one or more ECUs). Exemplary shared storage controllers include in-vehicle storage servers that allow multiple applications from different ECUs to store or retrieve data to/from shared storage. Exemplary shared storage includes centralized storage such as centralized flash drives. In certain embodiments, shared storage can be distributed among multiple devices, where storage centralization is a logical rather than a physical mechanism. Nevertheless, in certain embodiments, shared storage is a physical facility, whether it is a single device or a small number of centralized devices.

A storage server is communicatively coupled to an in-vehicle network (IVN) and is capable of storing data in a selected format for well-defined file systems and/or structured data objects and structures. Exemplary file systems (eg, formatting and addressing, decisions about which data is stored where, etc.) include vehicle data, user data, and/or video files (eg, generated during surveillance operations). post-event data capture, etc.). Exemplary data objects include data collection objects (e.g., data structures that hold collected data in a selected format), machine learning data (e.g., training data, feature vectors, neural parameters, etc.), and shared resources (e.g., data caches from ECUs on the system, configuration information, policy data, and/or any other shared resource data). In certain embodiments, the storage server provides virtual partitions or physical partitions (or a combination thereof, e.g., physical partitions to ECUs with large and steady demands for storage resources to facilitate movement of storage capacity between ECUs). provide one or more dedicated partitions of shared storage, which may be used to provide virtual partitions during transient demand, uncertain demand, and/or transient operating conditions). In certain embodiments, the storage server allows for adjusting the size of partitions to reduce waste of shared storage utilized. In certain embodiments, the storage server provides a shared partition, which can be shared among all ECUs and/or subsets of ECUs (e.g., matching functionality, data format, data storage duty cycle and / or grouping of ECUs by desynchronization, etc.).

Exemplary shared storage controllers include an authentication and authorization manager, such as policies (e.g., interfaces with the policy manager), configuration information, priorities associated with ECUs, and/or flows associated with ECUs. grants or denies access to the ECU for any particular container based on In particular embodiments, the authentication and authorization manager provides access to data storage capacity based on permissions, policies, priorities, and the like. For example, the authentication and authorization manager can provide access for writing to partitions, folders and/or subfolders, files, and the like. In embodiments, the authentication and authorization manager can separate read permissions from write permissions. For example, if a high priority ECU requires increased utilization of shared storage, the increased storage may be provided if available and/or obtained from low priority shared data storage users. can be done. In certain embodiments, snapshots, backups (full or partial), and/or cached data subject to external communication may be stored in shared storage.

Shared storage can be of any size, eg, 16 GB, 32 GB, 64 GB, or any other value. A person of ordinary skill in the art with the benefit of this disclosure and the information normally available when considering a particular system can readily determine the appropriate size of shared storage. Specific considerations for determining the size of the shared storage include, but are not limited to, the number of ECUs on the system and the net storage need beyond the internal storage capacity of the ECUs, the amount of data collection to be performed on the vehicle. amount, type of data to be stored, and profile of available data communication to external devices (e.g., bandwidth, cost, and/or size and extent of low-bandwidth or high-bandwidth periods), across individual networks The distribution of ECUs, the expected amount of data traffic between ECUs on separate networks, the bandwidth available in the in-vehicle network to support network intercommunication between ECUs on separate networks, and/or data storage (e.g. media buffering, preloading, data collection, etc.) and data requirements for consumer or third party functions. Refer to Table 2 to describe typical sizes of video files.

Table 2. Typical video file size data

An exemplary operating system for the shared storage controller includes the Linux operating system, although any operating system can be used. Exemplary data services include, but are not limited to: NAS server operations including file system protocols such as NFS, SMB, and/or FTP, object stores for object-based storage, and/or database servers for storing custom database tables and indexes. Embodiments of the present disclosure may use non-relational databases, such as key/value pair databases. In certain embodiments, the shared storage controller is configured to compress data as it is ingested, which can be configured depending on the type of data (e.g., highly digitized data and/or lossless compression for data for which compression loss is undesirable and/or does not meet the requirements for data; and/or lossless compression for e.g. highly continuous/changing data where loss of information is acceptable. Such). In certain embodiments, the shared storage controller is configured to perform deep compression of cold data, e.g., data that is unlikely to be utilized by the ECUs on the system in the near future, thereby allowing the vehicle control ECU to It also relieves deep compression tasks that can be very intensive on processing and/or I/O resources. In certain embodiments, the shared storage controller is configured to encrypt data at rest. In certain embodiments, the shared storage controller is configured to age data, delete unnecessary data, and/or enforce data retention policies. An exemplary shared storage controller is configured to back up snapshot data depending on connectivity to external backup devices (e.g., cloud servers) and/or available bandwidth for communicating snapshot data. be done.

Exemplary embodiments reduce costs by allowing resources to be dedicated to centralized storage, reducing wasted storage space, and highly variable individual ECUs that must be managed with individual storage capabilities associated with each device. It provides an expansion of the effective storage capacity of all ECUs on the vehicle, both through balancing centralized storage needs to provide greater certainty of system-wide storage needs against storage requirements. Exemplary embodiments provide ease of storage capacity and performance scalability that can significantly expand a system's available storage with relatively few resources. Exemplary embodiments provide data isolation with app-specific and/or ECU-specific partitions and secure access management between ECUs. Exemplary embodiments provide centralized secure storage of data and simplification of data security management (e.g., reducing the requirement to configure and verify individual ECUs to ensure secure storage of relevant data). do.

An exemplary system includes a provisioning client used as a proxy between apps running on individual ECUs and an authentication and authorization manager in shared storage. An exemplary system includes a data client (eg, NFS, SMB, object store) for apps to use as proxies to send and receive data to and from shared storage.

The increase in advanced vehicle features coupled with pressure to reduce costs has led to a typical vehicle configuration including multiple ECUs, eg, up to 150 ECUs. Current vehicle configurations result in inefficient use of hardware with redundant capabilities in processing power, memory, and other resources, as well as high network utilization, individual application processing power and/or memory limitations. , redundant software present throughout the system, and inconsistent quality and functionality of the ECU implementation.

Referring to FIG. 17, an exemplary system supports integrating vehicle functions and control actions with a reduced number of more powerful ECUs. In addition, the exemplary system supports the transition from legacy implementations with multiple ECMs to a gradual progression toward feature integration over time over the lifecycle of the vehicle, over several model years of the vehicle. ,Such.

Containerized applications make it easy to create feature sets for different models and trim levels, update vehicle features, and even relocate applications between servers for reliability and power management. can be added to, combined with, or moved to.

With the help of container technology, container deployment is fully controlled by the cloud-side container deployment manager. A container orchestration policy is created, specifying:
- Which containers are enabled on the ECU (for use cases such as OTA, trim selection, feature subscriptions, etc.)
Container image for each container Container security policy Container migration strategy (e.g. where to run containers to save power or in case of hardware failure)

The exemplary container orchestration controller receives policies and enforces the policies by utilizing other modules below.

Container Security Controller: This module enforces access control, authorization and accounting for container execution. A container must pass access control and authorization checks to qualify for the container runtime. It also collects container execution statistics and sends them back to the cloud.

Local Container Registry: This module downloads eligible container images from cloud container registries.

Container Runtime: This module provides an Open Container Initiative (OCI) and Container Runtime Interface (CRI) compliant container runtime optimized for embedded environments.

An implementation of a containerized application is provided below. The examples are illustrative of features of particular implementations possible according to this disclosure and are not limiting.

An exemplary implementation is a containerized application downloaded (e.g., OTA) and installed on the VFAS ECU with the most available resources (e.g., CPU, memory, and/or I/O), and/or containerized Includes VFAS ECUs where application installation will provide the least restrictions on available resource constraints, as well as VFAS ECUs with sufficient resources to implement a particular containerized application. Exemplary implementations include moving already installed containerized applications and/or balancing the overall load of containerized applications among available ECUs.

Exemplary embodiments include utilizing combined containerized applications to create feature sets for different vehicle models and/or trim levels. Implementations may add or remove features and/or provide upgraded versions of features to provide upgrades to the vehicle and/or to implement control actions for new model years of the vehicle. include.

An exemplary implementation includes the act of deploying containerized applications to support specific functionality for specific users. For example, critical data collection operations can be performed by containerized applications running on the vehicle's ECU, which can process the data and provide improved data collection response (e.g., faster and/or process the data, which can provide a reduction in the amount of data communicated over limited external data communication resources. In another example, an implementation may implement actions to deploy containerized applications to support specific functionality (e.g., subscription-based functionality) and, e.g., to free up system resources, depending on subscription expiration times. and an act of removing the containerized application.

Exemplary implementations may, for example, reduce network utilization on busy or low capacity networks and/or shift utilization from low capacity networks to high capacity networks. including the step of mechanizing the distribution of containerized applications.

Exemplary implementations include energy saving modes (e.g., is deployed in electric vehicles to support (utilization) when the battery reaches a selected state of charge.

Exemplary implementations include positioning containerized applications among ECUs to distribute system risk, e.g., placing critical vehicle applications in different containers than less critical applications (e.g., to reduce potential conflicts and/or prioritize resource allocation). In another example, a critical application has redundancy (e.g., multiple ECUs) so that failure of an ECU does not cause loss of the application, as the application can run from a backup version on another ECU. exist above). In certain embodiments, critical applications are migrated from a first ECU that has a fault or degraded performance to another ECU. The migration can be on-vehicle, for example if communication with the degraded ECU can still be established, and/or the migrated containerized application can be migrated by downloading another version from a cloud server. can do. In certain embodiments, non-critical applications may be migrated, shut down, and/or allocated reduced resources in response to ECU failure and/or performance degradation.

Lightweight containers require less server resources than hypervisors and virtual machines with embedded operating systems, and require negligible additional processing or memory compared to non-virtualized applications. OEM benefits from using containers include reduced hardware costs, faster time to market for features and vehicles, reduced development costs, and increased application and system reliability.

Some of the benefits of adopting a containerized application model include:

Containers under Docker are built with a focus on microservices. This removes burdensome infrastructure layers and enables application delivery and workflow optimization.

Through container repositories/registries like Docker Hub, you can simplify the deployment process and check in/out applications to turn infrastructure into code.

Templates such as Dockerfiles make it easy to provide application blueprints and make the application rollout process transparent. This new model almost completely eliminated the need for configuration management from the infrastructure and application pipeline overnight.

Significantly reducing the footprint of application environments significantly shortens the test/validation/deployment cycle of software development, and these lightweight containers are dynamically scalable microcontrollers where applications are broken down into smaller, atomic units. It has become useful for the realization of the service model.

Since container images are decoupled from their traditional heavyweight host OS, they are highly portable and can run in any container runtime environment that supports them. This allows for true hybrid deployment capabilities.

However, managing a container-based infrastructure required a completely different way of working, and the workflow often defied longstanding conventions, making the adoption of containers a challenge for traditional applications like automotive control implementations. became. In addition, there are the following issues for the introduction of containers.

End-to-end control of the operational environment can be a problem, as the rich ecosystem of infrastructure management tools developed over decades hardly applies to the container-based world.

Key data center resources that normally require tight management, such as network and storage endpoints, are abstracted and have limited control.

HA/redundancy has moved from monolithic architectures to horizontally scaled software driven platforms. This moved control from operations to the hands of developers.

Most hypervisors and virtualization platforms have powerful commercially supported options. However, the container world (and its associated ecosystem) is largely rooted in the "DIY", open source world and is continually evolving.

As the container ecosystem works with developers, their configuration matches their worldview, with API calls, configuration files written in declarative YAML or JSON templates, repositories, CI/CD It includes concepts such as integration with workflows. These concepts are not common in the traditional world of operations and require an entirely different approach and skill set to manage. Even within the IT industry, this continues to be a significant challenge.

Referring to FIG. 18, an example of workflow changes in container-based application development and traditional virtualization-based development is depicted for illustrative purposes.

Containers decouple in-vehicle software from hardware, allowing it to more easily allocate available hardware resources and develop independently of other software that may share resources.

For example, as shown in the diagram below, a containerized application environment allows deployment of different applications based on different trim vehicle levels on the same hardware platform.

Referring to FIG. 19, an example of comparing vehicle trim levels in containerized application development

This benefits OEMs by reducing development costs, optimizing hardware costs, accelerating application deployment and improving time to market. Customers will also benefit from vehicles with more features, greater reliability and post-purchase upgrade options. However, there are many issues to be addressed in moving vehicle applications to container-type application development.
・Container runtime optimized for embedded environments ・Container orchestration optimized for embedded environments ・Virtual network bridges for containers to integrate with entire in-vehicle network management solutions ・Private containers for safety and security ・Registries AUTOSAR Adaptive extensions and enhancements to support containers ARA::COM integration for containerized applications ARA::EM to manage containerized applications
ARA::UCM to upgrade/update containerized applications ARA::LT to support logging and tracing of containerized applications

Referring to FIG. 20, an exemplary architectural implementation for container-based applications on vehicles is schematically depicted. The example architecture of FIG. 20 improves workflow when multiple vendors are involved in ECU development. A container provides a clean separation between its functional modules. Suppliers are free to choose the middleware that best suits their interests, either AUTOSAR Adaptive or ad-hoc middleware.

Referring to FIG. 21, an alternative architectural implementation for container-based applications on vehicles is schematically depicted. In the example architecture of Figure 21, the functionality is self-contained within the container, providing at least two distinct advantages. First, features can be easily upgraded individually with zero downtime impact on other features. Second, the feature set can be easily extended or customized for different vehicle trims/levels. For example, the diagram below shows how to customize a full trim vehicle to an intermediate trim. All that is required is a simple change to the Container Orchestration Policy that determines which containers are enabled.

Each container can choose to either implement all middleware functions using AUTOSAR Adaptive or use ad-hoc middleware such as SOME/IP, DBus, Systemd. The decision should be made on a case-by-case basis, based on the coupling of container functionality and AUTOSAR Adaptive.

Additionally, each functional container can have a container manifest associated with it, which is defined and managed by the OEM. The manifest dictates the amount of resources (eg, CPU/memory) to allocate to the container, and also determines the privilege level of the container (set through the AppArmor profile).

Below is a deep dive into the container for data collection to help explain AppArmor and all the middleware components.

Referring to FIG. 22, a schematic diagram of certain details of the container is depicted.

Finally, containers bring additional challenges to infrastructure. As the number of containers in a vehicle increases, managing IP addresses and ensuring connectivity between containers becomes a significant and difficult task. The traditional approach of statically assigning IP addresses to each container does not scale under these circumstances.

Implementations include all containers dynamically joining the same network to facilitate SOA. Logically, each container runs like an individual ECU directly connected to a virtual Ethernet backbone.

Referring to FIG. 23, an example container networking implementation is schematically depicted.

This new virtualized network needs to adapt the network configuration as containers join or leave the network, allowing new containers to connect with other containers. This requires several new technologies such as MAC learning, Dynamic ARP, IgmpSnooping, DHCP and their security support. These new networking technologies are enabled by the advanced network management of embodiments of the present disclosure.

AUTOSAR Adaptive defines interfaces and organizes responsibilities in each module to provide a runtime environment for applications.
• ara::exec defines runtime responsibilities including:
• A functional group is a collection of applications that have independent states.
• Execution dependencies define the order in which programs are started to ensure that one process starts after the processes it depends on.
• Execution dependencies are defined for each functional group so that failure of one functional group does not affect other functional groups.
• Application lifecycle • Resource limits • ara::per provides storage and file proxies for Key-Value pairs that can be used by applications.

However, AUTOSAR Adaptive is designed to support legacy applications on POSIX-compliant operating systems, not containerized applications. In the working configuration, we extended and enhanced support for containers.

The container on top of AUTOSAR Adaptive provides isolation enforcement for adaptive applications. The Adaptive Platform proposes guidelines for making applications portable, but does not specify an OS-level architecture to achieve proper isolation. An example implementation utilizes Linux namespaces to allow a process and its child processes to have different views of the underlying system. As an implementation configuration, OS-level virtualization is applied to the adaptive platform.

Container functionality is implemented in the form of plugin libraries, and platform applications (eg, execution manager clusters) can enable functionality.

Table 3. Example of OS level separation function list

Referring to FIG. 24, an AUTOSAR adaptation example of functional state groups is schematically depicted.

AUTOSAR Adaptive defines a Function Group, which is a collection of applications. Depending on the functional group state, the application is started or terminated.

An application process can belong to more than one Function Group.

The set of Function Group States is machine specific and deployed as part of the machine manifest.

Function group 1 (FG1) and function group 2 (FG2) have independent states and can be executed simultaneously. No execution dependency is set between them.

FG1 defines the Function Group State as {Off, Running}.

FG2 defines the Function Group State as {Off, Running, Fallback, Diag}.

The state manager (ara::sm) functional cluster requests the execution manager (ara::exec) to transit the Function Group State.

Function Group State is defined in the Execution Manifest (included in the software package)

The container isolation function (namespace) is set for each function group. The sequence diagram below illustrates how container functions are enabled as part of the AUTOSAR Adaptive Function Group States.

Referring to FIG. 25, a functional flow for enforcing container policies is schematically depicted.

A container manager implements OS-level isolation features (eg, namespaces) and manages policies.

The ECU downloads and executes a policy that specifies a list of applications to configure and container features to enable. Policies can be different for each vehicle or group of vehicles, and policies can apply to both initial installation and subsequent policy updates. Referring to Figure 26, an embodiment of a container manager is schematically depicted.

Container policy:

accessible file system directory

range of uid/gid mappings

Resource allocation

Isolation function enable/disable function

Monitoring/Auditing:

resource usage

Application health monitoring

Application error detection

The AUTOSAR adaptive execution manager is integrated with the container plugin library.

AUTOSAR adaptive persistence is integrated with the container plugin library.

The AUTOSAR adaptive update and configuration manager is integrated with the container plugin library.

Deploying and managing containers requires cloud components.

Referring to FIG. 27, an exemplary apparatus 2700 for enforcing policies based on driver behavior and/or driver monitoring for a vehicle (or selected group of vehicles) is depicted. Exemplary apparatus 2700 may be included, in whole or in part, in any system, apparatus, and/or device described throughout, and aspects of apparatus 2700 may be defined in any manner throughout this disclosure. All or part of the acts, procedures, methods, and/or functions may be implemented. Aspects of the device 2700 can be on the vehicle, on any controller of the vehicle (e.g., CEG, CES, CND, and/or any controller and/or endpoint of the vehicle), external to the vehicle (e.g., cloud server or on a computing device, on an external computing device such as a service tool, a manufacturing tool, an OEM tool, a service device, an administrator, a service, an operator, an owner, an external user device such as an application), and/or any of these On a device that interfaces with - physical access to a network (e.g. LAN, dedicated network, etc.), port (e.g. OBD port, service port, CAN connection, Ethernet port, etc.), wireless access to vehicle, cloud or internet on a device that interfaces with any of these, either through a connection and/or through a cellular connection to the vehicle. Exemplary apparatus 2700 includes controller 2702 and is depicted as a single apparatus for purposes of illustration, but may be a single apparatus or distributed devices. The description of device 2700 depicts a number of circuits configured to functionally perform the operations of device 2700 . Although each circuit is depicted as a single device for clarity of illustration, a given circuit may be distributed among devices and/or combined in whole or in part with other devices. can.

Circuits, controllers, computing devices, modules, engines, configurable switches, configurable gateways, convergent network devices, managers, evaluators, authors, applications, and the like, without limiting other aspects of this disclosure. Exemplary embodiments of devices described throughout this disclosure that include the term: any sensor present on the vehicle and/or communicative coupling to any such sensor (e.g., sensor present on the vehicle, and/or communicative couplings to such sensors (electrical interfaces, LIN interfaces, A/D processing of sensor signals, etc.), actuators present in the vehicle, and/or communicative couplings to such actuators (electrical interface, LIN interface, command interface to actuator, feedback interface from actuator, etc.), controller on vehicle, computing device, cloud server, external device, etc., any one or two or more devices, or those devices instructions stored on a computer-readable medium, whereby the computing device that executes the instructions is the device's and/or accessing one or more of any of these (e.g., accessing parameters from controller memory values, commanding controller memory values values) or indirectly (e.g., accessing parameters on the vehicle network zone, providing command values to controllers on the vehicle network zone, sending requests or commands to the vehicle's controllers, accessing parameters, sending commands, implementing interfaces to configure functions, sensors, actuators, and/or control operations, etc.).

Exemplary apparatus 2700 includes policy retrieval circuitry 2704 configured to interpret vehicle policy data values 2710 including driver information description 2712 . Exemplary vehicle policy data values 2710 are, for example, policies provided to a vehicle, parsed portions thereof (e.g., provided to and/or made available to device 2700 ) as described throughout this disclosure. processed policy, etc.) that has portions of the policy associated with device 2700 . Without limiting other aspects of this disclosure, vehicle policy data values 2710 may include data collected from the vehicle, features that are enabled or disabled on the vehicle, configuration of feature parameters (e.g., setpoints, operator-configured possible range, enforced minimum or maximum values, display settings, data collection time range, sampling rate, amount of storage, etc.), and/or trigger conditions for any of the foregoing (e.g., data collection, function adjustment, etc.). are data values, events, thresholds, etc.) on which actions are performed in response to them. Driver information description 2712 includes driver role (e.g., part-time, full-time, employee, contractor, commercial license type, owner, etc.), driver identifier (e.g., identification of a identification of belonging to a group, identification of a driver's classification, etc.) and/or driver state values (e.g. driving in a certain number of hours into a driving event, a certain fuel economy performance value with a certain driver performance value or category). or having categories, etc.). Vehicle policy data values 2710, including driver information description 2712, provide adjustment of data collection and/or monitoring parameters according to a range of driver-related conditions that may be of interest, including driver type, driver past performance, driver It will be appreciated that it allows configuration of features, changes in monitored values, changes in data collection behavior, etc., based on any selected driver criteria, such as events detected in connection with the . Vehicle policy data values 2710, including driver information description 2712, may also utilize monitoring, configuration, and/or data collection actions for a given driver regardless of vehicle, e.g., when the driver switches vehicles. It can be seen, however, that it allows the vehicle to be configured for driver preferences, data monitoring, display values, and the like. In certain embodiments, vehicle policy data values 2710 automatically collect, monitor, and configure actions without introducing new policy information, for example, when driver roles or other generic driver information descriptions are utilized. - for example, if the device 2700 is configured to perform one set of actions for the "owner" driver and another set for the "operator" driver. is. In certain embodiments, vehicle policy data values 2710 may be retrieved from external devices (e.g., cloud servers, port, WiFi, etc., and/or driver-related devices such as mobile devices carried by the driver) to allow collection, monitoring, and /or configuration of configuration operations is enabled. In certain embodiments, driver-specific data may be retained after the driver switches to another vehicle (e.g., retaining historical, performance, and/or other individualized data about the vehicle) - e.g. , can be retained to allow for the reduction of data collected from vehicle policy data values 2710 when the driver returns to the original vehicle. In certain embodiments, the driver-specific data is deleted immediately after the driver switches to another vehicle and/or is stored for a period of time, selected for a selected period of time, event, when the driver uses another vehicle. It can be revoked after confirmation, etc. Configurations such as whether to retain, delete, migrate to another vehicle, store on a cloud server, and/or expiration criteria for such data can be specified in vehicle policy data values 2710. may be included.

Exemplary apparatus 2700 includes policy processing circuitry 2706 that generates parsed policy data including vehicle data collection description 2714 in response to, and at least in part based on, vehicle policy data values 2710 . A description that utilizes parsed policy data indicates that the policy herein defines parameters to be collected, storage allocations for collected parameters, transmission resource allocations for collected parameters, priorities for collection operations. utilization of in-vehicle network resources; utilization of off-vehicle transmission resources; processing resources (e.g., to configure and/or provide parameters; to process and/or format parameters; storage resources (e.g., resources for Collected Data, intermediate processing data associated with Collected Data, and supporting data such as trigger evaluation data, short-term historical data, etc., for expiry processing such as behavior (if applicable)) , cache storage, buffer storage, rolling buffer storage, and/or shared storage resources) usage. The parsed policy data is parsed for the vehicle (e.g., to determine the parameter names specified for collected data, endpoint locations, sample rate, units, format, etc.) to provide response data, and The portion of the vehicle policy data value 2710 that is provided to or made accessible to vehicle endpoints that perform support operations, process data, and/or store data. In particular embodiments, policy processing circuitry 2706 determines how collected data is formatted based on requested data criteria (eg, sampling rate, units, metadata, etc.) and available response data on the vehicle. Decide if it will run. In certain embodiments, policy processing circuitry 2706 manages conversions between external data requests made (eg, "ambient temperature") and data on the vehicle in response to the external data requests made— For example, it enables successful operation regardless of the configuration of network zones and/or endpoints on the vehicle, versions of parameters, controls, or interfaces on the vehicle, and the like. In certain embodiments, the policy processing circuit 2706 may, for example, detect changes in vehicle configuration (e.g., endpoints move from one network zone to another network zone, parameter names change on the vehicle's controller, update the parsed policy data in response to changes in the format of the parameters in (e.g., using different units, bit depths, resolutions, sampling rates, etc.) and/or changes in the parameter source (e.g., the first A parameter provided by a controller is now provided by a second controller, and/or non-nominal conditions such as sensor failure, fault conditions, etc. cause the parameter source to change)—these are, in certain embodiments, It can run without updates to vehicle policy data values 2710 . For example, a policy passed to a vehicle results in first parsed policy data at a first time and second parsed policy data at a second time, without modification of the passed policy to the vehicle. may bring In an embodiment, both the first parsed policy data and the second parsed policy data may depend on the policy passed to the vehicle, but the performance on the policy may vary (e.g., if the second source of parameters is inferior or superior to the original source in some way). In a further example, the second parsed policy data may not be fully compliant with the policy passed to the vehicle—e.g., if the requested parameters are no longer available. Such as when the requesting entity that provides at least the part no longer has sufficient authorization.

The operation of the policy processing circuit 2706 and the implementation of the policy passed to the vehicle--whether parsed policy data or another implementation is utilized is not specific to the device 2700 and is the entirety of this disclosure. Any device referenced through can perform similar implementation operations, including any device that performs any one or more of the following: Prepare vehicle endpoints to receive and/or process policies passed to the vehicle, support data collection, data collection support, trigger evaluation, memory operations, feature configuration, send operations, and/or automated operations. data types, associated flows, associated applications, associated vehicle functions, Collected Data requesting and/or providing endpoints, Collected Data processing, Collected Data storage, and/or Collected Data transmission. or to determine a priority value for provision. The description of FIG. 27 is provided in the context of policies passed to vehicles for clarity in illustrating certain aspects of the disclosure. In particular embodiments, the concepts represented by vehicle policy data values 2710 can additionally or alternatively be any type of policy, data request, automatic action value, trigger, or policy, as understood in the particular context. It may also be referred to as a descriptive value, actuator command value, remote access request value, or similar terms.

The example apparatus 2700 configures one or more of at least one network zone of the vehicle (eg, first network zone 2718 and second network zone 2720 in the example of FIG. 27) depending on the parsed policy data. includes policy enforcement circuitry 2708 configured to collect vehicle data 2722 from endpoints 2716 of the . Exemplary policy enforcement circuitry 2708 provides vehicle data 2722 collected in response to vehicle policy data values 2710, which is stored, transmitted, and utilized to determine whether a triggering event has been detected. (eg, to trigger further data collection, automated responses, changes in data collection parameters, etc.) or other actions described throughout this disclosure.

The exemplary apparatus 2700 includes endpoints 2716 located on at least two different network zones of a vehicle (eg, endpoints that provide data for collection and/or in response to activation commands of vehicle policy data values 2710). endpoints). The example driver information description 2712 may, for example, describe the current driver information to adjust the vehicle policy data values 2710 in response to the vehicle's current driver characteristics and/or to perform collection actions in accordance with the vehicle policy data values 2710 . Includes driver characteristics that are compared with information 2714 (eg, describing driver role, driver identification, driver history and/or performance data, etc.). The example policy enforcement circuitry 2708 interprets the current driver information 2714, compares it to the driver characteristics of the driver information description 2712, and collects vehicle data 2722 in response to the comparison—eg, parameters collected in response to the comparison. , the features configured, the format of the collected data, etc. Exemplary driver information descriptions 2712 include descriptions of monitored data for the driver of the vehicle--e.g., monitor parameters (e.g., speed, location, feature utilization, driving performance parameters, etc.) to the driver's role, specific identification, etc. and/or to match the characteristics of any other driver.

Referring to FIG. 28 , exemplary driver information description 2712 includes trigger conditions 2806 and policy enforcement circuitry 2708 collects vehicle data 2722 based on trigger conditions 2806 and/or driver characteristics 2802 . The vehicle data collected in response to trigger condition 2806 may be specified vehicle data 2804 provided in vehicle data collection description 2714 . For example, trigger condition 2806 may indicate an event or data value that causes vehicle data 2804 to be collected in response to, for example, a high speed event, a high acceleration event, extended operation of the vehicle, detection or diagnostic value of a fault condition, and the like. The use of trigger conditions 2806 and/or driver characteristics 2802 may also depend on the activity of interest on the vehicle, as well as years of experience, driver role, driver location (e.g., home location, current location, driver's license location). etc.) to collect data according to driver characteristics. Exemplary, non-limiting trigger conditions 2806 include event detection conditions (e.g., parameter values indicating that an event has occurred and/or processed parameter values), driver characteristic values (e.g., driver state, activity time, or data collection in response to changes in driver conditions, such as changing conditions), driver classification values (e.g., license type, performance index, experience index, ownership type, etc.), and/or driver performance values (e.g., efficiency performance, safe driving performance, function usage performance, etc.). In certain embodiments, collected vehicle data 2722 includes collected data in response to a determination of an event occurrence based on a comparison of some of the collected data values to trigger conditions 2806 .

Referring to FIG. 29, an exemplary procedure 2900 for collecting data in response to a driver information description is schematically depicted, for example to provide driver monitoring and/or collection of data based on driver characteristics. . Exemplary procedure 2900 includes an act 2902 of interpreting a vehicle policy data value that includes a driver information description and an act 2904 of generating a vehicle data collection description in response to the vehicle policy data value. Exemplary procedure 2900 further includes an act 2906 of collecting vehicle data from endpoints of the vehicle in response to the vehicle data collection description. Collected data can be stored and used to determine whether a trigger condition has been met and/or an event has occurred, and can be used by external devices (e.g., vehicle policy data values or relevant portions thereof). (associated with the providing entity and/or application), and/or can be revoked according to vehicle policy data value criteria.

Referring to FIG. 30, an exemplary procedure 2906 for performing collection actions in response to vehicle policy data values and/or driver information descriptions is schematically depicted. Exemplary procedure 2906 includes operation 3002 of determining whether a trigger condition is met, and in response to operation 3002 determining YES, procedure 2906 initiates and/or adjusts data collection operations. and an operation 3004 to perform. In response to operation 3002 determining 'NO', procedure 2906 stops data collection, continues data collection with the previous configuration (eg, does not change collection behavior), and/or checks for trigger conditions. (eg, return to operation 3002).

Referring to FIG. 31, an exemplary system for providing data collection actions in response to vehicle policy data values including starting, modifying, and/or stopping data collection actions based on fault codes from devices on the vehicle. A device 3100 is depicted. Statements herein that refer to fault codes are broadly understood and include actions based on: fault code values (e.g., provided by associated devices such as sensors, actuators, etc., determined by control actions) and/or determined from other parameters such as diagnostic algorithms, plausibility checks, comparisons with other data values), fault counters (e.g. data used for fault determination, such as incrementing or decrementing counters) management), diagnostic values (e.g., outputs of diagnostic actions such as "PASS", "FAIL", "SUSPECT", etc.), and/or diagnostic actions are turned off even if they have not yet diagnosed a fault. Intermediate values that may indicate having a preliminary indication of normal operation and/or diagnostic operation may return to normal even though diagnostic operation has not yet determined that off-normal operation has ceased. and/or a diagnostic trouble code (e.g., an industry standard code, a proprietary code, or a diagnostic trouble code, which may be any other diagnostic trouble code); parameters used to indicate events and/or states).

Exemplary device 3100 includes device state description 3102 that indicates, for example, which fault and/or diagnostic parameters and/or which device to utilize to start, modify, and/or stop data collection operations. Further included is policy acquisition circuitry 2704 for interpreting vehicle policy data values 2710 . Exemplary apparatus 3100 operates similarly to apparatus 2700 and determines parsed policy data in response to vehicle policy data values 2710 and device state description 3102, for example. Exemplary apparatus 3100 enables configuration of data collection actions in response to any device in the system, such as any endpoint, sensor, actuator, control action, etc., and generally collects data in response to failure activity. Tailor collection (e.g. collect specified data each time a fault occurs and/or from a group of faults of interest) and/or specific fault activity (e.g. Collecting specific data associated with the failure to determine the root cause of the failure, e.g., to determine whether highly correlated failures have also occurred and/or are likely to occur in the near future. to collect information and/or to capture historical information prior to failure occurrence). Operation of the device 3100 is to generate knowledge related to vehicles and/or groups of vehicles to support alternate actions (eg, determine whether to utilize alternate data values, control actions, etc. in response to failure occurrence). To assist (e.g., accumulate collected data with data from other vehicles and/or previous occurrences of failures in the current vehicle to improve design, improve failure predictiveness, and/or and/or for other purposes (e.g., warranty enforcement and/or response, alerts to operators, service personnel, fleet owners, and/or or to provide notifications, etc.).

Exemplary device state descriptions 3102 include descriptions of vehicle data collected based on at least one of device fault values or device diagnostic values (e.g., when fault or diagnostic values become active, become inactive, Collecting data as the counter value begins to increment, decrement, or reaches a selected value, etc.). Utilization of device state description 3102 provides responsive activity for fault or diagnostic values, e.g., data collection for fault values based on the time since the fault value was last activated and/or last deactivated. responsive actions to fault value collection (e.g., starting data collection when 3 fault values in a selected group of 20 fault values are activated), and/or fault or diagnostic values are cleared; Allows for responsive activity to intermediate values utilized in fault and/or diagnostic operations, such as counters, threshold comparisons, etc. that may indicate activity before it is confirmed or the like.

In particular embodiments, vehicle data collection descriptions 2714 include descriptions of vehicle data determined in response to vehicle policy data values 2710 and collected based on criteria within vehicle policy data values 2710 . Vehicle policy data values 2710 may collect data related to the device associated with device condition description 3102, but additionally or alternatively collect data related to any other device on the vehicle. be able to. For example, the device 3100 may capture vehicle speed data associated with a failed speed sensor (eg, the output of the speed sensor whose vehicle speed data failed, and/or other relevant data such as the voltage supply to the speed sensor). and/or other data not related to the failed speed sensor (e.g., current gear of the vehicle, power values across the vehicle's systems, multimedia activity data, etc.) , may be configured to collect that may be utilized in any manner as described. Examples of descriptions of monitoring data include failure state values; failure count values; diagnostic parameter values; failure confirmation values; diagnosis confirmation values; contains at least one data value of

Referring to FIG. 32, an example monitoring data description 3201 utilized, for example, in device 3100 provides device fault and/or diagnostic values 3202, which may be for the device in device status description 3102 or for another device on the vehicle. include. The example of FIG. 32 includes a vehicle data collection description 2714 having vehicle data 2804 for collection, and the example also has monitoring data 3204, eg, associated with the device in the device state description 3102 or another device of the vehicle. In certain embodiments, monitoring data 3204 and/or collection actions are responsive to trigger conditions, eg, as described in connection with FIG.

Referring to FIG. 33, an exemplary procedure 3300 for implementing policies responsive to fault and/or diagnostic values for devices within a vehicle system is schematically depicted. Exemplary procedure 3300 includes an act 3302 of interpreting a vehicle policy data value that includes a device state description, and an act 3304 of generating a vehicle data collection description in response to the vehicle policy data value. Exemplary procedure 3300 further includes an act 3306 of collecting vehicle data from the vehicle's endpoints in response to the vehicle data collection description.

Referring to FIG. 34, an exemplary embodiment of providing data collection actions in response to vehicle policy data values including starting, modifying, and/or stopping data collection actions based on endpoint performance descriptions for vehicle endpoints. A device 3400 is depicted. For example, the operation of the device 3400 may be determined based on endpoint capabilities, changes to endpoints, and/or endpoint performance, such as configuration of the vehicle (e.g., whether the vehicle is provided in a particular configuration). The ability of a sensor or actuator to provide an indication—for example, the presence of a particular sensor and/or the output value or resolution provided by the sensor indicates that a particular vehicle configuration, feature set, performance rating, etc. is present in the vehicle. (which may be indicated) allows selective data collection, as well as adjustment of the collected data.

Exemplary apparatus 3400 includes policy acquisition circuitry 2704 that interprets vehicle policy data values 2710 that include endpoint performance descriptions 3402, and parsing that includes vehicle data collection descriptions 2714 based at least in part on vehicle policy data values 2710. and policy processing circuitry 2706 that generates the finalized policy data.
Device 3400 otherwise operates similarly to devices 2700 and 3100 .

Referring to FIG. 35, an exemplary endpoint performance description 3402 includes conditions that indicate vehicle configuration (eg, network zone placement; endpoint locations on network zones; parameter names and/or formats available on the vehicle); and endpoint conditions indicating which vehicle configurations are active, such as functions, applications and/or flows active on the vehicle), conditions indicating off-nominal behavior (e.g. data values and/or ranges, parameter availability , fault and/or diagnostic codes, values provided by endpoints that may indicate that an out-of-nominal condition exists, such as a match between expected and observed values based on vehicle operating conditions), and/or one or more of the vehicle Conditions that indicate the configuration of two or more endpoints (e.g., where values from endpoints such as data values, status values, network address values, endpoint identifiers, endpoints and/or one or more other An on-vehicle configuration of an endpoint, where the configuration is a function, application or flow associated with one or more endpoints, the location of control actions on one or more endpoints, one or more data. endpoint status values 3502, such as the presence or absence of a value, the network zone and/or the location of the endpoint on the network zone, the format of the data values available on the vehicle, etc.; Exemplary apparatus 3400 includes vehicle data collection description 2714 generated from endpoint performance description 3402 and includes collected vehicle data 3516 generated in response to endpoint performance description 3402 . Exemplary and non-limiting examples of vehicle data for collection 2714 include endpoints and/or endpoint groups 3504 (e.g., endpoint locations for which data is to be collected depending on the performance state of the endpoints in endpoint performance description 3402). , sources for parameters, and/or endpoints of interest), collect data values 3506 (e.g., values of interest based on performance descriptions, validation and/or validation values, utilized to diagnose and/or predict performance changes). and/or results of endpoint performance, values for determining mitigation actions for endpoint performance, and/or determining whether associated endpoints, applications, flows, etc. were impacted by endpoint performance. format and/or processing description 3508 of collected data (e.g., as follows: formatting and/or processing operations to be performed depending on endpoint performance, e.g. sampling rate, data resolution, bit depth , where units, parameter names, metadata, etc. are adjusted based on endpoint performance); collection data storage description 3510 (e.g., to increase the likelihood that relevant data will persist until transmission becomes available; Increase memory allocation to deprioritize data collection according to endpoint performance exhibiting nominal or expected behavior and/or to store data for later access by service tools or other behavior and/or decrease, change storage priority, change data expiration time, etc.); collected data transmission description 3512 (eg, as follows: increasing and/or decreasing transmission priority, selected timeframes); moving data within (e.g., expediting transmissions depending on endpoint performance and/or changing data transmission limits, such as data caps or bandwidth limits, depending on endpoint performance); and/ or to change the priority value of the collected vehicle data 2722 according to the collected data priority value 3514 (e.g., which requires at least processing resources, transmission resources, memory resources, bandwidth resources, data (which can be utilized in any manner as described throughout this disclosure, including determining deadline management, data processing management, etc.).

Exemplary endpoint performance description 3402 includes a first data value collected in response to the target endpoint being in a first state and a first data value collected in response to the target endpoint being in a second state. contains a second data value that The use of the first condition and the second condition can be at least the type of endpoint, the state of the endpoint (e.g., nominal, pass, fail, suspect, etc.), and/or the vehicle's identity as indicated by the state of the endpoint. allows the data collected to be varied based on any state of the endpoint, including aspects of The example apparatus 3400 includes a target endpoint in a first state representing a first vehicle configuration and a target endpoint in a second state representing a second vehicle configuration. Exemplary apparatus 3400 displays the target endpoint in a second state indicating that the target endpoint has been determined to be in an abnormal state, such as a failure state, fault state, non-responsive state, and/or loss of communication state. Contains endpoints. The example apparatus 3400 indicates that the target endpoint in the first condition indicates a first target endpoint configuration (e.g., sensor type, actuator type, associated application version, flow, and/or control action, etc.); If the target endpoint in condition 2 includes the second target endpoint configuration, then the target endpoint includes the first target endpoint configuration. The first data value includes data collected from the first endpoint group (e.g., the target endpoint in the first condition indicates that the vehicle data collection description 2714 is in the parameter group from the first endpoint group). (which may or may not include a target endpoint), and the second data value includes data collected from a second group of endpoints (e.g., target in a second condition). endpoint indicates that the vehicle data collection description 2714 is directed to the parameter group of the second endpoint group, which may or may not include the target endpoint). In certain embodiments, the first endpoint group and the second endpoint group can include one or more or all of the same endpoints, and the first endpoint group and the second endpoint group Differences with endpoint groups are limited to overall parameter selection for collection from each endpoint group. In certain embodiments, and endpoint groups (e.g., first endpoint group and/or second endpoint group) can include a single endpoint - such as, but not limited to, multiple A smart controller that manages sensors, actuators, and/or control actions is such that the parameters represented by the first group of endpoints and/or the second group of endpoints are all available from a single smart endpoint. can do. can have multiple parameters. In certain embodiments, the first endpoint group and the second endpoint group have at least one different data value for collection (e.g., the data value for collection from the first endpoint group is have at least one different value than the data values for collection from the second endpoint group). In certain embodiments, the first endpoint group and the second endpoint group comprise at least one different endpoint (e.g., the endpoints that make up the first endpoint group have at least one different endpoint from the endpoints that make up the group). In certain embodiments, the difference between the first group of endpoints and the second group of endpoints may additionally or alternatively be data values or dimensions other than endpoints, such as priority values, format values, It exists in process values, sampling rates, etc.

The embodiments of FIGS. 34-35 are described, for purposes of illustration, in terms of data collection operations in response to endpoint performance descriptions. Additionally or alternatively, the operation of the device 3400 is responsive to endpoint performance descriptions to determine one or more of: feature parameters; enabling or disabling features; starting and/or stopping data collection; One or more of the actuator activations can be adjusted.

Referring to FIG. 36, an exemplary methodology 3600 for performing operations for adjusting data collection in response to endpoint performance descriptions is schematically depicted. The exemplary procedure 3600 includes an operation 3602 of interpreting a vehicle policy data value in response to an endpoint performance description and an operation 3604 of generating a vehicle data collection description--eg, based on policy data parsed from the vehicle policy data value--. including. Exemplary procedure 3600 further includes an act 3606 of collecting vehicle data from vehicle endpoints in response to the vehicle data collection description.

Referring to FIG. 37, an exemplary apparatus for providing data collection operations in response to location descriptive values including starting, modifying, and/or stopping data collection operations based on location values associated with a vehicle. 3700 is drawn. For example, operation of the device 3700 may be based on the location of the vehicle--eg, within a geographic region, within a jurisdiction, relative to a designated location, and/or within defined boundaries--based on selected data collection. , and/or enable adjustment of collected data. In certain embodiments, it may be desirable to adjust data collection behavior based on location—e.g., collect additional data, avoid collecting certain data, change the format and/or other configuration of collected data. , changes in transmission criteria (eg, to reduce transmission utilization and/or allow additional transmission utilization, etc.). Exemplary differences between locations that may be associated with data collection operations include, but are not limited to, differences in transmission resource availability, differences in vehicle service availability, parameter names, units, industry standards, or other Differences in practice, differences in reliability (e.g. where it is known that geographical regions lead to differences in reliability due to changes in e.g. ambient conditions, road conditions etc.) and/or artificial intelligence and/or machine learning determined by the components and may show differences in reliability between locations without necessarily knowing the reasons for the differences), differences in contractual obligations for locations, differences in warranty practices for locations, (e.g. allowing the use of certain features such as speed limits, weight limits, cruise control, engine braking, autonomous driving) and/or location-based data itself (e.g. various privacy laws, liability laws, emissions regulations, tracking and/or reporting, etc.). The use of variable location data collection accordingly supports many purposes. Those skilled in the art, having the benefit of this disclosure, and the information generally available in contemplating a particular system, including a system with device 3700 included therein, will find location description values 3702 of interest, and location description values 3702 to be: Adjusting the vehicle data collection description 2714 accordingly can be readily determined.

The embodiments of FIGS. 37-38 are described with respect to data gathering operations in response to location description values 3702 for illustrative purposes. Additionally or alternatively, the operation of the device 3700 is responsive to the location description values 3702 to determine feature parameters; enable or disable features; start and/or stop data collection; One or more of the actuation of the actuators can be adjusted.

Exemplary apparatus 3700 includes policy acquisition circuitry 2704 that interprets vehicle policy data values 2710 that include location description values 3702 and parsed vehicle data collection descriptions 2714 based at least in part on vehicle policy data values 2710 . and policy processing circuitry 2706 that generates policy data. Exemplary apparatus 3700 includes policy enforcement circuitry 2708 that collects vehicle data (eg, provided as collected vehicle data 2722) from vehicle network zone endpoints 2716 in response to parsed policy data. An exemplary implementation of the device 2700 is to capture data selected based on the location description values 3702, stop collecting data selected based on the location description values 3702, and change the source of the collected data. (e.g. which endpoint provides a particular data value - e.g. a change in which sensor provides the value, a change from a directly sensed value to a virtually determined value, a 1 to data value or collection of values that avoid or enable the use of more than one network zone, and/or collection of values that avoid or enable the use of one or more vehicle features, flows, applications, etc.), location description values. adjusting collection parameters based on 3702 (e.g., sampling rate, format, units, units, applications, etc.; adjusting sampling rate, format, units, bit depth, etc. based on location description values 3702; and/or , to adjust the storage and/or transmission criteria for collected vehicle data 2722 . In certain embodiments, device 2700 additionally or alternatively adjusts feature configurations, enables or disables features, adjusts trigger evaluation behavior, and /or may be utilized to coordinate storage and/or transmission operations for at least a portion of the vehicle data 2722 collected.

Referring to FIG. 38, exemplary, non-limiting location description values 3702 may include geographic location values (eg, GPS location information and/or “UNITED STATES”, “CANADA”, “CALIFORNIA”, “GERMANY”, Category information such as "EU COUNTRIES", "RURAL HIGHWAY", "POPULATION CENTER"), jurisdiction values (e.g., specific jurisdictions such as "FRANCE", and/or "EURO 6 EMISSIONS LOCATION", "PRIVACY RULE 2 LOCATION" ", relative location values (e.g., distance from a point, region, boundary, etc.), and/or defined geographic area values (e.g., "DELIVERY ROUTE 25", within or outside a defined region, etc.). ), including one or more of The example of FIG. 38 includes a vehicle data collection description 2714 having one or more collecting vehicle data 3516 values corresponding to one or more of the location description values 3702 . Exemplary collected vehicle data 3516 values include the endpoints or endpoint groups utilized 3504, collected data values 3506, collected data format and/or processing descriptions 3508, collected data storage descriptions 3510, collected data transmission descriptions 3512, and/or one or more of the collected data priority values 3514.

Referring to FIG. 39, an exemplary procedure 3900 for adjusting data collection depending on location description values is schematically depicted. Exemplary procedure 3900 includes an act 3902 of interpreting a vehicle policy data value that includes a location description value and an act 3904 of generating a vehicle data collection description in response to the location description value. Exemplary procedure 3900 further includes an act 3906 of collecting vehicle data from endpoints of the vehicle in response to the vehicle data collection description. Referring to FIG. 40, exemplary operations 3904 include adjusting vehicle data collection in response to location description values—eg, altering baseline data collection operations based on vehicle location. Referring to FIG. 43, an exemplary operation 3904 includes adding or modifying metadata of vehicle data collected according to location description values, eg, adjusting timestamps, tagging data, notation (eg, processing operations or other adjustments to data based on adjustments made according to location and/or according to location-related requirements to capture processing operations utilized). Referring to FIG. 42, an exemplary operation 3904 is an operation that prevents collection of vehicle data depending on the location description value (eg, including only some of the collected vehicle data or all of the collected vehicle data). ), where the action to prevent collection of vehicle data can include preventing any one or more actions in the collection cycle, such as requesting data from an endpoint (e.g., where , the data is not normally available, but the policy enforcement circuit 2708 obtains it by requesting it from the source endpoint), storage of collected data (e.g., caching, buffering storage for external transmission, and/or or storage of supporting information such as those used for trigger evaluation, post-event historical data capture, etc.); prevent relevant data and/or metadata collection; and/or preventing one or more actions in the collection cycle, such as, for example, restricting transmission options such as cellular data transfers. Referring to FIG. 41, an example operation 3904 includes initiating collection of vehicle data (and/or initiating any one or more operations of a collection cycle) in response to location description values. Referring to FIG. 44, an example operation 3904 determines a priority value (eg, network usage priority, data storage priority, and/or transmission priority) of at least a portion of the collected vehicle data as a function of the location description value. priority).

Referring to FIG. 45, an example apparatus 4500 is depicted that provides data collection operations in response to vehicle status data and/or based on data types of the collected data. For example, operation of device 4500 includes starting, modifying, and/or stopping data collection operations based on data types of vehicle status data. For example, operation of device 4500 can be controlled data types (e.g., data utilized to perform missions of the vehicle and/or operate mission-related functions of the vehicle), diagnostic data types (e.g., to diagnose vehicle operation, and/or data utilized in longer-term diagnostic learning operations for vehicles and/or groups of vehicles), performance data types (e.g., to improve vehicle performance, tune vehicle performance, monitoring data types (e.g., to monitor driver, vehicle status, etc.), and/or aggregated data types (e.g., summarized, aggregated with other data, aggregated with other data, etc.). data that can be summarized with the data, etc.). The operation of the device 4500 depends on how the data is utilized, the urgency of the data, degraded transmission performance (e.g., time delay before transmission, loss of some data resolution and/or time synchronization availability when summarizing, Allows adjustment of data collection according to data value considering lossy compression, intermittent gaps, etc.). Operation of apparatus 4500 enables protection of collected data against high-value loss events (e.g., mission-critical and experiences high-value loss with minor degradations in time, data resolution, and/or continuous sequence loss). protects both the data to be used), while allowing degradation and/or loss of data of low value and/or low value without experiencing high value loss. Additionally or alternatively, operation of apparatus 4500 enables removal of data that has already experienced high loss values—eg, removal of data that is no longer worth resource utilization due to degradation, and Prioritize other data that holds greater value. It can be seen that operation of device 4500 conserves system resources (eg, in-network communication resources, on-board processing resources, on-board memory resources, transmission resources, etc.) to maximize the value and utility of data collection operations. In certain embodiments, apparatus 4500 protects higher value data (eg, based on data type and/or priority value provided in vehicle policy data values), but initially lower value, for example. The overall value of the collected data can be preserved, such as maintaining data that may have a higher value than other data that has a higher initial value due to degradation.

Exemplary device 4500 may include vehicle status data 4502 (eg, any data available on the vehicle and/or services to determine operational status, diagnostic status, function operation, and/or vehicle status). It includes a policy acquisition circuit 2704 that interprets vehicle policy data values 2710 that include any data on the vehicle indicating conditions such as operations, diagnostic operations, and/or data utilized by applications. In certain embodiments, any data value available from a vehicle endpoint may be a vehicle status and/or data value depending on the context and actions of applications, flows, features, and/or external devices that utilize the collected data. Or it can be a value that indicates the status of vehicle endpoints, features, flows, and/or applications. . Exemplary apparatus 4500 further includes policy processing circuitry 2706 that generates parsed policy data in response to vehicle policy data values 2710 , the parsed policy data including vehicle data collection description 2714 . Exemplary apparatus 4500 further includes policy enforcement circuitry 2708 that collects vehicle data 2722 forming endpoints 2716 on network zones 2718, 2720 on the vehicle. Exemplary device 4500 selectively transmits at least a portion of collected vehicle data 2722 provided as illustratively transmitted collected data 4506 according to data type 4508 of collected vehicle data 2722. It further includes a vehicle data transmission circuit 4504 that

Exemplary operations for selectively transmitting collected vehicle data 2722 include prioritizing transmission resources according to vehicle data type 4508, providing selected in-vehicle storage for collected vehicle data 2722, opportunistic transmission of data. (e.g., when detecting a connection to WiFi, a bonded Ethernet service tool, or other low-cost transmission element); deleting stored collected vehicle data 2722 that has not been transmitted (e.g., collected data (based on storage needs, priority of competing collected data for storage, and residual value of stored data), and/or reduce storage effectiveness of collected vehicle data 2722 (e.g., reduce some of the data to summary data segments, aggregate data segment, compressed data segment, etc.). In certain embodiments, vehicle data type 4508 provides an indication of the value of data based on resolution (e.g., bit depth, precision, and/or sampling rate and/or temporal resolution such as synchronous data matching, etc.) and controls. data, may have a high practical cost for certain data types such as monitoring data, and may have a low cost for certain data types such as monitoring data), storage of contiguous data segments (e.g. storage of segments (e.g. contiguous data without temporal gaps is of high value for some data and not much value for others), time to transmission (e.g. some data is almost instantaneous) It is of high value if sent to , but of little value if sent later, while other data is independent of the time of transmission, or within hours, a day, a week, etc. ), summary effects (e.g. averages over a period of time, during selected events, etc.) are high values for some data types, but not for others. and/or compression effectiveness (e.g., the compression operation may be lossy or lossless, which may depend on the level of compression utilized; some data types may be of value despite compression loss). , but other data types may lose all or significant of their values along with the compression loss.Furthermore, the time delay to perform the compression operation may affect other data types type) Exemplary and non-limiting data types include control data types; diagnostic data types; performance data types; Exemplary data types are non-limiting and include, for example, data types associated with the data structure of the data (e.g., strings, floating point values, Boolean values, single precision values, double precision values, integer, etc.), and/or the data type associated with the data request in the vehicle policy data value 2710 (eg—“MAINTENANCE”, “FUEL ECONOMY”, “FINANCE”, etc.). Any data type can be utilized, including those that authorize a specified action, hi certain embodiments, vehicle policy data values 2710 are data value descriptions (e.g., quantitative descriptions, qualitative descriptions, ordering of data values, etc.) and/or loss of data values based on specific degradation events (eg, time delays, intermittent gaps, compression loss, summary loss, etc.). In certain embodiments, vehicle policy data values 2710 may further include specific actions that may result in value degradation for data types, and may define acceptable actions and/or loss descriptions (e.g., , send within 60 minutes of collection), and/or contain a description of the value associated with such action (e.g. 1: send within 1 minute, data holds value of 100 units; within 60 minutes) and the data holds a value of 75 units;and send within 1 day and the data holds a value of 35 units; Lossless 100 units, compression with 8-bit quantization 2-lossy 30 units, compression with 24-bit quantization 3-lossy 55 units, e.g. has the value 50, and columns less than 5 seconds have the value 0). Examples are provided for illustrative purposes, and matching operations for loss of value may be omitted (eg, operations that may cause degradation are indicated for particular data and/or data types 4508 and/or simplified loss determination (e.g., specific actions may vary by data type and may apply to all data types, but not to a particular data type). reducing the value of untransferred data by a fixed amount and/or ratio that can be applied only), or combinations thereof. The description of value units is exemplary and any value term, whether explicit or implicit, may be utilized. In certain embodiments, transmission of collected data may be performed at the priority of stored collected vehicle data 2722 (eg, at the priority defined in vehicle policy data value 2710 and/or vehicle data type 4508, and/or with priority-based weighted scheduling, sending the highest priority data whenever available), and/or scheduling operations that may result in depreciation by priority (e.g., protect higher priority collected vehicle data 2722 before lower priority data), and/or in order of loss value (e.g., actions that may result in degradation are more likely to cause deterioration in value of collected vehicle data 2722). protects collection vehicle data 2722 that suffers high losses). In certain embodiments, aggregated and/or weighted loss of value may be considered by vehicle data transmission circuitry 4504—eg, operations (eg, deletion, compression, etc.) on single blocks of collected vehicle data 2722. , summaries, etc.) may result in a high loss of value but protect against a greater loss of value (e.g. individually each may represent a smaller loss of value but are protected together). Loss of value is considered even if this protects multiple other blocks of collected vehicle data 2722 that store more value than a single block loses. In certain embodiments, some of the blocks of collected vehicle data 2722 may be protected—eg, store five minute continuous chunks of collected data and delete the remainder. In certain embodiments, value descriptions for collected vehicle data 2722 including loss-of-value determinations may include the amount of data, the number of parameters in the data, and/or the type of data (and/or data types) represented in the data. - for example, a 50 kb data block may be weighted according to a similar 100 kb data block (eg, a similar priority value and/or a similar data type or mix of data types represented in vehicle policy data value 2710). have a less weighted value than have).

In particular embodiments, the policy enforcement circuit 2708 includes endpoints that provide relevant vehicle data (e.g., source endpoints for collected vehicle data 2722); endpoints that request relevant vehicle data; (e.g., an entity associated with an external device providing vehicle policy data values 2710 or relevant portions thereof); depending on the application associated with the endpoint providing the relevant vehicle data (e.g., one or more of the following): Determine the data type of collected vehicle data 2722 . If the endpoint is part of a refueling control operation, the data type may be determined to be a control data type); the application associated with requesting vehicle data; the endpoint providing the associated vehicle data; flow; flow associated with a request for vehicle data;

46, exemplary vehicle status data 4502 includes one or more data types such as control data types, diagnostic data types, performance data types, monitoring data types, and/or aggregate data types. Exemplary data types are non-limiting and exemplary. The example of FIG. 46 includes a vehicle data collection description 2714 with associated operations for data collection cycles corresponding to each data type. The example of FIG. 46 includes endpoints or endpoint groups utilized 3504, data values for collection 3506, collected data formatting and/or processing description 3508, collected data storage description 3510, collected data transmission description 3512. , and/or vehicle data 3516 for collection associated with one or more of the collection data priority values 3514 .

Referring to FIG. 47, an exemplary procedure 4700 for scheduling data collection according to data type of collected data is schematically depicted. Exemplary procedure 4700 includes an act 4702 of interpreting vehicle policy data values that include vehicle status data, and an act 4704 of generating a vehicle data collection description in response to the vehicle policy data values. Exemplary procedure 4700 further includes an act 4706 of collecting vehicle data from vehicle endpoints in response to the vehicle data collection description. Referring to FIG. 48, an example act 4704 includes adjusting the collection of vehicle data according to the data type of the vehicle data collected. Referring to FIG. 49, exemplary act 4704 includes initiating collection of vehicle data depending on the data type of data to be collected. Referring to FIG. 50, exemplary actions 4704 include actions to prevent collection of vehicle data depending on the data type of the data collected—eg, if data cannot be transmitted and data cannot be stored. and/or to collect data of certain data types according to operating conditions of the vehicle that should not be collected (e.g., tag data types that should not be collected at certain locations during certain operating conditions, etc.). Referring to FIG. 51, an exemplary operation 4704 adds and/or modifies metadata of the collected vehicle data depending on the data type of the collected data—eg, timestamp information, source identification information, network Depending on the data type of the collected data, additional actions to address information and/or convert them. Referring to FIG. 52, exemplary act 4704 includes adjusting the priority value of the collected vehicle data according to the data type of the collected data.

Referring to FIG. 53, an exemplary procedure 5300 for scheduling data collection according to data type of collected data is schematically depicted. Exemplary procedure 5300 includes an operation 5302 of determining a data type of collected vehicle data. Action 5302 may be determined in response to vehicle policy data values 2710—eg, endpoints, applications, flows, entities utilizing data types defined in the policy and/or providing or requesting data. etc. to determine the data type. In certain embodiments, operation 5302 may determine after data collection, for example, determine from collected vehicle data 2722 the sources that provide elements of collected vehicle data 2722 . The example procedure 5300 further includes an act 5304 of configuring a vehicle data collection description and/or a data collection action depending on the data type, where the data collection action is any aspect of the collection cycle (e.g., in-vehicle network transmission resource , data storage resources, data format and/or processing resources, and/or off-vehicle transmission resource utilization). Referring to FIG. 54, example operation 5302 includes determining a data type based on a provisioning endpoint for collected data. Referring to FIG. 55, exemplary operation 5302 includes determining a data type based on a request endpoint for collected data. Referring to FIG. 56, exemplary operation 5302 includes determining a data type based on a requesting entity for collected data. Referring to FIG. 57, example operation 5302 includes determining the data type based on the application associated with the endpoint providing the collected data. Referring to FIG. 58, exemplary operation 5302 includes determining the data type based on the flow associated with the endpoint requesting the collected data. Referring to FIG. 59, example operation 5302 includes determining a data type based on the flow associated with the endpoint providing the collected data. Referring to FIG. 60, exemplary operation 5302 includes determining the data type based on the application associated with the endpoint requesting the collected data. Referring to FIG. 61, exemplary operation 5302 includes determining the data type based on the data types indicated in the policy. In certain embodiments, a given block of collected data includes data provided by multiple endpoints and/or multiple related flows, applications, and/or other prioritization and/or data May contain typing information. In certain embodiments, the highest priority and/or most important one of the associated endpoints, flows, applications, and/or indicated data types initiates a data collection operation for a given block of collected data. can be used to make decisions. In certain embodiments, weighted priority and/or data type values may be utilized (e.g., if 60% of the data is a high priority data type, then assign block priority to high priority data type). and/or the most common or descriptive priority and/or data type values can be utilized (e.g., 60% of the data is of the highest priority data type). treat the data block as a high priority data type).

Referring to FIGS. 62-65, examples of collected data priority values are schematically depicted. Examples of priority values are non-limiting, and any reference to determining the priority value of collected data throughout this disclosure can be utilized as collected data priority value 3514 . Further, any reference to priority value determination in this disclosure may additionally or alternatively contemplate one or more of the values depicted with reference to Figures 62-65. FIG. 62 depicts exemplary collected data priority values 3514 including in-vehicle data storage priority 6202, transmission priority 6204, and/or in-vehicle transmission priority 6206. FIG. Without limiting other aspects of this disclosure, in-vehicle storage resources may include memory allocation and/or stored values utilizing memory, resources utilized to delete, move, compress, and/or summarize stored data; and/or resources for determining memory allocations, updating memory allocations (e.g., based on the amount of data collected versus an estimated amount of data to collect), and/or tracking expiration and/or aging of stored data. can include Without limiting other aspects of this disclosure, off-vehicle transmission resources may include external data transfer components (eg, cellular data paths, Ethernet data paths, WiFi data paths, and/or other network data paths such as CAN communications). bandwidth utilization, data capacity limits (e.g., data volume caps, data volume associated with entities, applications, flows, etc., and/or data volume associated with Access Point Names (APNs)), and/or external data transfer (e.g., at any time and/or under certain operating conditions, such as when the vehicle's prime mover is not supplying power and battery power is available for external data transfer). Without limiting other aspects of this disclosure, in-vehicle transmission resources may be used to determine bandwidth utilization of one or more network zones, allowable utilization of network zones for a given endpoint, flow, application, etc., low-latency communication latency management of communications on network zones, including contention for access, and/or resource utilization of inter-network devices (eg, CEG, CES, and/or CND).

Referring to FIG. 63, exemplary in-vehicle data storage priorities 6202 include memory allocation priorities 6302 including for buffer capacity, cache capacity, short-term memory capacity, and/or long-term memory capacity; Expired data processing priorities 6304, including those for processing expiration date data, managing data longevity tracking and comparison to expiration time, and/or order of expiration data management, loss of value associated with expiration data management, etc. Data Expiration Priority 6306, including by decision. Referring to FIG. 64, an exemplary transmission priority 6204 is transmission priority based on limited competing transmission resources 6402, transmission priority based on available transmission paths 6404 (eg, cellular transmission is first priority, transmission priority 6406 based on intermittent connectivity (e.g., periods of high connectivity operation have the first priority set; WiFi transmissions may have a different priority set); low connectivity periods may have a second set of priorities and intermittent connectivity periods may have a third set of priorities); running at rated power, shutdown operation, start-up operation, idle operation, etc. may each have a different set of priorities for transmission of collected data). Referring to FIG. 65, an exemplary in-vehicle transmission priority 6206 is based on limited network zone resources 6502 (e.g., bandwidth, utilization, low-latency messaging slots, etc.), in-vehicle transmission priority (OVTP), bandwidth OVTP based on 6504 (e.g., absolute or relative bandwidth allowed for each data, current bandwidth utilization and/or availability of network zones, etc.), network zones and/or convergence devices passing parameters between network zones 6506 utilization-based OVTP (e.g., CES, CEG, and/or CND's ability to manage message transfer and/or provision for messages from a first network zone to be utilized in a second network zone) associated resources such as message processing resources, buffering and/or cache memory to support intra-network message transfers), and/or latency parameters 6508 (e.g., if the network zone limits the number of low-latency messages, network zone traffic level threatens latency performance of high priority messages).

Referring to FIG. 66, for providing data collection actions in response to vehicle status data that can be dynamically changed and/or adjusted based on vehicle geography, jurisdiction, and/or operating conditions. An exemplary device 6600 is depicted. For example, operation of device 6600 may include data collection operations in response to requested changes, detected events, evaluated trigger conditions, and/or detection of given vehicle operating conditions and/or changes in vehicle operating conditions. can be adjusted.

Exemplary device 6600 operates similarly to device 4500, with certain differences that are described here for purposes of illustration. Device 6600 may be included in a system having a vehicle with one or more network zones as described throughout this disclosure, and aspects of device 6600 may be defined in whole or in part as defined throughout this disclosure. may be included with any system, device, controller, and/or apparatus. Additionally or alternatively, aspects of any system, device, controller, and/or apparatus defined herein may be included in apparatus 6600, in whole or in part.

Exemplary apparatus 6600 includes vehicle status data adjustment circuitry 6602 that interprets vehicle status data collection change values 6604 . The example apparatus 6600 may include policy enforcement circuitry 2708 that adjusts collection operations for collected vehicle data 2722 in response to vehicle status data collection change values 6604 and/or includes a vehicle data transmission circuit 4504 that coordinates the transmission operation of the vehicle. In certain embodiments, vehicle status data adjustment circuit 6602 determines vehicle status data collection change values 6604 as a function of vehicle operating conditions 6606 . Exemplary vehicle operating states 6606 may be categorical and/or discrete values, such as state conditions (eg, shutdown, move, start up, idle, high load operation, low load operation, etc.). Additionally or alternatively, exemplary vehicle operating conditions 6606 may be quantitative and/or continuous values such as power handling capability levels, torque values, vehicle speed, and the like.

In certain embodiments, vehicle status data adjustment circuit 6602 determines vehicle status data collection change values 6604 in response to determining event occurrences 6608—eg, based on trigger conditions, fault values, diagnostic codes, and the like. In certain embodiments, vehicle status data conditioning circuitry determines event occurrence 6608 in response to one or more of the following: fault condition values (e.g., fault associated with data collection of respective parameters, data collection parameters and/or application-related failures, and failure conditions defined in policy 2710 to coordinate data collection), determination of failure count values (e.g., Determining diagnostic parameter values (e.g. , diagnostic codes, intermediate values for diagnostic actions, etc.); fault confirmation values (e.g., state values indicating whether a fault is active, latent, recently active, pending confirmation, etc.); diagnostic confirmation values (e.g., determine diagnostic conditions); fault median values (e.g., thresholds or other conditions that tend to indicate fault, determined by fault decision actions); and/or which values are used and/or faults that can be used to determine whether a fault is potentially active, about to be set, and/or cleared. value in decision making); and/or diagnostic intermediate values. In certain embodiments, vehicle policy data values 2710, for example, may be used to collect additional data related to the occurrence of faults and/or diagnostics, for example, whether fault and/or diagnostic determinations are working. , whether they can be improved or optimized, can be used to inform fault tree analysis and/or diagnostic root cause analysis.

The ability of device 6600, and/or other systems and devices herein, to determine whether any network zone of the vehicle before a fault condition and/or diagnostic action is ascertained—eg, by the ability of policy enforcement circuit 2708. early in the process, reaching any of the above endpoints and collecting data - e.g. , and also provides the ability to initiate data collection. Prior known systems provide light and/or other notifications in response to diagnostic actions confirming that a fault has been set or that a problem exists, but by the time notification is provided The operation of fault determination and/or diagnostic operations has already been completed and at best can only capture short-term historical data. Collecting larger amounts of data for previously known systems requires collecting parameters over a selected period of time with a huge amount of data and determining whether a failure occurs over the selected period of time. It is prohibited because it is not known whether or not to do so. Operation of the device 6600 is collected by data collection structured on the basis of intermediate failure values, e.g., collecting data when preliminary indications that a failure is likely to occur appear in the data. Increase the data (e.g., sampling rate, number of parameters, etc.) and/or further increase the data collected when a fault or diagnostic condition is more likely (e.g., increase the intermediate counter value toward the fault threshold). Then increase the data collection rate and/or parameters), while maintaining a high likelihood that the collected data is relevant to the intended use of the collected data. Furthermore, because data collection is not limited to data available on the network zone, the data that can be collected by device 6600 is improved and more relevant for deeper analysis of fault and diagnostic behavior, improved service procedures and/or fault tree analysis. Fast convergence etc. becomes possible. Further, the capabilities of the apparatus 6600 may include layout of network zones, distribution of endpoints over network zones, different distribution of controllers and control actions across endpoints, and/or different configurations (e.g., units, sampling rates, parameter names, bit depths, etc.). and/or resolution) to utilize a single policy for vehicles with different configurations. A given policy utilized to collect data represents a significant investment in determining what data is collected, timing of data collection for events, etc., for example, to improve failure determination. The ability to reuse a given policy across multiple vehicle configurations greatly reduces the cost of implementing and refining faults and diagnostics across vehicle systems. The use of apparatus 6600 for fault and diagnostic operations and other embodiments throughout this disclosure are exemplary to demonstrate various advantages of aspects of this disclosure. It can be seen that a number of other operations that represent similarly significant investments will similarly benefit from the capabilities of the systems, apparatus and operations described herein--for example, without limitation, vehicle Operations that adjust features (e.g., control governors, learning systems, etc.); operations that determine operator utilization of vehicle features (e.g., cruise control, seat adjustment, wiper blade operation, multimedia interaction, etc.); nominally unrelated systems. correlations between (e.g., time of day failures occur and/or features are utilized; relationships between changing locations and/or location types and vehicle operating conditions - e.g., populated areas to rural highways); determining which vehicle operating states and/or functions are likely to be utilized by the operator when transitioning to

Exemplary vehicle status data 4502 further includes trigger conditions, and vehicle status data adjustment circuit 6602 determines event occurrences 6608 as a function of the trigger conditions. A trigger condition can be any trigger condition described throughout this disclosure, including at least: an event detection condition; a vehicle status value; and/or a vehicle operating condition value.

Exemplary vehicle status data adjustment circuit 6602 further interprets vehicle status data collection change values 6604 in response to location description values included as part of vehicle policy data values 2710, for example. A location description value includes at least one description such as a geographic location value; a jurisdictional value; a relative location value; or a defined geographic area value. Policy enforcement circuitry 2708 prevents collection of at least a portion of the vehicle data, initiates collection of at least a portion of the vehicle data, responds to the vehicle status data collection change value 6604, and responsive to the location description value. Adjusting the format of at least some of the data and/or adjusting the priority associated with at least some of the vehicle data.

Referring to FIG. 67, an exemplary procedure 6700 for dynamically configuring data collection for vehicles is schematically depicted. The exemplary procedure 6700 includes an operation 6702 of interpreting a vehicle policy data value including vehicle status data, an operation 6704 of generating a vehicle data collection description responsive to the vehicle policy data value, and an operation 6704 of the vehicle data collection description responsive to the vehicle data collection description. and an operation 6706 of collecting vehicle data from the endpoint. The example procedure 6700 includes an operation 6708 of transmitting at least a portion of the collected vehicle data, an operation 6710 of determining a vehicle status of at least a portion of the collected vehicle data, and determining a vehicle status data collection change value. and operation 6710 . The example procedure 6700 includes an act 6712 of adjusting collection and/or transmission operations in response to vehicle status data collection changes.

Referring to FIG. 68, an exemplary procedure 6710 for determining vehicle status data collection change values includes interpreting vehicle operating conditions, operation 6802, and determining vehicle status data collection change values as a function of vehicle operating conditions, operation 6804. ,including. Referring to FIG. 69, an exemplary procedure 6710 includes an operation 6902 of determining an event occurrence and an operation 6904 of determining vehicle status data collection change values in response to the event occurrence. Referring to FIG. 70, an exemplary procedure 6710 includes an operation 7002 of determining a location description value and an operation 7004 of determining a vehicle status data collection modification value as a function of the location description value. 71-78, exemplary operations 6712 for adjusting collection and/or transmission of collected data values in response to vehicle status data collection change values are depicted. Referring to FIG. 71, an exemplary operation 6712 collects vehicle data (eg, parameters to collect, speed of collection, amount of data to capture, data timing of capture, etc.). Referring to FIG. 72, exemplary operation 6712 includes initiating collection of vehicle data in response to vehicle status data adjustments. Referring to FIG. 73, exemplary operation 6712 includes preventing collection of vehicle data in response to vehicle status data adjustments. Referring to FIG. 74, example operation 6712 includes adding and/or modifying metadata for collected vehicle data in response to vehicle status data adjustments. Referring to FIG. 75, exemplary operation 6712 includes adjusting priority values for collected vehicle data in response to vehicle status data adjustments. Referring to FIG. 76, example operation 6712 includes adjusting the transmission of collected vehicle data in response to adjusting vehicle status data. Referring to FIG. 77, example operation 6712 includes adjusting data storage of collected vehicle data in response to vehicle status data adjustments. Referring to FIG. 78, an example operation 6712 includes adjusting formatting and/or processing of collected vehicle data in response to adjusting vehicle status data.

Referring to FIG. 79, an exemplary procedure 7900 for dynamically configuring data collection for vehicles is schematically depicted. Exemplary procedures include an operation 7902 of determining vehicle status data collection change values in response to trigger conditions and/or event occurrences, and an operation of collecting and/or transmitting collected vehicle data in response to vehicle status data collection change values. and an operation 6712 of adjusting the . Referring to FIGS. 80-83, exemplary operations 7902 for determining event occurrence and/or trigger conditions are schematically depicted. Referring to FIG. 80, an example operation 7902 determines an event occurrence in response to fault data, e.g., determining that an event has occurred that alters data collection and/or transmission in response to an established fault. and/or determining that an intermediate fault value (eg, a fault counter, a threshold of data that tends to indicate fault, etc.) has occurred. Referring to FIG. 81, an example operation 7902 includes determining event occurrences in response to diagnostic data, e.g., data collection and/or transmission in response to diagnostic operation output values, intermediate values, and/or diagnostic code values. determining that an event has occurred to change the . Referring to FIG. 82, an exemplary operation 7902, depending on available vehicle data, including one or more collected vehicle data parameters or other vehicle data parameters available from vehicle endpoints. It includes the step of determining event occurrence. Referring to FIG. 83, exemplary operations 7902 include monitoring trigger evaluation data and determining event occurrence based on trigger status (eg, provided in a policy) and trigger evaluation data.

Referring to FIG. 84, an exemplary apparatus 8400 for implementing data collection utilizing policy hierarchy is schematically depicted. Exemplary device 8400 is disclosed in the context of data collection, but may perform automated actions, triggered data collection, and/or any other policy-based action as defined in this disclosure. can be used to configure Exemplary device 8400 depicts exemplary policy types to explain aspects of the present disclosure, but the depicted policy types are exemplary and non-limiting. Embodiments may include some or all of the policy types depicted, other policy types, and/or multiple policies of a given type.

Exemplary device 8400 operates similarly to device 4500, with certain differences that are described herein for purposes of illustration. Device 8400 may be included in a system having a vehicle with one or more network zones as described throughout this disclosure, and aspects of device 8400 may be defined in whole or in part as defined throughout this disclosure. may be included with any system, device, controller, and/or apparatus. Additionally or alternatively, aspects of any system, device, controller, and/or apparatus defined herein may be included in apparatus 8400, in whole or in part.

Exemplary apparatus 8400 includes policy acquisition circuitry 2704 that interprets vehicle policy data values 2710 . The example of FIG. 84 includes one or more of downloaded policy 8402, factory policy 8404, and/or built-in policy 8406, and vehicle policy data value 2710 is one or two of policies 8402, 8404, 8406. constructed from the above. Vehicle policy data value 2710 may utilize a selected one of policies 8402, 8404, 8406 as vehicle policy data value 2710 and/or vehicle policy data value 2710 may be one of policies 8402, 8404, 8406. It can be constructed using two or more of them. In certain embodiments, policies 8402, 8404, 8406 may be, for example, policy 8402 downloaded as vehicle policy data value 2710, factory policy 8404 (eg, if no downloaded policy 8402 exists), and/or built-in policy 8406, in order, are used in a hierarchical structure by using them if they exist. Examples utilizing built-in policies, factory policies, and downloaded policies are illustrative and non-limiting. Embodiments include a vehicle controller (e.g., a CND, and/or any other controller with policy management operations provided thereon) at the initial manufacture of the vehicle and/or the supply of each controller to the vehicle manufacturer. built-in policies 8406 provided on the controller), factory policies 8404 provided on the vehicle controller at a later stage of manufacture (e.g., by vehicle manufacturer, original equipment; vehicle manufacturer, original equipment manufacturer, body by the builder, assembler, entity that configures the vehicle for a particular application, and/or the dealer) and either after the vehicle has been driven and/or as a policy update action, for example by the dealer. is the downloaded policy 8402 provided at the time of . Any number of intermediate policies are contemplated herein, including stages either before or after the vehicle's manufacture and/or initial sale. In certain embodiments, built-in policies include specific functionality such as bootloading, initialization operations, etc. that allow for the collection of basic data, enforcement of policy updates, and the like. In particular embodiments, the base functionality provided by built-in policy 8406 is retained after other policies are implemented, and/or the base functionality may be implemented or replaced by subsequent policies.

In certain embodiments, higher-level policies (eg, downloaded policies 8402 versus factory policies 8404 and/or built-in policies 8406) take precedence over lower-level policies. In certain embodiments, conforming portions of lower-level policies are retained, and lower-level policies may be treated differently (e.g., one of factory policy 8404 and/or built-in policy 8406 may be compatible with higher-level policies). factory policy 8404 and/or the other one of the built-in policies 8406 are ignored, deprecated, and/or deleted upon receiving the higher-level policy). In certain embodiments, ignored or deprecated lower-level policies are reinstated upon removal and/or expiration of higher-level policies.

The description of the highest level policy in the example of Figure 84 refers to the highest level policy as "downloaded policy" as an example. However, the highest level policy and/or any other policy may additionally or alternatively be provided by tools with direct connectivity (e.g. physical ports coupled to the vehicle network zone), LAN or WiFi It may be received by connection, by cellular communication, and/or by any other operation. In certain embodiments, the downloaded policy 8402 may be received utilizing a replacement controller installed on the vehicle (eg, as a service operation to replace the vehicle's controller, the replacement controller was downloaded including policy 8402). In certain embodiments, the policy structure may have additional levels in the hierarchy and/or multiple policies at a given level of the hierarchy. In certain embodiments, assembly of vehicle policy data values 2710, or portions thereof, occurs on the vehicle controller—eg, one or more, or all of policies 8402, 8404, 8406 are received by policy acquisition circuit 2704. , where a hierarchy is applied to provide the final in-vehicle policy data value 2710 . In certain embodiments, in-vehicle policy data values 2710 are assembled outside the vehicle and passed to policy acquisition circuitry 2704 after assembly. In certain embodiments, combinations of these exist—eg, vehicle policy data value 2710 is assembled and passed to policy acquisition circuitry 2704, and another downloaded policy 8402 (and/or vehicle policy data value 2710) is It is provided to policy acquisition circuitry 2704, which can replace and/or add to existing policies in use on the vehicle.

Referring to FIG. 85, to perform vehicle data collection or other actions herein (eg, control evaluation of triggers and consequent actions, data access, service access, and/or authorization for data collection, etc.) An exemplary apparatus 8500 is schematically depicted for utilizing multiple policy types for the purpose.

Exemplary device 8500 operates similarly to device 4500, with certain differences that are described here for purposes of explanation. Device 8500 may be included in a system having a vehicle with one or more network zones as described throughout this disclosure, and aspects of device 8500 may be defined in whole or in part as defined throughout this disclosure. may be included with any system, device, controller, and/or apparatus. Additionally or alternatively, aspects of any system, device, controller, and/or apparatus defined herein may be included in apparatus 8500, in whole or in part.

The example of FIG. 85 includes vehicle policy data values 2710 provided including one or more of persistent policy 8502 , discrete (or limited) policy 8504 , and streaming policy 8506 . In certain embodiments, the persistent policy 8502 continuously presents data collection operations on the vehicle, or other operations, such as continuously collecting data (and/or checking conditions for data collection). ), and intermittently stored as Collected Vehicle Data 2722 and transmitted as Transmitted Collected Data 4506 (eg, in response to priority values and/or other actions defined herein) is set for The example discrete policy 8504 sets for data collection operations or other operations that are present on the vehicle for execution over a selected period of time, a selected number of operations, or the like. For example, a discrete policy 8504 can be configured to collect a particular set of data at once and/or to perform a particular action at once (eg, open a door, start a vehicle, verify the identity of the owner, etc.). After a selected number of executions and/or expiration of an effective timeframe, the discrete policy 8504 can be ignored, deprecated, and/or deleted. The example streaming policy 8506 provides for transmitting vehicle data 2722 immediately or as soon as it becomes available during operation according to the streaming policy 8506, either continuously, for a selected period of time, or the like. defines the data collection activity, or other activity, present on the vehicle. In certain embodiments, either persistent policy 8502 or discrete policy 8504 with a high transmission priority value can effectively operate in the same manner, and in certain embodiments, streaming policy 8506 is high. Implemented as a separate policy type with transmission priority values. Descriptions including persistent policy 8502, discrete policy 8504, and/or streaming policy 8506 are exemplary to illustrate the operation of particular embodiments. In certain embodiments, policy acquisition circuit 2704 replaces previous policies with updated vehicle policy data values 2710 and/or replaces previous policies with updated vehicle policy data values 2710 . In certain embodiments, vehicle policy data value 2710 defines whether the policy should replace and/or be appended to and/or utilized in addition to the previous policy. contains data fields or other implementation information that In certain embodiments, data fields or other implementation information may be used by policy providers (e.g., vehicle policy data values 2710 and/or one or more of policies 8502, 8504, 8506) prior to implementing updated policies. (providing entity) authorization. In certain embodiments, the treatment of policy types is explicit—eg, discrete policy 8504 and/or streaming policy 8506 can always be appended, and/or persistent policy 8502 can selectively replace previous policies. , may be added and/or added in parallel. The described operations are non-limiting examples.

Referring to FIG. 86, an exemplary procedure 8600 for enforcing policy enforcement on a vehicle is schematically depicted. The procedure 8600 includes an operation 8602 of interpreting a vehicle policy data value, an operation 8604 of generating a vehicle data collection description, an operation 8608 of collecting vehicle data from a vehicle endpoint according to the vehicle data collection description, and an operation 8608 of collecting vehicle data from the collected vehicle data collection description. and an act 8608 of transmitting at least a portion of the data. The operations of procedure 8600 may be performed according to a hierarchy of policies (see, eg, FIG. 84 and related discussion) and/or according to multiple policy types (see, eg, FIG. 85 and related discussion). can be done.

Referring to FIG. 87, an exemplary procedure 8700 for enforcing policy enforcement on a vehicle is schematically depicted. Procedure 8700 includes an act 8702 of determining a policy type to be provided to the vehicle and an act 8704 of generating a vehicle data collection description based on the policy type. Actions 8702, 8704 can be combined as action 8604 to generate a vehicle data collection description. Exemplary procedure 8700 determines whether policy collection is active (eg, whether data collection according to policy is active and/or whether monitoring of potential data collection according to policy is active). ), and an operation 8708 of collecting vehicle data in accordance with the vehicle data collection description if operation 8706 determines YES. Acts 8706, 8708 can be combined as act 8606 for collecting data from the vehicle's endpoints according to the vehicle data collection description. Exemplary procedure 8700 determines whether an inactive policy is deleted—eg, a replaced policy, an expired policy, a resolved discrete policy, and/or a discrete and/or streaming policy with an elapsed timeframe. It includes an operation 8710 of determining if-. In certain embodiments, the procedure 8700 at least determines the collected vehicle data, for example, as a function of the collected data from operation 8708 and/or as a function of the previously collected data for an inactive policy that has not yet been transmitted. An operation 8608 of sending a portion is included. In particular embodiments, example procedure 8700 includes an operation 8712 of deleting the policy and/or the inactive portion of the policy, eg, upon operation 8710 determining YES. The operations of procedure 8700 can be configured to hold an inactive policy until collected data is sent according to the inactive policy. Additionally or alternatively, inactive policies can be deleted and collected data can be sent at a later time in accordance with the inactive policies.

Referring to Figure 88, an exemplary utilized policy hierarchy 8802 is schematically depicted. In the example of FIG. 88, it is used when the downloaded policy 8402 exists, is used when the factory policy 8404 exists and when the downloaded policy 8402 does not exist, and is used when the built-in policy 8406 exists and is downloaded. It is used when neither the specified policy 8402 nor the factory policy 8404 exists. Referring to FIG. 89, another exemplary utilized policy hierarchy 8802 is schematically depicted. In the example of FIG. 89, the built-in policy 8406 includes a matching portion 8902 with the factory policy 8404 and the downloaded policy 8402, the factory policy 8404 includes a matching portion 8904 with the downloaded policy 8402, and the end-use policy is the factory It contains a combination of the policy 8404 and the appended matching portions 8904, 8902 of the built-in policy 8406 and the downloaded policy 8402. The example of FIG. 89 is illustrative, and for clarity, conformance portion 8902 of built-in policy 8406 is depicted as conforming with both factory policy 8404 and downloaded policy 8402. FIG. Portions of built-in policies 8406 can only match either factory policy 8404 or downloaded policy 8402, and only portions that match both factory policy 8404 and downloaded policy 8402 are added to the final policy. It will be understood. The example of FIG. 89 depicts adding the matching portion of the lower policy for clarity of explanation. In certain embodiments, policy processing circuitry 2706 may utilize the conforming portion to build vehicle data collection description 2714 without compiling the final policy with additional portions. For example, the policy processing circuit 2706 can provide the vehicle data collection description 2714 to implement the downloaded policy 8402 and the conforming portion of the subordinate policy without constructing an attached final policy.

Referring to FIG. 90, an exemplary utilized policy hierarchy 8802 is schematically depicted, with multiple downloaded policies 8402, 90002, 90002, 90002, 9004 is shown. In some embodiments, lower level policies may be ignored and/or utilized in the matching part. Referring to FIG. 91, an exemplary utilized policy hierarchy 8802 is depicted schematically, including one or more persistent policies 9102, one or more discrete policies 9104, and/or streaming policies 9106, etc. Has multiple high-level policies. The policy hierarchy 8802 utilized may be a compiled version of the policies 9102, 9104, 9106 and/or the vehicle data collection description 2714 built utilizing the policies 9102, 9104, 9106. In particular embodiments, the policies 9102, 9104, 9106 may be provided within a policy hierarchy, for example, all of the policies 9102, 9104, 9106 are treated as the downloaded policy 8402 and/or the highest level policy. . In certain embodiments, the policies 9102, 9104, 9106 have a hierarchy between them, determined according to, for example, priority and/or authorization values associated with the entity, device, flow, application, etc. providing the policy. , a higher policy 9102, 9104, 9106 supersedes a lower policy, and/or a matching portion of the lower policy is executed. In particular embodiments, the utilized policy hierarchy 8802 may further include sub-policies such as factory policies 8404, built-in policies 8406, where sub-policies 8404, 8406 may be ignored and/or Available in matching parts. In certain embodiments, discrete policies 9104 and/or streaming policies 9106 are provided that are incompatible with some of the lower policies 8404, 8406, and the incompatible parts are Ignored and reinstated after the higher-level policies 9104, 9106 are resolved (eg, data collection operations are completed, associated implementation times have expired, and/or the higher-level policies 9104, 9106 are deleted 8712).

Referring to FIG. 92, an exemplary procedure 9200 for updating data collection policies is schematically depicted. The exemplary procedure 9200 includes an operation 9202 of interpreting a vehicle policy data value and an operation 9204 of updating a data collection policy in response to the vehicle policy data value (e.g., adding an update to the policy, adding an additional policy to implement the added policy). provide as a policy and/or remove previous policies, etc.). The example procedure 9200 includes an operation 9206 of generating a vehicle data collection description in response to the updated data collection policy, an operation 9208 of collecting vehicle data in response to the vehicle data collection description, and at least one of the collected vehicle data. and an act 9210 of sending the part.

Referring to FIG. 93, an exemplary procedure 9300 for enforcing a policy hierarchy is depicted. Exemplary procedure 9300 includes an operation 9302 of determining if a downloaded policy exists on the vehicle, and an operation 9306 of generating a vehicle data collection description in response to operation 9302 determining YES. . The example procedure 9300 includes an operation 9304 of determining if a factory policy exists, and an operation 9308 of generating a vehicle data collection description in response to operation 9304 determining YES. The example procedure 9300 includes an act 9310 of generating a vehicle data collection description according to a built-in policy in response to act 9304 determining NO. The exemplary operation of procedure 9300 utilizes the top-level policy as the policy, but can be adjusted to enforce one or more matching parts of the lower-level policies.

Referring to FIG. 94, an example procedure 9400 for implementing a policy hierarchy is depicted. In the example of FIG. 94, operation 9402 determines whether a conforming portion of the factory policy exists in response to the YES decision from operation 9302 . In the example of FIG. 94, operation 9404 includes adding the conforming portion of the factory policy to the implemented policy and either the decision NO from operation 9404, the decision NO from operation 9402, and/or the decision YES from operation 9304. and, accordingly, an operation 9406 of determining if there is a matching portion of the built-in policy. Exemplary procedure 9400 includes act 9412 for generating a vehicle data collection description according to built-in policies, eg, if neither a downloaded policy nor a factory policy exists. Exemplary procedure 9400 includes operation 9410 for generating a vehicle data description according to an implementation policy other than a built-in policy, in response to operation 9406 determining NO. Exemplary procedure 9400 includes operations 9408 of adding the matching portion of the built-in policy to the implemented policy and, in response to operation 9406 determining YES, generating a vehicle data description according to the implemented policy. 9410 and

Referring to FIG. 95, an exemplary apparatus 9500 for performing data collection operations utilizing shared storage for collected data is schematically depicted. Exemplary device 9500 operates similarly to device 4500, with certain differences that are noted here for purposes of explanation. Device 9500 may be included in a system having a vehicle with one or more network zones as described throughout this disclosure, and aspects of device 9500 may be defined in whole or in part as defined throughout this disclosure. may be included with any system, device, controller, and/or apparatus. Additionally or alternatively, aspects of any system, device, controller, and/or apparatus defined herein may be included in apparatus 9500, in whole or in part.

The exemplary apparatus includes parameter acquisition circuitry 9502 that interprets a plurality of vehicle parameter values 9510 as a function of requested vehicle properties 9512 of vehicle policy data values 2710 . Vehicle parameter values 9510 are interpreted from endpoints 2716 on one or more network zones 2718, 2720 of the vehicle. The example apparatus 9500 further includes parameter storage circuitry 9504 that selectively stores at least a portion of the vehicle parameter values 9510, wherein at least a first portion of the stored vehicle parameter values 9514 are the stored vehicle parameter values. Stored on a different storage endpoint 9508 than the provisioning endpoint for 9514 . In certain embodiments, all of the stored vehicle parameter values 9514 are stored in a single endpoint. Utilization of shared storage for collected data parameters can be used to consolidate capacity within the system, providing a small number (or one) of high capacity storage resources within the system, and storage of data collection parameters. can reduce the overall cost and complexity of managing Shared storage can be general storage that can store any type of data from any ECU and/or application. Additionally or alternatively, the processing power can be consolidated into several (or one) high-capacity processing resources, which can be provided on controllers that also have high memory capabilities. The use of shared storage allows the parameter acquisition circuit 9502 to reach any endpoint on any network zone and move data while maintaining security using operations such as CEG, CES, and CND. supported by competence. In certain embodiments, data stored within the system (eg, buffered data, cached data, stored vehicle parameter values, policy information and/or parsed policy data, etc.) is encrypted. Management of encrypted stored data is simplified by reducing the number of storage resources utilized within the system. In particular embodiments, shared storage may be provided by a single controller with memory resources, which may include a controller with policy management components such as policy acquisition circuitry 2704 . However, the shared storage can be distributed among multiple controllers and/or included separately from the controller with the policy management component. In particular embodiments, the policy management component, in whole or in part, may be distributed across multiple controllers, partially provided to controllers with shared storage resources, or independent of controllers with shared storage resources. can be provided by Controllers with shared storage resources are coupled to the system as vehicle network zone endpoints, and in certain embodiments, controllers with policy management components are themselves vehicle network zone endpoints. The operation of the controller 2702 may be based on data collection behavior, buffering and caching of parameter values, expiration of stored data, transmission of stored data, and/or policy changes, observed data collection behavior, etc. It is possible to manage shared memory resources, including memory allocation provided for reallocation of

Allocation of memory resources affects the amount of data collected to support policy collection operations, rolling buffer data (e.g. for capturing historical data and performing trigger analysis), trigger evaluation data, and sending on demand conditionally stored data, network zone locations of endpoints that provide data and have shared storage resources (e.g., to determine in-vehicle network communication effectiveness in determining data generation and data storage locations), collected data is transmitted as transmission collected data 4506, the transmission effect on the in-vehicle network can be considered. For example, a shared storage resource that requires less in-vehicle network resources for transmission may be selected to store vehicle parameters that are likely to be transmitted, and a shared storage resource that requires more in-vehicle network resources for transmission (e.g. , which are transferred from one network zone to another before the data is sent), intermediate data used for calculations and/or hypothetical parameter determination, most of the data are iteratively rewritten and events It can be used for rolling buffer data that is sent only occasionally or never unless an event occurs, and/or any other type of data that is unlikely to be sent. In certain embodiments, data with lower priority values and/or with lower value loss indications in response to memory management operations (e.g., compression, summarization, down-sampling, aging, or the like) may be collected data maintain a relatively high percentage of the original value of ), such data tends to be reduced through memory management operations before transmission, but other Since it is more expensive than data, it can be stored on shared memory resources, which has a relatively high transmission cost.

Exemplary parameter storage circuitry 9504 selectively stores at least a portion of multiple vehicle parameter values 9514 to a single storage endpoint 9508 . Exemplary storage management circuitry 9506 determines a parameter transmission schedule 9516 for stored vehicle parameter values, and parameter storage circuitry 9504 selectively selects at least a portion of plurality of vehicle parameter values 9514 in response to parameter transmission schedule 9516. memorize to parameter transmission schedule 9516 can include estimates of data collection operations to service aspects of a policy (or policies), estimated transmission times for determining memory allocation values to support data collection operations; Data dwell time and the like can also be included. In particular embodiments, transmission schedule 9516 is defined in vehicle policy data values 2710 and/or depending on data in vehicle policy data values 2710—e.g., according to transmission time constraints, time delay cost descriptions, priority values, etc. Depending - determined. Accordingly, the parameter storage circuit 9504 determines which data acquisition operations require memory support, the amount of memory to support each operation, protects the value of the data, reduces transmission costs, Locations of storage endpoints 9508 (eg, where multiple shared storage resources are available) can be selected to maintain on-board network resources to support other functions.

The exemplary apparatus 9500 causes the storage management circuit 9506 to determine a parameter expiration schedule 9518 for the stored vehicle parameter values 9514, for example, as defined in a policy, determined according to the data type of each collected data; and/or determining a loss value for data based on time and according to memory management operations that would be performed on the data based on expected propagation delay (including consideration of propagation delay uncertainty); including. Exemplary parameter storage circuitry 9504 further selectively stores at least a portion of plurality of vehicle parameter values 9514 in response to parameter expiration schedule 9518, e.g., allocated memory values, selected storage endpoints 9508 etc. are adjusted.

Exemplary operations of parameter storage circuitry 9504 for parameter expiration schedule 9518 include operations such as: deleting at least some of the stored vehicle parameter values 9514 (e.g., determining that a parameter has expired); post); summarize at least some of the stored vehicle parameter values (e.g., a reduced form of the stored vehicle parameters 9514, such as statistical descriptions, mean values, qualitative descriptions, bucketed data descriptions, etc.); ); compressing at least some of the stored vehicle parameter values; and/or adjusting the amount of reserved memory 9520 associated with at least some of the stored vehicle parameter values 9514 . Any other memory management operations as described throughout this disclosure are also contemplated as operations of parameter storage circuitry 9504 for parameter expiration schedule 9518 . The example parameter storage circuitry 9504 determines a reserved memory amount 9520 associated with at least a portion of the plurality of vehicle parameter values (e.g., memory allocation values on the storage endpoint 9508) and, depending on the reserved memory amount 9520, stores a plurality of at least a portion of the vehicle parameter values 9514 of the .

Determining the specific amount of storage depends on the formatting and/or processing applied to the data, and determining the amount of storage may take into account how and when the formatting and/or processing occurs. you'll see. For example, a downsampling operation reduces the number of data values utilized to capture a particular stream of data (e.g., a 10 second segment of data), and in certain embodiments, the downsampling process reduces the number of data values in which the data is stored. can be run before In another example, the upsampling process increases the number of data values utilized to capture a given stream of data, which is the same as the initial data to store memory storage for the collected data. Can be executed after storage. In examples, the upsampling operation is performed before the data is transmitted and/or the upsampling operation is performed by off-vehicle processing resources before the transmitted data is provided to the end user and/or placed in cloud storage. can do. In certain embodiments, frame removal or reduction, bit depth reduction, precision reduction (e.g., converting double precision floating point values to single precision floating point values), and/or certain lossless compression operations (e.g., all data Certain types of processing, such as storage of consistent values (such as parameter name values in a single place or several places, rather than with values) reduce storage resources and utilize fewer processing resources to store data values can be executed before the storage of In certain embodiments, certain types of processing, such as adding or enhancing frames, increasing bit depth, and/or increasing precision, increase the size of the stored data values and process ( e.g., to minimize storage size), selectively processing (e.g., in batches when processing resources on the vehicle are in relatively low utilization periods--shutdown operation, idle operation, steady-state operation, etc.) ), may maintain responsiveness when transmission opportunities arise but reduce the overall storage impact of collected data, and/or transfer processing to off-vehicle resources (e.g., to end-users). processing operations performed by off-vehicle resources prior to provisioning and/or placement in cloud storage). In certain embodiments, certain types of processing, such as lossy compression operations, more advanced lossy compression operations that utilize significant processing, reduce the impact on storage and allow processing resources to remain available. , and/or as the stored data changes over time. Thus, the storage management circuit 9506 can determine system characteristics including in-vehicle network communication resources, storage resources, processing resources and availability based on vehicle operating conditions, the availability of transmission resources (estimated time gaps between transmission opportunities, The amount of reserved memory 9520, the parameter expiration schedule 9518, the parameter transmission schedule 9516, and the Determine processing, format and/or memory management behavior choices to reduce costs, reduce resource utilization, avoid impacting vehicle controller and/or network zone mission (and mission critical) functions, and system capacity. (e.g., improved memory resource management provides the ability to service policies with greater data collection capacity for a given amount of memory storage). Any one or more aspects may allow for, for example, but not limited to, parameter expiration times, memory management operations to be performed and associated data age values for such operations, policy related data collection. The transmission delay values that can be used, the availability of external processing power, and/or the formatting or processing operations that are allowed to migrate out of the vehicle can be at least partially defined in the policy.

Exemplary operations for determining the amount of reserved memory 9520 include operations such as: determining the amount of data collected to support at least a portion of multiple vehicle parameter values (e.g., sampling rate, (based on upsampling and/or downsampling operations, formatting operations, number of data values, estimated occupancy time of data values, etc.) collected to support trigger evaluation associated with at least a portion of a plurality of vehicle parameter values. (e.g., relevant data used to determine trigger evaluations and/or rolling buffers or other historical data that may be captured based on trigger events); A transmission latency value (e.g., transmission delay) associated at least in part may be imposed due to the storage location of the data value and/or processing operations to be performed on the stored data prior to transmission, resulting in a The parameter storage circuit 9504 adjusts the amount of reserved memory 9520 to ensure acceptable service). The example parameter storage circuitry 9504 further determines the reserved amount of memory 9520 as a function of priority values associated with at least some of the vehicle parameter values. In certain embodiments, a high priority value associated with collected data values may indicate a higher memory allocation, eg, to ensure that those values are available for transmission. In certain embodiments, a high priority value associated with a collected data value is associated with a high priority value, e.g., due to high time degradation of the data value (e.g., collected data with a zero value after 5 minutes requires more than 5 minutes of storage). not), and/or indicate a lower memory allocation due to the high probability that the data will be sent before it occupies significant memory space. In particular embodiments, the parameter storage circuitry 9504 determines the amount of reserved memory 9520 based on a priority value and other considerations and/or allocated, for example, Reduce allocations to data collection units that underutilize memory, increase allocations to data collection units that overutilize their allocated memory, constantly experience memory management operations, and/or past transmission opportunity values, vehicle operations The amount of reserved memory 9520 can be further updated in response to feedback, such as making adjustments based on state values and the like. Exemplary priority values can be provided in the policy, at least the in-vehicle data storage priority, transmission priority, and/or priority for endpoints (eg, providing, requesting, and/or storing data values). , priority for flows (providing and/or requesting data values), priority for applications (e.g., providing and/or requesting data values), priority for entities (e.g., requesting data values), and priority for data values. An associated priority, such as a priority associated with a data type, is included, including any priority value defined herein.

Referring to FIG. 96, an exemplary procedure 9600 for selectively storing collected data parameters on a vehicle is schematically depicted. Exemplary procedure 9600 includes an operation 9602 of interpreting vehicle policy data values including requested vehicle properties, and an operation 9604 of obtaining vehicle parameter values responsive to the requested vehicle properties. The example procedure 9600 further includes an act 9606 of selectively storing at least some of the vehicle parameter values, at least some of the stored values being stored at endpoints separate from the provider endpoints. . Referring to FIG. 97, exemplary operations 9606 include determining a parameter transmission schedule for the stored parameters, operation 9702, and selectively storing at least some of the vehicle parameter values according to the transmission parameter schedule, operation 9704. ,including. Referring to FIG. 98, exemplary operations 9606 include determining a parameter expiration schedule for the stored parameters, operation 9802, and selectively storing at least a portion of the vehicle parameter values in response to the parameter expiration schedule. 9804 and Referring to FIG. 99, exemplary operations 9606 include an operation 9902 of determining an amount of reserved memory for stored parameters and an operation of selectively storing at least a portion of the vehicle parameter values in response to the amount of reserved memory. 9904 and

100-103, exemplary operations 9804 for selectively storing at least a portion of vehicle parameter values in response to a parameter expiration schedule are schematically depicted. Referring to diagram 100, operation 9804 includes deleting at least some of the stored vehicle parameter values. Referring to FIG. 101, operation 9804 includes summarizing at least some of the stored vehicle parameter values. Referring to FIG. 102, operation 9804 includes adjusting the amount of reserved memory associated with the stored vehicle parameters. Referring to FIG. 103, operation 9804 includes compressing at least some of the stored vehicle parameters.

104-107, exemplary operations 9902 for determining a reserved amount of memory for stored parameters are schematically depicted. Referring to FIG. 104, operation 9902 includes determining the amount of data collected to support vehicle parameter values. Referring to FIG. 105, operation 9902 includes determining the amount of data collected to support trigger evaluations related to vehicle parameter values. Referring to FIG. 106, operation 9902 includes determining transmission latency values associated with vehicle parameter values. Referring to FIG. 107, operation 9902 includes determining a priority value associated with the vehicle parameter value.

Referring to Fig. 108, an exemplary apparatus 10800 for performing data collection operations that implement data collection policies is schematically depicted. Exemplary device 10800 operates similarly to device 4500, with certain differences that are described here for purposes of illustration. Apparatus 10800 may be included in a system having a vehicle having one or more network zones as described throughout this disclosure, and aspects of apparatus 10800 may be defined in whole or in part as defined throughout this disclosure. may be included with any system, device, controller, and/or apparatus. Additionally or alternatively, aspects of any system, device, controller, and/or apparatus defined herein may be included in apparatus 10800, in whole or in part.

The example apparatus 10800 includes a policy acquisition circuit 2704 that interprets a data collection policy 10804 that includes at least one requested vehicle property and, for example, available vehicle parameter values in response to the data collection requirements of the data collection policy 10804. and policy processing circuitry 2706 that determines property request values 10806 in response to at least one requested vehicle property that translates terminology utilized in data collection policy 10804 to determine. Exemplary device 10800 interprets at least one vehicle parameter value 10808 in response to property request value 10806, eg, collects data from endpoints 2716 on one or more network zones 2718, 2720 of the vehicle. A parameter acquisition circuit 9502 is included. Exemplary apparatus 10800 further includes parameter providing circuitry 10802 that selectively transmits at least one vehicle parameter value 10808 in response to data collection policy 10804 to provide transmitted collected data 108010, for example. Exemplary apparatus 10800 provides parameters such that data collection policy 10804 can request standardization and/or interface selection parameter descriptions without a requesting device providing data collection policy 10804 that requires knowledge of the vehicle or vehicle configuration. Determining on-vehicle data in response to request data, such as determining vehicle configuration such as name translation, endpoint distribution, and network zone configuration.

Exemplary data collection policy 10804 includes a policy type, and parameter acquisition circuit 9502 further interprets vehicle parameter values 10808 as a function of the policy type. A policy type can be any type of policy as described herein, eg, a persistent policy, a discrete and/or restrictive policy type, and/or a streaming policy type. In certain embodiments, the policy types are additionally or alternatively policy types within a policy hierarchy, eg, built-in policy types, factory policy types, and/or downloaded policy types. In certain embodiments, parameter acquisition circuitry 9502 persistently evaluates data collection policy 10804 responsive to the policy type being a persistent policy type—eg, persistently collects data and/or Continuously evaluate data collection criteria to determine whether data will be collected. In certain embodiments, the parameter acquisition circuit 9502 ceases evaluating data collection in response to meeting the data collection cycle of the data collection policy—eg, if the policy type is an on-demand policy (eg, defined data collection is serviced), a policy type of streaming policy (e.g., abort after defined data collection is served), and/or a policy type of discrete or limited policy (e.g., data collection event a fixed number, abort after expiration of the period, etc.). In certain embodiments, policy acquisition circuitry 2704 deletes data collection policy 10804 in response to parameter acquisition circuitry 9502 discontinuing evaluation of data collection policy 10804—eg, removes the associated policy when the evaluation operation is discontinued. Delete and/or delete the associated policy after the associated collected data has been sent.

Exemplary policy retrieval circuitry 2704 executes the downloaded policy, if one exists. Policy acquisition circuit 2704 ignores factory and built-in policies if downloaded policies exist. Policy acquisition circuit 2704 implements the adaptation portion of the factory policy, if one exists. Policy acquisition circuit 2704 executes the factory policy if the factory policy exists and the downloaded policy does not exist. An example policy acquisition circuit 2704 ignores built-in policies if, for example, factory policies and/or downloaded policies are present. Policy acquisition circuit 2704 implements the matching portion of the built-in policy, if one exists.

Referring to FIG. 109, exemplary data collection policies 10804 include one or more of the following: vehicle properties 10902 (e.g., external devices, viewed from a user interface, and/or APIs (e.g., FIG. 121 and the related discussion)); data collection period 10904 (e.g., timing, number of times, expiration, etc. that define the policy's requested data collection period); transmission description values 10906 (e.g., transmission criteria such as time values, data chunk sizes, expiration dates, associated APNs, and/or transmission paths); trigger data description 10910 (e.g., define trigger conditions to be evaluated, data collected in response to trigger occurrences, and/or actions to be performed in response to trigger occurrences such as actuator commands, function adjustments, etc.) policy priority value 10912 (e.g., priority associated with the policy in general and/or priority associated with individual elements of the policy such as vehicle properties, transmissions, etc.), and/or policy life Cycle description 10914 (eg, number of times executed, completion time, and/or persistence and/or discrete operation values). The example data collection policy 10804 can be provided in any manner. In particular embodiments, data collection policy 10804 is a data structure readable by policy retrieval circuitry 2704, such as an HTML file, an XML file, a delimited file, a binary file, and/or parsable by data retrieval circuitry 2704. Provided as any data structure. In certain embodiments, the data collection policy 10804 is collected by external systems such as cloud-based systems, service tools, manufacturing tools, for example, as described in FIGS. created.

Referring to FIG. 110, exemplary transmission description values 10906 include one or more of the following: transmission priority value 11002 (eg, transmission priority value associated with collected data), data storage description 11004 ( data storage priority, amount of reserved memory, data aging and/or expiration parameters, etc.), network zone usage description 11006 (e.g., network zone usage priority for policy, and/or bandwidth allowance for network zone and/or or for usage value and/or policy data collection operations), and/or APN 11008 (eg, each associated collection data element with one or more APNs). Referring to FIG. 111, exemplary policy priority values 10912 include data collection priority value 11102 (e.g., provides a data collection priority description for the data collection element of the policy), data storage priority value 11104 ( for example, providing data storage priority information to the data collection component of the policy), and/or one or more of the transmission priority values 11106. Note that the configuration of policy elements is non-limiting example - for example, transmission priority values can be provided in transmission description value 10906 and/or policy priority value 10912 . Additionally or alternatively, the elements may apply to the policy as a whole and/or to individual data collection aspects of the policy. Referring to FIG. 112, an exemplary policy lifecycle description 10914 includes policy start time 11202, policy end time 11204, triggered data description 11206, amount of data captured 11208, number of data collection events 11210, and/or trigger Contains one or more of the number of event actions performed 11212.

Referring to FIG. 113, an exemplary procedure 11300 for collecting data according to policy is schematically depicted. The example procedure 11300 includes an operation 11302 of interpreting a data collection policy including the requested vehicle properties, an operation 11304 of determining property request values in response to the requested vehicle properties, and an operation 11304 of determining property request values in response to the requested vehicle properties. Including an act 11306 of interpreting the vehicle parameters and an act 11308 of selectively transmitting the vehicle parameters depending on the data collection policy.

Referring to FIG. 114, an exemplary cloud system 11400 for obtaining selected data from vehicles and/or partitioning access to stored collected data and data is shown. The example of FIG. 114 is described as a cloud-based system 11400 for clarity of explanation for describing aspects of the present disclosure. However, the operation of system 11400 may additionally or alternatively be performed in any system configuration external to the vehicle. For example, operations may be performed in whole or in part by a service tool, a manufacturing tool, a computing device at least selectively communicatively coupled to a vehicle, or other arrangements described herein. Exemplary systems, whether cloud-based systems, include cellular data connections, WiFi connections, physical port connections to vehicle network zones, Bluetooth connections, and/or any other system understood in the art. It includes an external device coupled to the vehicle using a connection. Operation of an in-vehicle network zone connection device, such as CES, CEG, and/or CND, to receive, configure, and/or update policies implemented in the vehicle using the vehicle's connection to any network zone. and send collected data. In particular embodiments, aspects of system 11400 may be implemented in the cloud and other aspects in another external device.

The example system 11400 includes a request interface 11402 configured to interpret multiple response action values 11404 from an external device 11424 . Response action values 11404 include, but are not limited to, one or more of: data values for collection (e.g., requested data collected from vehicles); trigger conditions for conditional actions (e.g., Observed data value for a property that indicates a triggering event, e.g., processed response such as rate of change of value determined by threshold, trigger based on number of values, "ON", "OFF", "ACTIVE", etc. and/or mode values such as operating mode indications, control operating states); time frame for data collection (e.g., calendar time; operating time for the vehicle; amount of time-based data collected - e.g., 3 minutes); time relative to an event detection or trigger condition, such as 3 minutes of data preceding the event, starting 5 minutes after the event); priority information attributed to any of the foregoing; sampling rate of data values; format (eg, parameter units, bit depth, metadata description, etc.); and/or data type associated with the data value. In certain embodiments, the responsive action value 11404 may be provided by user selection of preconfigured values, for example, the user may select "vehicle speed" for inclusion as the responsive action value 11404. . In certain embodiments, aspects of the response action values 11404 that the user is not permitted to request are hidden from the user, for example, by not providing such values to user interfaces operated on the external device 11424. can be done. In certain embodiments, aspects of the response action value 11404 that the user is not authorized to request may be annotated, such as with grayed out text, such values being generally available. not available with the user's current permissions. In certain embodiments, aspects of the response action values 11404 are presented to the user, for example by excluding values from the final data collection policy 11408 and/or excluding the entire set of response action values 11404 from the final data collection policy 11408. Authorization enforcement is performed by the policy creator circuit 11406 by doing so.

In the example of FIG. 114, response action value 11404 indicates a defined action for data collection, trigger evaluation, and/or automatic vehicle operation, and vehicle data request 11422 indicates the response collected in response to response action value 11404. A request to access vehicle data 11418 is shown. The terms utilized herein are exemplary and non-limiting.

The act of generating a data collection policy 11408 with excluded values can include notifying the user that the requested response action value 11404 was not allowed. In certain embodiments, in response to an attempted submission by a user, a notification to the user that the requested response action value 11404 was not authorized—e.g. specifies and allows the user to adjust the responsive action value 11404--is performed. In certain embodiments, a combination of these operations is utilized on the interface - for example, hiding some unauthorized parameters completely from the user (e.g., highly sensitive parameters only available to certain users). ), displaying to the user some disallowed parameters. Additionally or alternatively, some parameters may be made available subject to further approval, for example, an entity's managing or supervising user has permission to approve certain parameters as response action values 11404. Another user from an entity requesting specific parameters receives a notification requesting approval, and/or an administrative or supervisory user receives a notification that one or more of the specific parameters are requested. You can accept it. Additionally or alternatively, some parameters may be available based on subscription, particular version of the user interface (e.g., standard vs. premium versions of web portals, local applications, mobile applications, etc.). , where the interface may prompt the user to obtain authorization features (e.g., subscribe or update interface versions) and/or notifications associated with the parameter may indicate the features required to access the parameter. can be shown. In certain embodiments, certain parameters are access characteristics--e.g., insecure access to an interface and/or partial login behavior to an interface (e.g., entering a password but not the second step of two-step authentication). (e.g., does not perform), the request interface 11402 can selectively hide parameters that are not available based on access characteristics and/or display the parameters as inactive on the interface.

In particular embodiments, the request interface 11402 is configured according to the type of external device, associated entity, and/or user and user goals associated therewith. For example, the request interface 11402 for interaction with vehicle owners and/or third party application developers may use selections from menus to select data collection parameters, utilize templates, and/or It can be simplified, allowing it to have more limited capabilities. In another example, the request interface 11402 for interaction with sophisticated developers such as manufacturing entities, fleet owners, etc., includes a convenience interface and a complete policy data structure (e.g., HTML file, XML file, delimited files, binary files, etc.), or a combination of these (e.g., building an initial data structure based on menu interactions and selections and source generated thereby for direct editing and submission can access the file).

In certain embodiments, the user device 11424 for providing the response action value 11404 and the user device 11424 for providing the vehicle data request 11422 may be different devices and/or have different interfaces 11402. can access. In certain embodiments, the first user providing the response action value 11404 and the second user providing the vehicle data request 11422 may be separate users, users associated with different entities, and/or completely unrelated. be able to. For example, a third party application developer can provide a response action value 11404 and a vehicle data request 11422 can be provided by a vehicle owner. In certain embodiments, multiple separate users may access responsive vehicle data 11418 .

In the example of FIG. 114, the system 11400 includes a first cloud boundary for external devices 11424, a second cloud boundary for vehicles 11426, and a request interface 11402, a policy creator circuit 11406, a raw data manager 11406, and a A cloud system including circuitry 11416 and cloud interface circuitry 11412 is depicted. In certain embodiments, one or more aspects of the cloud system, or all aspects of the cloud system, are from the cloud system, e.g., with aspects located on the vehicle 11426, another external device, or a combination thereof. can be positioned apart. Additionally or alternatively, aspects of the cloud system 11400 may be provided as Internet-based aspects, web portals, mobile applications, or the like. Exemplary request interfaces 11402 include, for example, a first interface that operates as a web portal, another interface that operates as a mobile application, another interface that operates on tools (eg, service tools, manufacturing tools, etc.), and/or Or with another interface, such as on an external device 11424 running a local application on the device, including multiple options for interfacing with the cloud system. In certain embodiments, the capabilities available for interacting with the cloud system relate to the interface utilized for interaction (e.g., service tools with different capabilities for mobile applications), the user executing the interface. entity (e.g., third-party application provider, manufacturer, dealer, vehicle owner, etc.) and/or type of interaction with the cloud system (e.g., different capabilities for manufacturing tools directly coupled to the vehicle network zone). web portal access). Additionally or alternatively, interactions with the cloud system include, for example, between the cloud system and an external device, between the cloud system and the vehicle, and between components of the cloud system, executing a login interface. Verification and/or authorization can be utilized, such as encrypted communication. In certain embodiments, components of the cloud system may be separate devices, including physically separate devices and/or logically separate devices. For example, request interface 11402 may be embodied on a separate device (or group of devices) from raw data manager circuitry 11416 . In another example, a portion of request interface 11402 may be at least partially included on the external device and/or on the vehicle.

Exemplary system 11400 includes policy creator circuitry 11406 that determines data collection policy 11408 as a function of response action value 11404 , data collection policy 11408 including vehicle data identifier 11410 . In certain embodiments, policy creator circuit 11406 compiles multiple response action values 11404 from multiple users into data collection policy 11408, e.g., creates a single compiled data structure representing the policy, and/or provide multiple separate data structures representing policies. In particular embodiments, the policy creator circuit 11406 checks authorization for parts of the policy depending on the entity, user, application, flow, etc. providing each part. In certain embodiments, policy creator circuitry 11406 is capable of servicing data collection or other operations in response to policies, for example, vehicle data storage resources, processing resources, parameter availability, and/or transmission resources. Check the ability of the policy to determine whether. In certain embodiments, the policy manager on the vehicle further performs authorization and/or capability checks of the policy provided to the vehicle, for example, provides confirmation to the cloud interface circuit 11412 if the policy is accepted, and is removed, provide a notification to the cloud interface circuit 11412 .

Exemplary cloud interface circuitry 11412 is configured to access a vehicle, for example, and is configured to receive identified vehicle data 11414 collected in accordance with data collection policy 11408 . Vehicle Data Identifier 11410 is specifically identifiable information about the vehicle—such as a vehicle identification number (VIN), number, media access control (MAC) address from the vehicle's designated controller, or the like, and /or can be identifiable information that ensures that the identifying vehicle data 11414 can be matched to the vehicle and/or the vehicle data request 11422; Exemplary vehicle data identifier 11410 is a session identifier (eg, identifies a data collection “session” and/or data collection instance associated with a block of collected data provided in response to data collection policy 11408)— For example, a unique identifier included in the data collection policy 11408 and attached to the identified vehicle data 11414, personal information about the vehicle owner, and separated from other information such as the identification of the particular vehicle associated with the data. able to identify responsive vehicle data 11418, etc.; In certain embodiments, the vehicle data identifier 11410 utilized for a particular data collection policy 11408 may utilize a type of policy (e.g., persistent policies may utilize a first type of identifier, discrete and/or The streaming policy may utilize the second type of identifier) and/or depending on the importance of keeping the identification information separate from the response vehicle data 11418 for the particular system. be able to.

Exemplary raw data manager circuit 11416 stores at least a portion of received identified vehicle data 11414 , at least a portion of identified vehicle data including response vehicle data 11418 and identification data 11420 . The identification data 11420 can be the same as the vehicle data identifier 11410 or can be a different identifier. In certain embodiments, the response vehicle data 11418 can be encrypted separately from the identification data 11420 so that the raw data manager circuit 11416 can compare the associated identification data 11420 without accessing the response vehicle data 11418. to provide correct response vehicle data 11418. Separation of Response Vehicle Data 11418 does not allow inappropriate access to a single aspect of the cloud system to match response data 11418 with identifying information such as owner name, specific vehicle, etc. Risk of Data Breach promote the separation of Exemplary identification data 11420 includes metadata specific to a particular set of response action values 11404 .

The example request interface 11402 interprets the vehicle data request 11422 and obtains at least a portion of the responsive vehicle data 11418 from the raw data manager circuit 11416 in response to the vehicle data request 11422 . Exemplary request interface 11402 provides the acquired data to external device 11424 .

Exemplary system 11400 includes response vehicle data 11418 encrypted using a first encryption keyset and identification data 11420 encrypted using a second encryption keyset. Accordingly, raw data manager circuit 11416 may be configured to identify response data to vehicle data request 11422 without accessing response vehicle data 11418 . In particular embodiments, raw data manager circuitry 11416 may utilize hash checks or other operations to identify responsive data. In certain embodiments, encryption keys for decrypting responsive vehicle data 11418 may not exist on cloud system 11400 and/or may not be available to selected portions of cloud system 11400 (e.g., not available to raw data manager circuit 11416).

Referring to FIG. 115, an exemplary cloud system 11500 for obtaining selected data from vehicles and/or partitioning access to stored collected data and data is schematically depicted. The example of FIG. 115 is described as a cloud-based system 11500 for clarity of explanation for describing aspects of the present disclosure. However, the operation of system 11500 may additionally or alternatively be performed in any system configuration external to the vehicle.

The exemplary system 11500 includes a collection vehicle data storage circuit 11502 that stores collected data 11504 from the vehicle, and a vehicle data collection request 11508 that is selected from external devices to the vehicle, such as by processing vehicle data collection requests 11508 into policy data structures that are provided to the vehicle. and an external data collection interface 11506 that is publicly provided. The example external data collection interface 11506 also provides at least a portion of the stored collected data 11504 from the collected vehicle data storage circuitry 11502 in response to vehicle data requests 11510 from external devices. The exemplary system includes separating at least a portion of the stored collected data 11504 and an encryption key for at least a portion of the stored collected data 11504 . Exemplary arrangements for separating the encryption key from at least a portion of the stored collected data 11504 include, but are not limited to other aspects of this disclosure, separate encryption, hashing, and hashing of the identification portion of the data and the payload portion of the data. Including identification and/or verification of the payload portion of the data using checks and/or identification and/or verification of the payload portion using another identifier for the payload portion. Exemplary external data collection interface 11506 implements vehicle data collection by providing requests 11508 to collected vehicle data storage circuitry 11502 and/or policy creator circuitry 11406 (see, eg, FIG. 114 and related discussion). Optionally provide a request 11508 to the vehicle.

Referring to FIG. 116, an exemplary procedure 11600 for data collection operations from a vehicle is schematically depicted. Exemplary procedure 11600 includes an act 11602 of interpreting a response operational value from an external device, and an act 11604 of determining a data collection policy as a function of the operational value, the data collection policy including the vehicle data identifier. The example procedure 11600 includes an operation 11606 of receiving vehicle data identified in accordance with a data collection policy, an operation 11608 of storing the received identification data and associated identification data from the vehicle in accordance with the data collection policy; and an act 11610 of interpreting the vehicle data request and obtaining at least a portion of the data in response.

Referring to FIG. 117, an exemplary procedure 11700 for separating response data to vehicle data collection operations from access to response data is schematically depicted. Exemplary procedure 11700 includes act 11702 of encrypting response data using a first encryption key and act 11704 of encrypting identification data using a second encryption key. In certain embodiments, the identification data may not be encrypted. The example procedure 11700 utilizes an act 11706 of storing the response data on a memory separate from the first encryption key and using the second encryption key (and/or utilizing the identification data). and an operation 11708 of obtaining the requested data.

Referring to FIG. 118, an exemplary procedure 11800 for separating response data to vehicle data collection operations from access to response data is schematically depicted. The example procedure 11800 includes an act 11802 of encrypting response data for storage on a first memory and an act 11804 of interpreting a vehicle data request directed to at least a portion of the encrypted response data. , and accessing the requested portion of the encrypted response data using the unencrypted identifier and/or the otherwise encrypted identifier 11808 .

Referring to FIG. 119, an exemplary system 11900 for obtaining selected data from a vehicle and/or partitioning access to stored collected data and data is depicted schematically. The example system 11900 utilizes vehicle data 11902 provided by a vehicle operating a data collection policy on the vehicle to generate responsive cryptograms collected in response to a data collection vehicle description 11408 (and/or policy). includes a raw data manager circuit 11416 that stores formatted data 11418; The example system 11900 includes an external data collection interface 11506 that provides at least a portion of the responsive encrypted data 11418 to an external device in response to the vehicle data request 11510 . In the example of FIG. 119, the encryption key 11512 for the responding encrypted data 11418 is separated, for example, to determine the portion of the responding encrypted data 11418 without decrypting the responding encrypted data 11418 . is kept separate from the raw data manager circuit 11416, such as using the identification data 11420 of the . 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. . Although in the example of FIG. 119 the discontinuity between response data encryption key 11512 and raw data manager circuit 11416 is explicitly drawn for illustration purposes, response data encryption key 11512 can be stored in a different device (another physical device or another logical device).

Referring to FIG. 120, exemplary and non-limiting examples of identification data 11420 are depicted. Exemplary identification data 11420 may include collected vehicle data metadata 12002, data collection session identifiers 12004, identifiers constructed in the absence of personally identifiable information (PII), and/or identification data ( For example, request interface 11402 and/or policy manager on vehicle provides a consent notice to an external device, where consent notice also includes consent to information presented in identification data 11420).

Referring to FIG. 121, an example cloud system for creating data collection policies and collecting response data from vehicles is schematically depicted. The example of FIG. 121 is described as a cloud-based system 12100 for clarity of explanation for describing aspects of the present disclosure. However, the operation of system 12100 may additionally or alternatively be performed in any system configuration external to the vehicle.

The example 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 creator 11408 to determine a data collection policy 11408 in response to the vehicle data collection request 12110. circuit 11406; The exemplary cloud interface comprises a raw data manager circuit (see, eg, FIG. 114) that provides data collection policies 11408 to vehicles and stores at least a portion of responsive vehicle data received from vehicles. .

The example request interface 11402 is further configured to expose an application programming interface (API) (eg, data collection API 12102) to the external devices 12104, 12106, 12108. APIs, for example, web portals, mobile applications, tools, local applications, etc., to operate interfaces for selecting data values available for collection, any of the policies described herein. Access to any selection operation can be included, such as configuring a data structure containing aspects and/or requesting data 14118 in response after a collection operation. The example request interface 11402 further interprets the vehicle data request 12112 and provides data retrieved from the response vehicle data 11418 to the external device in response to the vehicle data request 12112 . Data collection request 12110 and/or vehicle data request 12112 may be received based on interaction with a user interface provided on the external device and/or in response to user execution of API 12102, user-activated application, etc. . Exemplary policy creator circuit 11406 determines data collection policy 11408 as a function of data collection request 12110 and/or further as a function of policy collection authorization value 12120 and/or policy collection capability value 12118 .

An exemplary operation of policy creator circuit 11406 to determine policy authorization value 12118 is data storage size determined to support vehicle data collection requests, transmission volume value determined to support vehicle data collection requests, vehicle Determining a policy authorization value 12118 as a function of one or more of a data availability value associated with the data collection request or a data configuration value associated with the vehicle data collection request. An exemplary operation of the policy creator circuit is, in response to the vehicle data collection request 12110 and the at least one additional vehicle data collection request 12110, determine a policy authorization value 12118; selectively enabling at least one of determining a 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 creator circuit 11406 further determines the data storage size determined to support each of the vehicle data collection request 12110 and the at least one additional vehicle data collection request 12110, the vehicle data collection request 12110 and the at least one additional vehicle data collection request. a transmission volume value determined to support each of the requests 12110; a data availability value for each of the vehicle data collection requests 12110 and at least one additional vehicle data collection request 12110; the vehicle data collection requests 12110 and the at least one additional vehicle data; such as data configuration values associated with each of the collection requests 12110, or prioritization between one or more vehicle data collection requests 12110 and at least one additional vehicle data collection request 12110 of any of the foregoing; A policy authorization value 12118 is determined as a function of at least one parameter.

The example policy creator circuit 11406 determines a policy authorization value 12120 in response to the vehicle data collection request 12110 and selectively enables determination of the data collection policy 11408 in response to the policy authorization value, or Performing at least one action, such as determining a data collection policy 11408 to support at least a portion of the data collection request 12110 . The request interface 11402 provides at least one use case value 12116 to the user interface, each use case value 12116 including a vehicle data collection template 12114, and a response from the user interface to the provided at least one use case value 12116. It is configured to determine the vehicle data collection request 12110 accordingly. The request interface 11402 includes the entity type associated with the user interface, the permission value associated with the user interface, and the previous data collection policy determined for the user with the shared characteristics determined for the user interface. is further configured to determine at least one use case value in response to at least one of

Referring to FIG. 122, an exemplary policy creator circuit 11406 is depicted schematically. An exemplary policy creator circuit 11406 can be utilized in any system herein and/or associated with policy determination, interpretation, and/or creation of data collection actions herein. You can perform actions that The example policy creator circuit 11406 determines policy collection capability values 12118 in response to received data collection requests 12110 . In particular embodiments, the policy creator circuit 11406 determines policy collection capability values 12118 as a function of capability considerations 12202 such as: data storage support for servicing policies; data transmission support, data availability to support the policy (e.g., requested data values are available), data format, processing, and/or configuration support for the policy (e.g., units in which parameters are requested, bit depth) , sampling rate, response time, etc. (including whether processing support resources are available to perform operations to format and/or configure collected data), resource permissions associated with the request (For example, the entity, flow, and/or application associated with the data collection request 12110 has sufficient permission to utilize supporting resources and/or consumes the amount of supporting resources necessary to support the data collection request 12110. and/or priority comparison between requests (e.g., filtering out lower priority data collection requests 12110 if the overall policy including all requests exceeds the capacity value). can be done).

Referring to FIG. 123, an exemplary request interface 11402 for providing use case and/or template selections to an external device is schematically depicted. An exemplary request interface 11402 may be utilized in any system herein and/or herein associated with determining, interpreting, and/or creating policy and/or data collection actions. Actions and actions related to receiving and processing data collection requests can be performed. The example request interface 11402 determines data collection templates 12114 and/or data collection use cases 12116 to provide to external devices 12104, 12106, 12108 over the interface, where the use cases 12116 and/or templates 12114 provide data It is selectable as a collection request and/or available for modification to quickly configure the data collection request. The example request interface 11402 determines data collection templates 12114 and/or data collection use cases 12116 depending on selection considerations 12302 such as: entity type (eg, entity type—eg, manufacturing provide useful use cases and/or templates according to vendors, service organizations, application developers, dealers, vehicle operators, vehicle owners, etc.); permission values associated with interface external devices (e.g., similar permission profiles here users with similar permissions profiles are likely to seek similar data, and/or users with similar authorization profiles are effectively using the same templates and/or use cases due to duplication of available parameters. available), previous data collection policies and/or requests from the same user (and/or the same entity, same external device, same access location, etc.), and/or previous data collection policies and/or requests from other users that have characteristics in common with the user data collection policies and/or requirements (e.g., expressed goals, entity types, permission values, and/or categorical selections by users, where categorical selections are subject to data collection, location data, powertrain data , feature utilization data, etc.—and may also relate to intended use of collected data, service features, efficiency features, operator convenience features, etc.).

Referring to FIG. 124, an exemplary procedure 12400 for operating a request interface to determine data collection requests and/or collected data access requests is schematically depicted. An exemplary procedure 12400 includes an act 12402 of exposing a data collection API to an external device, an act 12404 of interpreting a vehicle data collection request in response to execution of the API, and determining a data collection policy in response to the vehicle data collection request. and operation 12406 . The exemplary procedure 12400 includes an act 12408 of providing a data collection policy to the vehicle, an act 12410 of receiving responsive vehicle data collected in response to the data collection policy, and an act 12412 of storing at least a portion of the responsive data. and including. The example procedure 124000 includes an act 12414 of interpreting a vehicle data request in response to execution of an API, an act 12416 of retrieving at least a portion of the stored data in response to the vehicle data request, and an operation 12416 transmitting the retrieved data to an external device. and a providing operation 12418 .

125-130, exemplary embodiments of the present disclosure are schematically depicted for operating container-based implementations of one or more control aspects of a vehicle. The devices, systems, circuits, and/or operations described in connection with FIGS. 125-130 and the associated description can be utilized in any embodiment of the present disclosure, including the embodiments of FIGS. 17-25. 17-25 may be utilized in whole or in part with the embodiment of FIGS. 125-130. Utilization of a container-based implementation of one or more control aspects of a vehicle utilizes aspects of embodiments of the present disclosure, including, but not limited to. The policy implementation infrastructure described herein can be utilized to install, update, enable, disable, and/or configure control actions and/or features on any network zone of any type. vehicle controller, enabled from aspects such as the ability of embodiments herein to obtain and/or provide data values to any endpoint of the vehicle, and the ability to determine, manage, and respond to network usage of vehicle network zones to allow distribution of control actions over Leveraging the policy implementation infrastructure described herein to perform authorization, verification, and capability determination operations, as well as container-based implementation of one or more control aspects of a vehicle. Allows external data transmission control and management, including resource management, to support increased burden and/or complexity. In certain embodiments, container-based implementation of one or more control aspects of a vehicle includes all or selected portions of available controllers on the vehicle, selected control operations on the vehicle, and/or Contain endpoints for selected network zones.

Referring to FIG. 125, exemplary apparatus 12500 includes container retrieval circuitry 12502 that interprets container application values 12508 each including an application operable on a vehicle endpoint. A container application value 12508 is an image, eg. The container application values 12508, either alone or in combination with instructions on the vehicle's controller, are executed by the processor on the vehicle's controller to provide the processor with the functions embodied in the container application values 12508--e.g., prime mover control, operator interface control. is another type of image containing computer readable instructions for performing actions--such as control actions of vehicle components. Exemplary apparatus 12500 includes container security circuitry 12504 that interprets authorization values 12510 associated with each of container application values 12508 . In certain embodiments, if the container application value 12508 appears to have insufficient authorization, the container application value 12508 is eliminated (eg, not downloaded) and/or, for example, the authorization value 12510 is later transferred to the respective container. It may be installed but disabled (eg, not running) to reduce download time at a later time when application values 12508 can be modified without re-downloading. The example device 12500 interprets the container policy 12512 and configures operational parameters 12516 for each of the plurality of container application values 12508 in response to the container policy 12512 and the authorization values 12510 associated with each of the plurality of container application values 12508 . A container orchestration circuit 12506 that determines the . In particular embodiments, the container policy 12512 includes one or more of the following: (e.g., based on application output values, application accessed data, application operation type, etc.) an authorization description defining authorization values 12510 required to perform an action, a data dependency description of container application values 12508 (e.g., which container applications depend on each other's data), one or more of container application values 12508 execution order (e.g., used to enforce selected order dependencies for applications), priority values of one or more of container application values 12508, and/or one or two of container application values 12508 Latency descriptions (eg, acceptable time delays for data used by applications and/or time delays between execution events of related applications).

The example container orchestration circuitry 12506 is further configured to distribute multiple container application values 12508 across multiple endpoints of the vehicle (eg, determine which container application values are provided on which controllers of the vehicle). is configured to Exemplary container orchestration circuitry 12506 may further coordinate multiple containers to balance the workload of the controller, including the number of endpoints, e.g., to balance the utilization of processing resources and/or data storage resources of the controller. configured to distribute application values 12508; The example container orchestration circuitry 12506 is further configured to distribute multiple container application values 12508 to balance network communication loads in multiple network zones of the vehicle, e.g., parameter values passed between applications. , and the layout of the controllers on the various network zones, to balance network zone utilization and/or limit network zone utilization within capacity limits and/or within given utilization limits. Distribute application value 12508 . The example container orchestration circuitry 12506 is further configured to distribute the plurality of container application values 12508 according to the network communication load of the vehicle network zone.

Exemplary container security circuitry 12504 is further configured to determine authorization value 12510 in response to an authorization associated with an entity providing each of the plurality of container application values, e.g. and/or have authorization to provide actuation commands utilized by the application corresponding to container application value 12508 . Exemplary container security circuitry 12504 is further configured to determine authorization value 12510 as a function of authorization requirements associated with operation of each of plurality of container application values 12508 . Exemplary container security circuitry 12504 is further configured to determine authorization requirements as a function of input data values for each of plurality of container application values 12508 . The example container security circuitry 12504 is further configured to determine authorization requirements as a function of the output data value of each of the plurality of container application values 12508. The example container security circuitry 12504 is further configured to determine authorization requirements as a function of actuator command values for each of a plurality of container application values 12508 . The example container security circuitry 12504 is further configured to determine authorization requirements as a function of memory support values for each of a plurality of container application values 12508 . Exemplary memory support values include one or more of an installed memory support value and/or an operating memory support value. The example container security circuitry 12504 is further configured to determine authorization requirements as a function of processing support values for each of the plurality of container application values.

The example container acquisition circuitry 12502 is further configured to interpret additional container application values (e.g., utilized to update applications and/or add new applications to the vehicle) to facilitate container orchestration. Circuitry 12506 is further configured to update plurality of container application values 12508 and operational parameters 12516 for additional container application values 12508 in response to additional container application values 12508 . The example container orchestration circuit 12506 distributes the added container application value 12508 to the selected endpoints of the vehicle according to the selected endpoint's ability to execute the added container application value 12508. is further configured to The example container orchestration circuit 12506 changes the distribution of the container application values 12508 across the endpoints of the vehicle in response to the added container application values 12508 - e.g., the added container application values 12508 to rebalance and/or provide the ability to execute installed container application values 12508—further configured.

The example container acquisition circuit 12502 may include multiple container application values 12508, wherein container orchestration circuitry 12506 is further configured to determine operational parameters 12516 as a function of the valid values. The example container orchestration circuitry 12506 is further configured to interpret vehicle operating conditions and determine operating parameters 12516 in response to the vehicle operating conditions—eg, operating parameters until a selected vehicle operating condition exists. Certain operating states that delay reconfiguration of 12516 (e.g., stationary, stopped, idle, etc.) and/or disable selected actions of the application based on vehicle operating state, e.g., features not utilized in the particular operating state. provides behavior in response to operational conditions, such as enabling features to be utilized and/or changing the rate and/or order of execution of features depending on operational conditions. The example container orchestration circuitry 12506 is further configured to interpret vehicle configuration values (eg, indicating power rating, trim level, performance rating, model identifier, etc.) and determine operating parameters in response to the vehicle configuration values. be done.

Referring to FIG. 126, exemplary container operating parameters 12516 are schematically depicted. In particular embodiments, container operational parameters 12516 may be stored as a local container registry (see, eg, FIG. 17 and related discussion). Exemplary container operational parameters 12516 include container location 12602 (e.g., location where container application value 12508 is installed), container execution order 12604 (e.g., a list of container application execution orders, and in certain embodiments: container application values 12508 provided on a given controller), and/or container data instructions 12606 (e.g., one or more, or all of which are utilized by container application values 12508 and /or provide a description of the data value, including the format and/or processing for the data value being provided.

Referring to FIG. 127, exemplary authorization values 12510 are depicted schematically. In a particular embodiment, authorization values 12510 are permissions associated with container provider 12702, permissions associated with container input data 12704, permissions associated with container output data 12706, permissions associated with actuator commands accessed by the container. 12708, permissions 127010 related to container memory support, and/or permissions 12712 related to container processing support.

Referring to FIG. 128, exemplary vehicle resource information 12514 values are schematically depicted. In certain embodiments, one or more aspects of vehicle resource information 12514 are utilized by container orchestration circuitry 12506 to determine capacity and/or load balancing of container operations and to determine container application values 12508 across vehicle endpoints. is used to determine container operating parameters 12516, including the distribution of Exemplary vehicle resource information 12514 includes one or more aspects such as: endpoint processing capability description 12802, endpoint memory capability description 12804, endpoint I/O description 12806 (eg, which sensors and/or or whether the actuator is operatively coupled to a given endpoint and/or sensor and/or actuator configuration such as voltage range, electrical characteristics, A/D processing behavior, etc.), endpoint network zone location 12808 , a network zone capability description 12810 (e.g., including bandwidth, latency, synchronization description, types of messages available, network protocols, etc.), a convergence device capability description 12812 (e.g., CEG, CES, and/or CND data throughput and/or processing power); redundancy support considerations 12814 (e.g., redundancy such as alternate container applications that can perform all or part of another container application's operations in response to communication loss, endpoint loss, off-nominal behavior, etc.); and/or data and/or control security considerations 12816 (e.g., network zones deemed insufficiently secure for certain types of data and/or control functions, etc.); ).

Referring to FIG. 129, an exemplary procedure 12900 for providing a containerized implementation of one or more control actions on a vehicle is depicted schematically. The example procedure 12900 includes an operation 12902 to interpret container application values, an operation 12904 to interpret authorization values associated with each of the container application values, an operation 12904 to interpret container policies, an operation 12906 to interpret container policies and authorization values. and determining operational parameters for each of the container application values accordingly 12908 . Referring to FIG. 130, an exemplary procedure 13000 for providing a containerized implementation of one or more control actions on a vehicle is schematically depicted. Exemplary procedure 13000 includes an act 13002 for distributing container application value (eg, installing a container application) across multiple endpoints of a vehicle.

With reference to FIGS. 131-134, exemplary embodiments of the present disclosure include detected data values, data value responses, combined data values and/or responses, and trigger evaluation, as described throughout this disclosure. is schematically drawn to provide automated vehicle operation based on The devices, systems, circuits, and/or operations defined in connection with FIGS. 131-134 and the associated description can be utilized in any embodiment of the present disclosure, including the embodiments of FIGS. 1-16. and/or aspects of the embodiments depicted in Figures 1-16 may be utilized in whole or in part with the embodiments of Figures 131-134. Utilization of vehicle auto-response behavior takes advantage of several aspects of embodiments of the present disclosure--including, but not limited to, enabling rapid deployment configuration of features utilizing little or no application development resources for the features. enabling the installation and use of features with a light footprint in terms of rendering, validating, installing and distributing features to multiple vehicles, creative third parties and/or vehicle owners/drivers can provide high value and/or convenience enhancements for interacting with the vehicle, and/or feature installation (e.g., also installing functionality (e.g., as a containerized application) for the first time and later (e.g., to provide validation time, to provide distributed applications, etc., to provide validation time, to provide distributed rollout risk, etc.). In form, aspects of the present disclosure enable highly capable automated vehicle operations, including aspects such as: obtaining data values to any endpoint on any type of network zone and/or functions that protect vehicle security and mission integrity; the ability to control access to endpoints, applications, flows, and/or actuators; The ability to access any data and/or any actuators on the vehicle, and/or the use of external device facing interfaces and APIs to provide select user experiences and facilitate access to available capabilities of the vehicle. and the like.

Referring to FIG. 131, an exemplary apparatus for performing automated operations on a vehicle is schematically depicted. Exemplary apparatus 13100 includes automatic action circuitry 13102 configured to interpret automatic action values 13110 including automatic action description 13112 for the vehicle. The example apparatus 13100 further includes an automation manager circuit 13104 configured to determine trigger description values 13114 as a function of the automatic action values 13110, where the trigger description values 13114 are linked to trigger state values 13116 (e.g., data values, operating states, state values, and/or mode values that define detection values used to determine whether a trigger event has occurred), and trigger response values 13118 (e.g., actuator operation, data collection, notification or actions to be performed in response to the occurrence of a triggering event 13120 including providing an alert). Exemplary apparatus 13100 further includes trigger evaluation circuitry 13106 configured to determine trigger event occurrence 13120 in response to trigger status value 13116 and at least one vehicle data value 13122 . Exemplary apparatus 13100 includes task and/or trigger execution circuitry 13108 configured to execute trigger response 13124 in response to trigger event occurrence 13120 . Embodiments of the present disclosure can perform one or more tasks without triggers.

Exemplary, non-limiting trigger responses 13124 include performing data collection operations 13402 (see, eg, FIG. 134), providing actuator command values 13404, and/or including operations such as enabling operation of features 13406; Exemplary trigger responses 13124 may, for example, provide immediate feedback to a user that an action has been initiated, provide immediate notification or external communication, and/or Including providing high priority responses 13408 to allow a quick user experience, such as providing high priority actuator commands (eg, unlock doors) as part of 13124 . Exemplary automatic action values 13110 may, for example, provide pre-configured actions available on the interface to enable rapid configuration of automatic actions, and/or certain actions always together or From a number of pre-configured automatic action values 13110 to ensure that it runs in a determined configuration (e.g., check aspects before allowing engine start, such as zero vehicle speed, forced door closing, etc.). including the selection of The example automation manager circuit 13104 is further configured to determine authorization values 13126 associated with the automatic action values 13110 and selectively determine trigger description values 13114 in response to the authorization values 13110 (e.g., if the authorization is If insufficient, preclude enforcement of automatic action value 13110, notify not to enforce automatic action value 13110, etc.). The example automation manager circuit 13104 further defines the trigger description value 13114 as a permanent value (eg, similar to permanent policy enforcement) and/or as a limited execution value (eg, a limited and/or separate policy (similar to the implementation of ). The example automation manager circuit 13104 is further configured to maintain the vehicle's receiver in the selected power mode during selected operating conditions of the vehicle--e.g. Maintaining the vehicle's receiver in a selected power mode to enable exchange of external data to support autonomous driving and/or to enhance vehicle response time. The example automation manager circuit 13104 further maintains at least one controller of the vehicle in a selected power mode during selected operating conditions of the vehicle, e.g., monitors data values that support automated operation, and /or monitor the trigger state value 13116 and/or reduce the vehicle's response time to automatic actions, e.g., keep the controller selected for power modes with reduced wake-up time and/or eliminated to manage power consumption. while being configured to reduce vehicle response time. The example automation manager circuit 13104 maintains at least one controller of the vehicle in a selected power mode depending on the contents of the trigger description value 13114 (e.g., the selected controller associated with the monitored value and/or actuator). power mode).

Referring to FIG. 132, an exemplary procedure 13200 for implementing automated driving of a vehicle is schematically depicted. The exemplary procedure 13200 includes operations 13202 for interpreting automatic action values, operations 13204 for determining trigger description values in response to the automatic action values, and operations 13204 for determining trigger event occurrences in response to trigger state values and vehicle data values. 13206 and an act 13208 of executing the trigger response in response to the trigger event occurrence. In embodiments, one or more triggers/event responses may be included in a recipe that can be created via an external tool, such as a cloud application, and deployed to one or more vehicles. Referring to FIG. 133, another exemplary procedure 13300 for implementing automated vehicle operation is schematically depicted. Exemplary procedure 13300, in addition to procedure 13200, further includes an operation 13302 for maintaining the controller and/or receiver (eg, WiFi and/or cellular data receiver) in the selected power mode.

Referring to Fig. 135, an exemplary apparatus 13500 for vehicle data transmission operations with a cloud system and/or external devices is schematically depicted. The exemplary apparatus 13500 comprises a policy acquisition circuit 13502 that interprets a vehicle policy data value 13508 that includes at least one requested vehicle property 13510, and at least one a parameter acquisition circuit 13504 configured to interpret a plurality of vehicle parameter values 13512 in response to one requested vehicle property 13508; Exemplary vehicle policy data values 13508 further include authorization value 13522 for determining whether transmission is authorized and/or whether particular transmission resource utilization is authorized. can be used to Exemplary apparatus 13500 includes vehicle data transmission circuitry 13506 that selectively transmits at least a portion of collected vehicle data 13520 provided by an endpoint, eg, in response to vehicle parameter values 13512 and provided as transmitted vehicle data 13518. Including further. In certain embodiments, vehicle parameter values 13512 are obtained from vehicle network zones and/or requested from endpoints for which a given vehicle parameter value 13512 is not already available on the network zone.

Exemplary vehicle data transmission circuitry 13506 further selectively transmits at least a portion of collected vehicle data 13520 by selecting a transmission interval 13516 for at least a portion of collected vehicle data 13520 . Exemplary vehicle data transmission circuitry 13506 further determines the interval provided in vehicle policy data value 13508, the interval according to the priority of at least a portion of collected vehicle data 13520, the availability description for transmitting the resource. The transmission interval 13516 is configured to select a transmission interval 13516 in response to at least one of the selected intervals (eg, any of the following). based on current vehicle operating conditions, availability of external data communications, current bandwidth of network zones supporting external communications, and/or transceivers providing external communications, for at least some of the collected vehicle data 13520; , an interval dependent on past transmission availability to the vehicle and/or an interval corresponding to the operational state of the vehicle.

Exemplary vehicle data transmission circuitry 13506 selects bandwidth utilization 13524 for at least a portion of collected vehicle data 13520 (eg, acceptable bandwidth utilization for elements of collected vehicle data 13520). and is further configured to selectively transmit at least a portion of the vehicle data 13520 received. The example vehicle data transmission circuit 13506 further determines the bandwidth utilization provided in the vehicle policy data value, the bandwidth utilization according to the priority of at least a portion of the collected vehicle data 13520, the collected vehicle data Bandwidth utilization 13524 as a function of at least one of an availability description for at least some of the transmission resources of 13520, an interval as a function of past transmission availability for the vehicle, or an operational state of the vehicle. configured to select.

The example vehicle data transmission circuitry 13506 is configured to selectively transmit at least a portion of the collected vehicle data 13520 by selecting a transmission interval 13516 as a function of a data type 13514 of at least a portion of the collected vehicle data 13520. is further configured to Vehicle data transmission circuitry 13506 is further responsive to vehicle operational effects 13536 of transmission operations (e.g., network zone and/or external data transfer resource utilization by various vehicle operating conditions such as operating conditions, power throughput, engine speed, etc.). based on) to selectively transmit at least a portion of the collected vehicle data 13520. The vehicle data transmission circuitry is further configured to selectively transmit at least a portion of the collected vehicle data depending on the power usage impact of the transmission operation. Vehicle data transmission circuitry 13506 is further configured to selectively transmit at least a portion of collected vehicle data 13520 in response to data transmission capacity value 13532 . Data transmission capacity values 13532 include at least one data transmission capacity value such as: data transmission capacity 13532 associated with a time interval (e.g., transmission rate and/or amount of data over a given period of time); data transmission capacity 13532 for entities associated with at least a portion of the collected vehicle data; data transmission capacity 13532 for access point names; data transmission capacity 13532 for flows associated with at least a portion of the collected vehicle data; including a data transmission capacity value of at least one of a data transmission capacity 13532 related to a vehicle application related to at least a portion of the data or a data transmission capacity 13532 related to a vehicle function related to at least a portion of the collected vehicle data. .

Exemplary vehicle data transmission circuitry 13506 further selectively transmits at least a portion of collected vehicle data 13520 according to currently available transmission types 13526, such as cellular data transmission, WiFi transmission, physically connected device transmission, etc. is configured as Vehicle data transmission circuitry 13506 is further configured to selectively transmit at least a portion of the collected vehicle data by selecting a data transmission chunk size 13538 for at least a portion of the collected vehicle data. . Data send chunk size 13538 includes at least one of an individual message size (eg, packet size value) or a single send flow size (eg, amount of data to be sent during a single send attempt period). The example vehicle data transmission circuitry 13506 is further configured to select a transmission chunk size 13538 in response to at least one of: the transmission chunk size provided in the vehicle policy data value; The transmission chunk size for at least some of the priority of the data (e.g., increasing the chunk size to pass high priority data faster and/or increasing the chunk size to improve the transmission success rate of high priority data) transmission chunk size depending on the availability description for transmission resources for at least a portion of the collected vehicle data (e.g., configuring the chunk size based on available transmission resource capabilities), past transmissions to the vehicle Transmission chunk size according to availability or vehicle operating state. The example vehicle transmission circuitry 13506 is further configured to coordinate selectively transmitting at least a portion of the collected vehicle data (e.g., transmission allow adjustments and/or variations in parameters to continuously improve transmission and/or adapt transmission parameters to circumstances). The vehicle transmission circuitry is further configured to coordinate selectively transmitting at least a portion of the collected vehicle data in response to a quality of service parameter 13528 for transmission operations (e.g., improve quality of service). adapting transmission selection to enforce quality of service requirements, etc.).

Referring to FIG. 136, an exemplary procedure 13600 for managing vehicle transmission operations is schematically depicted. Exemplary procedure 13600 includes an act of interpreting vehicle policy data values 13602, an act of interpreting vehicle parameter values 13604 in response to vehicle properties of the vehicle policy data values, and selectively extracting at least a portion of the collected vehicle data. and a send operation 13606 . 137-146, exemplary operations 13606 for selectively transmitting at least a portion of the collected vehicle data are schematically depicted. Referring to FIG. 137, operation 13606 includes selectively transmitting collected data according to a selected transmission interval. Referring to FIG. 138, operation 13606 includes selectively transmitting collected data according to the selected bandwidth utilization. Referring to FIG. 139, operation 13606 includes selectively transmitting the collected data depending on the data type of the collected data. Referring to FIG. 140, operation 13606 includes selectively transmitting collected data in response to vehicle operational impact of the transmission operation. Referring to FIG. 141, operation 13606 includes selectively transmitting collected data depending on the power usage impact of the transmission operation. Referring to FIG. 142, operation 13606 includes selectively transmitting collected data depending on the data transmission capacity value. Referring to FIG. 143, operation 13606 includes selectively transmitting collected data according to currently available transmission types. Referring to FIG. 144, operation 13606 includes selectively transmitting collected data according to the selected data transmission chunk size. Referring to FIG. 145, example operation 13606 includes selectively transmitting collected data depending on success parameters of the transmission operation. Referring to FIG. 146, example operation 13606 includes selectively transmitting collected data according to a quality of service value for the transmission operation.

Referring to Fig. 147, an exemplary apparatus 14700 for performing remote assistance operations on a vehicle is schematically depicted. The example apparatus 14700 is configured to interpret remote access request values 14710 from a requesting device (eg, an external device coupled to the cloud system and/or otherwise communicating with the vehicle). Remote access execution circuitry 14702 is included, and remote access request values 14710 include at least one requested vehicle property 14712 . The example apparatus 14700 includes a property conversion circuit 14704 configured to determine property request values 14714 in response to at least one requested vehicle property 14712 and a plurality of vehicle parameter values 14716 in response to the property request values 14714. and a parameter acquisition circuit 14706 configured to interpret. The example apparatus 14700 includes a parameter adjustment circuit 14708 configured to generate vehicle property data 14718 from a plurality of vehicle parameter values 14716 in response to property request values 14714, the vehicle property data 14718 being at least one request. In response to vehicle properties 14712 retrieved, remote access execution circuitry 14702 is further configured to transmit vehicle property data 14718 to the requesting device—eg, as transmit vehicle property data 14720 . For example, requested vehicle properties 14712 may be provided by an interface--eg, a service interface (eg, technical assistance is provided by a remote service representative), and/or the vehicle owner or operator (eg, if the owner/operator is interested in It describes parameters of interest to the user of the requesting device, which can be selected from (remotely accessing the vehicle to determine certain data and/or perform remote actions). In an embodiment, property request values 14714 may be provided as values requested from, for example, vehicle network zone endpoints, and vehicle parameter values 14716 are responsive values provided by the endpoints. In a further example, vehicle property data 14718 includes vehicle parameter values 14716 configured according to external values requested in requested vehicle properties 14712, e.g., values determined from one or more vehicle parameter values 14716, and/or or include vehicle parameter values 14716 with the format, selection units, sampling rate, bit depth, etc. configured in the requested vehicle properties 14712 . Exemplary apparatus 14700 is an integrated network device configured to coordinate communications between a first network zone having a first network endpoint and a second network zone having a second network endpoint. (CND), at least a portion of the plurality of vehicle parameter values 14716 being generated by each of the first network endpoint and the second network endpoint.

The system determines that the remote access request value 14710 is a vehicle function value 14722 - e.g., actuator operation, enable, execute, and/or set function and/or sequence of actions (e.g., start engine, sequence of actions). operating the vehicle through motion, testing multiple actuators, etc.). Exemplary property conversion circuitry 14704 determines actuator command values 14726 as a function of vehicle function values 14722; remote operations circuitry 14724 provides actuator command values 14726 to vehicle network zone endpoints. Exemplary apparatus 14700 coordinates communication between a first network zone having a first network endpoint and a second network zone having a second network endpoint and including a vehicle network zone. a converged network device (CND) configured to: a first network endpoint providing at least a portion of the plurality of vehicle parameter values; a second network endpoint providing actuator command values 14726; including. Exemplary property conversion circuitry 14704 determines actuator command values 14726 as a sequence of actuator commands corresponding to diagnostic test operations; determines actuator command values 14726 as a sequence of actuator commands corresponding to remote control operations; and/or performing at least one action such as determining actuator command value 14726 as at least one actuator command corresponding to vehicle function value 14722 .

The example apparatus 14700 includes an additional plurality of endpoints distributed across at least a first network zone and a second network zone, each of the additional plurality of endpoints at least a portion of the plurality of vehicle parameter values 14716. I will provide a. The example apparatus 14700 further includes an additional number of endpoints distributed across at least the first network zone and the second network zone, each additional plurality of endpoints each representing at least a portion of the actuator command value 14726. , including corresponding actuators. Exemplary remote access request values 14710 include policy. The policy includes at least one value such as a requesting device authorization value, a data collection description including at least one requested vehicle property, a trigger description value including trigger state and trigger response values, and parameter acquisition circuit 14706 further: It is further configured to generate at least a portion of vehicle property data 14718 from the plurality of vehicle parameter values 14716 as a function of the trigger description values and/or policy priority values.

Referring to FIG. 148, an exemplary system including apparatus 14700 is schematically depicted. Exemplary systems can include any device as described herein and are not limited to including device 14700 . Additionally or alternatively, apparatus 14700 and/or portions thereof may be provided in vehicle 14806 and/or external device 14804 . Although the example of FIG. 148 illustrates apparatus 14700 provided as a cloud system, the connection between external device 14804 and vehicle 14806 may be WiFi, LAN, and/or any other device described throughout this disclosure. can be provided in any manner, including connection by a connection configuration of In certain embodiments, the external device 14804 can be directly coupled to the vehicle 14806 and the operations of the apparatus 14700 are performed in a cloud system and/or at the vehicle 14806 and/or the external device 14804. The example of FIG. 148 includes a CND 14802 configured to allow data value and/or actuator access between network zones 14808, 14810 of a vehicle 14806. The system of FIG. 148 can be applied to data values regardless of the configuration of the endpoints on the vehicle 14806 and without requiring knowledge of the vehicle configuration by the user of the external device 14804 and/or the user configuring the operation of the apparatus 14700. enable remote assistance and/or remote control operations of the vehicle 14806, including access to, actuation of actuators, and/or operation of more complex motion functions.

Referring to FIG. 149, an exemplary procedure 14900 for performing remote actions on a vehicle, including remote assistance actions, is schematically depicted. Exemplary procedure 14900 includes operations 14902 of interpreting remote access request values including at least one requested vehicle property; An act 14906 of interpreting the vehicle parameter values as a function of the properties, an act 14908 of generating vehicle property data from the vehicle parameter values in response to the property request values, and an act 14910 of sending the vehicle property data to the requesting device. Referring to FIG. 150, an exemplary procedure 15000 for performing actions on a vehicle, including remote assistance actions, is schematically depicted. An exemplary procedure 15000 includes an operation 15002 of interpreting a remote access request value that includes a vehicle capability value, an operation 15004 of determining an actuator command value as a function of the vehicle capability value, and an operation 15004 of delivering the actuator command value to a vehicle network zone endpoint. and a providing operation 15006 .

Referring now to FIG. 151, one embodiment of an apparatus 15100 for collecting and/or managing vehicle data according to the present disclosure is shown. Device 15100 can be a stand-alone controller or can form part of one or more of any controller described herein. Thus, in embodiments, the device 15100 may be placed on board a vehicle. In embodiments, as described in more detail herein, some or all of device 15100 may be located off-board the vehicle. Apparatus 15100 includes parameter acquisition circuitry 15110 configured to interpret vehicle parameter values 15112 . Apparatus 15100 further includes property conversion circuitry 15114 configured to interpret property request values 15116 that at least partially define the requested vehicle property. Apparatus 15100 further includes parameter adjustment circuitry 15118 configured to generate vehicle property data 15120 from vehicle parameter values 15112 in response to property request values 15116 . Vehicle property data 15120 may correspond to requested vehicle properties, eg, vehicle properties defined at least in part by property request values 15116 .

One embodiment of apparatus 15100 is depicted in FIG. 151 as interpreting/receiving a single vehicle parameter value 15112 . However, it is understood that embodiments of apparatus 15100 may interpret/receive multiple vehicle parameter values 15112 . For example, the device 15100 continuously collects vehicle parameter values 15112 over a period of time, e.g., a day, a week, a month, a year, the operating life of the vehicle, and/or under certain conditions, e.g. be able to. While the vehicle is occupied and/or unoccupied, while driving and/or stationary, the period during which the parameter value is within a given range, above or below a given threshold, and/or the characteristics of the parameter ( For example, parameters are collected in response to selected values having a rate of change greater than a given value and/or within a given range, switching between selected values, etc.). Although the example parameters and collected values are described as relating to a particular parameter for purposes of explanation, the collected parameters and/or collection criteria can utilize multiple parameters, vehicle operating conditions, and the like. . Parameters for collection and/or for determining collection criteria can be quantitative (eg, numeric) and/or qualitative (eg, categorical, Boolean, state values, etc.). Vehicle parameter values 15112 may be generated by one or more vehicle sensors, vehicle controllers, and/or vehicle actuators (e.g., feedback values, position values, fault values, etc.) as described herein. can. Non-limiting examples of vehicle parameter values include vehicle speed values, prime mover speed values, prime mover torque values, user-actuated vehicle feature values, vehicle position values, network utilization values for vehicle network zones, raw network messages from vehicle network zones. , the network address for the endpoint on the vehicle network zone, the memory storage description of the vehicle's controller, the value from the endpoint on the Controller Area Network (CAN), the value from the endpoint on the Local Interconnection Network (LIN), the intermediate Including control values, actuator states or feedback values and/or the like. Vehicle parameter values may be provided by vehicle endpoints on vehicle network zones, on vehicle endpoints, in memory of vehicle controllers, and/or in response to requests or commands to endpoints, for example, to provide parameters. It can be any possible value.

The device 15100 embodiment of FIG. 151 is also depicted as interpreting/receiving a single property request value 15116 . However, it should be understood that an embodiment of device 15100 can interpret/receive multiple property request values 15116 . For example, the device 15100 may operate over a period of time, e.g., days, weeks, months, years, the operational life of the vehicle, and/or under certain conditions, e.g., while the vehicle is occupied and/or unoccupied, while driving. and/or the property request values 15116 can be collected continuously, such as during suspension. Property request values 15116 are generated outside the vehicle by one or more computing devices, as described herein, and connected to one or more network connections, also as described herein. can be sent to the vehicle via Non-limiting examples of vehicle properties include component temperature values, sensor raw values, component speed values, actuator feedback values, drivetrain/component speed values, driveshaft speed values, driveshaft torque values, gear selection values, battery health values, battery state of charge values, battery throughput values, and/or the like.

The parameter acquisition circuit 15110 includes one or more electronic devices that generate vehicle parameter values 15112, such as vehicle sensors, and/or have access to network devices, controllers and/or sensors located in the vehicle. It may include and/or communicate with a communication port. The exemplary parameter acquisition circuit 15110 can communicate with any network zone of the vehicle, any endpoint of the vehicle, and acquire data from any network zone and/or endpoint, memory of the controller. and/or can command any endpoint to provide a value—eg, a value that is available to the endpoint but not normally exposed to the network zone.

Property translation circuitry 15114 may include and/or communicate with one or more telecommunications ports having access to network devices and/or controllers that access property request values 15116 . The example property conversion circuit 15114 determines available property request values 15116 as a function of the vehicle parameter values 15112—eg, when an external device and/or other user converts the data into general terms (eg, “vehicle speed”). property request values to retrieve selected data from the vehicle without requiring knowledge of data location, vehicle configuration, parameters and/or control action version, etc., while allowing vehicle data to be requested using 15116. Accordingly, an interface to an external device to enable requesting vehicle parameter values 15112 for collection may be related to the location or details of the vehicle, vehicle network zone configuration, and/or control actions and/or data availability on the vehicle. It can be configured for required user interface operation without updating information and/or knowledge. Further, without limiting other aspects of this disclosure, the interface to the external device may work well for a variety of vehicles (eg, multiple models, model years, trims, configurations, etc.) and may continue to operate properly as the system undergoes changes (e.g., moving endpoints, upgrading control actions, adding or removing endpoints, changing control action locations, adding functions or control actions, etc.) .

Property adjustment circuitry 15118 may communicate with parameter acquisition circuitry 15110 and/or property conversion circuitry 15114 . Generating vehicle property data 15120 may include conditioning, formatting, interpolating, and/or other adjustments and/or operations on vehicle parameter values 15112 .

For example, turning to FIG. 152, vehicle parameter values 15210 directly correspond to requested vehicle properties, eg, vehicle property data 15214 convey substantially the same information as vehicle parameter values 15210—eg, the same unit type. (e.g., length, mass, time, etc.), have differences only in the time domain (e.g., sampling rate differences), and/or vehicle parameter values 15210 and/or vehicle property data 15214 are , contains enough information to be correlated except for potential changes in format, processing, etc. However, it will be appreciated that property adjustment circuit 15118 may adjust the format and/or units of vehicle parameter values 15210 when generating vehicle property data 15214 . Formatting the vehicle parameter values 15210 may include adjusting the network protocol of the vehicle parameter values 15210 for transmission from the vehicle, for example, the vehicle parameter values 15210 may have their underlying data processed by the property adjustment circuit 15118. It may be repackaged into TCP/IP packets and received in CAN format. Although the preceding example describes conversion from CAN to TCP/IP, embodiments of device 15200 can perform conversion between other types of networks described herein. Without limiting other aspects of this disclosure, the formatting of vehicle parameter values 15210 may include upsampling parameter values, downsampling parameter values, parameter value bit depth (e.g., number of fixed-point bits allocated to a value). , and/or precision level of floating-point parameter values); changing the sampling rate of parameter values (e.g., changing the sampling rate of parameter values; frequency of providing), change the processing of parameter values (e.g., reserved ranges that indicate information such as filtering, debouncing, faults, diagnostic values, state values), rename parameter values, and/or metadata of parameter values. can be added, deleted, and/or modified (eg, timestamps, source endpoints, packet information, associated applications and/or flows, etc.).

Shown in FIG. 153 is another embodiment of apparatus 15300 in which property adjustment circuitry 15310 can generate vehicle property data 15312 from two or more vehicle parameter values 15314 and 15316 . For example, in an embodiment property adjustment circuit 15310 may generate/derive virtual vehicle property values 15318 (also shown in FIG. 154) from two or more vehicle parameter values 15314 and 15316, wherein vehicle property data 15312 is , contains virtual vehicle property values 15318 . For example, property request value 15320 may request a property, such as an estimated vehicle operating cost value, although the vehicle may not have sensors that directly generate the requested property. Additionally or alternatively, virtual vehicle property values 15318 may be used even when directly generated properties are available, e.g., to reduce network traffic (e.g., while values are available, values may be can also be determined from other values already collected), as a backup value (e.g. utilizing the virtual vehicle property value 15318 in response to a failure state of the sensor associated with the directly generated property), etc. priority and/or authorization considerations to reduce processing of (eg, the request flow, entity, application, etc. associated with the data request does not have access to directly available values, but does have access to virtual vehicle property values 15318, etc.). Thus, the property adjustment circuit 15310 converts the requested properties from two or more vehicle parameter values 15314 and 15316, such as fuel economy sensors or determinations, oil change detection sensors or determinations, to virtual vehicle property values 15318. can be derived as Non-limiting examples of virtual vehicle properties include vehicle speed values; power efficiency values; event occurrence values; list of previous vehicle positions; component remaining life value; component time to maintenance value; diagnostic counter value; list of one or more user-operated features; average vehicle runtime value; State values of sensors, actuators, control actions, and/or vehicles, and the like. In embodiments, generation/derivation of virtual vehicle property values 15318 from two or more vehicle parameter values 15314 and 15316 may be performed by interpolation, model operations, use of one or more lookup tables, state diagram operations, etc. can include In certain embodiments, the value directly available to the property adjustment circuit 15310 can be a hypothetical parameter value determined from multiple other parameters in the system, but can be requested directly as a parameter so that the property adjustment circuit 15310 as directly available values. In certain embodiments, virtual vehicle property values 15318 as used herein are values that property adjustment circuit 15310 determines from one or more additional directly available values and/or property adjustment circuit 15310 Including parameters provided directly by other controllers, which may have adjustment, control, validation, verification, and/or other visibility into the determination of directly provided parameter values.

Shown in FIG. 154 is another embodiment of an apparatus 15400 for collecting and/or managing vehicle data according to the present disclosure. Apparatus 15400 includes parameter acquisition circuitry 15110, property transformation circuitry 15114, and property adjustment circuitry 15118, as described herein. Apparatus 15400 further includes claimant verification circuitry 15410 configured to determine entity authorization values 15412 and vehicle property provision circuitry 15414 configured to transmit vehicle property data 15120 in response to entity authorization values 15412. can contain. Determination of entity authorization values 15412 can be responsive and based at least in part on property request values 15116 . For example, the property request value 15116 may include an indication of the requesting entity, eg, the entity that generated the property request value 15116, and the requestor verification circuit 15410 checks the requesting entity against an authorized access list. be able to. Vehicle property provision circuit 15414 receives vehicle property data 15120 to the requesting entity or vehicle property data 15120 if the authorized access list indicates that the requesting entity is authorized to access the requested property. The entity approval value may be configured to indicate the same to send to the entity and/or location indicated by property request value 15116 as being approved by the requesting entity to do so. For example, device 15120 may receive property request values 15116 from a vehicle manufacturer requesting that vehicle property data 15120 be sent to an approved third party vendor. Upon receiving property request values 15116, device 15400, via requester verification circuitry 15410, checks the vehicle manufacturer and/or third party vendor against an approved access list and determines whether the vehicle manufacturer and/or third party vendor is on the approved access list, the vehicle property data 15120 can be sent to the third party vendor. As will be appreciated, embodiments of the present disclosure may use other forms of authentication and/or verification, e.g., cryptographic keys, digital certificates, etc., to control access to vehicle property data 15120. can be done.

In an embodiment, apparatus 15400 may include subscription circuitry 15416 configured to add requesting entities, e.g., entities that generated property request values 15116, to subscriber data list 15418, and property provision circuitry 15414 may: It is configured to send vehicle property data 15120 to the requesting entity in response to subscriber data list 15418 . Adding the requesting entity to subscriber data list 15418 may be responsive to property request values 15116 . For example, interpreted property request value 15116 can trigger subscription circuit 15416 to add the requesting entity to subscriber data list 15418 . Thereafter, vehicle property provision circuitry 15414 periodically or continuously distributes vehicle property data 15120 to the requesting entity (or to entities and/or locations approved by the requesting entity) as long as the requesting entity remains in subscriber data list 15418. can be sent directly.

In embodiments, the device 15400 includes a CND 15420 described herein that coordinates communication between a first network zone with a first vehicle sensor and a second network zone with a second vehicle sensor. can contain. In such embodiments, vehicle parameter values 15421 may be generated by at least one of the first vehicle sensor and/or the second vehicle sensor. In an embodiment, the first vehicle parameter value 15421 may be generated by a first vehicle sensor (in the first network zone) and the second vehicle parameter value 15422 may be generated by a sensor (in the second network zone). ) can be generated by a second vehicle sensor. In embodiments, the first network zone and the second network zone may be of different types as described herein.

Referring now to FIG. 155, one embodiment of a method 15500 for collecting and/or managing vehicle data according to the present disclosure is shown. Method 15500 may be performed by devices 15100 and/or 15400 and/or by the controller and/or processor of any other device described herein. Thus, referring to FIGS. 151 and 155, the method 15500 includes steps 15510 to interpret vehicle parameter values, 15512 to interpret property request values, and 15514 to generate vehicle property data 15120 .

154 and 156, in an embodiment, the method 15500 determines 15610 an entity authorization value based, at least in part, as a function of the property request value 15116; and Step 15612 of sending property data 15120 . Method 15500 can further include step 15614 of adding the requesting entity to subscriber data list 15418 in response to property request value 15116 . In such embodiments, the step of sending 15612 vehicle property data 15120 may be responsive to subscriber data list 15418 .

154 and 157, in an embodiment, a method 15500 coordinates communication between a first network zone with a first vehicle sensor and a second network zone with a second vehicle sensor. Step 15710 can be included. Method 15500 may further include step 15712 of generating vehicle parameter values 15421 and/or 15422 by at least one of the first vehicle sensor and the second vehicle sensor. In an embodiment, interpreting vehicle parameter values 15510 may include interpreting a plurality of vehicle parameter values 15421 and 15422 15714 . In such embodiments, step 15514 of generating vehicle property data is based, at least in part, on multiple vehicle parameter values 15421 and 15422 . In such an embodiment, first vehicle parameter value 15421 may be from a first vehicle sensor (within the first network zone) and second vehicle parameter 15422 may be from (second network zone).

As will be appreciated, embodiments of the present disclosure may be agnostic with respect to how different vehicles acquire/collect data and/or vehicle configurations (eg, network zones, endpoints, control action locations, etc.). can provide the request entity to the In other words, embodiments of the present disclosure apply the same It can be provided that the requesting entity uses the same type of property request value to request the vehicle property. For example, a first vehicle of a first make, model and year may have an oil temperature sensor located on the CAN. The requesting entity may be able to obtain the oil temperature from the first vehicle via a first property request requesting "oil temperature". The first property request value is then interpreted by a device (e.g., 15100 or 15400) to generate first vehicle property data that provides the requesting entity with the first vehicle's oil temperature. may occur. A newer version of the model of the first vehicle, for example a second vehicle of the same make and model but newer year, may have an oil temperature sensor located on the Ethernet and/or Or the oil temperature sensor may be of an entirely different type and/or have a different formatted output compared to the oil temperature of the first vehicle. Embodiments of the present disclosure provide for the requesting entity to send a second property request to the second vehicle requesting "oil temperature", which is substantially the same as the first property request. The second property request can then be interpreted by a device, e.g. Vehicle property data is generated, which provides the requesting entity with the oil temperature of the second vehicle.

Accordingly, referring now to FIG. 158, another method 15800 for collecting and/or managing vehicle data is shown. Method 15800 includes interpreting 15810 a first property request value and generating 15812 first vehicle property data from the first plurality of vehicle parameter values. Method 15800 further includes interpreting 15814 a second property request value corresponding to the requested vehicle property, and generating 15816 second vehicle property data from the second plurality of vehicle parameter values. The first vehicle data and the second vehicle data both correspond to requested vehicle properties. In an embodiment, generating vehicle property data 15514 may include generating 15716 virtual vehicle properties 15618 .

Turning to FIG. 159, in an embodiment, method 15800 may further include step 15910 of generating a first plurality of vehicle parameter values via the first vehicle sensor and the second vehicle sensor; One vehicle sensor is located on a first network of the first vehicle and a second vehicle sensor is located on a second network of the first vehicle, the first network being different from the second network Type. Method 15800 may further include step 15912 of generating a second plurality of vehicle parameter values via a third vehicle sensor and a fourth vehicle sensor, wherein the third vehicle sensor is on a third network of the second vehicle. A fourth vehicle sensor is located on a fourth network of the second vehicle, the third network being a different type of network than the fourth network.

Referring now to FIG. 160, one embodiment of an apparatus 16000 for data collection policy capture and execution is shown, according to embodiments of the present disclosure. As described in more detail below, embodiments of device 16000 may provide for capturing, parsing, and/or executing vehicle policies that control the collection and/or transmission of vehicle data. Such policies may prescribe the collection of particular types of vehicle data and/or particular times and/or conditions that trigger the collection of vehicle data. For example, policies can be used to start and stop data collection based on specific regions, eg, cities, states/provinces, countries, etc., and data privacy laws applicable within such regions. In a non-limiting example, an embodiment of the device 16000 can be used to determine whether sensors and/or controllers onboard and/or onboard a vehicle can be used by the vehicle under privacy laws to which such types of vehicle data collection apply. Collection and/or transmission of one or more types of vehicle data may be triggered when determined to be in an acceptable area. Similarly, embodiments of the device 16000 may be useful if sensors and/or controllers onboard and/or onboard the vehicle are prohibited under applicable privacy laws to collect such types of vehicle data. stopping collection and/or transmission of one or more types of vehicle data can be triggered when it is determined that the vehicle is in an area.

In another non-limiting example, an embodiment of the device 16000 can determine whether and/or when certain data is passively or actively collected. Passive data collection is defined in certain embodiments as parameters for collection, e.g., if the parameters are normally provided by the endpoint to the Network Zone and are observable on the Network Zone without a specific request or other action. is available without device 16000 operation. Active data collection, in certain embodiments, is defined as the parameters for collection being unavailable, only intermittently available, and/or available but not fully usable for collection—e.g., insufficient parameters. Device 16000 provides requests or instructions to endpoints that provide active collected data that are provided at a reasonable data rate, are not provided continuously, and/or are provided with insufficient resolution or otherwise. - indicates. It will be appreciated that data parameters may be actively collected at a first time and/or under certain operating conditions and passively collected at a second time and/or under other operating conditions. In certain embodiments, operation of device 16000 to collect data parameters is active for certain purposes (e.g., providing parameters and/or providing instructions to endpoints to configure parameters). and can be considered passive for other purposes (e.g., a period of time during which the endpoint is already configured to provide sufficient parameters to satisfy the directive even in the absence of the directive).

Further, embodiments of device 16000 may provide for delegation of vehicle data collection to various controllers located on-board and/or off-board the vehicle. In such an embodiment, device 16000 can serve as a collection point for vehicle data collected by a delegated controller.

Accordingly, in an embodiment, apparatus 16000 includes policy acquisition circuitry 16010 configured to interpret vehicle policy data values 16012 comprising at least a portion of a vehicle policy. Vehicle policy data value 16012 may be a text file, such as an XML file or other markup-based format, having instructions encoded therein. In embodiments, vehicle policy data values 16012 may be data files having machine code, assembly, high-level code, such as C, C#, Ada, and/or other suitable programming code therein, for example. can be done. In embodiments, a policy data value may be a data structure, for example, an instantiated class object with various fields and/or properties that store data that affects part of the vehicle policy. Apparatus 16000 is configured to generate parsed policy data 16016 including one or more vehicle sub-policies of a vehicle policy in response to, and at least partially based on, vehicle policy data values 16012. Further includes circuitry 16014 . Apparatus 16000 further includes policy enforcement circuitry 16018 configured, in response to parsed policy data 16016, to collect vehicle data 16020 from one or more vehicle sensors as described herein.

In embodiments, policy enforcement circuitry 16018 may electronically communicate with one or more sensors, actuators, and/or controllers within the vehicle. Policy enforcement circuitry 16018 may also electronically communicate with and/or control other circuitry of device 16000 as described herein. Policy execution circuitry 16018 may interpret portions of parsed policy data 16016 and generate command values for controlling actuator operation. For example, a portion of the parsed policy data 16016 may correspond to a sub-policy relating to fuel timing percentages of the vehicle's engine, and the policy execution circuit 16018 updates the fuel timing to the controller responsible for controlling the fuel timing of the engine. You can generate and send command values to In an embodiment, policy enforcement circuitry 16018 determines what type of vehicle data is collected, how long the vehicle data is collected, and whether the vehicle data is onboard and/or transmitted off-vehicle. A portion of parsed policy data 16016 corresponding to a sub-policy for which can be interpreted. For example, in one embodiment, the sub-policy states that vehicle location data is collected whenever the vehicle's engine is running, and that collected vehicle data is collected onboard the vehicle when it is collected. can be indicated to be stored in the specified memory device. The sub-policy may further direct that the collected vehicle data be sent to the off-vehicle database at predetermined intervals, eg, once a day, week, month. In this manner, policy enforcement circuitry 16018 can direct circuitry of device 16000 and/or other controllers onboard the vehicle to collect and store location data within the vehicle memory device. Policy enforcement circuitry 16018 may then direct circuitry of device 16000 and/or circuitry of other controllers onboard the vehicle to transmit location data collected at predetermined intervals to an off-vehicle database. can. Although the previous examples were for location data, other types of vehicle data are also contemplated.

Turning to FIG. 161, there is shown another embodiment of an apparatus 16100 for capturing and executing data collection policies, according to embodiments of the present disclosure. Apparatus 16100 includes policy retrieval circuitry 16110 configured to interpret vehicle policy data values 16112 comprising at least a portion of a vehicle policy. Apparatus 16100 is configured to generate parsed policy data 16116 including those of one or more vehicle sub-policies of the vehicle policy as a function of and at least partially based on vehicle policy data values 16112. Further includes policy processing circuitry 16114 . Apparatus 16100 further includes policy enforcement circuitry 16118 configured to collect vehicle data 16120 from one or more vehicle sensors as described herein in response to parsed policy data 16116. .

As shown in FIG. 161 , policy processing circuitry 16114 may be further configured to determine vehicle policy type value 16122 from vehicle policy data value 16112 . Non-limiting examples of type values 16112 include passive policy and active policy.

In embodiments, policy enforcement circuitry 16118 may be configured to passively collect vehicle data 16112 in response to type value 16122 being a passive policy. For example, a vehicle policy (or sub-policy) may indicate that the fuel economy of the vehicle should be collected whenever the vehicle is being driven. In response, policy enforcement circuitry 16118 collects fuel economy data for the vehicle while the vehicle is being driven, in various circuits within device 16100 and/or other controllers onboard the vehicle. More than one memory device, such as an on-board memory device, can be directed to store.

In embodiments, policy enforcement circuitry 16118 may be configured to actively collect vehicle data 16120 in response to type value 16122 being an active policy. For example, a vehicle policy (or sub-policy) may specify that vehicle alarm data, such as collision indicators, engine fire indicators, airbag status indicators, and/or other types of data that might not normally be passively is collected and transmitted out of the vehicle, eg to an emergency response entity, when it experiences a malfunction and/or an accident, eg a crash.

As shown in FIG. 162, policy enforcement circuitry 16118 may be configured to send a start collection command value 16124 to actively collect vehicle data 16120 . A start collection command value 16124 may be sent to circuitry of device 16100 and/or circuitry of other controllers onboard the vehicle to instruct it to begin collecting one or more types of vehicle data. . The command value 16124 may be the type of vehicle data 16120 to be collected, the period of time the vehicle data 16120 is collected, the location the collected vehicle data 16120 is sent to, the conditions under which the vehicle data 16120 is collected, and/or the vehicle data 16120 collected. Indications identifying other types of instructions for 16120 collection, storage, and/or processing may be included. For example, the command value 16124 may be sent to a controller in communication with a sensor that monitors prime mover torque, and in response to the command value 16124, the controller collects vehicle data 16120 regarding prime mover torque and transmits vehicle data 16120 to It is transmitting to the on-board memory device for storage. Although the foregoing examples relate to prime mover torque, other types of controllers and/or sensors onboard the vehicle are contemplated.

As shown in FIG. 163 , policy enforcement circuitry 16118 may be configured to generate vehicle property values 16310 based at least in part on collected vehicle data 16120 and to actively collect vehicle data 16120 .

As shown in FIG. 164, policy enforcement circuitry 16118 may be configured to send query values 16410 to actively collect vehicle data 16120 . The query value 16410 is then used onboard the vehicle and/or to retrieve previously stored vehicle data that can be transmitted by the device 16100 to another memory device off the vehicle and/or in the vehicle. Or it can be sent to another controller and/or database outside the vehicle, such as a memory device. In embodiments, the query values 16410 may be sent to a controller onboard the vehicle, which then transmits the requested vehicle data to the device 16100 and/or to another device, e.g., the vehicle. Responsive transmission to on-board and/or off-vehicle memory devices.

Returning to FIG. 161, apparatus 16100 can include a memory device 16125 configured to store vehicle data 16120 collected. Memory device 16125 may include a database for storing collected vehicle data 16120 . The database may be in the form of a text file, eg, a comma-delimited file, a relational database, an object database, and/or any other type of suitable system for storing collected vehicle data 16120.

Apparatus 16100 may include a Converged Network Device (CND) 16126 that coordinates communications between the first network zone and the second network zone, as described elsewhere in this disclosure. As described elsewhere in this disclosure, the first network zone can have a first vehicle sensor of the one or more vehicle sensors from which vehicle data 16120 is collected; A second network zone may have a second of the one or more vehicle sensors from which vehicle data 16120 is collected. In embodiments, the first network zone and the second network zone may be of different types as described herein. In embodiments, CND 16126 may provide for device 16100 and its circuitry to communicate with devices in either the first network zone and/or the second network zone. For example, vehicle policy values 16112 may be generated by devices in a first network zone and vehicle data 16120 may be collected from devices in a second network zone.

In embodiments, the policy enforcement circuit 16118 performs the processing of the vehicle data 16120 as described herein via transmitting at least a portion of the parsed policy data 16116 to one or more vehicle controllers. Collection can be configured to be delegated to one or more vehicle controllers. For example, in an embodiment, policy enforcement circuitry 16118 delegates to a first controller collection of engine-related vehicle data 16120 associated with monitoring and/or controlling the vehicle's engine and monitoring the location of the vehicle. Related, collection of position data may be entrusted to the second controller. The delegated controller may then transmit the collected vehicle data 16120 to the device 16100, store the collected data 16120 in a memory device onboard the vehicle, and/or transmit the collected data 16120 external to the vehicle. can be sent. In embodiments, policy enforcement circuitry 16118 may provide authorization, eg, credentials, to the delegate controller to access sensors and/or other devices for collecting vehicle data 16120 . In embodiments, policy enforcement circuitry 16118 may provide authorization, eg, credentials, to the delegate controller to transmit collected vehicle data 16120 out of the vehicle. In embodiments, policy enforcement circuitry 16118 may delegate collection of vehicle data 16120 based on the capacity of controllers that can be installed on the vehicle. For example, a vehicle may have multiple climate controllers that monitor and/or regulate certain vehicle systems, such as climate control, and policy enforcement circuitry 16118 directs the collection of climate data to available processing power. can choose to delegate to a climate controller with

As further shown in FIG. 161, the device 16100 can include collected data acquisition circuitry 16128 configured to interpret vehicle data 16120 collected by one or more vehicle controllers. In embodiments, the delegating controller may send collected vehicle data 16120 to a collected data acquisition circuit 16128 where the collected vehicle data 16120 is made accessible to other circuits within the device 16100 .

In embodiments, apparatus 16100 may include collected data providing circuitry 16130 configured to transmit collected vehicle data 16120 . Collected data provision circuitry 16130 may be configured to communicate with and transmit collected vehicle data 16120 to devices on board the vehicle and/or to devices not on board the vehicle. In embodiments, the collection data provision circuitry 16130 is configured based on one or more formats of the communication channel used to transmit the collection vehicle data 16120 and/or the format used by the device to which the collection vehicle data 16120 is transmitted. can be used to format the collected vehicle data 16120. For example, the collected data provision circuit 16130 may package the collected vehicle data 16120 into TCP/IP packets or other network formats and/or compress the collected vehicle data 16120 prior to transmission.

Shown in FIG. 165 is a method 16500 for capturing and executing data collection policies, according to an embodiment of the present disclosure. Method 16500 may be performed by device 16000, device 16100, and/or any other controller described herein. Thus, referring to FIGS. 160 and 165, in an embodiment method 16500 includes interpreting 16510 vehicle policy data values 16012 comprising at least a portion of a vehicle policy. The method 16500 generates 16512 parsed policy data 16016 including those of one or more vehicle sub-policies of the vehicle policy as a function of the vehicle policy data values 16012 and based at least in part onboard. further includes Method 16500 further includes step 16514 of collecting vehicle data 16020 from one or more vehicle sensors in response to parsed policy data 16016 .

161 and 166 , in an embodiment, the method 16500 may include determining 16516 the vehicle policy type value 16122 from the vehicle policy data value 16112 . Thus, step 16514 of collecting vehicle data may include step 16610 of passively collecting vehicle data 16120 in response to type value 16122 . In an embodiment, step 16514 of collecting vehicle data 16620 may include step 16612 of actively collecting vehicle data 16620 in response to type value 16122 . The step 16612 of actively collecting vehicle data 16120 may include the step 16614 of sending a start collection command value 16124 (Fig. 162).

As shown in FIG. 167, actively collecting 16612 vehicle data 16120 may include generating 16710 vehicle property values 16310 (FIG. 163) based at least in part on the collected vehicle data 16120. can.

As shown in FIG. 168, the step 16612 of actively collecting vehicle data 16120 can include the step 16810 of sending query values 16410 (FIG. 164).

161 and 169, in an embodiment method 16500 may include step 16910 of coordinating communication between the first network zone and the second network zone. In embodiments, a first network zone may comprise a first vehicle sensor of one or more vehicle sensors from which vehicle data 16120 is collected, and a second network zone may comprise a vehicle sensor from which vehicle data 16120 is collected. A second vehicle sensor of the one or more vehicle sensors may be provided. In embodiments, the first network zone and the second network zone may be of separate types. In embodiments, collecting vehicle data 16120 16514 may include step 16910 of delegating collection of vehicle data 16120 to one or more vehicle controllers. Delegating collection of vehicle data 16120 to one or more vehicle controllers 16910 may include transmitting 16912 at least a portion of parsed policy data 16116 to one or more vehicle controllers.

In embodiments, the method 16500 may further include a step 16914 of interpreting vehicle data 16120 collected by one or more vehicle controllers.

In an embodiment, method 16500 may include transmitting 16916 collected vehicle data 16120 .

Referring now to Fig. 170, one embodiment of an apparatus 17000 for data collection in mixed network environments, such as automobiles and/or other vehicles described herein, is provided. As shown in FIG. 170, apparatus 17000 includes Converged Network Device (CND) 17010, which has a first network endpoint as described herein and elsewhere in this disclosure. and a second network zone having a second network endpoint. Endpoints may include vehicle sensors and/or other devices as described herein. A plurality of vehicle parameter values 17012 and 17014 are generated by the first network endpoint and the second network endpoint. Apparatus 17000 further includes parameter acquisition circuitry 17016 configured to interpret a plurality of vehicle parameter values 17012 and 17014 . Apparatus 17000 further includes property conversion circuitry 17018 configured to interpret property request values 17020 including at least some of the requested vehicle properties. Apparatus 17000 further includes parameter adjustment circuitry 17022 configured to generate vehicle property data 17024 from a plurality of vehicle parameter values 17012 and 17014 in response to property request values 17020 . As can be appreciated, vehicle property data 17024 corresponds to requested vehicle properties.

Turning to Fig. 171, another embodiment of an apparatus 17100 is provided for data collection in mixed network environments, such as automobiles and/or other vehicles as described herein. Similar to device 17000 of FIG. 170, device 17100 has a first network zone with a first network endpoint and a second network endpoint, as described herein and elsewhere in this disclosure. a CND 17010 that can be configured to coordinate communications between a second network zone having Endpoints may include vehicle sensors and/or other devices as described herein that generate multiple vehicle parameter values 17012 and 17014 . Apparatus 17100 further includes parameter acquisition circuitry 17016 configured to interpret a plurality of vehicle parameter values 17012 and 17014 . Apparatus 17100 further includes property conversion circuitry 17018 configured to interpret property request values 17020 including at least some of the requested vehicle properties. Apparatus 17100 further includes parameter adjustment circuitry 17022 configured to generate vehicle property data 17024 from a plurality of vehicle parameter values 17012 and 17014 in response to property request values 17020 . As can be appreciated, vehicle property data 17024 corresponds to requested vehicle properties.

As further shown in FIG. 171 , the device 17100 can include a parameter providing circuit 17110 configured to transmit vehicle property data 17024 . In embodiments, the first network zone and the second network zone are of different types as described herein. In embodiments, the first network zone may include a controller area network (CAN), an Ethernet-based network, and/or any other type of network described herein. In embodiments, the first and second network endpoints may be vehicle sensors. In an embodiment, multiple vehicle parameter values 17012 and 17014 directly correspond to requested vehicle properties.

In embodiments, one or more of vehicle parameter values 17012 and 17014 include at least one of vehicle speed values; prime mover speed values; prime mover torque values; user-actuated vehicle feature values; In embodiments, one or more of the plurality of vehicle parameter values 17012 and 17014 are network usage values for the vehicle network zone; raw network messages from the vehicle network zone; network addresses for endpoints on the vehicle network zone; including at least one of: a memory storage description of the vehicle's controller; values from endpoints on a controller area network (CAN); values from endpoints on a local interconnection network (LIN); or intermediate control values. be able to. In embodiments, the requested vehicle properties may include at least one of component temperature values, sensor raw values, component velocity values, or actuator feedback values. In embodiments, the requested vehicle property is one of a driveline component speed value, a drive shaft speed value, a drive shaft torque value, a gear selection value, a battery health state value, a battery state of charge value, or a battery power throughput value. At least one can be included.

As further shown in FIG. 171 , parameter adjustment circuitry 17022 may be configured to generate virtual vehicle property values 17112 from two or more vehicle parameter values 17012 and/or 17014 in response to property request values 17020 . can. In an embodiment, vehicle property data 17024 includes virtual vehicle property values 17112 .

In embodiments, virtual vehicle property values 17112 include at least one of vehicle speed values; power efficiency values; event occurrence values; or a list of previous vehicle locations. In embodiments, virtual vehicle property values 17112 include at least one of a list of one or more user-actuated characteristics; an average vehicle runtime value; or an estimated vehicle operating cost value.

In an embodiment, vehicle property data 17024 is in a different format than vehicle parameter values 17012 and 17014 . Further, although embodiments of CND 17010 facilitate communication between devices 17000 and 17100 and two on-board networks through which vehicle parameter values 17012 and 17014 are transmitted, in embodiments CND 17010 may It will be appreciated that communication with one or more off-vehicle networks may be facilitated, as described in the section below.

FIG. 172 illustrates a method 17200 for data collection in mixed network environments, such as automobiles and/or other vehicles described herein, according to embodiments of the present disclosure. Method 17200 may be performed by any embodiment of apparatus 17000, 17100, and/or by any other apparatus and/or controller described herein. Thus, referring now to FIGS. 170 and 172, method 17200 coordinates communication between a first network zone having a first network endpoint and a second network zone having a second network endpoint. A plurality of vehicle parameter values 17012 and 17014 are generated by the first and second network endpoints. Method 17200 further includes step 17212 of interpreting a plurality of vehicle parameter values 17012 and 17014 . Method 17200 further includes interpreting 17214 property request values 17020 that at least partially define the requested vehicle property. The method 17200 further includes, in response to the property request values 17020, generating 17216 vehicle property data 17024 from the plurality of vehicle parameter values 17012 and 17014 such that the vehicle property data 17024 corresponds to the requested vehicle properties.

171 and 173, in an embodiment method 17200 may include step 17310 of transmitting vehicle property data 17024. FIG.

In embodiments, the first network zone and the second network zone may be of different types as described herein. In embodiments, the first network zone may include a controller area network (CAN). In embodiments, the first network endpoint and the second network endpoint may be vehicle sensors. In embodiments, multiple vehicle parameter values 17012 and 17014 may directly correspond to requested vehicle properties.

In an embodiment, method 17200 may include step 17312 of generating virtual vehicle property values 17112 from two or more vehicle parameter values 17012 and 17014 in response to property request values 17020 . In an embodiment, vehicle property data 17024 includes virtual vehicle property values 17112 .

Referring now to Fig. 174, there is shown an apparatus 17400 for data collection process management, according to an embodiment of the present disclosure. Apparatus 17400 includes parameter acquisition circuitry 17410 configured to interpret vehicle parameter values 17412 and property conversion circuitry 17414 configured to interpret property request values 17416 that at least partially define requested vehicle properties. and including. Although FIG. 174 depicts the parameter acquisition circuit 17410 interpreting a single vehicle parameter value 17412, in embodiments the parameter acquisition circuit 17410 may interpret two or more vehicle parameters (as shown in FIG. 175). It will be appreciated that the parameter value 17412 may be interpreted. Apparatus 17400 further includes parameter adjustment circuitry 17418 configured to generate modified vehicle parameter data 17420 from vehicle parameter values 17412 in response to property request values 17416 . As can be seen, the modified vehicle parameter data 17420 corresponds to the requested vehicle properties. The modified vehicle parameter data 17420 can then be transmitted through the modified data providing circuit 17421 . Transmission of modified vehicle parameter data 17420 may be to the requesting entity, i.e., the entity that generated the property request value 17416, and/or another entity and/or location specified by the requesting entity, and/or as described herein. may be specified by vehicle policy as described in .

As will be described in more detail below, embodiments of the parameter adjustment circuit 17418 format the vehicle parameter values 17412, extract data and/or values from the vehicle parameter values 17412 (for inclusion in the modified vehicle parameter data 17420). and/or the modified vehicle parameter data 17420 is in a desired format, e.g., a format usable and/or expected by the intended receiving device, e.g., another controller and/or storage device. Modified vehicle parameter data 17420 is generated by otherwise adjusting the data in vehicle parameter values 17412 to include data about . In embodiments, the desired format may be in units, network protocols, expected sampling and/or streaming rates, storage of vehicle parameter values on non-transitory computer-readable media, compression standards, and/or other types of formats. can be based, at least in part, on Accordingly, an embodiment of apparatus 17400 provides that the requesting entity, ie, the entity that generates property request values 17416, is agnostic as to the native/raw format of vehicle parameter values 17412 used to generate data corresponding to the request properties. provide to be. Embodiments of apparatus 17400 also provide for vehicle manufacturers to be agnostic to the format requirements of requesting entities when selecting on-board sensors and/or on-board communication infrastructure.

For example, property request value 17416 may correspond to a request for oil temperature in degrees Fahrenheit, and vehicle parameter value 17412 may be oil temperature in degrees Celsius. Parameter adjustment circuit 17418 may generate modified vehicle parameter data 17420 by converting parameter values 17412 to degrees Fahrenheit. In another non-limiting example, property request value 17416 may correspond to a request for total vehicle mileage, and vehicle parameter value 17412 may be vehicle total kilometers. Parameter adjustment circuit 17418 may generate modified vehicle parameter data 17420 by converting parameter value 17412 to distance traveled. In yet another example, the requesting entity, or other entity or device, intended to receive the modified vehicle parameter data 17420 matches the vehicle parameters to the speed generated on board the vehicle and/or It may have the capacity to receive modified vehicle parameter data 17420 that would otherwise be inconsistent. In such scenarios, embodiments of device 17400 may adjust the rate at which modified vehicle parameter data 17420 is transmitted to meet the needs of the receiving entity and/or device. In yet another example, modified vehicle parameter data 17420 may be destined for storage on a non-transitory computer-readable medium having limited storage capacity, such as a memory device. In such a scenario, an embodiment of apparatus 17400 may generate modified vehicle parameter data 17420 such that the information corresponding to the requested property is in compressed form. As will be appreciated, such compression can increase the amount of data regarding requested vehicle properties that can be stored and/or transmitted. In yet another non-limiting example, embodiments of apparatus 17400 adjust the transmission rate of modified vehicle parameter data 17420 based on network transportation costs, e.g., cellular network bandwidth and/or data rates. can be done. In such embodiments, the apparatus 17400 reduces the transmission rate of the modified vehicle parameter data 17420 when network transportation costs are expensive, and reduces the transmission rate of the modified vehicle parameter data 17420 when network transportation costs are low. transmission rate can be increased. In yet another non-limiting example, embodiments of apparatus 17400 can adjust the transmission rate of modified vehicle parameter data 17420 based on available off-vehicle network bandwidth. In such an embodiment, the device 17400 reduces the transmission rate of the modified vehicle parameter data 17420 when the off-vehicle network bandwidth is limited and/or otherwise "slow", thereby reducing the off-vehicle network bandwidth. If bandwidth is not limited and/or otherwise "fast", the transmission rate of modified vehicle parameter data 17420 may be increased.

Turning to FIG. 175 , in an embodiment parameter adjustment circuit 17418 may generate virtual property value 17510 . Virtual vehicle property values 17510 may be derived and/or otherwise based at least in part from two or more vehicle parameter values 17412 and 17512 . As shown in FIG. 175 , modified vehicle parameter data 17420 may include virtual vehicle property values 17510 .

In an embodiment, parameter adjustment circuit 17418 formats vehicle parameter values 17412 and/or 17512 into the desired format of requested vehicle properties 17416 such that modified vehicle parameter data 17420 has the desired format. A configured formatting circuit 17514 may be included. Such formatting of vehicle parameter values 17412 and/or 17512 includes packaging vehicle parameter values 17412 and/or 17512 in a network protocol, e.g., TCP/IP; It may include converting to a protocol (which may then be packaged within a network protocol), compressing the data, and/or other types of formatting.

In an embodiment, parameter adjustment circuit 17418 is requested to adjust one or more units of vehicle parameter values 17412 and/or 17512 such that modified vehicle parameter data 17420 has the desired one or more units. A unit conversion circuit 17416 configured to convert the vehicle property to one or more desired units may be included. Non-limiting examples of unit types that can be converted include distance, time of day, temperature, pressure, strain, rotational speed, rpm, fuel efficiency, battery charge, and the like.

In an embodiment, parameter adjustment circuit 17418 adjusts the sampling rate of vehicle parameter values 17412 and/or 17512 to the desired sampling rate of the requested vehicle property such that modified vehicle parameter data 17420 has the desired sampling rate. A sampling circuit 17518 structured to condition may be included. In embodiments, the sampling rate of the vehicle parameter values 17412 and/or 17512 may be the rate at which the vehicle parameter values 17412 and/or 17512 are generated and the desired sampling rate of the requested vehicle property is modified. can be the rate at which vehicle parameter data 17420 is transmitted. Accordingly, sampling circuit 17518 may be configured to upsample and/or downsample vehicle parameter values 17412 and/or 17512 .

For example, turning to FIG. 176, a non-limiting example of downsampling vehicle parameter values is shown. In such an embodiment, sampling circuit 17518 may receive a plurality of vehicle parameter values 17610, 17612, 17614, and 17616 at a first rate ▽1, eg, sampling circuit 17518 may receive vehicle parameter value 17610 , 17612, 17614, and 17616 can be received at subsequent time periods t0, t1, t2, t3, respectively, where t1≈t0+t1, t2≈t1+t _▽1 , and t3≈t2+t _▽1 . be. Vehicle parameter values 17610, 17612, 17614, and 17616 may be obtained from the same sensor or from different sensors. Next, sampling circuit 17518 transmits vehicle parameter values 17610, 17612, 17614, and 17616 from device 17400 as modified vehicle parameter data 17618, 17620, 17622, and 17624 at a second rate ▽2. For example, modified vehicle parameter data 17618, 17620, 17622, and 17624 corresponding to vehicle parameter values 17610, 17612, 17614, and 17616, respectively, can be obtained at time periods subsequent to times t4, t5, t6, t7. can be transmitted respectively from device 17400, where t5≈t4+t _▽2 , t6≈t5+t _▽2 , and t7≈t6+t _▽2 . As will be appreciated, ▽2 can be greater than ▽1, eg, modified vehicle parameter data is sent at a slower rate than vehicle parameter values are received. In embodiments, the sampling circuit 17518 may adjust ▽2 based on information contained within the property request value 17416 and/or vehicle policy, as described herein. In embodiments, the sampling circuit 17518 may adjust ▽2 based on off-vehicle network connection available bandwidth and/or transmission costs. For example, if the off-vehicle network connection available bandwidth is high and/or the transmission cost is low, ▽2 may be decreased. Conversely, if the off-vehicle network connectable bandwidth is low and/or the transmission cost is high, ▽2 may be increased.

In embodiments, the sampling circuit 17518 may reduce the number of modified vehicle parameter data, each corresponding to a vehicle parameter value, transmitted out of the device 17400, e.g. Vehicle parameter values 17610, 17612, 17614, 17616 may be received and/or interpreted at t1, t2 and t3, respectively, and modified vehicle parameter data 17618 and 17622 may be transmitted at times t4 and t6, respectively. In such embodiments, modified vehicle parameter data 17618, 17622 may correspond to vehicle parameter values 17610, 17614, respectively. In embodiments, modified vehicle parameter data 17618 and 17622 may correspond to two or more of vehicle parameter values 17610, 17612, 17614, and 17616, respectively. For example, modified vehicle parameter data 17618 may be derived from vehicle parameter values 17610 and 17612, and/or may otherwise be a combination thereof, and modified vehicle parameter data 17622 may be: It can be derived from vehicle parameter values 17614 and 17616 and/or can be a combination of vehicle parameter values 17614 and 17616 . In such embodiments, each of the modified vehicle parameter data 17618 and 17622 may be an average of corresponding vehicle parameter values.

Turning to FIG. 177, a non-limiting example of upsampling vehicle parameter values is shown. In such embodiments, the sampling circuit 17518 may receive a plurality of vehicle parameter values 17610, 17612, and 17614 at a first rate ▽1; , and 17614 can be received at subsequent time periods t0, t1, and t2, where t1≈t0+t _▽1 and t2≈t1+t _▽1 . Parameter values 17610, 17612, and 17614 can be from the same sensor or from different sensors. Sampling circuit 17518 then samples vehicle parameter data 17710, 17712, 17714, 17716, 17718, and 17720 more modified as compared to the vehicle parameter values received by sampling circuit 17518 for subsequent time periods t3, t4. , t5, t6, t7, t8, where t4 ≈ t3 + t _{▽ 2} , t5 ≈ tt4 + t _{▽ 2} , and t6 ≈ t5 + t _{▽ 2} and so on. As will be appreciated, ▽2 can be less than ▽1, ie, modified vehicle parameter data is sent at a faster rate than vehicle parameter values are received. In embodiments, the sampling circuit 17518 may adjust ▽2 based on information contained within the property request value 17416 and/or vehicle policy, as described herein. In embodiments, the sampling circuit 17518 may adjust ▽2 based on off-vehicle network connection available bandwidth and/or transmission costs. For example, if the off-vehicle network connection available bandwidth is high and/or the transmission cost is low, ▽2 may be decreased. Conversely, when the external network connectable band is low and/or when the transmission cost is high, ▽2 can be increased.

As shown in the non-limiting example of FIG. 177, modified vehicle parameter data 17710, 17714, and 17718 may correspond to vehicle parameter values 17610, 17612, and 17614, respectively, and modified vehicle parameter data 17712 , 17716, and 17720 are additional modified vehicle parameter data inserted into the transmit sequence. In embodiments, additional modified vehicle parameter data 17712, 17716, and 17720 may be interpolated and/or otherwise derived from parameter values 17610, 17612, and/or 17614.

As will be appreciated, the insertion of additional modified parameter data into the transmission sequence can provide that modified vehicle parameter data is transmitted to the receiving entity and/or device at an expected rate. Further, embodiments in which additional modified parameter data is interpolated from vehicle parameter values 17610, 17612, and/or 17614 can approximate higher resolution monitoring of requested vehicle properties.

Turning to FIG. 178, a method 17800 for data collection process management is shown, according to one embodiment of the present disclosure. Method 17800 may be performed by device 17400 and/or any other device and/or controller described herein. Thus, referring now to FIGS. 174 and 178, method 17800 includes step 17810 of interpreting vehicle parameter values 17812; step 17812 of interpreting property request values 17416; and generating modified vehicle parameter data 17420 from 17814 . Property request values 17416 define, at least in part, requested vehicle properties, and modified vehicle parameter data 17420 correspond to the requested vehicle properties.

175 and 179 , step 17814 of generating modified vehicle parameter data 17420 includes step 17910 of generating virtual vehicle property values 17510 . Modified vehicle parameter data 17420 may include virtual vehicle property values 17510 . In embodiments, virtual vehicle property values 17510 may be based at least in part on two or more vehicle parameter values 17412 and 17512 . In an embodiment, method 17800 includes step 17912 of formatting vehicle parameter values 17412 and/or 17512 into the desired format of the requested vehicle properties such that modified vehicle parameter data 17420 has the desired format. can be done. In an embodiment, step 17912 of formatting vehicle parameter values 17412 and/or 17512 is step 17914 of generating network protocol packets configured to transmit vehicle parameter values 17416 (in the form of modified vehicle parameter data). including. In an embodiment, formatting 17912 vehicle parameter values 17412 includes modifying 17916 vehicle parameter values 17412 and/or 17512 for storage on non-transitory computer readable media. In an embodiment, modifying 17916 vehicle parameter values 17412 and/or 1751 includes compressing 17918 vehicle parameter values 17412 and/or 17512 . FIG. 179 depicts step 17918 of compressing vehicle parameter values 17412 and/or 17512 as part of step 17916 of modifying vehicle parameter values 17412 and/or 17512 for storage on non-transitory computer readable media. However, in embodiments, step 17918 of compressing vehicle parameter values 17412 and/or 17512 may be performed in addition to step 17916 of modifying vehicle parameter values 17412 and/or 17512 for storage on non-transitory computer readable media. can be done.

In an embodiment, the method 17800 calculates the requested vehicle property values 17412 and/or 17512 in one or more units such that the modified vehicle parameter data 17420 has the desired one or more units. can include a step 17919 of converting to one or more desired units of . Step 17919 of converting one or more units of vehicle parameter values 17412 and/or 17512 may be performed as part of step 17814 of generating modified vehicle parameter data 17420 .

In an embodiment, method 17800 adjusts the sampling rate of vehicle parameter values 17412 and/or 17512 to the desired sampling rate of the requested vehicle property such that modified vehicle parameter data 17420 has the desired sampling rate. Step 17920 can be included. Step 17920 of adjusting the sampling rate of vehicle parameter values 17412 and/or 17512 may be performed as part of step 17814 of generating modified vehicle parameter data 17420 . In an embodiment, adjusting 17920 the sampling rate 17920 of the vehicle parameter values 17412 and/or 17512 includes upsampling 17922 the vehicle parameter values 17412 and/or 17512 . In an embodiment, adjusting 17920 the sampling rate of vehicle parameter values 17412 and/or 17512 may include downsampling 17924 the vehicle parameter values.

Referring now to FIG. 180, shown is an apparatus 18000 for data storage management, according to one embodiment of the present disclosure. Apparatus 18000 includes parameter acquisition circuitry 18010 configured to interpret a plurality of vehicle parameter values 18012 and 18014, and one or more caches of vehicle parameter values 18012 and 18014 as disclosed herein. a parameter adjustment circuit 18016 configured to condition for storage in a device; and a parameter storage circuit 18020 configured to store the adjusted plurality of vehicle parameter values 18018 in one or more cache devices. Prepare. As described in more detail herein, embodiments of apparatus 18000 convert vehicle parameter values into a form suitable for storage in an onboard vehicle memory cache, e.g. transfer from the vehicle memory cache device to off-vehicle storage systems and devices, e.g., network cloud-based storage systems, and/or store some adjusted vehicle parameter values directly in the on-board memory cache, and some adjusted vehicle Storing parameter values directly in an off-vehicle storage system and/or device may provide efficient storage and/or retrieval of vehicle parameter values. As also described herein, embodiments of the apparatus 18000 may direct and/or control the expiration of conditional vehicle parameter values in onboard vehicle cache and/or off-vehicle storage systems. As will be appreciated, such data expiration control can help mitigate oversaturation, e.g., "full", of on-board vehicle cache and/or off-vehicle storage systems with vehicle parameter values. Additionally, embodiments of the device 18000 can provide on-board vehicle parameter value storage when the off-vehicle network connection is slow and/or interrupted.

Thus, as shown in FIG. 181, in an embodiment parameter adjustment circuitry 18016 can be configured to determine a storage location value 18110 and parameter storage circuitry 18020 adjusts and is further configured to store a plurality of vehicle parameter values 18018 that have been generated. For example, storage location value 18110 may indicate that adjusted vehicle parameter values 18018 are stored in one or more cache devices onboard the vehicle. In an embodiment, each of the one or more cache devices located on board the vehicle is of the type disclosed herein, with a different controller associated with the other of the one or more cache devices. device and/or controller. For example, storage location value 18110 indicates that conditional vehicle parameter values 18018 corresponding to vehicle engine data are stored in a cache device associated with the vehicle engine controller for the vehicle, while storage location value 18110 corresponds to location data. It can be indicated that the conditional vehicle parameter values 18018 to be stored in a cache device associated with the controller responsible for tracking the location of the vehicle.

In embodiments, the storage location values 18110 store the adjusted plurality of vehicle parameter values 18018 in one or more caching devices that are not onboard the vehicle, such as data operated by the vehicle manufacturer and/or a third party. It can indicate that it is to be stored at the center. For example, storage location values 18110 are stored in data centers accessible by third parties, while conditional vehicle parameter values 18018 corresponding to vehicle occupant use of third party applications forming part of the vehicle's infotainment system are stored in a data center. It can be shown that

In an embodiment, the storage location values 18110 are stored in a first cache device of the one or more cache devices and the first portion of the adjusted plurality of vehicle parameter values 18018 is stored in a first cache device of the one or more cache devices. of the vehicle parameter values 18018 are stored in a second cache device of the one or more cache devices. In such embodiments, the first cache device may be located onboard the vehicle and the second cache device may be located off-board the vehicle. For example, in an embodiment, the storage location value #RZAF10 is a high priority vehicle parameter value, e.g., a vehicle parameter value that the receiving entity wishes to see in a quick manner, is stored in off-vehicle cache and a low priority vehicle It may be indicated that parameter values, eg vehicle parameter values that the receiving entity does not need to see in a quick manner, are stored in an on-board vehicle cache.

As further shown in FIG. 181, the parameter adjustment circuit 18016 can be configured to generate expiration values 18112 for a plurality of conditional vehicle parameter values 18018, where the expiration values 18112 are 1 or 2 configured to cause selective expiration of adjusted plurality of vehicle parameter values 18018 in said cache device. Expiration value 18012 may be a time value corresponding to a time period for storing multiple vehicle parameter values in one or more caches. For example, expiration value 18112 may indicate that adjusted vehicle parameter values 18018 are stored for days, weeks, months, years, decades, etc. before being deleted. . In embodiments, the expiration value 18012 may indicate an ordered ordering of vehicle parameter values such that the cache operates as a queue and/or stack. For example, the vehicle parameter value may be an incremental identification value associated with the individual (or group) of conditional vehicle parameter values #RZAE18, and receipt of the vehicle parameter value at the cache device will result in the cache having the lowest identification value. triggers deletion of vehicle parameter values in

In embodiments, the parameter storage circuitry 18020 may be further configured to send the expiration value 18110 to one or more cache devices. Sending the expiration value 18112 may occur along with the conditional vehicle parameter value 18018 , eg, the expiration value 18112 is included as part of the conditional vehicle parameter value 18018 . Transmission of the expiration value 18112 can also be separate from the conditional vehicle parameter value 18018, e.g., the expiration value 18112 is transmitted as a different datagram and/or message than the conditional vehicle parameter value 18018 be. In embodiments, a cache device receiving an expiration time value 18110 may be responsible for deleting the corresponding conditional vehicle parameter value stored within the cache device.

In an embodiment, the expiration value 18112 may indicate that the stored conditional vehicle parameter values are deleted upon the occurrence of the condition. For example, the expiration date value 18112 can be an expiration date, and the cache device can be configured to delete stored conditional vehicle parameter values 18018 that have timestamps beyond the expiration date. In an embodiment, the expiration value 18112 may indicate that the conditional vehicle parameter value 18018 is deleted when the vehicle is powered off. In embodiments, the expiration date value 18112 may indicate that the conditional vehicle parameter value 18018 is deleted upon sale and/or transfer of the vehicle.

In an embodiment, parameter storage circuitry 18020 may be configured to selectively expire multiple conditional vehicle parameter values 18018 in response to expiration time value 18112 . For example, parameter storage circuitry 18020 communicates with one or more caches that store conditional vehicle parameter values 18018 and deletes selected conditional vehicle parameter values 18018 in the one or more caches. You can send the above commands.

Also shown in FIG. 181, in an embodiment, device 18000 includes policy acquisition circuitry 18114 configured to interpret vehicle policy data values 18116 that include at least a portion of a vehicle policy, as described herein. can include In such embodiments, parameter adjustment circuit 18016 may be configured to generate expiration date value 18112 in response to vehicle policy data value 18116 . In embodiments, a vehicle policy may indicate where certain conditional vehicle parameter values are stored, how long conditional vehicle parameter values are stored, and/or under what conditions conditional vehicle parameter values are deleted. .

In an embodiment, the parameter adjustment circuit 18016 may be further configured to determine type values 18118 for the plurality of vehicle parameter values 18012 and/or 18014 and to generate the expiration value 18112 in response to the type values 18118 . Non-limiting examples of type values 18118 include engine data (eg, data relating to the engine and/or prime mover, operating parameters relating thereto, fault values relating thereto, and/or control parameters relating thereto), control data (eg, at least control operation of any component, system, endpoint, flow, application, etc., including input control parameters, control outputs, and/or intermediate control values such as thresholds, setpoints, error values, and/or state values data), mission-critical data (e.g., data utilized for mission operations of the vehicle, and/or data whose delay, loss, and/or degradation may result in reduced and/or lost mission performance capabilities). motivational state data (e.g., data indicating the state and/or current operational state associated with the vehicle's motivational motion, such as vehicle speed, position, selected gear values, motion-related actuator feedback values, etc.); and/ or drive operating data (eg, torque values, power throughput, active governor and/or control actions with grants, intermediate control values, etc., data indicative of motor operating state and/or current operating state). Non-limiting examples of type values 18118 include vehicle status values (e.g., driving conditions such as "RUNNING", "SHUTDOWN", "IDLE"; environmental parameters such as location, altitude, ambient temperature; and/or nominal performance, vehicle mode value (e.g. control mode, such as control operation with permission to vehicle functions; power, power off operation, idle operation); , hoteling operation; and/or any type of special mode operation such as high altitude operation, limp home operation, performance operation, economy operation, etc.); diagnostic value (e.g., diagnostic value (e.g., diagnostic code, counters, statuses, and/or intermediate parameters, which can be associated with any sensor, actuator, flow rate, application, endpoint, control action, etc.); and/or fault values (e.g., fault status, counters, code, intermediate value, etc., which may be associated with any sensor, actuator, flow rate, application, endpoint, control action, etc.).

Mission, vehicle mission, or other similar terms used herein should be understood broadly. Mission, as used herein, refers to primary function, intended function, critical function, and/or minimally enabling function (e.g., function necessary for operation to be considered normal and/or function accepted to allow continued operation). For example, a vehicle's mission may depend on the vehicle's current operating state and/or the vehicle's intended use. For example, a vehicle mission may include the ability to provide power and/or power operations, and the minimum available power, torque, and/or vehicle speed (e.g., the same as rated values for these). may include performance statements such as In another example, a mission may be the ability to provide power and/or functionality for a vehicle's systems--eg, lights, communication operations, maintenance operations, cabin environment operations, and the like. In certain embodiments, some level of operation of the vehicle or component is restricted when the vehicle or component is not mission capable—e.g., when powered operation is possible but below the acceptable performance characteristics of the vehicle. can be made available. In certain embodiments, mission-related aspects do not impact vehicle performance, but may nonetheless be mission-critical, e.g., loss of airbag function, ABS function, etc. may affect the mission ( (e.g., power operation), but may be considered mission-critical because the vehicle nevertheless continues to operate in an acceptable manner. Missions such as vehicles, components, control actions, etc. may be affected by design considerations, purpose of the vehicle, policies and/or preferences of entities associated with the vehicle (e.g., fleet owners, vehicle owners, regulatory authorities, etc.), geography of the vehicle. It will be appreciated that it may depend on the context of the vehicle, such as the target position, and/or the vehicle's terrain position (eg, current altitude, grade, road type, etc.). The data value or other characteristic is the first vehicle but not the second vehicle and/or the first time for the given vehicle but not the second time for the given vehicle, the mission It can be a critical and/or mission related data value or feature. Those of ordinary skill in the art, having the benefit of this disclosure and the information commonly available about vehicles and their components, will be able to determine whether data values, control operations, components, or other elements of the system are mission-critical and/or mission-related. It is possible to easily decide whether Specific considerations for determining whether a system data value, control operation, component, or other element is mission-critical and/or mission-related include, but are not limited to, vehicle rating, vehicle intended use, , quality of service requirements associated with the vehicle, warranties for the vehicle or its components, expected duty cycle of the vehicle, geographical operating area of the vehicle, geographical operating area of the vehicle, regulatory requirements associated with the vehicle, and/or Includes policy considerations related to vehicles.

In embodiments, parameter adjustment circuit 18016 may be configured to adjust vehicle parameter values 18012 and/or 18014 through compression of vehicle parameter values 18012 and/or 18014 . Compression of vehicle parameter values 18012 and/or 18014 may be performed in such a way that more adjusted vehicle parameter values 18012 and/or 18014 can be stored in a given cache than would otherwise be possible. may be reduced in overall size.

In embodiments, parameter adjustment circuit 18016 may be configured to adjust vehicle parameter values 18012 and/or 18014 via summarization of vehicle parameter values 18012 and/or 18014 . Summarizing vehicle parameter values 18012 and/or 18014 may include rounding and/or truncating the raw values of vehicle parameter values 18012 and/or 18014 . Summarizing vehicle parameter values 18012 and/or 18014 may include reducing vehicle parameter values 18012 and/or 18014 to a simpler data form. For example, vehicle parameter values 18012 and/or 18014, which have long floating point numbers corresponding to engine temperature, oil temperature, revolutions per minute, etc., can be summarized together as one bit, where "0" The engine is functioning optimally, and a "1" represents the engine not functioning optimally. Summarizing vehicle parameter values 18012 and/or 18014 may reduce overall memory requirements for caching vehicle parameter values 18012 and/or 18014 .

Shown in FIG. 182 is a method 18200 for data storage management, according to one embodiment of the present disclosure. Method 18200 may be performed by device 18000 and/or by any other device and/or controller described herein. Thus, referring now to Figures 180 and 182, the method 18200 comprises a step 18210 of interpreting a plurality of vehicle parameter values 18012 and/or 18014; Step 18212 of adjusting 18012 and/or 18014 and storing 18214 the adjusted plurality of vehicle parameter values 18018 in one or more cache devices.

181 and 183, in an embodiment method 18200 may include step 18310 of determining a storage location value 18110. FIG. In such embodiments, the step 18214 of storing the adjusted plurality of vehicle parameter values 18018 may be responsive to the storage position values 18110 . In embodiments, one or more cache devices may be located on the vehicle. In such embodiments, each of the one or more cache devices located on the vehicle may be associated with a different controller than the controller associated with the other of the one or more cache devices. In embodiments, one or more cache devices may be located outside the vehicle. In such embodiments, one or more cache devices may be based, at least in part, on a network cloud-based storage system.

181 and 184, the method 18200 comprises storing 18410 a first portion of the adjusted plurality of vehicle parameter values 18018 in a first cache device; a step 18412 of storing a second portion 18412 of 18018 in a second cache device, the first cache device located on the vehicle and the second cache device located outside the vehicle; can include

In an embodiment, method 18200 includes expiration values for a plurality of vehicle parameter values 18012 and/or 18014 configured to trigger selective expiration of conditional vehicle parameter values 18018 in one or more cache devices. A step 18414 of generating 18112 can be included.

In embodiments, the method 18200 may include sending 18416 the expiration value 18112 to one or more cache devices.

As shown in FIG. 185 , in an embodiment method 18200 may include selectively expiring 18510 a plurality of conditional vehicle parameter values 18018 in response to expiration time value 18110 . In embodiments, the expiration time value 18112 may be a time value corresponding to a time period during which the plurality of conditional vehicle parameter values 18018 are stored in one or more caches.

181 and 186, in embodiments the method 18200 may include a step 18610 of interpreting a vehicle policy data value 18116 that includes at least a portion of a vehicle policy, as described herein. . In such an embodiment, step 18414 of generating expiration time values 18112 for plurality of conditional vehicle parameter values 18018 is responsive to vehicle policy data values 18116 .

In an embodiment, the method 18200 may include determining 18612 a type value 18118 for the plurality of vehicle parameter values 18012 and/or 18014 . In such embodiments, step 18414 of generating expiration values 18112 for a plurality of vehicle parameter values 18012 and/or 18014 is responsive to type value 18118 .

In an embodiment, adjusting 18212 the plurality of vehicle parameter values 18012 and/or 18014 includes compressing 18614 the plurality of vehicle parameter values 18012 and/or 18014 .

In an embodiment, adjusting 18212 multiple vehicle parameter values 18012 and/or 18014 includes summarizing 18616 multiple vehicle parameter values 18012 and/or 18014 .

Referring to FIG. 187, receiving a trigger description value 18701 from a user, outputting a response action value 18707 to a remote device such as a cloud device in response to the trigger description value 18701, and identifying vehicle data in response to the response action value 18707. A box diagram illustrating an exemplary user device 18710 configured to receive at least one of 18705 or alert response values 18703 is shown.

Response action value 18707 may be configured to identify vehicle data that is conditionally returned to the user. For example, a fleet operator user may desire to receive vehicle speed and position data when the vehicle's ignition is turned on. Response action values 18707 may also be configured to identify alert response values to be conditionally returned to the user. A user may be a person or entity such as a vehicle manufacturer, original equipment manufacturer, vehicle owner, bodybuilder, vehicle service department, fleet operator, or third party vendor, to name a few. .

User device 18710 includes vehicle event graphical user interface (GUI) 18711 , request circuit 18713 and cloud interface 18715 . Vehicle event graphical user interface 18711 is configured to interpret trigger description values 18701 from a user, where trigger description values 18701 include trigger conditions. In certain embodiments, trigger description value 18701 includes multiple trigger conditions that must be evaluated to determine whether to capture a particular identified vehicle data value, or multiple trigger conditions represent different data values. Multiple values of identified vehicle data from the source may be supported. In certain embodiments, multiple trigger conditions include multiple data types.

In certain embodiments, GUI 18711 is configured to display vehicle use case templates of a plurality of vehicle use case templates in response to template selections from a user. For example, a mechanic may use a vehicle case template that displays selectable on-demand diagnostic tests to be run on the vehicle. GUI 18711 may be configured to display a portion of the plurality of vehicle usage template identifiers, GUI 18711 determining the portion based on at least one of authorization values and location values. In particular embodiments, authorization values may correspond to a user, such as an authorization level or hierarchy granted to the user. The location value may correspond to the location of the user device, the location of the vehicle from which the data is collected, or the location of the device receiving the alert response value 19005 depending on the data collection policy 19003 . For example, a fleet operator may not be able to request vehicle data specified on a vehicle usage template generated by a manufacturer. In another example, a manufacturer may be prohibited from collecting certain types of data depending on the jurisdiction in which the vehicle and/or user is currently located.

In certain embodiments, GUI 18711 is configured to display a plurality of vehicle usage template identifiers and indicate that some of the displayed plurality of vehicle user template identifiers are unavailable to the user. For example, vehicle use case templates may not be available based on vehicle data collection parameter values, such as requested data sampling frequency, which the vehicle cannot perform. In certain embodiments, GUI 18711 indicates by displaying a notification that includes the reason why the vehicle use case template is not available. In certain embodiments, GUI 18711 is configured to display a vehicle usage template that includes multiple vehicle data identifiers based on authorization values. For example, GUI 18711 may display only vehicle use case templates that the user is authorized to use. An authorization value may indicate that a user is authorized to collect either trigger evaluation data or identified vehicle data from a particular data source, subject to vehicle data collection parameters. For example, one authorization value may indicate that a user may collect vehicle speed, but only at a rate of less than 1 sample per second. Therefore, users would not be permitted to use vehicle use case templates where vehicle speed is collected at a sampling rate greater than 1 sample per second.

the request circuit 18713 is configured to determine a response action value in response to the trigger description value, the response action value being a vehicle data identifier configured to identify vehicle data to be captured in response to the trigger condition; or At least one alert execution description sent in response to a trigger condition is included.

In certain embodiments, the request circuit 18713 is configured to filter out the trigger description values depending on the vehicle data collection parameter values and notify the user. For example, a trigger description value may be excluded if the corresponding vehicle data has already been collected. In another example, a trigger description value can be excluded if the vehicle cannot collect the data specified by the trigger description.

After sending the response action value 18707 to a remote device, such as a cloud device, the cloud interface 18715 receives at least a portion of the identified vehicle data and/or the alert response value determined in response to the alert execution description. Configured. It is to be understood that any or all of the aforementioned features of user device 18700 may also be present in other user devices disclosed herein.

Referring to FIG. 188, an exemplary user device based vehicle data collection process 18800 is illustrated. Process 18800 may be implemented in whole or in part in one or more of the user devices disclosed herein. Variations and modifications of process 18800 are contemplated, including, for example, omitting one or more aspects of process 18800, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. shall be further understood.

Process 18800 begins with operation 18801 which includes operating a user device including a vehicle graphical user interface, a request circuit, and a cloud interface. Process 18800 continues to operation 18803 where the user device interprets the trigger description value from the user, the trigger description value including the trigger state. Process 18800 continues to operation 18805 where the user device determines a response action value in response to the trigger description value, the response action value being vehicle data configured to identify vehicle data captured in response to the trigger condition. It includes at least one of an identifier or an alert execution description sent in response to a trigger condition. Process 18800 continues to operation 18807 where the user device receives at least a portion of the identified vehicle data or at least one of the alert response values determined in response to the alert execution description. It is understood that any or all of the aforementioned features of exemplary process 18800 may also be present in other processes disclosed herein, such as the process shown in FIG. 189, to name one example. shall be

Referring to FIG. 189, an exemplary user device based vehicle data collection process 18900 is illustrated. Process 18900 may be implemented in whole or in part in one or more of the user devices disclosed herein. Variations and modifications of process 18900 are contemplated, including, for example, omitting one or more aspects of process 18900, adding additional conditions and actions, or reorganizing or separating actions and conditions into separate processes. It is further understood that

Process 18900 begins with operation 18901 which involves operating a user device. Process 18900 continues to operation 18903 where the user device displays the vehicle use case template. Act 18903 may include displaying a portion of the plurality of vehicle use template identifiers and, in response to template selection, displaying vehicle use case templates of the plurality of vehicle use case templates. Act 18903 is displaying the plurality of vehicle usage template identifiers and indicating that some of the plurality of vehicle usage template identifiers are unavailable based on the vehicle data collection parameter values, where the vehicle data collection parameter values are , indicating that the identified vehicle data cannot be captured by the vehicle. Act 18903 can include displaying a vehicle use case template including multiple vehicle data identifiers based on the authorization value.

Process 18900 continues to operation 18905 where the user device interprets the trigger description value from the user. Process 18900 continues to operation 18907 where the user device determines responsive action values as a function of the trigger description values. Act 18907 may include excluding trigger description values as a function of vehicle data collection parameter values and receiving updated trigger description values from the user. Process 18900 continues to operation 18909 where the user device receives at least a portion of the identified vehicle data or at least one of the alert response values determined in response to the alert execution description. It is understood that any or all of the aforementioned features of exemplary process 18900 may also be present in other processes disclosed herein, such as the process shown in FIG. 188, to name one example. shall be

Referring to FIG. 190, a cloud system 19010 including cloud devices 19020 and 19030 is illustrated. Cloud system 19010 receives response action values 19001 from one or more user devices such as user device 18710 in FIG. 187, outputs data collection policies 19003 to vehicles such as vehicle 19610 in FIG. is configured to receive at least one of the alert response value 19005 or the identified vehicle data 19007 in response to.

Cloud appliance 19020 includes request interface 19021 , policy creator circuitry 19022 , cloud interface 19023 , template storage circuitry 19024 , validation circuitry 19025 and authorization circuitry 19026 .

Request interface 190 is configured to interpret multiple response action values. Request interface 190 may be configured to communicate with multiple user devices.

Policy creator circuitry 19022 is configured to determine data collection policy 19003 as a function of one or more response action values. The data collection policy 19003 includes a vehicle data identifier configured to identify vehicle data to be captured, a trigger evaluation data identifier configured to identify trigger evaluation data, and a trigger evaluation data identifier configured to identify trigger evaluation data. and a trigger condition to be triggered. In certain embodiments, determining the data collection policy 19003 includes mapping vehicle data identifiers to vehicle data sources. For example, if one of the response action values 19001 calls for vehicle speed, policy creator circuit 19022 determines the source of vehicle data that observes vehicle speed and includes an identifier corresponding to the vehicle data in data collection policy 19003 . In another example, the data collection policy 19003 can combine vehicle data from multiple sources to form a virtual data source and associate vehicle data identifiers with the virtual data source.

In certain embodiments, multiple response action values 19001 include multiple evaluation collection parameter values each corresponding to trigger evaluation data from a common vehicle data source. Policy creator circuitry 19022 is configured to determine an evaluation collection parameter value for the data collection policy in response to a plurality of evaluation collection parameter values. For example, the multiple evaluation collection parameter values may be multiple different frequencies, and the evaluation collection parameter value of the data collection policy 19003 specifies a single frequency of collecting vehicle data such that the response action value meets the frequency requirements. specify.

Data collection policy 19003 is configured to define data collection procedures to be implemented by the vehicle. Data collection policy 19003 includes one or more trigger policies, each trigger policy includes one or more triggers, and each trigger includes a trigger state. According to the data collection policy 19003, the vehicle collects trigger evaluation data to evaluate the trigger conditions of the data collection policy 19003. Vehicles may also collect identified vehicle data from sources according to data collection parameters, such as frequency, defined by data collection policy 19003 . The data capture time window for the identified vehicle data to be collected is determined by evaluating the data collection policy 19003 triggers. For example, the data collection policy 19003 may start transmitting the vehicle's location information when the vehicle's ignition is turned on and the vehicle enters a geofence, and stop transmitting location information when the ignition is turned off. be able to.

A data collection policy 19003 can include multiple trigger types. A trigger can include a trigger identifier, a trigger type identifier, and a trigger state. Triggers can also contain additional fields. A trigger identifier is a globally unique identifier configured to identify a corresponding trigger to distinguish the corresponding trigger from other triggers. A trigger type identifier is configured to identify the type of trigger. For example, the trigger type identifier is a value that identifies the trigger as a signal trigger, vehicle status trigger, timing trigger, schedule trigger, or geofence trigger, environment trigger, user input trigger, or error trigger, to name a few. can do.

A trigger condition is either satisfied or unsatisfied, also called true or false, and evaluation of the trigger produces a Boolean result indicating whether the trigger condition was satisfied. A trigger state can include one or more fields of the trigger.

In certain embodiments, trigger conditions are configured as comparison expressions in which keys and values are compared. Keys and values can be compared using one of several comparators such as greater than, less than, equal to, greater than, less than, or not equal to name a few. can. The key is based on trigger evaluation data interpreted by the vehicle's data acquisition controller. For example, if vehicle speed collected from the vehicle is the key and 5 is the value, a trigger condition can be used to determine if the vehicle speed is greater than 5 mph. In certain embodiments, the key is the derivative or anti-derivative of the trigger evaluation data. In certain embodiments, the key is the sum of the trigger evaluation data.

In certain embodiments, trigger states are configured as modified pairs in which the previous value of the key, the current value of the key, and the preset value are compared. The trigger condition is met when the current value of the key equals the preset value and the previous value of the key did not equal the preset value. For example, the trigger state change equation may be satisfied at the time it is determined that the vehicle has started, and then future trigger state evaluations may fail, even though the vehicle is still driving.

The multiple triggers can include signal triggers. The data collection controller uses signal triggers to collect data based on the values of signals generated by the vehicle. The signal trigger includes a signal identifier configured to identify a single signal containing the value, the signal being transmitted over one of the vehicle's communication channels. A signal identifier contains the name of a signal that is unique across all communication channels of the vehicle. In certain embodiments, signal names are based on CAN and Ethernet databases. A signal trigger includes a trigger condition that is determined to be met based on evaluating an expression using the identified signal. In certain embodiments, the signal trigger condition can be evaluated to determine whether the value of the identified signal satisfies a comparison or varying equation. For example, a signal trigger condition may be met when the value of the identified signal changes from a previous value to a preset value indicating that the ABS alert light has been illuminated. In another example, the signal trigger condition may be met if the value of the identified signal makes the comparison expression true, such as when the signal value is 5 and the expression is greater than 3. .

The multiple triggers can include vehicle status triggers. The data collection controller uses vehicle status triggers to collect data based on the vehicle status of the vehicle. The vehicle status trigger includes a vehicle status identifier configured to identify a vehicle status of the vehicle. For example, the vehicle status identifier may identify an accessory mode status or one of multiple ignition position statuses. Vehicle status triggers include conditions that are met based on the vehicle status corresponding to the vehicle status identifier. For example, if the vehicle status identifier corresponds to an accessory mode and the condition that the accessory mode is on is met and the data acquisition controller determines that the vehicle's accessory mode is indeed on, then the condition is met. can be made available.

The multiple triggers can include timing triggers. The data collection controller uses timing triggers to collect data based on times occurring after discrete events. A timing trigger includes a discrete event identifier and a condition that includes a delay value. The discrete event identifier is configured to identify a discrete event of the vehicle, such as an engine start, to name one example. Delay values include durations, such as milliseconds, by way of example. When the condition is met after the duration has completed following the discrete event, the timing trigger outputs a value indicating that the timing trigger has been met. For example, if the timing trigger includes a discrete event identifier for vehicle activation and a delay value of 5000 milliseconds, the condition of the timing trigger will be satisfied 5000 milliseconds after the data collector controller determines that vehicle activation has occurred. Become.

Multiple triggers can include schedule triggers. The data collection controller uses schedule triggers to collect data on a schedule. Schedule triggers include conditions that are met at one or more times. Conditions can include multiple fields such as minutes, hours, days of the week, days of the month, and years, to name a few. In certain embodiments, each unfilled field of the plurality of fields corresponds to repeated times that would satisfy the trigger. For example, with a condition that includes an Hour field filled with 12, a Minute field filled with 0, and a Day of Week field filled with Sunday, the trigger will fire at 12:00 on Sunday for all Sundays in all months of the year. will be filled. In certain embodiments, the schedule trigger includes a missed schedule field configured to indicate whether the last scheduled data collection was missed. If missed, the schedule trigger condition is met and data collection will occur immediately rather than at the next scheduled time.

Multiple triggers can include geofence triggers. The data collection controller uses geofence triggers to collect geofence-based data. A geofence trigger includes a trigger identifier, an event field, and an area field. The event field contains values corresponding to entering an area, being in an area, being outside an area, or leaving an area. This area field may contain coordinates that define the boundaries of the geographic area. In particular embodiments, the area field includes longitude and latitude coordinates of a first location and origin 2 and latitude coordinates of a second location, wherein the first and second locations are of a rectangular geographic region. Corresponding to opposite corners. A geofence trigger condition is met when a vehicle completes an event to an area. For example, a geofence trigger may include event field values corresponding to being all inside a rectangular geographic area. The condition is met by determining that the longitude of the vehicle is between the longitudes of the first and second positions of the area and the latitude of the first and second positions of the area.

Multiple triggers can include error triggers. The data collection controller uses error triggers to collect data based on error messages generated by the vehicle. For example, a trigger condition may specify a low oil pressure alert such that the trigger condition is met when the low oil pressure alert is activated.

Multiple triggers can include environmental triggers. The data collection controller uses environmental triggers to collect data based on environmental parameters. For example, a trigger condition can specify an ambient temperature such that the trigger condition is met when the ambient temperature exceeds a preset value.

The multiple triggers can include user input triggers. The data collection controller uses user input triggers to collect data based on input received from the user. For example, a trigger condition may specify a signal from a button in the vehicle such that the trigger condition is met when the button is pressed.

The triggering policy of data collection policy 19003 defines which triggers are evaluated to determine the occurrence of the triggering event and which triggers are evaluated to determine the termination of the triggering event. A trigger policy can include a trigger identifier, a trigger type identifier, and a condition. Trigger policies can also include additional fields. A trigger identifier is a globally unique identifier configured to identify a corresponding trigger to distinguish the corresponding trigger from other triggers. A trigger type identifier is configured to identify the type of trigger. For example, the trigger type identifier is a value that identifies the trigger as a signal trigger, vehicle status trigger, timing trigger, schedule trigger, geofence trigger, error trigger, environment trigger, or user input trigger, to name a few. be able to. In certain embodiments, the end of a trigger event is determined not by the trigger, but instead by a maximum start value, which indicates the number of times the starting trigger condition can be true before the trigger is disabled.

Data collection policy 19003 identifies vehicle data to be captured in response to each trigger policy of data collection policy 19003 . Alternatively, data collection policy 19003 identifies alert response values to be sent in response to one or more trigger policies of data collection policy 19003 . Data collection policy 19003 also identifies trigger evaluation data, which is data that is required to be collected to evaluate the trigger condition of data collection policy 19003 . Data collection policy 19003 may cause multiple types of data to be obtained and transmitted from the vehicle and may require multiple types of data to be collected for trigger evaluation data.

The cloud interface 19023 is configured to communicate with the cloud interface 19033 of the cloud device 19030 to receive vehicle data 19007 identified according to the data collection policy 19003 or alert response values 19005 according to the data collection policy 19003. can be configured to

Template storage circuitry 19024 is configured to store a plurality of vehicle use case templates. Upon request from the user device, template storage circuitry 19024 can provide the requested template. In certain embodiments, template storage circuitry 19024 stores the requested template only after determining that the user is authorized to view the template based on authorization values or based on vehicle or user device location. I will provide a.

Verification circuitry 19025 is configured to determine that the vehicle can capture the data requested by the user and eliminate one of response action values 19001 . In certain embodiments, verification circuitry 19025 is configured to eliminate one of plurality of response action values 19001 in response to determining the execution parameter value. Validation circuit 19025 determines the running parameter values by determining that the vehicle data identified by the excluded response action values cannot be captured by the vehicle.

Authorization circuitry 19026 is configured to tag data collection policies according to authorization values. Authorization value indicates that a user requesting one of multiple response action values 19001 is not authorized to receive identified vehicle data 19007 . For example, a manufacturer can request camera data from a vehicle, but the request is tagged if the vehicle owner has not yet given authorization to the manufacturer. In this way, camera data may still be captured and returned to the cloud, but the manufacturer will not be able to access the camera data until the vehicle owner grants authorization.

Cloud device 19030 includes vehicle data storage circuitry 19031 , cloud interface 19033 and vehicle data query circuitry 19035 . Vehicle data storage circuitry 19031 is configured to store identified vehicle data received from vehicles in accordance with data collection policy 19003 . In certain embodiments, identified vehicle data 19007 is stored with vehicle storage circuitry 19031 such that cloud device 19030 is not configured to decode identified vehicle data 19007 stored with vehicle data storage circuitry 19031 . Encrypted while stored. In this way, a cyber attacker who has achieved access to the stored identification vehicle data 19007 does not have means to decrypt the data, and a cyber attacker who has achieved access to the cloud device 19020 also has access to the identified vehicle data. Unable to get access to 19007.

Cloud interface 19033 is configured to provide identified vehicle data to cloud interface 19023 in response to vehicle data requests from vehicle data query circuitry 19027 of cloud device 19020 . In response to the vehicle data request, cloud device 19030 may retrieve metadata corresponding to identified vehicle data stored in vehicle data storage circuitry 19031 . It is to be understood that any or all of the aforementioned features of cloud system 19010 may also exist in other cloud systems disclosed herein. It should be appreciated that any or all of the aforementioned features of cloud system 19010 may also be present in other embodiments disclosed herein. It is to be understood that any or all of the aforementioned features of data collection policy 19003 may be present in other embodiments disclosed herein.

Referring to FIG. 191, an exemplary cloud system based vehicle data collection process 19100 is illustrated. Process 19100 may be implemented in whole or in part in one or more cloud systems disclosed herein. Variations and modifications of process 19100 are contemplated, including, for example, omitting one or more aspects of process 19100, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. It is further understood that

Process 19100 begins with operation 19101 which includes operating a cloud system including a request interface, a policy creator circuit, and a cloud interface. Process 19100 continues to operation 19103 where the cloud system interprets multiple response action values. Process 19100 continues to operation 19105 where the cloud system determines a data collection policy in response to the plurality of response action values, the data collection policy including the vehicle data identifier and the trigger configured to identify the trigger evaluation data. Proceed to operation 19106, which includes an evaluation data identifier and a trigger condition to be evaluated in response to the identified trigger evaluation data. Process 19100 continues to operation 19107, where the cloud system receives at least a portion of the vehicle data identified according to the data collection policy or at least one of the alert response values according to the data collection policy. Any or all of the aforementioned features of exemplary process 19100 may also be present in other processes disclosed herein, such as the processes shown in FIGS. 192-195, to name a few examples. It shall be understood that

Referring to FIG. 192, an exemplary cloud system based vehicle data collection process 19200 is illustrated. Process 19200 may be implemented in whole or in part in one or more cloud systems disclosed herein. Variations and modifications of process 19200 are contemplated, including, for example, omitting one or more aspects of process 19200, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. It is further understood that

The process 19200 begins with operation 19201 comprising operating a cloud system including a first cloud device including a request interface, a policy creator circuit, and a cloud interface, and a second cloud device. Process 19200 continues to operation 19203, where the first cloud device stores a plurality of vehicle use case templates. Process 19200 continues to operation 19205, where the first cloud device provides one of a plurality of vehicle use case templates in response to the user device request and at least one of the authorization value or the location value. Configured. Process 19200 continues to operation 19207 where the first cloud device interprets the plurality of response action values. Process 19200 continues to operation 19209 where the first cloud device determines a data collection policy in response to multiple response action values, the data collection policy configured to identify the vehicle data identifier and the trigger evaluation data. act 19209, including the identified trigger evaluation data identifier and the trigger condition evaluated in response to the identified trigger evaluation data. Process 19200 continues to operation 19211, where the second cloud device receives at least a portion of the vehicle data identified according to the data collection policy or at least one of the alert response values according to the data collection policy. Any or all of the aforementioned features of exemplary process 19200 may be present in other processes disclosed herein, such as processes 191 and 193-195, to name a few. shall be understood.

Referring to FIG. 193, an exemplary cloud system based vehicle data collection process 19300 is illustrated. Process 19300 may be implemented in whole or in part in one or more cloud systems disclosed herein. Variations and modifications of process 19300 are contemplated, including, for example, omitting one or more aspects of process 19300, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. It is further understood that

Process 19300 begins with operation 19301 which includes operating a cloud system including a request interface, policy creator circuitry, validation circuitry, and a cloud interface. Process 19300 continues to operation 19303 where the cloud system interprets multiple response action values. Process 19300 continues to operation 19305 where the cloud system eliminates one of the plurality of responsive action values in response to determining execution parameter values. Process 19300 continues to operation 19307 where the cloud system determines a data collection policy as a function of the plurality of response action values, the data collection policy including the vehicle data identifier and the trigger configured to identify the trigger evaluation data. Act 19308, including an evaluation data identifier and a trigger condition to be evaluated in response to the identified trigger evaluation data. Process 19300 continues to operation 19309, where the cloud system receives at least a portion of the vehicle data identified according to the data collection policy or at least one of the alert response values according to the data collection policy. Any or all of the foregoing features of exemplary process 19200 may be used in other processes disclosed herein, such as the processes shown in FIGS. It shall be understood that there may also be

Referring to FIG. 194, an exemplary cloud system based vehicle data collection process 19400 is illustrated. Process 19400 may be implemented in whole or in part in one or more cloud systems disclosed herein. Variations and modifications of process 19400 are contemplated, including, for example, omitting one or more aspects of process 19400, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. It is further understood that

Process 19400 begins with operation 19401 which includes operating a cloud system including a request interface, policy creator circuitry, authorization circuitry, and a cloud interface. Process 19400 continues to operation 19403 where the cloud system interprets multiple response action values. Process 19400 continues to operation 19405 where the cloud system determines a data collection policy in response to the plurality of responsive action values, the data collection policy is the vehicle data identifier and the trigger configured to identify the trigger evaluation data. It includes an evaluation data identifier and a trigger condition to be evaluated in response to the identified trigger evaluation data. Process 19400 continues to operation 19407 where the cloud system tags the data collection policy with an authorization value, the authorization value being a source of the plurality of response action values received the identified vehicle data. indicates that you are not authorized to do so. Process 19400 continues to operation 19409 where the cloud system receives at least a portion of the vehicle data identified in response to the data collection policy or receives an alert response value in response to the data collection policy. Any or all of the foregoing features of exemplary process 19400 are also present in other processes disclosed herein, such as the processes shown in FIGS. It shall be understood that

Referring to FIG. 195, an exemplary cloud system based vehicle data collection process 19500 is illustrated. Process 19500 may be implemented in whole or in part in one or more cloud systems disclosed herein. Variations and modifications of process 19500 are contemplated, including, for example, omitting one or more aspects of process 19500, adding additional conditions and actions, or reorganizing or separating actions and conditions into separate processes. It is further understood that

Process 19500 begins with operation 19501 which involves operating a cloud system including a first cloud device and a second cloud device. Process 19500 continues to operation 19503 where the first cloud device interprets multiple response action values. Process 19500 continues to operation 19505, where the first cloud device determines a data collection policy in response to the plurality of response action values, the data collection policy configured to identify the vehicle data identifier and the trigger evaluation data. a trigger evaluation data identifier identified; and a trigger condition to be evaluated in response to the identified trigger evaluation data. Process 19500 continues to operation 19511 where the second cloud device receives the identified vehicle data according to the data collection policy. Process 19500 continues to operation 19505 where the second cloud device stores the identified vehicle data and metadata corresponding to the identified vehicle data. Process 19500 continues to operation 19505 where the second cloud device provides the identified vehicle data to the first cloud device in response to a request from the first cloud device. Process 19500 continues to operation 19507 where the cloud system interprets multiple response action values.

Referring to FIG. 196, receiving a data collection policy 19601, determining that the data collection policy 19601 is valid and permitted, and triggering evaluation data and potentially identified vehicle data 19605 defined by the data collection policy 19601. and configured to output at least one of alert response values 19603 or identified vehicle data 19605 in response to data collection policy 19601. It is

Vehicle communication system 196 includes cloud interface 19621 , policy update circuitry 19622 , trigger evaluation circuitry 19623 , policy manager circuitry 19624 and transmission circuitry 19625 .

Cloud interface 19621 is configured to interpret data collection policies 19601 from remote devices, such as cloud devices. Data collection policy 19601 can include a trigger evaluation data identifier configured to identify trigger evaluation data collected according to vehicle data collection parameters, where the trigger evaluation data evaluates the trigger status of data collection policy 19601. This data is necessary for For example, data collection policy 19601 may specify vehicle speed as the trigger evaluation data, sampling frequency as the data collection parameter, and vehicle speed greater than 80 mph as the trigger condition.

Policy update circuit 19622 is configured to determine whether the vehicle is capable of performing actions required by data collection policy 19601 . Policy update circuit 19622 may determine collection verification values as a function of identified trigger evaluation data and vehicle data collection parameters. The collected verification value may indicate whether the vehicle is configured to provide trigger evaluation data or identified vehicle data. For example, if the vehicle data collection parameters include a sampling frequency that is too high to be performed by the vehicle, the collection verification value will indicate that the vehicle cannot perform the data collection policy 19601.

In certain embodiments, policy update circuitry 19622 is configured to determine the authorization status of data collection policy 19601 . Authorization status may be determined based on the authorization value of the user requesting information from the vehicle. For example, policy update circuitry 19622 may determine that a manufacturer with authorization value and requesting vehicle data is authorized to receive vehicle data captured in accordance with data collection policy 19601. . In another example, policy update circuit 19622 indicates that certain vehicle data can be collected based on the location of the vehicle, the location of the user requesting the data, or the location of an intermediary device that transmits vehicle data from the vehicle to the user. Authorization status can be determined. In certain embodiments, authorization values can be used to determine authorization to collect certain vehicle data according to corresponding data parameters. For example, a vehicle owner's authorization value may indicate authorization to collect vehicle speed, but not at sampling rates above 1 Hz. In certain embodiments, policy update circuit 19622 determines a change in the authorization status of data collection policy 19601 and causes the vehicle to stop executing data collection policy 19601 . For example, execution may stop in response to updated authorization values and/or updated location values.

Trigger evaluation circuit 19623 is configured to evaluate the trigger status of data collection policy 19601 as a function of collection verification values and/or authorization status. For example, trigger evaluation circuitry 19623 may receive a trigger condition only if policy update circuitry 19622 determines that data collection policy 19601 is authorized and/or valid.

Policy manager circuitry 19624 is configured to parse data collection policy 19601 depending on collection verification values and/or authorization status. Policy manager circuit 19624 distributes parsed data collection policies effective to reconfigure the vehicle to collect data according to data collection policy 19601 . In certain embodiments, policy manager circuit 19624 controls data collection policy 19601 depending on a collection verification value indicating that data collection policy 19601 is valid and/or an authorization status indicating that data collection policy 19601 has been authorized. and replace the previous data collection policy with the data collection policy 19601.

Transmission circuitry 19625 is configured to provide identified vehicle data 19605 or alert response values in response to the occurrence of a trigger event determined by trigger evaluation circuitry 19623 . The sending circuit 19625 can communicate with the remote device that sent the data collection policy 19601 or another device such as a user device. The alert response values may include at least one of alert criteria, alert type, alert content, and alert location. It is to be understood that any or all of the aforementioned features of vehicle 19610 may also be present in other vehicles disclosed herein.

Referring to FIG. 197, an exemplary vehicle-based vehicle data collection process 19700 is illustrated. Process 19700 may be implemented in whole or in part in one or more vehicles disclosed herein. Variations and modifications of process 19700 are contemplated, including, for example, omitting one or more aspects of process 19700, adding additional conditions and actions, or reorganizing or separating actions and conditions into separate processes. It is further understood that

Process 19700 begins with operation 19701 which includes operating a vehicle including a cloud interface, policy update circuitry, and trigger evaluation circuitry. Process 19700 continues to operation 19703 where the vehicle interprets the data collection policy from the remote device, the data collection policy including a trigger evaluation data identifier configured to identify trigger evaluation data to be evaluated in response to trigger conditions. including. Process 19700 continues to operation 19705 where the vehicle determines collection verification values in response to the identified trigger evaluation data and vehicle data collection parameters. Process 19700 continues to operation 19707 where the trigger evaluation circuit receives a trigger condition responsive to the collected verification value. Any or all of the foregoing features of exemplary process 19700 may also be present in other processes disclosed herein, such as the processes illustrated in FIGS. 198-200, to name a few. It shall be understood that

Referring to FIG. 198, an exemplary vehicle-based vehicle data collection process 19800 is illustrated. Process 19800 may be implemented in whole or in part in one or more vehicles disclosed herein. Variations and modifications of process 19800 are contemplated, including, for example, omitting one or more aspects of process 19800, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. It is further understood that

Process 19800 begins with operation 19801 which includes operating a vehicle including a cloud interface, policy update circuitry, and trigger evaluation circuitry. Process 19800 continues to operation 19803 where the vehicle interprets the data collection policy from the remote device, the data collection policy including a trigger evaluation data identifier configured to identify trigger evaluation data to be evaluated in response to trigger conditions. including. Process 19800 continues to operation 19805 where the vehicle determines collection verification values in response to the identified trigger evaluation data and vehicle data collection parameters. Process 19800 continues to operation 19807 where the vehicle parses the data collection policy according to the collection verification values. Process 19800 continues to operation 19809 where trigger evaluation receives a trigger condition responsive to collected verification values. Any or all of the foregoing features of exemplary process 19800 may also be applied in other processes disclosed herein, such as the processes shown in FIGS. 197 and 199-200, to name a few. It is to be understood that there may be

Referring to FIG. 199, an exemplary vehicle-based vehicle data collection process 19900 is illustrated. Process 19900 may be implemented in whole or in part in one or more vehicles disclosed herein. Variations and modifications of process 19900 are contemplated to include, for example, omitting one or more aspects of process 19900, adding additional conditions and actions, or reorganizing or separating actions and conditions into separate processes. It is further understood that

Process 1900 begins at operation 19901 which includes operating a vehicle including a cloud interface, policy update circuitry, and trigger evaluation circuitry. Process 1900 continues to operation 19903 where the vehicle interprets the data collection policy from the remote device, the data collection policy including a trigger evaluation data identifier configured to identify trigger evaluation data to be evaluated in response to a trigger condition. include. Process 1999 continues to operation 19905 where the vehicle determines collection verification values in response to the identified trigger evaluation data and vehicle data collection parameters. Process 1999 continues to action 19907 where the trigger evaluation circuit receives a trigger condition responsive to the collected verification value. Process 19900 advances to operation 19909 where the vehicle determines a trigger event has occurred depending on the trigger condition. Process 19900 continues to operation 19911 where the vehicle provides identified vehicle data in response to the occurrence of a trigger event or provides an alert response value in response to the occurrence of a trigger event.

Referring to diagram 200, an exemplary vehicle-based vehicle data collection process 20000 is illustrated. Process 20000 may be implemented in whole or in part in one or more vehicles disclosed herein. Variations and modifications of process 20000 are contemplated, including, for example, omitting one or more aspects of process 20000, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. It should be further understood that

Process 20000 begins at operation 20001 which includes operating a vehicle including a cloud interface, policy update circuitry, policy manager circuitry, and trigger evaluation circuitry. Process 20000 continues to operation 20003 where the vehicle interprets the data collection policy from the remote device, the data collection policy including a trigger evaluation data identifier configured to identify trigger evaluation data to be evaluated in response to a trigger condition. including. Process 20000 continues to operation 20005 where the vehicle determines collection verification values as a function of the identified trigger evaluation data and vehicle data collection parameters. Process 20000 continues to operation 20007 where the policy manager circuitry encrypts the data collection policy. Process 20000 continues to operation 20009 where the policy manager circuit replaces the previous data collection policy with the data collection policy depending on the collection verification value. Process 20000 continues to action 20011 where the vehicle receives a trigger condition responsive to the collected verification values.

Referring to FIG. 201, a block diagram illustrating an exemplary vehicle 20110 including a vehicle communication system 20120 is shown. Vehicle communication system is configured to receive data collection policy 20105 from a remote device, such as a cloud device, and output at least one of alert response value 20101 or identifying vehicle data 20103 in response to data collection policy 20105 . In certain embodiments, vehicle communication system 20120 is configured to simultaneously implement at least two of an on-demand data collection policy, a persistent data collection policy, and a streaming data collection policy. It is to be understood that the vehicle communication system 20120 topology is shown for illustrative purposes and is not intended as a limitation of the present disclosure. For example, vehicle communication system 20120 may include multiple data sources coupled to one of multiple endpoints by one of multiple data source networks. In another example, the vehicle communication system 20120 may include a single endpoint or single data source network, to name a few examples.

Vehicle communication system 20120 includes data collection controller 20121 , Ethernet switch 20123 , multiple endpoints 20125 , multiple data source networks 20127 and multiple data sources 20129 . Ethernet switch 20123 is communicatively coupled between data collection controller 20121 and plurality of endpoints 20125 . Each endpoint of plurality of endpoints 20125 is communicatively coupled between Ethernet switch 20123 and at least one of plurality of data source networks 20127 . Each data source of plurality of data sources is communicatively coupled to endpoints of plurality of endpoints 20125 via a data source network of plurality of data source networks 20127 .

The data collection controller 20121 receives the data collection policy 20105 and determines the set of data that must be collected from one or more data sources according to the data collection parameters in order to evaluate the trigger condition of the data collection policy 20105. and is referred to herein as trigger evaluation data. The data collection controller 20121 also controls data collected from one or more data sources of the vehicle, at least a portion of which is transmitted from the vehicle when at least one trigger condition of the data collection policy 20105 is met. is referred to herein as identified vehicle data. Data collection controller 20121 provides instructions or data collection effective to reconfigure Ethernet switch 20123 and plurality of endpoints 20125 to collect raw vehicle data streams including trigger evaluation data streams and identified vehicle data streams. It is configured to output part of policy 20105 . In certain embodiments, Ethernet switch 20123 and plurality of endpoints 20125 are reconfigured to collect identified vehicle data streams after a trigger condition is met.

Ethernet switch 20123 is configured to receive data from multiple endpoints 20125 and output data to data collection controller 20121 . In certain embodiments, Ethernet switch 20123 includes data sources for collecting trigger evaluation data or identified vehicle data values. For example, trigger evaluation data can include Ethernet switch 20123 network traffic data. In certain embodiments, data collection controller 20121 is integrated into the electronic control unit of Ethernet switch 20123 .

Multiple endpoints 20125 are configured to receive data from multiple data sources 20129 . In certain embodiments, data collection controller 20121 reconfigures one or more of the plurality of endpoints to collect a portion of the trigger evaluation data stream or identified vehicle data stream. For example, the data collection controller 20121 can provide the endpoint with a list of CAN signals that the data collection controller 20121 needs for trigger evaluation data. Trigger evaluation data may need to include data from a data source that is not already outputting the required data, in which case the endpoint is reconfigured to request data from the data source. New data may include new CAN messages or CAN signals, to name a few.

In another example, endpoints can be reconfigured to request data source output data according to different data collection parameters, such as increased frequency. Each endpoint can be configured to provide raw vehicle data streams, including trigger evaluation data streams and identified vehicle data streams, depending on data collection policy 20201 . In certain embodiments, the raw data stream transmitted from the endpoint contains only a portion of the data received by the endpoint. For example, an endpoint can be reconfigured to receive data from a data source with a high sampling frequency, filter the data, and output a raw vehicle data stream containing data with a reduced sampling frequency. .

In certain embodiments, data collection policy 20105 includes trigger conditions that require the same trigger evaluation data values collected from the same source at different frequencies. Accordingly, the endpoint is configured to collect trigger evaluation data values at the highest requested frequency or at frequencies that are multiples of one or more of the different frequencies. For example, one trigger condition may request vehicle speed at a frequency of 2 samples/second and a second trigger condition may request vehicle speed at a frequency of 3 samples/second. The endpoint may be configured to collect vehicle speed at 3 samples per second or 6 samples per second. It is to be understood that any or all of the aforementioned features of vehicle 20110 may also be present in other vehicles disclosed herein.

Referring to FIG. 202 , configured to receive data collection policy 20201 and reconfigure a vehicle communication system including components of data collection controller 20210 to collect trigger evaluation data identified by data collection policy 20201 . An example data collection controller 20210 of the example vehicle communication system illustrated in FIG. Data collection controller 20210 may also reconfigure vehicle communication systems, including components of data collection controller 20210 , to collect identified vehicle data specified by data collection policy 20201 .

Controller 20210 includes policy manager circuitry 20211, filtering circuitry 20213, vehicle data processing circuitry 20215, rotating buffer circuitry 20217, trigger evaluation circuitry 20219, data storage circuitry 20221, compression circuitry 20223, encryption circuitry 20225, and cloud interface 20227. In other embodiments, controller 20210 may include fewer or more components.

Policy manager circuitry 20211 is communicatively coupled to filtering circuitry 20213, vehicle data processing circuitry 20215, rotating buffer circuitry 20217, trigger evaluation circuitry 20219, data storage circuitry 20221, compression circuitry 20223, encryption circuitry 20225, and cloud interface 20227. be. Policy manager circuitry 20211 is configured to interpret data collection policy 20201, configured to identify trigger evaluation data, and may be configured to identify vehicle data. The policy manager circuit 20211 controls the components of the data collection controller 20210 and the vehicle communication system to evaluate the trigger conditions of the data collection policy 20201 and transmit at least one of the identified vehicle data 20203 or the alert response value 20205. It is further configured to parse the data collection policy 20201 to reconfigure other components.

Filtering circuitry 20213 is configured to interpret the raw vehicle data stream and determine trigger evaluation data streams of the raw vehicle data stream in response to trigger evaluation data identifiers provided by policy manager circuitry 20211 . Filtering circuitry 20213 may then provide the trigger evaluation data stream to vehicle data processing circuitry 20215 or to rotation buffer circuitry 20217 in embodiments where data acquisition controller 20210 does not include circuitry 20215 . Filtering circuitry 20213 may also be configured to determine identified vehicle data streams of the raw vehicle data streams in response to vehicle data identifiers provided by policy manager circuitry 20211 . In certain embodiments, filtering circuit 20213 is configured to discard remaining portions of the raw vehicle data stream that are not trigger evaluation data or identified vehicle data streams.

Vehicle data processing circuitry 20215 is configured to pre-process the data filtered by filtering circuitry 20213 . In certain embodiments, vehicle data processing circuitry 20215 is configured by policy manager circuitry 20211 to sample trigger evaluation data streams or identified vehicle data streams in accordance with sampling parameters of data collection policy 20201. . For example, the vehicle data processing circuit 20215 may select the sampling frequency of the trigger evaluation data stream if the sampling parameter of the data collection policy 20201 specifies a sampling frequency required for trigger condition evaluation that is less than the sampling frequency received by the vehicle data processing circuit 20215. The sampling frequency of the values may be reduced. In certain embodiments, vehicle data processing circuitry 20215 is configured by policy manager circuitry 20211 to normalize trigger evaluation data value types or identified vehicle data value types. For example, the trigger evaluation data value may be converted from miles per hour to meters per second if the trigger evaluation data value format required by the trigger condition is meters per second. In certain embodiments, vehicle data processing circuitry 20215 is configured to determine trigger evaluation data aggregation parameters needed to evaluate trigger conditions of data collection policy 20201 . Data aggregation parameters may include averages, sums, minimums, maximums, averages, or counts of the value streams of the trigger evaluation data stream, to name a few examples. In certain embodiments, vehicle data processing circuitry 20215 is configured to determine identified vehicle data aggregation parameters for identified vehicle data in response to collection policy 20201 .

Rotational buffer circuit 20217 may be configured to store rotational time windows of trigger evaluation data streams or identified vehicle data streams. Different values of the trigger evaluation data stream can be stored according to different size time windows. The size of the time window of the trigger evaluation data stream is determined according to the trigger condition. For example, if the trigger condition is met when the peak vehicle speed for the past two minutes exceeds the preset value, rotation buffer circuit 20217 stores a two minute time window of vehicle speed values in the trigger evaluation data with policy manager circuit 20211. configured to The time window size for the identified vehicle data stream is determined corresponding to data collection policy 20201 . For example, if data collection policy 20201 specifies that image data should be captured from 30 seconds prior to the occurrence of a trigger indicative of a vehicle crash, rotating buffer circuit 20217 may select a 30 second time window of image data for the identified vehicle data stream. memorize

Policy manager circuitry 20211 is configured to provide trigger evaluation circuitry 20219 with trigger policies including one or more trigger conditions. Trigger evaluation circuit 20219 may be configured to determine the occurrence of a trigger event in response to evaluating the trigger condition using the first rotating time window. Trigger evaluation circuit 20219 is configured to simultaneously evaluate multiple trigger conditions of the data collection policy, and trigger evaluation circuit 20219 is configured to determine trigger event occurrence in response to multiple trigger conditions.

Vehicle data storage circuitry 20221 may be configured to store identified vehicle data 20203 of identified vehicle data streams in response to triggering event occurrences and data collection policies. Policy manager circuitry 20211 may configure vehicle data storage circuitry 20221 to store data based on transmission parameters of data collection policy 20201 . For example, vehicle data storage circuitry 20221 stores identified vehicle data if transmission parameters indicate that the identified vehicle data is to be transmitted from the vehicle periodically, rather than streamed in real time. can do.

In certain embodiments, vehicle data storage circuitry 20221 discards stored data according to priorities defined by data collection policy 20105 . For example, data can be discarded based on the age of the data, whether an acknowledgment for the data has been received from the cloud device, or changes in the memory space of the data storage circuit 20221, and the like.

Compression circuit 20223 may be configured to compress the identified vehicle data to increase bandwidth efficiency. Encryption circuit 20225 may be configured to encrypt the identified vehicle data. Cloud interface 20227 may be configured to provide identified vehicle data 20203 for identified vehicle data streams in response to data collection policy 20201 triggering event occurrences and transmission parameter values. Cloud interface 20227 can be configured to provide alert response values 20205 in response to the occurrence of a triggering event. In certain embodiments, data is uploaded to the cloud using HTTPS with encryption defined by the HMC Cloud Security Standard. Transmission can occur at regular intervals or as soon as the trigger condition exit occurs, to name a few examples. It should be appreciated that any or all of the aforementioned features of data collection controller 20210 may be present in other vehicles disclosed herein.

Referring to FIG. 203, an exemplary vehicle data collection process 20300 is illustrated. Process 20300 may be implemented in whole or in part in one or more of the vehicle communication systems disclosed herein. Variations and modifications of process 20300 are contemplated, including, for example, omitting one or more aspects of process 20300, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. It should be further understood that

Process 20300 begins with operation 20301 of operating a vehicle, the vehicle including a vehicle communication system including a policy manager circuit and an endpoint. In certain embodiments, the vehicle communication system includes a policy manager circuit, a filtering circuit, a vehicle data processing circuit, a rotating buffer circuit, a trigger evaluation circuit, a vehicle data storage circuit, a vehicle data compression circuit, a vehicle data encryption circuit, or a cloud interface. a data acquisition controller including at least one of

Process 20300 continues to operation 20303 where the vehicle communication system interprets the data collection policy. In a particular embodiment, operation 20303 includes, in the policy manager circuit, a vehicle data identifier configured to identify a trigger condition and vehicle data to be captured in response to the occurrence of the trigger event; interpreting a data collection policy including a trigger evaluation data identifier configured to identify the trigger evaluation data;

Process 20300 continues to operation 20305 where the vehicle communication system provides raw vehicle data streams, which may include trigger evaluation data streams and may include identified vehicle data streams, depending on the data collection policy.

Process 20300 continues to operation 20307 where the vehicle communication system filters the raw vehicle data stream. Act 20307 can include determining, with a filtering circuit, a trigger evaluation data stream of the raw vehicle data stream responsive to the trigger evaluation data identifier. Act 20307 can include determining, with a filtering circuit, the identified vehicle data stream as a function of the vehicle data identifier.

Process 20300 continues to operation 20309 where the vehicle communication system preprocesses the trigger evaluation data stream. Act 20309 samples the trigger evaluation data stream according to sampling parameters of the data collection policy, normalizes the trigger evaluation data value format, or performs trigger evaluation data aggregation parameters according to multiple trigger states of the data collection policy. at least one of determining

Process 20300 continues to operation 20311 where the vehicle communication system determines a time window for the trigger evaluation data stream. Act 20311 can include determining, with the rotation buffer circuit, a rotation time window in response to a trigger condition. Act 20311 can also include determining, with the rotating buffer circuit, a second rotating time window in response to a data collection policy.

Process 20300 continues to operation 20313 where the vehicle communication system stores the time window of the trigger evaluation data stream determined in operation 20311 . Act 20313 can include storing a rotating time window of trigger evaluation data in a rotating buffer circuit. Act 20313 may also include storing a second rotating time window of the identified vehicle data stream depending on the data collection policy.

Process 20300 continues to operation 20315 where the vehicle communication system determines that a triggering event has occurred. Act 20315 can include, with the trigger evaluation circuit, determining a trigger event occurrence in response to evaluating a trigger condition using a rotating time window of trigger evaluation data stored with the rotating buffer circuit. In certain embodiments, the trigger evaluation circuit concurrently evaluates multiple trigger conditions of the data collection policy and determines the trigger event occurrence in response to evaluating the multiple trigger conditions using a rotating time window. .

Process 20300 continues to operation 20317 where the vehicle communication system determines the termination of the triggering event. Act 20317 can include determining a triggering event termination as a function of a triggering state of the data collection policy.

Process 20300 continues to operation 20319 where the vehicle communication system stores the identified vehicle data captured in response to at least one of the occurrence of the triggering event and the termination of the triggering event. Act 20319 can include storing the identified vehicle data of the identified vehicle data stream in the vehicle data storage circuit in response to the triggering event occurrence and the data collection policy. In certain embodiments, at least some of the identified vehicle data occurred prior to the occurrence of the triggering event.

Process 20300 continues to operation 20321 where the vehicle communication system provides the identified vehicle data. Act 20321 can include providing, by the cloud interface, identified vehicle data of the identified vehicle data stream in response to the occurrence of the triggering event and transmission parameter values of the data collection policy. Act 20321 can also include providing, at the cloud interface, an alert response value in response to the occurrence of the triggering event, the alert response value being at least one of alert criteria, alert type, alert content, and alert location. including one. Any or all of the aforementioned features of exemplary process 20300 are also present in other processes disclosed herein, such as the processes illustrated in FIGS. 204-205, to name a few. It shall be understood that

Referring to FIG. 204, an exemplary vehicle data collection process 20400 is illustrated. Process 20400 may be implemented in whole or in part in one or more of the vehicle communication systems disclosed herein. Variations and modifications of process 20400 are contemplated, including, for example, omitting one or more aspects of process 20400, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. It should be further understood that

Process 20400 begins with operation 20101 of operating a vehicle, the vehicle including a vehicle communication system including a policy manager circuit and an endpoint. In certain embodiments, the vehicle communication system includes a policy manager circuit, a filtering circuit, a vehicle data processing circuit, a rotating buffer circuit, a trigger evaluation circuit, a vehicle data storage circuit, a vehicle data compression circuit, a vehicle data encryption circuit, or a cloud interface. a data acquisition controller including at least one of

Process 20400 continues to action 20403 where the vehicle communication system interprets the data collection policy. In a particular embodiment, act 20403 interprets, with the policy manager circuit, a data collection policy comprising a trigger condition and a trigger evaluation data identifier configured to identify trigger evaluation data to be captured in response to the trigger condition. including the step of

Process 20400 continues to operation 20405 where the vehicle communication system provides raw vehicle data streams including trigger evaluation data streams in accordance with data collection policies.

Process 20400 continues to operation 20407 where the vehicle communication system filters the raw vehicle data stream. Act 20407 can include determining, with a filtering circuit, a trigger evaluation data stream of the raw vehicle data stream responsive to the trigger evaluation data identifier.

Process 20400 continues to operation 20409 where the vehicle communication system preprocesses the raw vehicle data stream. Act 20409 samples the trigger evaluation data stream according to sampling parameters of the data collection policy, normalizes the trigger evaluation data value format, or performs trigger evaluation data aggregation parameters according to multiple trigger states of the data collection policy. at least one of determining

Process 20400 continues to action 20411 where the vehicle communication system determines a time window for the trigger evaluation data stream. Act 20411 can include determining, with a rotating buffer circuit, one or more rotating time windows of trigger evaluation data depending on the trigger condition.

Process 20400 continues to operation 20413 where the vehicle communication system stores the time window of the trigger evaluation data stream determined in operation 20411 . Act 20413 can include storing multiple time windows for multiple values of the trigger evaluation data stream in a rotating buffer circuit.

Process 20400 continues to operation 20415 where the vehicle communication system determines that a triggering event has occurred. Act 20415 can include, with the trigger evaluation circuit, determining a trigger event occurrence in response to evaluating a trigger condition using a rotating time window of trigger evaluation data stored with the rotating buffer circuit. In certain embodiments, the trigger evaluation circuit concurrently evaluates multiple trigger conditions of the data collection policy and determines the trigger event occurrence in response to evaluating the multiple trigger conditions using a rotating time window. .

Process 20400 continues to operation 20421 where the vehicle communication system provides alert response values in response to the triggering event occurrence, the alert response values being at least one of alert criteria, alert type, alert content, and alert location. including. Any or all of the foregoing features of exemplary process 20400 may also be present in other processes disclosed herein, such as the processes illustrated in FIGS. 203 or 205, to name a few. It shall be understood that

Referring to FIG. 205, an exemplary vehicle data collection process 20500 is illustrated. Process 20500 may be implemented in whole or in part in one or more of the vehicle communication systems disclosed herein. Variations and modifications of process 20500 are contemplated, including, for example, omitting one or more aspects of process 20500, adding additional conditions and actions, or reorganizing or separating actions and conditions into separate processes. It should be further understood that

Process 20500 begins with operation 20101 of operating a vehicle, the vehicle including a vehicle communication system including a policy manager circuit and an endpoint. In certain embodiments, the vehicle communication system includes a policy manager circuit, a filtering circuit, a vehicle data processing circuit, a rotating buffer circuit, a trigger evaluation circuit, a vehicle data storage circuit, a vehicle data compression circuit, a vehicle data encryption circuit, or a cloud interface. a data acquisition controller including at least one of

Process 20500 continues to action 20503 where the vehicle communication system interprets the data collection policy. In a particular embodiment, operation 20503 includes, in the policy manager circuit, a vehicle data identifier configured to identify the trigger condition and vehicle data to be captured in response to the occurrence of the trigger event; interpreting a data collection policy including a trigger evaluation data identifier configured to identify the trigger evaluation data;

Process 20500 continues to operation 20505 where the vehicle communication system provides raw vehicle data streams, which may include trigger evaluation data streams and may include identified vehicle data streams, depending on the data collection policy. Any or all of the foregoing features of exemplary process 20500 are also present in other processes disclosed herein, such as the processes illustrated in FIGS. 203-204, to name a few. It shall be understood that

Referring to FIG. 206, there is a block diagram illustrating an exemplary vehicle 20610 including a vehicle communication system 20620. As shown in FIG. Vehicle communication system is configured to receive data collection policy 20601 from a remote device, such as a cloud device, and update operation of vehicle communication system 20620 in response to data collection policy 20601 . It should be understood that the vehicle communication system 20620 topology is shown for illustrative purposes and is not intended as a limitation of the present disclosure. For example, vehicle communication system 20620 may include more or fewer endpoints, more or fewer data source networks, or more or fewer data sources, to name a few.

Vehicle communication system 20620 includes data collection controller 20630 , Ethernet switch 20621 , endpoints 20623 , data source network 20625 , and data sources 20627 . Data collection controller 20630 is configured to receive data collection policy 20601 from a remote device, such as a cloud system, and, in response to data collection policy 20601, capture vehicle data from vehicle data sources, including multiple data sources 20627. can be done.

In the illustrated embodiment, data collection controller 20630 includes policy manager circuitry 20631 and vehicle data interface 20633 . In certain embodiments, the data collection controller 20630 includes additional components such as those of the data collection controllers illustrated in FIGS. The components of data collection controller 20630 include instructions, memory devices configured to store the instructions, and effective to perform the operations attributed to the components of data collection controller 20630 described herein. and a processing device configured to execute storage instructions. In certain embodiments, one or more of the components of data collection controller 20630 may share memory devices or processing devices.

The processing units of data collection controller 20630 in different embodiments may be programmable, dedicated, hardwired state machines, or combinations thereof. The processing units may further include processors, arithmetic logic units (ALUs), central processing units (CPUs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), to name a few. Also, in the form of a processing device having a plurality of processing units, distributed processing, pipeline processing, parallel processing, and the like can be used as appropriate. A processing unit may be dedicated solely to performing the operations described herein or may be utilized for one or more additional uses. The processing unit can be a programmable variety that performs processing and processes data according to programming instructions (such as software or firmware) stored in a memory device of data collection controller 20630 . Alternatively or additionally, programming instructions may be defined by hardwired logic or other hardware. A processor may be comprised of one or more components of any type suitable for processing signals received from input/output devices and providing desired output signals. Components of such processors may include digital circuitry, analog circuitry, or a combination of both.

The memory devices of the data acquisition controller 20630 in different embodiments are of one or more types, such as semiconductor varieties, electromagnetic varieties, optical varieties, or combinations of these forms, to name a few. Further, memory devices may be volatile, non-volatile, transient, non-transitory, or combinations of these types, and some or all of the memory devices may include, to name a few examples, disks, It can be of various portable types such as tapes, memory sticks, cartridges, and the like. Further, memory devices, in addition to or instead of storing programming instructions, may be used by data acquisition controllers, such as data representative of signals received from or sent to input/output devices, to name one example. The data operated on by the 20630 processing device can be stored.

Policy manager circuit 20631 is configured to interpret data collection policy 20601 . As described in detail above, data collection policy 20601 is configured to identify the data required to be evaluated by a trigger condition and to identify vehicle data to be captured when the trigger condition is met. can be configured to In particular embodiments, data collection policy 20601 includes multiple trigger evaluation data identifiers configured to identify trigger evaluation data evaluated by multiple trigger conditions of the data collection policy. In certain embodiments, data collection policy 20601 includes a plurality of vehicle data identifiers configured to identify vehicle data captured in response to trigger conditions specified by the trigger policy. Trigger Evaluation Data Identifiers and Vehicle Data Identifiers may be controller area network (CAN) messages, CAN signals, Ethernet packets, vehicle location, vehicle status, diagnostic trouble codes, Ethernet conditions, stored within the vehicle, to name a few. Multiple data types may be supported, including at least two of a file, or vehicle communication controller statistics.

In response to data collection policy 20601, policy manager circuit 20631 is configured to cause vehicle communication system 20620 to collect data identified by data collection policy 20601 and transmit a raw vehicle data stream to data collection controller 20630. be. Raw vehicle data streams may include trigger evaluation data streams and identified vehicle data streams. In certain embodiments, the trigger evaluation data stream and the identified vehicle data stream may include common values of the raw vehicle data stream. In certain embodiments, the trigger evaluation data stream and the identified vehicle data stream may not contain common values of the raw vehicle data stream. Each value in the trigger evaluation data stream or identified vehicle data stream corresponds to data received from the vehicle's data source according to the data collection parameters specified by data collection policy 20601 . A trigger evaluation data stream or identified vehicle data stream may include multiple value streams from multiple data sources of the vehicle 20610 .

Vehicle data interface 20633 is configured to receive raw vehicle data streams including trigger evaluation data streams, and can include identified vehicle data streams.

Each endpoint of plurality of endpoints 20623 may be configured to ingest at least a portion of the trigger evaluation data stream, subject to data collection policy #20601. In certain embodiments, endpoints of endpoints 20623 are configured to capture and output a portion of the trigger evaluation data stream or identified vehicle data stream. Each endpoint of plurality of endpoints 20623 may be communicatively coupled to Ethernet switch 20621 . In particular embodiments, an endpoint is communicatively coupled to two or more of networks 20625 configured to communicate data sources using multiple communication protocols.

In certain embodiments, the trigger evaluation data stream or identified vehicle data stream includes data from data sources configured to communicate with one endpoint using different communication protocols. For example, the trigger evaluation data stream received by the endpoint includes CAN messages from the CAN bus network and Ethernet packets received from another network communicatively coupled between the data source and the endpoint. be able to. In certain embodiments, the endpoint does not need to request the values of the trigger evaluation data stream or the identified vehicle data stream because the data source already provides the data. In certain embodiments, depending on data collection policy 20601, the endpoint requests trigger evaluation data stream values or identified vehicle data stream values from a data source communicatively coupled to the endpoint. It should be understood that any or all of the aforementioned features of vehicle 20610 may also be present in other vehicles disclosed herein.

Referring to FIG. 207, exemplary vehicle 20700 including data collection controller 20710 is illustrated. Data collection controller 20710 is configured to receive raw vehicle data stream 20701 and output at least one of identified vehicle data 20703 or alert response values 20705 . It should be appreciated that data collection controller 20710 can include components and functionality described herein with respect to other illustrated data collection controllers, such as data collection controller 20210 of FIG.

The illustrated data collection controller 20710 includes policy manager circuitry 20711, vehicle data interface 20713, filtering circuitry 20715, vehicle data processing circuitry 20717, rotational buffer circuitry 20719, trigger evaluation circuitry 20721, data storage circuitry 20723, compression circuitry 20725, encryption circuit 20727 and cloud interface 20729. In other embodiments, data collection controller 20710 may include more or fewer components.

Policy manager circuit 20711 may be configured to interpret data collection policies including vehicle data identifiers and triggers configured to define trigger conditions. A data collection policy may include multiple trigger types, including signal triggers, vehicle status triggers, timing triggers, schedule triggers, geofence triggers, error triggers, environmental triggers, or user input triggers. . In certain embodiments, multiple trigger states of multiple triggers correspond to the same value of the trigger evaluation data.

In certain embodiments, the trigger evaluation data or identified vehicle data includes at least one of vehicle status, vehicle status, vehicle operating mode, or vehicle discrete event. In certain embodiments, the plurality of trigger evaluation data or identified vehicle data comprises at least two of controller area network (CAN) messages, CAN signals, Ethernet packets, vehicle location, vehicle status, and diagnostic trouble codes. Supports multiple data types, including In certain embodiments, trigger evaluation data or identified vehicle data includes virtual sensor values derived from a plurality of vehicle data values.

Filtering circuit 20715 receives raw vehicle data stream 20701 from vehicle data interface 20713, determines trigger evaluation data stream or identified vehicle data stream from raw vehicle data stream 20701, trigger evaluation data stream or identified vehicle data stream. It can be configured to output only the vehicle data stream. In certain embodiments, filtering circuit 20715 discards remaining portions of raw vehicle data stream 20701 .

Vehicle data processing circuitry 20717 receives trigger evaluation data streams or identified vehicle data streams, pre-processes the received streams for either trigger evaluation circuitry 20721 or cloud interface 20729, and receives them into rotating buffer circuitry 20719. can be configured to output a stream

Rotational buffer circuit 20719 is configured to store a time window of the value stream of the trigger evaluation data stream or the identified vehicle data stream, depending on the data collection policy. The time window size is based on the historical values of the value stream as required by the data collection policy. For example, the time window for the engine temperature value stream may be 5 minutes if the trigger condition corresponding to the value stream is met when the threshold temperature is exceeded within the past 5 minutes. In another example, if the data collection policy specifies that two minutes of historical vehicle speed are collected in response to a vehicle crash, the time window for the stream of vehicle speed values may be two minutes. Rotational buffer circuit 20719 may be configured to provide a time window of trigger evaluation data to trigger evaluation circuit 20721 while storing identified vehicle data until a trigger condition corresponding to the trigger evaluation data is met. In certain embodiments, at least some of the trigger evaluation data is not stored by rotating buffer circuit 20719 .

Trigger evaluation circuit 20721 is configured to determine trigger event occurrence as a function of trigger status and trigger evaluation data. In certain embodiments, trigger evaluation circuit 20721 determines trigger event occurrence by evaluating trigger evaluation data with a trigger condition, which is a preset value that may or may not be met by the trigger evaluation data. define the relationship between For example, the trigger evaluation circuit may determine trigger occurrence when a trigger condition evaluating whether vehicle speed exceeds a threshold is met. In certain embodiments, trigger evaluation circuit 20721 determines trigger event occurrence as a function of multiple trigger conditions. For example, trigger evaluation circuit 20721 may determine that a trigger event has occurred when the vehicle ignition is on and an alert CAN signal is being transmitted. In certain embodiments, trigger evaluation circuit 20721 determines trigger event occurrence in response to at least two trigger conditions. In certain embodiments, the determination of trigger event occurrence is made based on multiple trigger conditions of different trigger types.

Trigger evaluation circuit 20721 is configured to determine trigger event termination. Trigger evaluation circuit 20721 can determine trigger event termination depending on the trigger condition or after a period of time following the trigger event occurrence. In certain embodiments, determining the trigger event end includes determining that multiple trigger conditions of different trigger types are met.

Trigger evaluation circuit 20721 is configured to determine a data capture window in response to the occurrence of trigger events, termination of trigger events, and data collection policies. The portion of the identified vehicle data stream generated during the data capture window is the identified vehicle data transmitted from vehicle 20701 . In certain embodiments, the data capture window may begin with the occurrence of the trigger event and may end with the termination of the trigger event. In certain embodiments, the data capture window may begin before the trigger event occurs and may end after the trigger event ends. In certain embodiments, the data collection policy may specify that identified vehicle data occurring before the triggering event occurs or after the triggering event ends is captured. For example, a data collection policy may specify to collect 30 minutes of engine temperature values collected prior to an engine failure. In another example, a data collection policy may specify data collection 2 seconds after the end of the trigger event so that the measurements stabilize before the measurement after the end of the trigger event.

Data storage circuit 20723 is configured to store the identified vehicle data captured within the data capture window if the data collection policy specifies that the identified vehicle data is stored before being sent. be done. For example, a data collection policy may specify transmission intervals at which captured identified vehicle data is aggregated before being transmitted. In another example, data storage circuit 20723 may not store identified vehicle data values within a data capture window where the data collection policy indicates that the values are streamed from the vehicle in real time.

Compression circuit 20725 is configured to compress the aggregated identified vehicle data prior to transmission to increase bandwidth efficiency. Encryption circuit 20727 is configured to encrypt identified vehicle data transmitted from the vehicle. In certain embodiments, the identified vehicle data is encrypted using a key that is unavailable to the remote device that receives and stores the identified vehicle data.

Cloud interface 20729 is configured to provide at least one of identified vehicle data 20703 or alert response values 20705 to a remote device, such as a cloud device. In certain embodiments, cloud interface 20729 may be configured to provide alert response values 20705 directly to user devices.

Alert response values 20705 may include at least one of alert criteria, alert type, alert content, and alert location. Alert criteria can be configured to notify a user that a trigger condition has been met or that a trigger event has occurred. An alert type can be configured to identify a notification medium such as a text message or haptic feedback, to name a few. The alert content can be configured to convey a notification to the user and can include prompts for user response. The alert location can be configured to identify the location of the vehicle. It should be understood that any or all of the aforementioned features of vehicle 20700 may also be present in other vehicles disclosed herein.

In one example, the data collection controller 20710 can send the alert response value 20705 to notify the user that a triggering event has occurred. In another example, data collection controller 20710 can send alert response values 20705 to designated devices upon occurrence of a triggering event. In another example, the data collection controller 20710 can send an alert response value 20705 to notify the user that the identified vehicle data 20703 has been captured and sent from the vehicle. In another example, data collection controller 20710 may send alert response value 20705 in response to policy manager circuit 20711 determining that a data collection policy or trigger policy is invalid. In another example, data collection controller 20710 causes policy manager circuit 20711 to determine that the data collection policy is in effect, but the user is not yet authorized to receive captured identified vehicle data. In response, an alert response value 20705 can be sent. In another example, data collection controller 20710 may send alert response values 20705 configured to provide periodic summaries of data collection policy enforcement on the vehicle. In certain embodiments, data collection controller 20710 transmits identified vehicle data 20703 and/or alert response values 20705 to multiple external devices.

Referring to FIG. 208, an exemplary vehicle data collection process 20800 is illustrated. Process 20800 may be implemented in whole or in part in one or more of the vehicle communication systems disclosed herein. Variations and modifications of process 20800 are contemplated, including, for example, omitting one or more aspects of process 20800, adding additional conditions and actions, or reorganizing or separating actions and conditions into separate processes. shall be further understood.

Process 20800 begins with operation 20801 which includes operating a vehicle including a policy manager circuit, an endpoint, and a vehicle data interface. Process 20800 continues to operation 20803 where the vehicle interprets the data collection policy including the trigger condition and trigger evaluation data identifier. In certain embodiments, the data collection policy includes a plurality of trigger evaluation data identifiers configured to identify trigger evaluations evaluated by multiple trigger conditions of the data collection policy, the trigger evaluation data identifiers in the controller area. Multiple data types are supported, including at least two of network (CAN) messages, CAN signals, Ethernet packets, vehicle location, vehicle status, and diagnostic trouble codes.

Process 20800 continues to action 20805 where the vehicle captures the trigger evaluation data stream in response to the trigger evaluation data identifier and trigger status. In certain embodiments, the vehicle includes a plurality of endpoints communicatively coupled to the Ethernet switch, and at least some of the plurality of endpoints select one of the plurality of trigger evaluation data streams depending on the data collection policy. take in the part In certain embodiments, the endpoint is communicatively coupled to multiple networks configured to communicate using multiple communication protocols, and the endpoint can communicate from the multiple networks depending on the data collection policy. Ingest multiple trigger evaluation data streams. In certain embodiments, capturing the trigger evaluation data stream includes receiving the trigger evaluation data stream from a data source communicatively coupled to the endpoint without requesting the trigger evaluation data or communicable to the endpoint. requesting a trigger evaluation data stream from a data source coupled to the .

Process 20800 continues to operation 20805 where the vehicle data interface receives the trigger evaluation data stream. Any or all of the aforementioned features of exemplary process 20800 may be present in other processes disclosed herein, such as the processes shown in FIGS. 209 or 210, to name a few examples. It shall be understood that

Referring to FIG. 209, an exemplary vehicle data collection process 20900 is illustrated. Process 20900 may be implemented in whole or in part in one or more of the vehicle communication systems disclosed herein. Variations and modifications of process 20900 are contemplated, including, for example, omitting one or more aspects of process 20900, adding additional conditions and actions, or reorganizing or separating actions and conditions into separate processes. It should be further understood that

Process 20900 begins with operation 20901 that includes operating a vehicle that includes policy manager circuitry and trigger evaluation circuitry. Process 20900 continues to operation 20903 where the vehicle interprets the data collection policy including the vehicle data identifier and the trigger configured to define the trigger condition. Process 20900 continues to operation 20905 where the vehicle determines trigger event occurrence as a function of trigger conditions and trigger evaluation data. The step of determining trigger event occurrence can include evaluating trigger evaluation data with trigger conditions, where the trigger conditions relate to current values that may or may not be met by the trigger evaluation data. Define. In certain embodiments, the vehicle determines trigger event occurrence in response to at least two trigger conditions. In certain embodiments, the determination of trigger event occurrence is based on evaluating multiple trigger conditions of different trigger types.

Process 20900 continues to operation 20907 where the vehicle determines the end of the triggering event. Process 20900 continues to operation 20909 where the vehicle determines the data capture window in response to trigger event occurrence, trigger event termination, and data collection policy. Process 20900 continues to operation 20911 where the vehicle captures the identified vehicle data according to the data capture window and the vehicle data identifier. Any or all of the foregoing features of exemplary process 20900 may also be present in other processes disclosed herein, such as the processes illustrated in FIGS. 208 or 210, to name a few. It shall be understood that

Referring to FIG. 210, an exemplary vehicle data collection process 21000 is illustrated. Process 21000 may be implemented in whole or in part in one or more of the vehicle communication systems disclosed herein. Variations and modifications of process 21000 are contemplated, including, for example, omitting one or more aspects of process 21000, adding additional conditioning and operations, or reorganizing or separating operations and conditioning into separate processes. It should be further understood that

Process 210 begins at operation 21001 which includes operating a vehicle including a policy manager circuit, a rotating buffer circuit, a trigger evaluation circuit, a vehicle data storage circuit, and a cloud interface. Process 21000 continues to operation 21003 where the vehicle interprets the data collection policy including the vehicle data identifier and the trigger configured to define the trigger condition. Process 21000 continues to operation 21005 where the vehicle stores the identified vehicle data time window and the trigger evaluation data time window.

Process 21000 continues to action 21007 where the vehicle determines the occurrence of a trigger event as a function of trigger conditions and trigger evaluation data. Process 21000 continues to operation 21009 where the vehicle determines the end of the triggering event. Process 21000 continues to action 21011 where the vehicle determines the data capture window in response to trigger event occurrence, trigger event termination, and data collection policy. Process 21000 continues to operation 21013 where the vehicle captures the identified vehicle data according to the data capture window and data collection policy. Process 21000 continues to operation 21015 where the vehicle stores the identified vehicle data according to the data capture window. In certain embodiments, at least some of the identified vehicle data occurs prior to the occurrence of the triggering event. Process 21000 continues to operation 21017 where the vehicle provides at least a portion of the vehicle data identified in accordance with the data collection policy to the cloud system. Any or all of the aforementioned features of exemplary process 21000 may also be present in other processes disclosed herein, such as the processes shown in FIGS. 208 or 210, to name a few examples. It shall be understood that

Exemplary embodiments of the present disclosure utilize one or more aspects as described above to download and store one or more new features, configurations, and/or content for mobile applications. , which can be downloaded using one or more of cellular, WiFi, Bluetooth, hardwired, or other data connections, and/or stored using shared storage resources residing in the mobile application can do. Exemplary embodiments further include obtaining approval from a user (eg, operator, owner, fleet personnel, etc.), which includes prompting the user for approval and, depending on the approval, one or more and implementing new features, configurations, and/or content. Example embodiments further include dynamically rerouting data collection and/or communications to implement one or more new features, configurations, and/or content. Embodiments of the present disclosure can be used to upgrade vehicles, implement and/or upgrade consumer features, change vehicle control setpoints, thresholds, and/or fault descriptions, change vehicle ratings, classifications, and/or utilization parameters, and /or include, but are not limited to, new features, configurations, and/or content such as changes to collected data, data collection triggers, automation triggers, and/or remote control triggers. Embodiments are described in the context of a vehicle after production and in service by an operator for convenience of explanation, but embodiments are during production (e.g., selected stages of production, etc.) without limitation; prior to the first sale of the Mobile Application (e.g., by OEMs, bodybuilders, dealers, service departments, etc.); selected events of the Mobile Application (e.g., retrofits, upgrades, changes in use or duty cycle; sale of the Mobile Application to others; at any point in the lifecycle of the mobile application, including in response to a sale, a recall or campaign event associated with the mobile application, and/or a refurbishment or remanufacturing event of the mobile application or portions thereof).

Exemplary embodiments of the present disclosure utilize one or more aspects as described above to provide communicative coupling (e.g., WiFi, Internet access, application utilization, and/or over power coupling) to a charging station network. communication), allowing users (e.g., operators, owners, fleet personnel, etc.) to check prices, initiate or terminate charging, set charging parameters, monitor charging behavior, and trade parameters (costs, power transfers, log data, etc.). confirmation and/or authorization of payment. Exemplary, non-limiting embodiments include interacting with the user through user interfaces such as vehicle displays, mobile devices, web applications, and the like. In certain further embodiments, the action includes providing additional information to the user, such as: availability of alternate charging locations and/or associated costs, availability, and/or capacity; and planned mileage; State of charge against thresholds such as battery management charge targets and/or scheduled operations for mobile application missions.

Exemplary embodiments of the present disclosure utilize one or more aspects as described above to detect incidents (e.g., impact sensors; door actuator positions; and/or other physical incident-related and/or using external communications, such as intrusion alarms from home security systems), and notifying users (eg, operators, owners, fleet personnel, etc.) of incidents. Incident notification may include photographs, video clips, audio information, incident decision descriptions (e.g. sensor/actuator values indicating break-in and/or “door accessed without key”, “hood improperly opened”). , these selected descriptions such as "impact detected", etc.) may also be included. External information can be generated by a device associated with the mobile application (eg, a camera on the vehicle) and/or communicated to the mobile application (eg, video provided by a security system). Additionally or alternatively, the information can be streamed to selected devices such as mobile applications, cloud servers, web applications, etc. associated with the user. Additionally or alternatively, information can be provided upon user request. In certain embodiments, information can be stored (e.g., on a vehicle, in shared network storage, communicated to a cloud server for storage, and/or stored on another device such as a home PC, security device, USB storage device, etc.). to an external device), which can be done automatically and/or upon request from the user. In certain embodiments, external device provided data such as security camera footage, security system status, etc. may be provided and/or stored to the user in response to the incident. For example, if an incident indicates a potential intrusion into a vehicle (eg, an event of opening a door without key access), vehicle camera data may be stored and/or streamed to the user and/or accessed by an external device. (eg, home or parking lot security cameras), relevant data is streamed to the vehicle and/or the user, and/or the vehicle requires the corresponding data to be stored for later access.

Exemplary embodiments of the present disclosure utilize one or more aspects as described above to ensure that geographic boundaries are crossed and/or approached (e.g., inter-state, inter-country , urban or rural conditions, altitude changes, road grade changes, etc.).

In certain further embodiments, one or more users (e.g., operators, owners, fleet personnel, etc.) control boundary changes and/or approaching changes and actions to be applied in response to boundary changes (e.g., (current values, thresholds, speed, audio volume, data collection changes, etc.). Examples and non-limiting embodiments are by fleet managers, vehicle owners, and/or rental companies; for the recovery of stolen vehicles; by the warranty enforcement entity for the vehicle; and/or by the driver's parents or guardians; including tracking and/or setting vehicle behavior. Exemplary non-limiting embodiments configure mobile applications to comply with multiple jurisdictions and/or geographies, comply with data collection and/or privacy policies depending on jurisdiction and/or location. and/or configuring the mobile application to adjust performance depending on jurisdiction and/or geography.

Exemplary embodiments of the present disclosure utilize one or more aspects as described above to determine the current operator of the mobile application (e.g., the current driver of the vehicle); and/or determining characteristics and implementing the behavior of the mobile application according to the driver's preferences. For example, comfort, performance, entertainment, travel (e.g., routing, stop time scheduling, etc.), subscriptions, insurance, payment data, event triggers, notifications, etc. may affect driver preferences and/or other driver differences (e.g., age , permissions, ownership, etc.) may have differences between the first driver and the second driver, and the exemplary embodiments respond to different preferences and driver differences to operate according to the present disclosure. including steps to perform. Exemplary embodiments of the present disclosure provide access to driver preferences and/or characteristics (e.g., downloads from cloud servers and/or web applications) and second vehicles (e.g., recently purchased vehicles, rented vehicles). using driver preferences and/or characteristics in private, shared, and/or rented vehicles. Utilization of driver preferences and/or characteristics in the second vehicle may omit utilization of some values (e.g. setting cruise control speed if the second vehicle does not have cruise control). ), and/or characteristics of the second vehicle (e.g., where the second vehicle may have different capabilities, performance characteristics, and where the driver has a different set of privileges and/or authorizations with respect to the second vehicle). may include adjusting the value according to the In certain embodiments, the data associated with the driver is stored in a second driver, such as when the operation is completed, when the vehicle is returned, when the vehicle is sold, and/or when another driver operates the vehicle. It can be removed from the vehicle. In certain embodiments, driver-related data may be used by an external device (e.g., an application running on a cloud server, as a web application, etc.), used by the first vehicle (e.g., tracking time driven or distance traveled by the driver). , learning algorithms using driver driving data), and/or uploaded for download to the next vehicle (e.g., so preferences can be transferred to a newly purchased vehicle).

Exemplary embodiments of the present disclosure utilize one or more aspects as described above, including operations that customize the behavior of mobile applications based on user-defined settings and actions based on various inputs. . An example customization action to illustrate some of the customization options made available by aspects of this disclosure is a voice-activated command that automates the action of any sensor or actuator of this disclosure; !” command, which causes embodiments of the present disclosure to lower the convertible top, adjust the HAC and seat heater settings to the selected values, implement the selected music playlist, and turn the audio volume to the selected values. a vocal "spa mode" command, whereby embodiments of the present disclosure analyze the operator's mind rate from a connected wearable device to adjust vehicle lighting, audio volume (and/or audio content selection), climate control, Includes heated seats and/or massage functions (eg, to help the driver relax and concentrate on driving). Although exemplary customization actions are described in response to voice commands, commands can be provided via any mechanism, including input on a mobile device, vehicle display, and/or all or all of the commands. Event-driven decisions can also be included as part (e.g., seat adjustments to selected ranges following driver seatbelt actuation to implement specific audio, climate, and/or lighting schemes, and vehicle Fuel fill events following movement provide trip and fuel fill data to third party applications, driver changes provide different fuel economy decision buckets, etc.).

Exemplary data collection use cases (see, eg, FIG. 121 and related discussion) include field support scenarios and/or situations. For example, a vehicle field support team may receive a call and/or other notification that the vehicle is having a problem, for example, that the vehicle operator is sensing excessive vibration in the steering wheel. The field support team can then send on-demand policies to obtain selected data, such as data from various sensors associated with the vehicle's steering system. Upon receiving the on-demand policy, one or more of the devices described herein may interpret the on-demand policy and begin sending selected data to the field support team immediately or nearly immediately in accordance with the on-demand policy. good.

Another exemplary data collection use case (see, e.g., FIG. 121 and related discussion) is a business team wishing to monitor selected vehicles driven in real-time, e.g., via a real-time map. including. In embodiments, business teams can build streaming policies that are intended for continuous execution. The streaming policy is then pushed out to selected vehicles, which in turn causes one or more devices on board those vehicles to transmit vehicle location data as described herein. be able to. Vehicle position data can be transmitted to business teams in real time or near real time. If the selected vehicle is unable to transmit its location data and/or the location data of the selected vehicle is lost during transmission to the business team, e.g. the selected vehicle is located in an area with poor cellular coverage. If so, it may continue to attempt to transmit its location data so that it will be received by the business team once the selected vehicle is able to transmit again. In embodiments, the streaming policy provides the selected vehicle with information about "how" the vehicle is being driven, such as speed, braking, acceleration, etc., and/or other data regarding the driver's driving of the vehicle. You can also report it.

Another exemplary data collection use case (see, e.g., FIG. 121 and related discussion) is monitoring and/or performance of new products, e.g., new vehicles, vehicle accessories, vehicle components, infotainment applications, etc. Including R&D teams who wish to validate. The research and development team may have significant and/or extended periods of time to validate and/or determine the performance of new products. So the R&D team can create a policy that will be pushed out to selected vehicles related to new products, and the policy will cause the selected vehicles to send data about the new product to the R&D team. . In embodiments, a policy may require that data regarding new products be sent to the research and development team on a daily, weekly, monthly, and/or other periodic basis.

Another exemplary data collection use case (see, eg, FIG. 121 and related discussion) includes tracking common vehicle parameters for a group of vehicles selected for a manufacturer. For example, manufacturers may support certain features on selected vehicles, provide historical data about selected vehicles to their respective drivers (and/or owners), and detect abnormal occurrences on selected vehicles. and/or monitor corresponding warranties using vehicle parameters.

Another exemplary data collection use case (e.g., see FIG. 121 and related discussion) includes using collected data from a vehicle to predict future maintenance requirements for the vehicle (e.g., see FIG. 121 and related explanation). For example, embodiments of the present disclosure can track various characteristics of the vehicle, such as wheel bearing wear, oil level and/or age, coolant level and/or age, so that when the vehicle is serviced, For example, it can be used by in-vehicle and/or off-vehicle devices as described herein to predict when an oil change is needed.

Another exemplary data collection use case (see, e.g., FIG. 121 and related discussion) is to initially collect vehicle data after an event/problem of which the vehicle owner, service provider, manufacturer, etc. is unaware. including the step of capturing. For example, an engine may experience timing sequence problems of a magnitude that is unnoticeable to the driver of the vehicle. Embodiments of the present disclosure capture event/problem related data and store the captured data on-board and/or on-board the vehicle for later access and review by vehicle owners, service providers, manufacturers, etc. It can be stored outside the vehicle. Upon reviewing the data, captured data that vehicle owners, service providers, manufacturers, etc. may provide to recognize events/problems and/or diagnose events/problems and/or take corrective action. You may notice discrepancies in

Another exemplary data collection use case (see, e.g., FIG. 121 and related discussion) is the identification of vehicles frequently and/or most used by vehicle occupants so that dealers can advertise identified characteristics. including identifying features.

Another exemplary data collection use case (eg, reference diagram 121 and related discussion) involves using captured vehicle data for insurance monitoring purposes. For example, data regarding driver behavior, such as acceleration, braking, speed, etc., may be transmitted directly from the vehicle to the company (or other entity) insuring the vehicle and/or the driver. In embodiments, such monitoring may require driver and/or owner consent.

Another exemplary data collection use case (see, eg, FIG. 121 and related discussion) includes monitoring various aspects/parameters/characteristics of the vehicle, eg, battery and/or charging system. Such monitoring may provide detection of trends regarding vehicle components and/or systems corresponding to collected data.

Another exemplary data collection use case (see, eg, FIG. 121 and related discussion) includes monitoring data regarding vehicle fleets. For example, embodiments of the present disclosure may provide operators of commercial fleets of vehicles to view trends and/or patterns regarding vehicles within the fleet. Embodiments of the present disclosure may also provide operators of commercial fleets of vehicles to detect whether a particular vehicle is generating data outside trends and/or patterns.

Another exemplary data collection use case (see, eg, FIG. 131 and related discussion) includes using time-based triggers, eg, triggers related to calendar dates and/or events.

Another exemplary data collection use case (eg, reference diagram 131 and related discussion) includes using triggers based on vehicle parameters related to signals, eg, speed, airbag deployment, and the like.

Another exemplary data collection use case (eg, reference diagram 131 and related discussion) includes using triggers based on errors, eg, detected defects. Embodiments may also use triggers based on comparing values, such as vehicle speed and vehicle position, such as determining that the vehicle is exceeding a known speed limit for a particular section of road. .

Another exemplary data collection use case (see, eg, FIG. 131 and related discussion) involves using location-based triggers. For example, a trigger may initiate capture of vehicle data as the vehicle enters and/or exits a geographic area, ie, geofencing.

Another exemplary data collection use case (see, e.g., FIG. 131 and related discussion) is external data, e.g., data from outside the vehicle such as temperature/environment and/or signals sent to the vehicle from an external source. using triggers based on data received from.

Another exemplary data collection use case (see, eg, FIG. 131 and related discussion) involves using triggers that can act as immediate user responses for data collection. For example, a user may press a button and/or other actuator that turns on the camera's recording function. Embodiments also provide for user-initiated capture of other types of vehicle data. For example, a user may detect an abnormal sound coming from the wheels and/or engine and then press a button and/or other actuator to initiate collection of vehicle data corresponding to the wheels and/or engine.

Another exemplary data collection use case (see, eg, FIG. 131 and related discussion) is in an autonomous vehicle that the vehicle made a sharp turn, braked hard, and/or other data that may be of interest. Using a trigger based on detection of an event of type. Embodiments of the present disclosure can also use “virtual sensors” for event detection that serve as triggers for data collection.

The methods and systems described herein are configured to execute computer readable instructions, program code, instructions, and/or functionally perform one or more operations of the methods and systems herein. It may be deployed partially or wholly through a machine, including computers, computing devices, processors, circuits, and/or servers, including hardened hardware. As used herein, the terms computer, computing device, processor, circuit, and/or server (“computing device”) are understood broadly.

Exemplary computing devices include any type of computer capable of accessing instructions stored in communication therewith, such as on non-transitory computer-readable media, where the computer executes the instructions. perform the actions of a computing device when In certain embodiments, such instructions themselves constitute a computing device. Additionally or alternatively, a computing device may include separate hardware devices, one or more computing resources distributed across hardware devices, and/or logic circuits, embedded circuits, sensors, actuators, inputs and /or output devices, network and/or communication resources, any type of memory resources, any type of processing resources, and/or functionally implement one or more operations of the systems and methods herein. It may include aspects such as a hardware device configured to comply with conditions determined to perform.

Networks and/or communication resources include, but are not limited to, local area networks, wide area networks, wireless, 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 a plurality of devices included as an interoperable set of resources for performing the described functions of the computing device; work together to perform the operations of a switching device. In particular embodiments, each computing device may reside on separate hardware and/or one or more hardware devices may be implemented by, for example, separately executable instructions stored on the device. and/or as logically divided aspects of a set of executable instructions, including aspects of a plurality of computing devices, some of which constitute one of the first computing devices; Any aspect may form part of another of the computing devices.

A computing device may be part of a server, client, network infrastructure, mobile computing platform, stationary computing platform, or other computing platform. A processor can be any type of computing or processing device capable of executing program instructions, code, binary instructions, and the like. A processor may be a signal processor, digital processor, embedded processor, microprocessor, or coprocessor (mathematical coprocessor, graphics coprocessor) capable of directly or indirectly facilitating the execution of program code or program instructions stored thereon. , a communications coprocessor, etc.). Further, a processor may enable execution of multiple programs, threads, and code. Threads can be executed concurrently to increase processor performance and facilitate concurrent application operation. As an implementation, the methods, program code, program instructions, etc. described herein may be implemented in one or more threads. Threads may spawn other threads that may have assigned priorities associated with them, and the processor may assign these threads based on priorities or other ordering based on instructions provided in the program code. threads can run. The processor may include memory for storing methods, code, instructions and programs as described herein and elsewhere. A processor may access storage media through an interface that may store methods, code, and instructions such as those described herein and elsewhere. Storage media associated with processors for storing methods, programs, codes, program instructions or other types of instructions executable by a computing or processing device include CD-ROM, DVD, memory, hard disk, flash drive, RAM , ROM, cache, etc., but are not limited to these.

A processor may include one or more cores, which may increase the speed and performance of multiprocessors. In embodiments, a process may be a dual-core processor combining two or more independent cores (called dies), a quad-core processor, other chip-level multiprocessors, and the like.

The methods and systems described herein may be implemented in part through machines executing computer readable instructions on servers, clients, firewalls, gateways, hubs, routers, or other such computer and/or network hardware. Or all can be deployed. The computer readable instructions may be associated with servers, which may include file servers, print servers, domain servers, Internet servers, intranet servers, and other variations such as secondary servers, host servers, distribution servers, and the like. A server may include memory, processors, computer-readable transitory and/or non-transitory media, storage media, ports (physical and virtual), communication devices, and other servers, clients, machines, and devices through wired or wireless media. can include one or more of such interfaces that can access the A method, program, or code described herein may be executed by a server. Additionally, other apparatus required to perform methods as described herein can be considered part of the infrastructure associated with the server.

A server may provide interfaces to other devices including, but not limited to, clients, other servers, printers, database servers, print servers, file servers, communication servers, distribution servers, and the like. Additionally, this coupling and/or connection can facilitate remote execution of instructions over a network. Networking some or all of these devices may facilitate parallel processing of program code, instructions, and/or programs at one or more locations without departing from the scope of this disclosure. . Moreover, all devices connected to the server via an interface may include at least one storage medium capable of storing methods, program code, instructions and/or programs. A central repository can provide program instructions to be executed on different devices. In this embodiment, the remote repository can serve as a storage medium for methods, program code, instructions, and/or programs.

The methods, program code, instructions, and/or programs may include file clients, print clients, domain clients, internet clients, intranet clients, and other variants such as secondary clients, host clients, distribution clients, etc. can be associated. A client may include memories, processors, computer-readable transitory and/or non-transitory media, storage media, ports (physical and virtual), communication devices, and other clients, servers, machines, and devices through wired or wireless media. can include one or more of such interfaces that can access the Methods, program code, instructions and/or programs described herein and elsewhere may be executed by a client. In addition, other equipment required for execution of methods as described herein can be considered part of the infrastructure associated with the client.

Clients may provide interfaces to other devices including, but not limited to, servers, other clients, printers, database servers, print servers, file servers, communication servers, distribution servers, and the like. Additionally, this coupling and/or connection may facilitate remote execution of methods, program code, instructions and/or programs over a network. Networking some or all of these devices may facilitate parallel processing of methods, program code, instructions and/or programs at one or more locations without departing from the scope of this disclosure. can. Moreover, all devices connected to clients via interfaces may include at least one storage medium capable of storing methods, program code, instructions, and/or programs. A central repository can provide program instructions to be executed on different devices. In this embodiment, the remote repository can serve as a storage medium for methods, program code, instructions, and/or programs.

The methods and systems described herein may be deployed in part or in whole through a network infrastructure. A network infrastructure may include computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices, and other active and passive devices, modules, and/or It can contain elements such as components. Computing and/or non-computing devices associated with the network infrastructure may include storage media such as flash memory, buffers, stacks, RAM, ROM, etc., among other components. The methods, program code, instructions and/or programs described herein and elsewhere may be executed by one or more of the elements of the network infrastructure.

The methods, program code, instructions and/or programs described herein may be executed in a cellular network having multiple cells. A cellular network can be either a frequency division multiple access (FDMA) network or a code division multiple access (CDMA) network. A cellular network may include mobile devices, cell sites, base stations, repeaters, antennas, towers, and so on.

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

Methods, program code, instructions, and/or programs are computer components, devices, and recording media that retain, for intervals, digital data used in computing; semiconductor storage known as random access memory (RAM); Typical mass storage for more permanent storage such as forms of magnetic storage such as optical disks, hard disks, tapes, drums, cards and other types; processor registers, cache memory, volatile memory, non-volatile memory; CD, DVD optical storage such as flash memory (e.g. USB sticks or keys), removable media such as floppy disks, magnetic tapes, paper tapes, punched cards, standalone RAM disks, Zip drives, removable mass storage, off-line and other removable media; dynamic memory , static memory, read/write storage, mutable storage, read-only, random access, sequential access, location addressable, file addressable, content addressable, network attached storage, network of storage areas, bar codes, magnetic ink, etc. can be stored and/or accessed on machine-readable transitory and/or non-transitory media, which can include other computer memory such as

Certain operations described herein involve interpreting, receiving, and/or determining one or more values, parameters, inputs, data, or other information (“received data”). . The act of receiving data includes, but is not limited to, receiving data via user input, receiving data over any type of network, reading a data value from a memory location in communication with the receiving device. , utilizing default values as received data values, estimating, calculating or deriving data values based on other information available to the receiving device, and/or depending on subsequent received data values. updating the In certain embodiments, a data value may be received by a first operation as part of receiving the data value and later updated by a second operation. For example, a first receive operation may be performed when communication is stopped, intermittent, or interrupted, and an updated receive operation may be performed when communication is restored.

Certain logical groupings of acts herein, such as methods or procedures of the disclosure, are provided to illustrate aspects of the disclosure. Operations described herein are generally described and/or depicted, and operations may be combined, divided, reordered, added, or deleted in a manner consistent with this disclosure. . Although the context of the description of the actions may require an order for one or more actions and/or an order for one or more actions may be explicitly disclosed, the order of the actions is , any equivalent grouping of operations to provide equivalent results of the operations is specifically contemplated herein and is to be understood broadly. For example, if a value is used in one action step, the determination of the value is dependent on that action in a particular context (e.g., when the time delay of data for action to achieve a particular effect is important). may be required prior to a step, but may be required prior to that action process in other contexts (e.g., when the use of values from previous execution cycles of the action is sufficient for their purposes). may not be. Thus, in certain embodiments, the order of operations and groupings of operations as described is expressly contemplated herein, and in certain embodiments, reordering, subdividing, and/or Different groupings are expressly contemplated herein.

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

The methods and/or processes described above, and steps thereof, are either hardware, program code, instructions, and/or programs, or hardware and methods, program codes, instructions, and/or programs suitable for particular applications. can be realized by a combination of Hardware may refer to a dedicated computing device or a particular computing device, particular aspects or components of a particular computing device, and/or hardware for performing one or more operations of a method and/or system. It may include an arrangement of hardware components and/or logic circuitry. A process can be implemented in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors, or other programmable devices, along with internal and/or external memory. The process may also, or alternatively, be embodied in an application specific integrated circuit, programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. be able to. It will further be appreciated that one or more of the processes can be embodied as computer-executable code executable on a machine-readable medium.

The computer-executable code may be in a structured programming language such as C, an object-oriented programming language such as C++, or one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and computer readable instructions; or other high-level or low-level programming languages (including assembly language, hardware description languages, database programming languages and techniques) that can be stored, compiled or interpreted for execution on any other machine capable of executing program instructions can be created by

Thus, in one aspect, each of the methods and combinations thereof described above can be embodied in computer-executable code that performs the steps when executed on one or more computing devices. In another aspect, the method may be embodied in a system that performs its steps, may be distributed among devices in any number of ways, or all of the functionality may reside on dedicated stand-alone devices or other hardware. can be integrated into 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.

Although this disclosure has been disclosed with respect to specific embodiments illustrated and described in detail, various modifications and improvements thereto will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present disclosure should not be limited by the above examples, but should be construed in the broadest sense permitted by law.

14702 Remote Access Execution Circuit 14704 Property Conversion Circuit 14706 Parameter Acquisition Circuit 14708 Parameter Adjustment Circuit 14710 Remote Access Request Values 14712 Requested Vehicle Properties 14714 Property Request Values 14716 Vehicle Parameter Values 14718 Vehicle Property Data 14720 Transmit Vehicle Property Data 14722 Vehicle Function Values 14724 Remote Operation Circuit 14726 Actuator Command Value

Claims (75)

a device,
Remote access enforcement circuitry configured to interpret a remote access request value from a requesting device, said remote access request value including at least one of a requested vehicle property or vehicle function value. and,
a property conversion circuit configured to determine at least one of a property request value responsive to the at least one requested vehicle property or an actuator command value responsive to the vehicle function value;
a parameter acquisition circuit configured to interpret a plurality of vehicle parameter values in response to the property request;
a remote operating circuit configured to provide the actuator command value to a vehicle network zone endpoint;
a parameter adjustment circuit configured to generate vehicle property data corresponding to at least the requested vehicle property from the plurality of vehicle parameter values in response to the requested property value;
with
the remote access enforcement circuitry is further configured to transmit the vehicle property data to the requesting device;
Device. further comprising a converged network device (CND) configured to coordinate communication between a first network zone having a first network endpoint and a second network zone having a second network endpoint;
2. The apparatus of claim 1, wherein at least some of said plurality of vehicle parameter values are generated by each of said first network endpoint and said second network endpoint. an integrated network device configured to coordinate communication between a first network zone having a first network endpoint and a second network zone having a second network endpoint and including a vehicle network zone; CND),
2. The apparatus of claim 1, wherein the first network endpoint provides at least some of the plurality of vehicle parameter values and the second network endpoint includes an actuator responsive to the actuator command value. . The property conversion circuit further comprises:
determining the actuator command value as a sequence of actuator commands corresponding to a diagnostic test operation;
determining the actuator command values as a sequence of actuator commands corresponding to remote control actions; or determining the actuator command values as at least one actuator command corresponding to the vehicle function values;
2. The apparatus of claim 1, configured to determine the actuator command value by performing at least one operation selected from operations consisting of: 2. The apparatus of claim 1, wherein the property request value comprises at least one of a vehicle speed value, a prime mover speed value, a prime mover torque value, a user-actuated vehicle characteristic value, or a vehicle position value. The property request values include network utilization values for the vehicle network zone, raw network messages from the vehicle network zone, network addresses of endpoints on the vehicle network zone, memory storage descriptions of vehicle controllers, controller area network ( 2. The apparatus of claim 1, comprising at least one of a value from an endpoint on a CAN), a value from an endpoint on a Local Interconnect Network (LIN), or an intermediate control value. an automatic behavior circuit configured to interpret an automatic behavior value that includes an automatic behavior description of the vehicle;
an automation manager circuit configured to determine a trigger description value in response to said automatic action value, said trigger description value including a trigger state value and a trigger response value;
a trigger evaluation circuit configured to determine the occurrence of a trigger event as a function of the trigger status value and at least one vehicle data value;
a trigger execution circuit configured to execute a trigger response in response to the occurrence of a trigger event;
2. The apparatus of claim 1, further comprising: 2. The apparatus of claim 1, wherein the property request value comprises at least one of a fault state value, a fault count value, a diagnostic parameter value, a fault confirmation value, a diagnostic confirmation value, a fault median value, or a diagnostic median value. . a device,
a policy acquisition circuit configured to interpret vehicle policy data values including location description values;
policy processing circuitry configured to generate parsed policy data including a vehicle data collection description in response to and based at least in part on the vehicle policy data values;
policy enforcement circuitry configured to collect vehicle data from one or more endpoints of at least one network zone of the vehicle in response to the parsed policy data;
A device comprising: 10. The apparatus of claim 9, wherein the location description values include at least one description selected from descriptions consisting of geographic location values, jurisdictional values, relative location values, or defined geographic region values. 10. The apparatus of claim 9, wherein the policy enforcement circuitry is further configured to adjust collection of the vehicle data in response to the location description values. 12. The apparatus of Claim 11, wherein the policy enforcement circuitry is further configured to prevent collection of at least a portion of the vehicle data in response to the location description value. 12. The apparatus of Claim 11, wherein the policy enforcement circuitry is further configured to initiate collection of at least a portion of the vehicle data in response to the location description value. 12. The apparatus of Claim 11, wherein said policy enforcement circuitry is further configured to adjust the format of at least a portion of said vehicle data in response to said location description value. 12. The apparatus of claim 11, wherein the policy enforcement circuitry is further configured to modify collected parameters in response to the location description values. 12. The apparatus of Claim 11, wherein the policy enforcement circuitry is further configured to add or modify metadata to at least a portion of the vehicle data in response to the location description value. 12. The apparatus of Claim 11, wherein the policy enforcement circuitry is further configured to adjust a priority associated with at least a portion of the vehicle data as a function of the location description value. 18. The apparatus of claim 17, wherein said priority comprises in-vehicle data storage priority. 18. The apparatus of claim 17, wherein said priority comprises transmission priority. 18. The apparatus of claim 17, wherein said priorities comprise in-vehicle transmission priorities corresponding to at least one network zone of said vehicle. a device,
a policy acquisition circuit configured to interpret vehicle policy data values including vehicle status data;
policy processing circuitry configured to generate parsed policy data including a vehicle data collection description as a function of and at least partially based on the vehicle policy data values;
policy enforcement circuitry configured to collect vehicle data from one or more endpoints of at least one network zone of the vehicle in response to the parsed policy data;
a vehicle data transmission circuit configured to transmit at least a portion of the collected vehicle data;
A vehicle status data conditioning circuit configured to interpret a vehicle status data collection change value, comprising:
the policy enforcement circuitry is further configured to adjust collecting the vehicle data in response to the vehicle status data collection change value; or
the vehicle data transmission circuitry is further configured to coordinate transmission of at least a portion of the collected vehicle data in response to the vehicle status data collection change value;
at least one of: a vehicle status data conditioning circuit;
A device comprising 22. The apparatus of claim 21, wherein the vehicle status data conditioning circuit is further configured to interpret the vehicle status data collection change value as a function of operating conditions of the vehicle. 22. The apparatus of claim 21, wherein said vehicle status data conditioning circuit is further configured to interpret said vehicle status data collection change value in response to an event occurrence. The vehicle status data conditioning circuit further comprises:
determining a fault condition value;
determining a failure count value;
determining a diagnostic parameter value;
determining a failure confirmation value;
determining a diagnostic confirmation value;
determining a failure median value; or determining a diagnostic median value;
24. The apparatus of claim 23, configured to determine said event occurrence by performing at least one action selected from the actions of: 24. The apparatus of Claim 23, wherein the vehicle status data further includes a trigger condition, and wherein the vehicle status data conditioning circuit is further configured to determine the event occurrence in response to the trigger condition. 26. The apparatus of claim 25, wherein the trigger conditions include at least one condition selected from conditions consisting of an event detection condition, a vehicle status value, or a vehicle operating condition value. 22. The apparatus of claim 21, wherein the vehicle status data conditioning circuit is further configured to interpret the vehicle status data collection change value responsive to a location description value. 28. The apparatus of claim 27, wherein the location description values include at least one description selected from descriptions consisting of geographic location values, jurisdictional values, relative location values, or defined geographic region values. 28. The apparatus of claim 27, wherein the policy enforcement circuitry prevents collection of at least a portion of the vehicle data in response to the location description value in response to the vehicle status data collection change value. 28. The apparatus of claim 27, wherein the policy enforcement circuitry is responsive to the vehicle status data collection change value to initiate collection of at least a portion of the vehicle data responsive to the location description value. 28. The apparatus of claim 27, wherein the policy enforcement circuitry adjusts the format of at least a portion of the vehicle data responsive to the location description value responsive to the vehicle status data collection change value. 28. The apparatus of claim 27, wherein the policy enforcement circuitry adjusts a priority associated with at least a portion of the vehicle data responsive to the location description value responsive to the vehicle status data collection change value. 33. The apparatus of claim 32, wherein said priority comprises onboard data storage priority. 33. The apparatus of claim 32, wherein said priority comprises transmission priority. 33. The apparatus of claim 32, wherein said priorities comprise in-vehicle transmission priorities corresponding to at least one network zone of said vehicle. 28. The apparatus of claim 27, wherein the vehicle data transmission circuitry is responsive to the vehicle status data collection change value to adjust the priority of at least a portion of the collected vehicle data responsive to the location description value. a device,
a container acquisition circuit configured to interpret a plurality of container application values each containing an application operable on an endpoint of the vehicle;
container security circuitry configured to interpret authorization values associated with each of the plurality of container application values;
configured to interpret a container policy to determine operating parameters for each of the plurality of container application values in response to the container policy and the authorization values associated with each of the plurality of container application values; a configured container orchestration circuit;
A device comprising: 38. The apparatus of claim 37, wherein each of said plurality of container application values includes an image of an associated container application. The container policy further:
an execution order of at least one container application value of the plurality of container application values;
a data dependency description of at least one container application value of said plurality of container application values; or a priority value of at least one container application value of said plurality of container application values;
38. The apparatus of claim 37, comprising at least one value selected from the values consisting of: 38. The apparatus of claim 37, wherein the container orchestration circuitry is further configured to distribute the plurality of container application values to a plurality of endpoints of the vehicle. 41. The apparatus of claim 40, wherein the container orchestration circuitry is further configured to distribute the multiple container application values to balance workload of multiple controllers including the multiple endpoints. . 41. The apparatus of claim 40, wherein the container orchestration circuitry is further configured to distribute the plurality of container application values according to workloads of the plurality of controllers comprising the plurality of endpoints. 41. The apparatus of claim 40, wherein the container orchestration circuitry is further configured to distribute the multiple container application values to balance network communication loads of multiple network zones of the vehicle. 41. The apparatus of claim 40, wherein the container orchestration circuitry is further configured to distribute the plurality of container application values according to network communication loads of a plurality of network zones of the vehicle. 38. The apparatus of Claim 37, wherein the container security circuitry is further configured to determine the authorization value as a function of authorization associated with an entity providing each of the plurality of container application values. 38. The apparatus of Claim 37, wherein said container security circuitry is further configured to determine said authorization value in response to authorization requirements associated with operation of each of said plurality of container application values. 47. The apparatus of claim 46, wherein said container security circuitry is further configured to determine said authorization requirements as a function of input data values for each of said plurality of container application values. 47. The apparatus of claim 46, wherein said container security circuitry is further configured to determine said authorization requirements as a function of output data values of each of said plurality of container application values. 47. The apparatus of Claim 46, wherein the container security circuitry is further configured to determine the authorization requirement as a function of an actuator command value for each of the plurality of container application values. 47. The apparatus of Claim 46, wherein said container security circuitry is further configured to determine said authorization requirements as a function of a memory support value for each of said plurality of container application values. 51. The apparatus of claim 50, wherein said memory support value comprises an installed memory support value. 51. The apparatus of claim 50, wherein memory support values include operating memory support values. 47. The apparatus of Claim 46, wherein said container security circuitry is further configured to determine said authorization requirements as a function of a processing support value for each of said plurality of container application values. The container acquisition circuitry is further configured to interpret additional container application values, and the container orchestration circuitry is further configured to determine the plurality of container application values and operational parameters for the additional container application values in response to the additional container application values. 38. The device of claim 37, configured to update. The container orchestration circuitry is further configured to distribute the added container application value to selected endpoints of the vehicle according to the selected endpoint's ability to execute the added container application value. 55. The apparatus of claim 54, configured. 55. The container orchestration circuit of claim 54, wherein the container orchestration circuitry is further configured to modify the distribution of the plurality of container application values across the plurality of endpoints of the vehicle in response to the added container application values. equipment. The container acquisition circuitry is further configured to interpret an enable value for at least one of the plurality of container application values, and the container orchestration circuitry further determines the operating parameter as a function of the enable value. 38. Apparatus according to claim 37, configured to: 38. The apparatus of claim 37, wherein the container orchestration circuitry is further configured to interpret vehicle operating conditions and determine the operating parameters in response to the vehicle operating conditions. 38. The apparatus of claim 37, wherein the container orchestration circuit is further configured to interpret vehicle configuration values and to determine the operating parameters in response to the vehicle configuration values. a device,
a parameter acquisition circuit configured to interpret a plurality of vehicle parameter values;
parameter adjustment circuitry configured to adjust the plurality of vehicle parameter values for storage in one or more cache devices;
a parameter storage circuit configured to store the adjusted plurality of vehicle parameter values in the one or more cache devices;
A device comprising: the parameter adjustment circuit is further configured to determine a storage location value;
the parameter storage circuitry is further configured to store the adjusted plurality of vehicle parameter values in response to the storage location values;
wherein the one or more cache devices are mounted on a vehicle;
61. Apparatus according to claim 60. 62. The method of claim 61, wherein each of the one or more cache devices onboard the vehicle is associated with a controller that is different from controllers associated with other of the one or more cache devices. Device. the parameter adjustment circuit is further configured to determine a storage location value;
the parameter storage circuitry is further configured to store the adjusted plurality of vehicle parameter values in response to the storage location values;
61. The apparatus of claim 60, wherein the one or more cache devices are located outside the vehicle. 64. The apparatus of claim 63, wherein said one or more cache devices are based at least in part on a network cloud-based storage system. the parameter adjustment circuit is further configured to determine a storage location value;
The parameter storage circuit is further responsive to the storage location value to:
a first portion of the adjusted plurality of vehicle parameter values on a first cache device of the one or more cache devices;
a second portion of the adjusted plurality of vehicle parameter values on a second cache device of the one or more cache devices;
configured to store
61. The apparatus of claim 60, wherein the first cache device is mounted on a vehicle and the second cache device is located outside the vehicle. The parameter adjustment circuit is further configured to generate an expiration value for the plurality of vehicle parameter values configured to trigger selective expiration of the plurality of vehicle parameter values in the one or more cache devices. 61. The apparatus of claim 60, configured. 67. The apparatus of claim 66, wherein said parameter storage circuitry is further configured to send said expiration value to said one or more cache devices. 67. The apparatus of Claim 66, wherein said parameter storage circuitry is further configured to selectively expire said plurality of vehicle parameter values in response to said expiration date value. 67. The apparatus of claim 66, wherein said expiration value is a time value corresponding to a time period for storing said plurality of vehicle parameter values in said one or more cache devices. further comprising policy acquisition circuitry configured to interpret a vehicle policy data value including at least a portion of a vehicle policy, wherein the parameter adjustment circuitry generates the expiration value as a function of the vehicle policy data value. 67. The apparatus of claim 66, further configured. 67. The apparatus of Claim 66, wherein the parameter adjustment circuit is further configured to determine a type value for the plurality of vehicle parameter values and to generate the expiration date value in response to the type value. 72. The apparatus of claim 71, wherein the type value corresponds to at least one of engine data, control data, mission critical data, drive status data, or drive operation data. 72. The apparatus of claim 71, wherein the type value corresponds to at least one of a vehicle status value, a vehicle mode value, a diagnostic value, or a fault value. 61. The apparatus of claim 60, wherein said parameter adjustment circuit is further configured to adjust said plurality of vehicle parameter values via compressing said plurality of vehicle parameter values. 61. The apparatus of claim 60, wherein said parameter adjustment circuit is further configured to adjust said plurality of vehicle parameter values via summarizing said plurality of vehicle parameter values.

Images