SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION - Patent application

Abstract

A vehicle data collection and management device includes a remote access execution circuit, a property conversion circuit, a parameter acquisition circuit, a remote operation circuit, and a parameter adjustment circuit. The remote access execution circuit interprets a remote access request value including a requested vehicle property and / or vehicle function value. The property conversion circuit determines a property request value corresponding to the requested vehicle property and / or an actuator command value corresponding to the vehicle function value. The parameter acquisition circuit interprets a vehicle parameter value corresponding to the property request value. The remote operation circuit provides the actuator command value to a vehicle network zone endpoint. The parameter adjustment circuit generates vehicle property data from the vehicle parameter value in response to the property request value. The vehicle property data corresponds to the requested vehicle property. The remote access execution circuit transmits the vehicle property data to a requesting device.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application is a continuation of U.S. Provisional Patent Application No. 62 / 986,444 (SONA-0004-P01), filed March 6, 2020, entitled "SYSTEM, METHOD AND APPARATUS FOR IMPLEMENTING Configurable Data Collection for a Vehicle," U.S. Provisional Patent Application No. 63 / 024,383 (SONA-0005-P01), filed May 13, 2020, entitled "SYSTEM, METHOD AND APPARATUS FOR IMPLEMENTING Configurable Data Collection for a Vehicle," and U.S. Provisional Patent Application No. 63 / 024,383 (SONA-0005-P01), filed December 10, 2020, entitled "SYSTEM, METHOD AND APPARATUS FOR IMPLEMENTING Configurable Data Collection for a Vehicle." Priority is claimed to U.S. Provisional Patent Application No. 63 / 123,531 (SONA-0009-P01), entitled "A VEHICLE."

[0002] This application claims priority to and is a continuation-in-part of U.S. patent application Ser. No. 17 / 027,167 (SONA-0006-U01), filed Sep. 21, 2020, entitled "SYSTEM, METHOD, AND APPARATUS TO SUPPORT MIXED NETWORK COMMUNICATIONS ON A VEHICLE."

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

[0004] This application claims priority to and is a continuation-in-part of U.S. patent application Ser. No. 17 / 027,187 (SONA-0007-U01), filed Sep. 21, 2020, and entitled "SYSTEM, METHOD, AND APPARATUS TO EXTRA VEHICLE COMMUNICATIONS CONTROL."

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

[0006] All of the above patents are incorporated herein by reference in their entirety. [Background technology]

[0007] Vehicle communication networks are utilized to connect sensors, actuators, controllers, user interfaces, rider personal devices, trailers, and communication devices throughout a vehicle. Recent trends of more connected devices, more data passing between devices, low latency requirements to meet vehicle performance, safety, and emission requirements, and the addition of vehicle features are increasing the strain on these vehicle communication networks. Furthermore, consumers expect increased connectivity, reduced driver workload, and features that place increased strain on the vehicle communication networks. These trends are likely to continue and accelerate in the future.

[0008] Traditional vehicle communication networks (e.g., CAN, LIN, FlexRay, MOST, LVDS, etc.) have several drawbacks and challenges. These vehicle communication networks were developed to address the unique challenges of the vehicle environment and have evolved accordingly, separate from other networks such as computer local area networks, wide area networks, large-scale interconnected networks (e.g., the Internet), and wireless networks. Most vehicle networks consist of a data link layer and an application layer, utilizing robust, specialized equipment such as a controller area network (CAN) bus with dedicated or shared wiring between devices that utilize specific data protocols (e.g., J1939, OBD, etc.). Modern vehicles may have multiple network buses, with specific commands and communications available, limiting the customization and data speeds available. For example, a CAN bus typically operates at a maximum of approximately 1 Mbps, while a high-capability CAN bus operates at a maximum of approximately 10 Mbps. Furthermore, a CAN bus exhibits high latency, greater than 25 ms, typically between approximately 60 ms and 500 ms, depending on the configuration, traffic on the CAN, the priority of specific messages, and the like.

[0009] As the number of devices and data rate demands from devices increase, traditional vehicle communication networks require higher performance bus implementations. Because the automotive industry is a high-volume production industry with extremely low tolerance for component failure, vehicle manufacturers use the same components for long periods of time and across a wide range of vehicles, including sharing of components between manufacturers. Furthermore, changing to a nominally more capable component can introduce risk, integration costs, recertification burdens for a given application, or other undesirable effects on the system. Therefore, even as vehicle communication networks migrate to higher performance network configurations, it is desirable to keep network types separate within the system and maintain a large number of legacy devices (e.g., CAN-compatible) within the system over the long term.

[0010] Collecting data from vehicles presents additional 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 exposed to risks while in possession of the data, such as in the event of inadvertent or malicious access to the data. With respect to collected vehicle data, large volumes of data may be collected and there may be multiple purposes for data collection, increasing risks compared to other common data storage applications. Therefore, to reduce risks, it may be desirable to control data collection, storage, and access, and further may include data access validation, partitioning or other exclusion of data when not in use, and the like.

[0011] 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 networked systems are limited by mobile application constraints, costs, and / or bandwidth constraints caused by high data rates and large data transfers. Even considering the above, customer demands, market expectations, increasing demands for efficient vehicle operations, and increasing functional capabilities of data-related applications continue to significantly increase the total amount of data transferred, the number of off-vehicle applications that utilize the transferred data, the number of purposes for which the data can be utilized, and the number of users or entities that legitimately require a portion of the transferred data. Furthermore, data-utilizing applications continue to grow in sophistication and functionality, increasing data demands on limited transfer resources and increasing the cost and complexity of logistics and storage of the transferred data. For example, more capable vehicle routing or operational algorithms, increased automation of vehicle functions, increased demand for predictive decisioning and / or maintenance support, and an increase in media streams (both the number of media streams and their quality) all result in increased demands on data rates, the amount of data stored, and the number of entities or applications that access the stored data.

[0012] The complexities mentioned above and other challenges have a multiplicative effect, making the complexity of the vehicle data environment much greater than the sum of the individual contributions from each challenge.

[0013] As one example, increasing the number of entities or applications accessing data increases the likelihood of individual data requests being duplicated, e.g., by multiple entities requesting the same or similar data. Furthermore, increasing the number of entities or applications accessing data increases the likelihood that members of an accessing group share similar privilege levels, such that data access for individual members of the entity or application group requires data management.

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

[0015] In yet another example, the complex environment of currently known and transitioning vehicle network architectures, e.g., vehicles with mixed network types and / or split networks, increases the complexity of data access for individual entities, and without certain aspects of the present disclosure, may require determining request parameter specifications for specific data elements and updating these request parameters as the vehicle network architecture evolves. Given the increasing number of entities requesting data access, the total cost to the automotive support market increases non-linearly as each entity incurs the cost of tracking request parameter specifications. Furthermore, the trajectory of additional entities requesting data access is toward entities located further away in the technical knowledge space from the vehicle's core functions, and correspondingly, the complexities and specificities of the vehicle and / or vehicle application, including in-vehicle network configurations, specific data descriptions, data requests and communication protocols, industry standards or practices for presenting information, and the like, are less known on average with each incremental new entity, further increasing the cost volume function (e.g., the cost over time for a given entity to fulfill a desired data collection deliverable, where the given entity can be an automobile manufacturer, and / 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:

[0016] COST = Number of entities * Base learning cost * Transition cost Adapt to trajectory * Data trajectory cost * Regulation adaptation cost * Data access / storage responsibility cost

[0017] The described COST functions are non-limiting hypothetical examples that illustrate how various challenges and complexities associated with currently known systems interact and synergize to increase the cost of meeting future data collection capabilities for vehicle applications. The described cost parameters are not intended to cover all costs associated with the automotive data collection industry or the challenges present in currently known systems. Parameters can be averages or other complex functions, and the values ​​of particular parameters are generally not specifically known. Furthermore, COST units can be expressed as monetary values ​​for resources (e.g., engineering hours, computing hours, etc.) to achieve data collection goals over the long term, or other non-monetary units such as equivalent emissions, customer satisfaction, risks incurred, public-perceived losses or gains, etc. The entity count parameter generally reflects the number of entities accessing vehicle data over time; basic learning cost reflects the cost for new entities to learn specific vehicle, vehicle type, market, and other data collection requirements and protocol specifications; adaptation to transition cost trajectory reflects the cost of adapting to changes in vehicle network configuration, including network type and mechanisms; data trajectory cost reflects the increase in demand for data collection from associated vehicles over time, including data communication, storage, and resulting functional consequences such as an inability to support desired applications or the cost of enhancing the data communication infrastructure; regulation adaptation cost reflects the costs associated with an increase in the number of regulations, an increase in the number of regulatory frameworks, and / or an increase in the number of regulatory bodies; and data access / storage liability cost reflects the costs incurred for data compliance and security, and / or losses incurred due to data breaches, misuse, and the like. Summary of the Invention

[0018] An exemplary apparatus includes a policy acquisition circuit configured to interpret a vehicle policy data value including a driver information description; a policy processing circuit 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 value; and a policy execution circuit 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.

[0019] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The one or more endpoints include endpoints located on at least two network zones of the vehicle. The driver information description includes a description of vehicle data to be collected based on driver characteristics. The policy execution circuit is further configured to interpret driver information corresponding to a current driver of the vehicle and collect vehicle data in response to a comparison of the driver characteristics with the driver information corresponding to the current driver of the vehicle. The driver information description includes a description of driver monitoring data of the vehicle. The driver information description further includes a description of the driver monitoring data based on the driver characteristics. The driver information description further includes a trigger condition, and the policy execution circuit is further configured to collect further vehicle data in response to the trigger condition. The trigger condition includes at least one condition selected from the following conditions: an event detection condition; a driver characteristic value; a driver classification value; or a driver performance value. The collected vehicle data further includes a determination of an event occurrence in response to the trigger condition.

[0020] An exemplary apparatus includes a policy acquisition circuit configured to interpret a vehicle policy data value including a device state description; a policy processing circuit 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 value; and a policy execution circuit 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.

[0021] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The one or more endpoints include endpoints located on at least two network zones of the vehicle. The device state description includes a description of vehicle data collected based on at least one of a device fault value or a device diagnostic value. The device state description includes a description of monitoring data of a device of the vehicle. The vehicle data collection includes a description of monitoring data of a device based on at least one of a device fault value or a device diagnostic value. The 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 description of the monitoring data includes at least one data value selected from the 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 intermediate value, or a diagnostic intermediate value. The description of the monitoring data includes monitoring data of a device other than the device corresponding to at least one of the device fault value or the device diagnostic value.

[0022] An example apparatus includes a policy acquisition circuit configured to interpret vehicle policy data values ​​including endpoint performance descriptions; a policy processing circuit configured to generate parsed policy data including a vehicle data collection description based at least in part on the vehicle policy data values; and a policy execution circuit configured to collect vehicle data from one or more endpoints in at least one network zone of the vehicle in response to the parsed policy data.

[0023] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. 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. The target endpoint in the first state includes a first vehicle configuration, and the target endpoint in the second state includes a second vehicle configuration. The target endpoint in the second state includes a target endpoint determined to be in an off-nominal state. The off-nominal state includes at least one state selected from the group consisting of a fault condition, a failure condition, a non-responsive condition, or a loss of communication condition. The target endpoint in the first condition includes a first target endpoint configuration, and the target endpoint in the second condition includes a second target endpoint configuration. The first data value includes data collected from a first endpoint group, and the second data value includes data collected from a 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.

[0024] An exemplary apparatus includes a policy acquisition circuit configured to interpret vehicle policy data values ​​including a location description value; a policy processing circuit 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; and a policy execution circuit 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.

[0025] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in particular embodiments. The location description value includes at least one description selected from the following descriptions: a geographic location value; a jurisdiction value; a relative location value; or a defined geographic region value. The policy enforcement circuit is further configured to adjust collection of the vehicle data in response to the location description value. The policy enforcement circuit 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 circuit 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 circuit is further configured to adjust a format of at least a portion of the vehicle data in response to the location description value. The policy enforcement circuit is further configured to modify collected parameters in response to the location description value. The policy enforcement circuit 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 circuit is further configured to adjust a priority associated with at least a portion of the vehicle data in response to the location description value. The priority includes an on-board data storage priority. The priority includes a transmission priority. The priority includes an on-board transmission priority corresponding to at least one network zone of the vehicle.

[0026] An exemplary apparatus includes a policy acquisition circuit configured to interpret vehicle policy data values ​​including vehicle status data; a policy processing circuit 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; a policy execution circuit 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; and a vehicle data transmission circuit configured to transmit at least a portion of the collected vehicle data in response to a data type of the collected vehicle data.

[0027] Certain further aspects of the exemplary apparatus are described below, any one or more of which may be present in particular embodiments. The data type includes at least one data type selected from a control data type, a diagnostic data type, a performance data type, a monitoring data type, or an aggregation data type. The policy enforcement circuit is further configured to adjust collection of the vehicle data according to the data type of the collected vehicle data. The policy enforcement circuit is further configured to prevent collection of at least a portion of the vehicle data according to the data type of the collected vehicle data. The policy enforcement circuit is further configured to initiate collection of at least a portion of the vehicle data according to the data type of the collected vehicle data. The policy enforcement circuit is further configured to adjust a format of at least a portion of the vehicle data according to the data type of the collected vehicle data. The policy enforcement circuit is further configured to adjust a priority associated with at least a portion of the vehicle data according to a location description value. The priority includes an on-board data storage priority. The priority includes a transmission priority. The priority includes an on-board transmission priority corresponding to at least one network zone of the vehicle. The vehicle data transmission circuit is further configured to adjust a priority associated with at least a portion of the vehicle data according to the data type of the collected vehicle data. The priority includes an on-board data storage priority. The priority includes a transmission priority. The priority includes an on-board transmission priority corresponding to at least one network zone of the vehicle. The policy enforcement circuitry is further configured to determine a data type of the collected vehicle data in response to at least one of an endpoint providing the relevant vehicle data, an endpoint requesting the relevant vehicle data, an entity requesting the relevant vehicle data, an application associated with the endpoint providing the relevant vehicle data, an application associated with the request for vehicle data, a flow associated with the endpoint providing the relevant vehicle data, a flow associated with the request for vehicle data, or an instruction data type provided in a vehicle policy data value for the vehicle data.

[0028] An exemplary apparatus includes a policy acquisition circuit configured to interpret vehicle policy data values ​​including vehicle status data; a policy processing circuit 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; a policy execution circuit 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; and a vehicle status data adjustment circuit configured to interpret the vehicle status data collection change value, wherein the policy execution circuit is at least one of: further configured to adjust the collection of the vehicle data in response to the vehicle status data collection change value; or the vehicle data transmission circuit is at least one of: further configured to adjust the transmission of at least a portion of the collected vehicle data in response to the vehicle status data collection change value.

[0029] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The vehicle status data conditioning circuit is further configured to interpret the vehicle status data collection change value in response to an operational state 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 is further configured to determine the event occurrence by performing at least one operation selected from the operations consisting of determining a fault condition value, determining a fault count value, determining a diagnostic parameter value, determining a fault confirmation value, determining a diagnostic confirmation value, determining a fault intermediate value, or determining a diagnostic intermediate value. The vehicle status data further includes a trigger condition, and the vehicle status data conditioning circuit is further configured to determine the event occurrence in response to the trigger condition. The trigger condition includes at least one state selected from the states consisting of an event detection state, a vehicle status value, or a vehicle operational state value. The vehicle status data conditioning circuit is further configured to interpret the vehicle status data collection change value in response to a location description value. The location description value includes at least one description selected from the descriptions consisting of a geographic location value, a jurisdiction value, a relative location value, or a defined geographic region value. The policy enforcement circuit 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. The policy enforcement circuit initiates 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. The policy enforcement circuit adjusts a 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. The policy enforcement circuit adjusts a 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. The priority includes an on-vehicle data storage priority. The priority includes a transmission priority. The priority includes an on-vehicle transmission priority corresponding to at least one network zone of the vehicle. The vehicle data transmission circuit adjusts a priority of at least a portion of the collected vehicle data in response to the location description value in response to the vehicle status data collection change value.

[0030] The 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 in response to and based at least in part on the updated data collection policy, the parsed policy data including a vehicle data collection description; a policy execution circuit configured to collect vehicle data from one or more endpoints in at least one network zone of the vehicle in response to the parsed policy data; and a vehicle data transmission circuit configured to transmit at least a portion of the collected vehicle data.

[0031] Certain further aspects of the exemplary apparatus are described below, any one or more of which may be present in particular embodiments. The data collection policy includes a built-in policy, and the vehicle policy data value includes either a factory policy or a downloaded policy, and the policy acquisition circuitry is further configured to update the data collection policy by replacing the data collection policy with a policy determined in response to the vehicle policy data value. The data collection policy includes a built-in policy, and the vehicle policy data value includes either a factory policy or a downloaded policy, and the policy acquisition circuitry is further configured to generate an updated policy by adding a matching portion of the built-in policy to the policy determined in response to the vehicle policy data value, and to update the data collection policy by replacing the data collection policy with the updated policy. The data collection policy includes a factory policy, and the vehicle policy data value includes a downloaded policy, and the policy acquisition circuitry is further configured to update the data collection policy by replacing the data collection policy with the policy determined in response to the vehicle policy data value. The data collection policy includes a factory policy and the vehicle policy data value includes a downloaded policy, and the policy retrieval circuitry is further configured to generate an updated policy by adding a conforming portion of the factory 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 updated policy. The policy retrieval circuitry is further configured to update the data collection policy by appending a requested policy determined in response to the vehicle policy data value to the data collection policy.The policy acquisition circuitry is further configured to update the data collection policy by removing the added request policy in response to at least one of 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 an external device, a change in subscription status of the entity providing the vehicle policy data value, or a change in authorization status of the entity providing the vehicle policy data value. The vehicle policy data value further includes a trigger condition, and the policy execution circuitry is further configured to collect vehicle data in response to the trigger condition.

[0032] An example apparatus includes a policy retrieval circuit configured to interpret vehicle policy data values ​​including at least one requested vehicle property; a parameter retrieval circuit configured to interpret a plurality of vehicle parameter values ​​responsive to the at least one requested vehicle property from a plurality of provisioning endpoints, each of the plurality of provisioning endpoints being on at least one network zone of the vehicle; and a parameter storage circuit configured to selectively store at least a portion of the plurality of vehicle parameter values, wherein at least a first portion of the stored at least a portion of the plurality of vehicle parameter values ​​is stored on a storage endpoint different from an associated portion of the provisioning endpoint for the stored at least a first portion of the vehicle parameter values.

[0033] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The parameter storage circuit is further configured to selectively store at least a portion 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 being further configured to selectively store at least a portion of the plurality of vehicle parameter values ​​in accordance with the parameter transmission schedule. The apparatus further includes a storage management circuit configured to determine a parameter expiration schedule for the stored vehicle parameter values, the parameter storage circuit being further configured to selectively store at least a portion of the plurality of vehicle parameter values ​​in accordance with the parameter expiration schedule. The parameter storage circuit is further configured to perform at least one operation selected from the group consisting of deleting at least a portion of the stored vehicle parameter values, summarizing at least a portion of the stored vehicle parameter values, compressing at least a portion of the stored vehicle parameter values, or adjusting an amount of reserved memory associated with at least a portion of the stored vehicle parameter values ​​in accordance with the parameter expiration schedule. The parameter storage circuit is further configured to determine a reserved memory amount associated with at least some of the plurality of vehicle parameter values ​​and selectively store at least some of the plurality of vehicle parameter values ​​in accordance with the reserved memory amount. The parameter storage circuit is further configured to determine the reserved memory amount by performing at least one operation selected from the operations of determining an amount of data to be collected to support at least some of the plurality of vehicle parameter values, determining an amount of data to be collected to support trigger evaluations associated with at least some of the plurality of vehicle parameter values, or determining a transmission latency value associated with at least some of the plurality of vehicle parameter values. The parameter storage circuit is further configured to determine the reserved memory amount in accordance with a priority value associated with at least some of the vehicle parameter values.The priority value includes an on-board data storage priority. The priority value includes a transmission priority. The priority value includes a priority associated with an endpoint providing at least a portion of the vehicle parameter values. The priority value includes a priority associated with an endpoint requesting at least a portion of the vehicle parameter values. The priority value includes a priority associated with an entity requesting at least a portion of the vehicle parameter values. The priority value includes a priority associated with an application requesting at least a portion of the vehicle parameter values. The priority value includes a priority associated with an application associated with the endpoint requesting at least a portion of the vehicle parameter values. The priority value includes a priority associated with a flow requesting at least a portion of the vehicle parameter values. The priority value includes a priority for a flow associated with the endpoint requesting at least a portion of the vehicle parameter values.

[0034] An example apparatus includes a container acquisition circuit configured to interpret a plurality of container application values, each of which includes an application operable on an endpoint of the vehicle; a container security circuit configured to interpret an authorization value associated with each of the plurality of container application values; and a container orchestration circuit configured to interpret a container policy and to determine operational parameters for each of the plurality of container application values ​​in response to the container policy and the authorization value associated with each of the plurality of container application values.

[0035] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. Each of the plurality of container application values ​​includes an image of an associated container application. The container policy further includes at least one value selected from the following values: an execution order of at least one of the plurality of container application values; a data dependency description of at least one of the plurality of container application values; or a priority value of at least one of the plurality of container application values. The container orchestration circuit is further configured to distribute the plurality of container application values ​​to a plurality of endpoints of the vehicle. The container orchestration circuit is further configured to distribute the plurality of container application values ​​to balance the workload of a plurality of controllers including the plurality of endpoints. The container orchestration circuit is further configured to distribute the plurality of container application values ​​according to the workload of the plurality of controllers including the number of endpoints. The container orchestration circuit is further configured to distribute the plurality of container application values ​​to balance the network communication load of a plurality of network zones of the vehicle. The container orchestration circuit is further configured to distribute the plurality of container application values ​​according to the network communication load of the plurality of network zones of the vehicle. The container security circuit is further configured to determine an authorization value in response to an authorization associated with an entity providing each of the plurality of container application values. The container security circuit is further configured to determine an authorization value in response to an authorization associated with an operation of each of the plurality of container application values. The container security circuit is further configured to determine an authorization requirement in response to an input data value of each of the plurality of container application values. The container security circuit is further configured to determine an authorization requirement in response to an output data value of each of the plurality of container application values.The container security circuit is further configured to determine authorization requirements in response to the actuator command value for each of the plurality of container application values. The container security circuit is further configured to determine authorization requirements in response to a memory support value for each of the plurality of container application values. The memory support value includes an installation memory support value. The memory support value includes an operating memory support value. The container security circuit is further configured to determine authorization requirements in response to a processing support value for each of the plurality of container application values. The container acquisition circuit is further configured to interpret the additional container application value, and the container orchestration circuit is further configured to update the plurality of container application values ​​and operational parameters for the additional container application value in response to the additional container application value. The container orchestration circuit is further configured to distribute the additional container application value to selected endpoints of the vehicle in response to the capabilities of the selected endpoints to execute the added container application value. The container orchestration circuit 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 value. The container acquisition circuit is further configured to interpret an enable value for at least one of the plurality of container values, and the container orchestration circuit is further configured to determine operational parameters in response to the enable value. The container orchestration circuitry is further configured to interpret the vehicle operating state and to determine the operating parameters as a function of the vehicle operating state. The container orchestration circuitry is further configured to interpret the vehicle configuration values ​​and to determine the operating parameters as a function of the vehicle configuration values.

[0036] The exemplary apparatus includes an automation operation circuit configured to interpret automation operation values ​​including an automation operation description for a vehicle; an automation manager circuit configured to determine a trigger description value in response to the automation operation values, the 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 in response to the trigger state value and at least one vehicle data value; and a trigger execution circuit configured to execute a trigger response in response to the occurrence of the trigger event.

[0037] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The trigger response includes at least one action selected from the actions of performing a data collection action, providing an actuator command value, or enabling operation of a preconfigured function on a controller of the vehicle. The trigger response includes providing a high-priority response to at least a portion of the trigger response. The high-priority response includes transmitting a selected data value to an external device. The high-priority response includes providing a high-priority actuator command value. The automatic operation value includes selecting from a number of predefined automatic operation values. The automation manager circuit is further configured to determine an authorization value associated with the automatic operation value and selectively determine a trigger description value in response to the authorization value. The automation manager circuit is further configured to determine the trigger description value as a permanent value. The automation manager circuit is further configured to determine the trigger description value as a limited execution value. The automation manager circuit is further configured to maintain a receiver of the vehicle in a selected power mode during a selected operating state of the vehicle. The automation manager circuit is further configured to maintain at least one controller of the vehicle in a selected power mode during a selected operating state of the vehicle. The automation manager circuit is further configured to maintain at least one controller of the vehicle in a selected power mode in response to the content of the trigger description value.

[0038] The example apparatus includes a policy acquisition circuit 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 ​​responsive to the at least one requested vehicle property from a plurality of providing endpoints, each of the plurality of providing endpoints being on at least one network zone of the vehicle; and a vehicle data transmission circuit configured to selectively transmit at least a portion of the collected vehicle data.

[0039] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The vehicle data transmission circuit is further configured to selectively transmit at least some of the collected vehicle data by selecting a transmission interval for at least some of the collected vehicle data. The vehicle data transmission circuit is further configured to select the transmission interval in response to at least one of an interval provided in a vehicle policy data value, an interval corresponding to a priority of at least some of the collected vehicle data, an interval corresponding to an availability description for transmitting resources for at least some of the collected vehicle data, an interval corresponding to a historical transmission availability of the vehicle, or an operating state of the vehicle. The vehicle data transmission circuit is further configured to selectively transmit at least some of the collected vehicle data by selecting a bandwidth utilization for at least some of the collected vehicle data. The vehicle data transmission circuit is further configured to select the bandwidth utilization in response to at least one of a bandwidth utilization provided in a vehicle policy data value, a bandwidth utilization corresponding to a priority of at least some of the collected vehicle data, a bandwidth utilization corresponding to an availability description for transmission resources for at least some of the collected vehicle data, an interval corresponding to a historical transmission availability of the vehicle, or an operating 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 responsive to a data type of at least some of the collected vehicle data. The vehicle data transmission circuitry is further configured to selectively transmit at least some of the collected vehicle data responsive to a vehicle operation impact of the transmission operation. The vehicle data transmission circuitry is further configured to selectively transmit at least some of the collected vehicle data responsive to a power usage impact of the transmission operation. The vehicle data transmission circuitry is further configured to selectively transmit at least some of the collected vehicle data responsive to a data transmission capacity value.The data transmission capacity values ​​include at least one data transmission capacity value selected from the group consisting of a data transmission capacity associated with a time interval, a data transmission capacity associated with an entity associated with at least a portion of the collected vehicle data, a data transmission capacity associated with an access point name, a data transmission capacity associated with a flow associated with at least a portion of the collected vehicle data, a data transmission capacity associated with a vehicle application associated with at least a portion of the collected vehicle data, or a data transmission capacity associated with a vehicle function associated with at least a portion of the collected vehicle data. The vehicle data transmission circuit is further configured to selectively transmit at least a portion of the collected vehicle data according to a currently available transmission type. The vehicle data transmission circuit 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 a portion of the collected vehicle data. The data transmission chunk size includes at least one of an individual message size or a single transmission flow size. The vehicle data transmission circuit is further configured to select the transmission chunk size in response to at least one of a transmission chunk size provided in the vehicle policy data value, a transmission chunk size for a priority of at least a portion of the collected vehicle data, a transmission chunk size corresponding to an availability description for a transmission resource for at least a portion of the collected vehicle data, a transmission chunk size corresponding to a past transmission availability for the vehicle, or an operating state of the vehicle. The vehicle transmission circuit is further configured to coordinate the selective transmission of at least a portion of the collected vehicle data in response to a success parameter of the transmission operation. The vehicle transmission circuit is further configured to coordinate the selective transmission of at least a portion of the collected vehicle data in response to a quality of service parameter for the transmission operation.

[0040] An exemplary apparatus includes a remote access execution 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 property conversion circuit configured to determine a property request value in response to the at least one requested vehicle property; a parameter acquisition circuit 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 the plurality of vehicle parameter values ​​corresponding to the at least one requested vehicle property in response to the property request value, wherein the remote access execution circuit is further configured to transmit the vehicle property data to the requesting device.

[0041] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The apparatus further includes an integration network device (CND) configured to regulate communications between a first network zone having a first network endpoint and a second network zone having a second network endpoint, wherein at least a portion of the plurality of vehicle parameter values ​​are generated by each of the first network endpoint and the second network endpoint. The remote access request value includes a vehicle function value, and the property conversion circuit is further configured to determine an actuator command value according to the vehicle function value, and the apparatus further includes a remote operation circuit configured to provide the actuator command value to an endpoint of the vehicle network zone. The apparatus further includes an integration network device (CND) configured to regulate communications between the first network zone having the first network endpoint and a second network zone having a second network endpoint and including the vehicle network zone, wherein the first network endpoint provides at least a portion 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 is further configured to determine the actuator command values ​​by performing at least one operation selected from the operations of: determining the actuator command values ​​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 a remote control operation, or determining the actuator command values ​​as at least one actuator command corresponding to a vehicle function value. 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 providing at least a portion of the multiple vehicle parameter values.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 including a corresponding actuator, each responsive to at least a portion of the actuator command value. The remote access request value includes a policy. The policy includes at least one value selected from the group consisting of an authorization value of the requesting device, a data collection description including at least one requested vehicle property, a trigger description value including a trigger state and a trigger response value, where the parameter acquisition circuitry is further configured to generate at least a portion of the vehicle property data from the plurality of vehicle parameter values ​​in response to the trigger description value, or a policy priority value. The remote access request value includes a policy. The policy includes at least one value selected from the group consisting of an authorization value of the requesting device, a trigger description value including a trigger state and a trigger response value, where the remote operation circuitry further provides an actuator command value in response to the trigger description value, and a policy priority value.

[0042] An example apparatus includes a vehicle event graphical user interface (GUI) configured to interpret trigger description values ​​from a user, the trigger description values ​​including a trigger condition; a request circuit configured to determine a response action value in response to the trigger description value, the response action value including at least one of a vehicle data identifier configured to identify vehicle data to be captured in response to the trigger condition or an alert execution description to be transmitted in response to the trigger condition; and a cloud interface configured to receive at least one of the identified vehicle data or the alert response value determined in response to the alert execution description.

[0043] Certain further aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The GUI is configured to display one vehicle use case template of a plurality of vehicle use case templates in response to a template selection. The GUI is configured to display a portion of a plurality of vehicle usage template identifiers, the GUI determining the portion based on at least one of an authorization value and a location value. The location value corresponds to at least one of a location of the apparatus and a location of the vehicle. The GUI is configured to display the plurality of vehicle usage template identifiers, the GUI configured to indicate that a portion of the plurality of vehicle usage template identifiers are unavailable based on a vehicle data collection parameter value. The GUI is configured to display a vehicle usage template including a plurality of vehicle data identifiers based on the authorization value. The alert response value includes at least one of an alert criteria, an alert type, an alert content, and an alert location. The request circuit is configured to exclude a trigger description value in response to the vehicle data collection parameter value. The 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 a trigger state, and the identified vehicle data will be captured in response to the plurality of trigger conditions. Multiple trigger conditions use multiple vehicle data types.

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

[0045] Certain further aspects of the exemplary method are described below, any one or more of which may be present in particular embodiments. Displaying a portion of the plurality of vehicle usage template identifiers; and displaying a vehicle use case template of the plurality of vehicle use case templates in response to a template selection. Displaying the plurality of vehicle usage template identifiers; and indicating that a portion of the plurality of vehicle usage template identifiers are unavailable based on a vehicle data collection parameter value, the vehicle data collection parameter value indicating that the identified vehicle data cannot be captured by the vehicle. Displaying a vehicle use case template including the plurality of vehicle data identifiers based on an authorization value. Eliminating a trigger description value in response to the vehicle data collection parameter value.

[0046] The exemplary cloud system includes: a request interface configured to interpret a plurality of response action values; a policy creator circuit configured to determine a data collection policy in response to the plurality of response action values, the data collection policy including 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.

[0047] Certain further aspects of the exemplary cloud system are described below, any one or more of which may be present in particular embodiments. A template storage circuit configured to store a plurality of vehicle use case templates and provide one of the plurality of vehicle use case templates in response to a request from a user device and in response to at least one of an authorization value or a location value. The plurality of response action values ​​include a plurality of assessment collection parameter values ​​corresponding to a common vehicle data source, and the policy creator circuit is configured to determine an assessment collection parameter value for a data collection policy in response to a response to the plurality of assessment collection parameter values. The plurality of assessment collection parameter values ​​include a plurality of different frequencies, and the assessment collection parameter includes a frequency 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 that are evaluated based on trigger evaluation data identified by a plurality of trigger evaluation data identifiers. A validation circuit configured to reject one of the plurality of response action values ​​in response to determining the execution parameter value. The validation circuit determines the execution parameter value by determining that the vehicle data identified by the rejected response action value cannot be captured by the vehicle. and an authorization circuit configured to tag a data collection policy according to an authorization value, the authorization value indicating that one source of a plurality of response action values ​​is not authorized to receive the identified vehicle data. The system further includes: a first partition including a request interface, a policy creator circuit, and a cloud interface; a vehicle data storage circuit configured to store the identified vehicle data from the vehicle, and a second partition including a second cloud interface configured to provide the identified vehicle data to the first cloud interface in response to the vehicle data request; the identified vehicle data is encrypted while stored in the vehicle data storage circuit, and the first partition is not configured to decrypt the identified vehicle data stored in the vehicle data storage circuit.The second partition includes a vehicle data query circuit configured to store metadata corresponding to the identified vehicle data and to provide vehicle data query results responsive to the metadata.

[0048] 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; determining a data collection policy in response to the plurality of response action values, the data collection policy including 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 in response to the data collection policy or an alert response value in response to the data collection policy.

[0049] An exemplary vehicle includes a vehicle communication system including a cloud interface configured to interpret a data collection policy from a 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; a policy update circuit configured to determine a collection validation value in response to the identified trigger evaluation data and vehicle data collection parameters; and a trigger evaluation circuit configured to receive a trigger condition in response to the collection validation value.

[0050] Certain further aspects of the exemplary vehicle are described below, any one or more of which may be present in certain embodiments. The vehicle communication system includes a policy manager circuit configured to parse a data collection policy in response to a collection validation value. The trigger evaluation circuit is configured to determine a trigger event occurrence in response to a trigger condition, and the vehicle communication system includes a transmission circuit configured to provide at least one of identified vehicle data in response to the trigger event occurrence or an alert response value in response to the trigger event occurrence. The alert response value includes at least one of an alert criterion, an alert type, an alert content, and an alert location. The data collection policy includes a vehicle data identifier configured to identify the identified vehicle data. The collection validation value indicates that the vehicle is configured to provide trigger evaluation data. The policy manager circuit is configured to encrypt the data collection policy and replace a previous data collection policy with the data collection policy in response to the collection validation value. The vehicle communication system stops execution of the data collection policy in response to at least one of an updated authorization value or an updated location value.

[0051] An exemplary apparatus includes a parameter acquisition circuit configured to interpret vehicle parameter values; a property conversion circuit configured to interpret property request values, the property request values ​​at least partially defining a requested vehicle property; and a parameter adjustment circuit configured to generate vehicle property data from the vehicle parameter values ​​in response to the property request values, the vehicle property data corresponding to the requested vehicle property.

[0052] Certain further aspects of the exemplary apparatus are described below, any one or more of which may be present in particular embodiments. The apparatus further includes a requestor verification circuit configured to determine an entity authorization value responsive to and based at least in part on the property request value; and a vehicle property providing circuit configured to transmit vehicle property data responsive to the entity authorization value. The apparatus further includes a subscription circuit configured to add the requesting entity to a subscriber data list responsive to the property request value, the vehicle property providing circuit configured to transmit the vehicle property data to the requesting entity responsive to the subscriber data list. The apparatus further includes a vehicle property providing circuit configured to transmit the vehicle property data responsive to the property request value. An integrated network device (CND) configured to regulate communications between a first network zone having a first vehicle sensor and a second network zone having a second vehicle sensor; the vehicle parameter value is generated by at least one of the first vehicle sensor and the second vehicle sensor. The parameter acquisition circuit is configured to interpret a plurality of vehicle parameter values; the parameter adjustment circuit is configured to generate vehicle property data from 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. The vehicle parameter values ​​directly correspond to the requested vehicle property. The vehicle parameter values ​​include at least one of a vehicle speed value, a prime mover speed value, a prime mover torque value, a user-actuated vehicle property value, or a vehicle position value. The vehicle parameter values ​​include at least one of a network utilization value of the vehicle network zone, 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 a controller of the vehicle, a value from an endpoint on a Controller Area Network (CAN), 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 a component temperature value, a sensor raw value, a component speed value, or an actuator feedback value. The requested vehicle properties include at least one of a driveline component speed value, a driveshaft speed value, a driveshaft torque value, a selected gear value, a battery health value, a battery state of charge value, or a battery power throughput value. The parameter adjustment circuit is configured to generate a virtual vehicle property value from two one or more vehicle parameter values ​​in response to the property request values, and the vehicle property data includes the virtual vehicle property value. The virtual vehicle property value includes at least one of a vehicle speed value, a power efficiency value, an event occurrence value, or a list of previous vehicle positions. The virtual vehicle property value includes 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 remaining life value, a component time until maintenance value, or a diagnostic counter value. The virtual vehicle property value includes at least one of a list of one or more user-activated characteristics, an average vehicle runtime value, or an estimated vehicle operating cost value. The vehicle property data is in a format different from the vehicle parameter values.

[0053] An exemplary method includes interpreting vehicle parameter values, interpreting property request values ​​that at least partially define a requested vehicle property, and generating vehicle property data corresponding to the requested vehicle property from the vehicle parameter values ​​in response to the property request values.

[0054] Certain further aspects of the exemplary method are described below, any one or more of which may be present in particular embodiments. The method further includes determining an entity authorization value in response to and based at least in part on the property request value; and transmitting vehicle property data in response to the entity authorization value. The method further includes adding the requesting entity to a subscriber data list in response to the property request value, and transmitting the vehicle property data in response to the subscriber data list. The method further includes transmitting the vehicle property data in response to the property request value. The method further includes regulating communication between a first network zone having a first vehicle sensor and a second network zone having a second vehicle sensor; and generating a vehicle parameter value by at least one of the first vehicle sensor and the second vehicle sensor. The step of interpreting the vehicle parameter value includes interpreting a plurality of vehicle parameter values, and the step of generating the vehicle property data is based at least in part on the plurality of vehicle parameter values, wherein a first vehicle parameter value of the plurality of vehicle parameter values ​​is provided from the first vehicle sensor and a second vehicle parameter value of the plurality of vehicle parameter values ​​is provided from the second vehicle sensor. The first network zone and the second network zone are of different types. The vehicle parameter value directly corresponds to the requested vehicle property. The vehicle parameter value 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 vehicle parameter value includes at least one of a network utilization value of the vehicle network zone, 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 value from an endpoint on a Controller Area Network (CAN), a value from an endpoint on a Local Interconnect Network (LIN), or an intermediate control value. The requested vehicle property includes at least one of a component temperature value, a sensor raw value, a component speed value, or an actuator feedback value.The requested vehicle properties include at least one of a driveline component speed value, a driveshaft speed value, a driveshaft torque value, a selected gear value, a battery health value, a battery state-of-charge value, or a battery power handling capability value. The parameter adjustment circuit is configured to generate virtual vehicle property values ​​from two one or more vehicle parameter values ​​in response to the property request values, and the vehicle property data includes the virtual vehicle property values. The virtual vehicle property values ​​include at least one of a vehicle speed value, a power efficiency value, an event occurrence value, 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, an average vehicle runtime value, or an estimated vehicle operating cost value. The vehicle property data is in a different format than the vehicle parameter values.

[0055] An example method includes the steps of: interpreting, at a first vehicle, a first property request value that at least partially defines a requested vehicle property; generating, at the first vehicle and in response to the first property request value, first vehicle property data corresponding to the requested vehicle property from a first plurality of vehicle parameter values ​​of the first vehicle; interpreting, at a second vehicle, a second property request value that corresponds to the requested vehicle property; and generating, at the second vehicle, second vehicle property data corresponding to the requested vehicle property from a second plurality of vehicle parameter values ​​of the second vehicle in response to the second property request value.

[0056] Certain additional aspects of the exemplary method are described below, any one or more of which may be present in certain embodiments. The first vehicle property data and the second vehicle property data are substantially the same. The first property request value and the second property request 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, where the first vehicle sensor is located on a first network on the first vehicle and the second vehicle sensor is located on a second network on the first vehicle, the first network being a different type than the second network, and generating a second plurality of vehicle parameter values ​​via a third vehicle sensor and a fourth vehicle sensor, where the third vehicle sensor is located on a third network on the second vehicle and the fourth vehicle sensor is located on a fourth network on the second vehicle, the third network being a different type than the fourth network, and at least one of the first and second networks being 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 in a first vehicle, and generating a second plurality of vehicle parameter values ​​via a second vehicle sensor located on a second network in a second vehicle, the second network being of a different type than the first network.

[0057] An exemplary apparatus includes a policy acquisition circuit configured to interpret a vehicle policy data value comprising at least a portion of a vehicle policy; a policy processing circuit configured to generate parsed policy data in response to and based at least in part on the vehicle policy data value, the parsed policy data comprising one or more vehicle sub-policies of the vehicle policy; and a policy execution circuit configured to collect vehicle data from one or more vehicle sensors in response to the parsed policy data.

[0058] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in particular embodiments. The policy processing circuit 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 circuit is further configured to passively collect vehicle data in response to the type value being a passive policy. The policy enforcement circuit is further configured to actively collect vehicle data in response to the type value being an active policy. The policy enforcement circuit is further configured to send a collection start command value for actively collecting vehicle data. The policy enforcement circuit is further configured to generate a vehicle property value for actively collecting vehicle data based at least in part on the collected vehicle data. The policy enforcement circuit is further configured to send a query value for actively collecting vehicle data. The apparatus further includes a memory device configured to store the collected vehicle data. The apparatus further includes an integration network device (CND) configured to regulate communication between a first network zone and a second network zone, the first network zone having a first vehicle sensor among the one or more vehicle sensors, and the second network zone having a second vehicle sensor among the one or more vehicle sensors. The first network zone and the second network zone are of different types. The policy enforcement circuit is further configured to delegate collection of vehicle data to 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 a collected data acquisition circuit configured to interpret vehicle data collected by the one or more vehicle controllers. The apparatus further includes a collected data provision circuit configured to transmit the collected vehicle data.

[0059] An exemplary method includes interpreting vehicle policy data values ​​comprising at least a portion of a vehicle policy; generating parsed policy data in response to and based at least in part on the vehicle policy data values, the parsed policy data comprising one or more vehicle sub-policies of the vehicle policy; and collecting vehicle data from one or more vehicle sensors in response to the parsed policy data.

[0060] Certain further aspects of the exemplary method are described below, any one or more of which may be present in certain embodiments. The method further includes determining 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 collecting vehicle data step includes passively collecting vehicle data according to the type value. The collecting vehicle data step includes actively collecting vehicle data according to the type value. The actively collecting vehicle data step includes sending a collection start command value. The actively collecting vehicle data step includes generating a vehicle property value based at least in part on the collected vehicle data. The actively collecting vehicle data step includes sending a query value. The method further includes regulating communication between a first network zone and a second network zone, the first network zone having a first vehicle sensor of the one or more vehicle sensors, and the second network zone having a second vehicle sensor of the one or more vehicle sensors. The first network zone and the second network zone are of different types. Collecting the vehicle data includes delegating collection of the vehicle data to one or more vehicle controllers via transmitting at least a portion of the parsed policy data to the one or more vehicle controllers. The method further includes interpreting the collected vehicle data by the one or more vehicle controllers. The method further includes transmitting the collected vehicle data.

[0061] An example apparatus includes an integration network device (CND) configured to regulate communications 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 parameter values ​​are generated by the first network endpoint and the second network endpoint; a parameter acquisition circuit configured to interpret the plurality of vehicle parameter values; a property conversion circuit configured to interpret property request values ​​including at least a portion of a requested vehicle property; and a parameter adjustment circuit configured to generate vehicle property data from the plurality of vehicle parameter values ​​in response to the property request values, wherein the vehicle property data corresponds to the requested vehicle property.

[0062] Certain additional aspects of the exemplary device are described below, any one or more of which may be present in certain embodiments. The device 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. The first network zone includes a controller area network (CAN). The first and second network endpoints are vehicle sensors. The plurality of vehicle parameter values ​​directly correspond to the requested vehicle property. The plurality of vehicle parameter values ​​include 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 ​​include at least one of a network utilization value of the vehicle network zone, 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 a controller of the vehicle, a value from an endpoint on the controller area network (CAN), a value from an endpoint on the local interconnect network (LIN), or an intermediate control value. The requested vehicle property includes at least one of a component temperature value, a sensor raw value, a component speed value, or an actuator feedback value. The requested vehicle property includes at least one of a driveline component speed value, a driveshaft speed value, a driveshaft torque value, a selected gear value, a battery health value, a battery state-of-charge value, or a battery power throughput value. The parameter adjustment circuit is configured to generate a virtual vehicle property value from two one or more vehicle parameter values ​​in response to the property request values, and the vehicle property data includes the virtual vehicle property value. The virtual vehicle property value includes at least one of a vehicle speed value, a power efficiency value, an event occurrence value, or a list of previous vehicle locations. The apparatus of claim 288, wherein the virtual vehicle property value includes 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. The vehicle property data is in a different format than the plurality of vehicle parameter values.

[0063] An exemplary method includes the steps of regulating 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 parameter values ​​are generated by the first network endpoint and the second network endpoint; interpreting the plurality of vehicle parameter values; interpreting a property request value that at least partially defines a requested vehicle property; and generating vehicle property data corresponding to the requested vehicle property from the plurality of vehicle parameter values ​​in response to the property request value.

[0064] Certain further aspects of the exemplary method are described below, any one or more of which may be present in certain embodiments. The method further includes transmitting vehicle property data. The first network zone and the second network zone are distinct types. The first network zone includes a controller area network (CAN). The first network endpoint and the second network endpoint are vehicle sensors. The plurality of vehicle parameter values ​​directly correspond to the requested vehicle properties. The plurality of vehicle parameter values ​​include 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 ​​include at least one of a network utilization value of the vehicle network zone, 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 a controller of the vehicle, a value from an endpoint on the controller area network (CAN), a value from an endpoint on the local interconnect network (LIN), or an intermediate control value. The requested vehicle properties include at least one of a component temperature value, a sensor raw value, a component speed value, and an actuator feedback value. The requested vehicle properties include at least one of a driveline component speed value, a driveshaft speed value, a driveshaft torque value, a selected gear value, a battery health value, a battery state-of-charge value, or a battery power handling capability value. The parameter adjustment circuit is configured to generate a virtual vehicle property value from two one or more vehicle parameter values ​​in response to the property request values, and the vehicle property data includes the virtual vehicle property value. The virtual vehicle property value includes at least one of a vehicle speed value, a power efficiency value, an event occurrence value, or a list of previous vehicle positions. The virtual vehicle property value includes 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. The vehicle property data is in a different format than the plurality of vehicle parameter values.

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

[0066] Certain further aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The modified vehicle parameter data includes a virtual vehicle property value. The virtual vehicle property value is based at least in part on two or more vehicle parameter values. The parameter adjustment circuit includes a formatting circuit configured to format the vehicle parameter value into a desired format for 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 a network protocol. The desired format is based at least in part on storage of the vehicle parameter value on a non-transitory computer-readable medium. The desired format is based at least in part on a compression standard. The parameter adjustment circuit includes a unit conversion circuit configured to convert one or more units of the vehicle parameter value into one or more desired units of the requested vehicle property such that the modified vehicle parameter data has the desired one or more units. The parameter adjustment circuit includes a sampling circuit configured to adjust a sampling rate of the vehicle parameter value to a desired sampling rate for the requested vehicle property such that the modified vehicle parameter data has the desired sampling rate. The sampling circuit is configured to upsample the vehicle parameter value. The sampling circuit is configured to down-sample the vehicle parameter value.

[0067] An exemplary method includes interpreting vehicle parameter values, interpreting property request values ​​that at least partially define a requested vehicle property, and generating modified vehicle parameter data corresponding to the requested vehicle property from the vehicle parameter values ​​in response to the property request values.

[0068] Certain additional aspects of the exemplary method are described below, any one or more of which may be present in certain embodiments. Generating 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 a desired format for the requested vehicle property such that the modified vehicle parameter data has the desired format. Formatting the vehicle parameter values ​​includes generating a network protocol packet configured to transmit the vehicle parameter values. Formatting the vehicle parameter values ​​includes modifying the vehicle parameter values ​​for storage on a non-transitory computer-readable medium. Modifying the vehicle parameter values ​​includes compressing the vehicle parameter values. The method further includes converting one or more units of the vehicle parameter values ​​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. The method further includes adjusting a sampling rate of the vehicle parameter values ​​to a 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.

[0069] An exemplary apparatus includes a parameter acquisition circuit configured to interpret a plurality of vehicle parameter values; a parameter adjustment circuit configured to adjust the plurality of vehicle parameter values ​​for storage in one or more cache devices; and a parameter storage circuit configured to store the adjusted plurality of vehicle parameter values ​​in the one or more cache devices.

[0070] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. The parameter adjustment circuit is further configured to determine a storage location value, the parameter storage circuit is further configured to store a plurality of adjusted vehicle parameter values ​​according to the storage location value, and the one or more cache devices are onboard the vehicle. Each of the one or more cache devices onboard the vehicle is associated with a controller that is different from the controllers associated with others of the one or more cache devices. The parameter adjustment circuit is further configured to determine a storage location value, the parameter storage circuit is further configured to store a plurality of adjusted vehicle parameter values ​​according to the storage location value, and the one or more cache devices are located off-board the vehicle. The 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 store a first portion of the adjusted plurality of vehicle parameter values ​​on a first cache device of the one or more cache devices and a second portion of the adjusted plurality of vehicle parameter values ​​on a second cache device of the one or more cache devices in response to the storage location value; the first cache device is mounted on the 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. The parameter storage circuit is further configured to transmit the expiration value to the one or more cache devices. The parameter storage circuit is further configured to selectively expire the plurality of vehicle parameter values ​​in response to the expiration value. The expiration value is a time value corresponding to a time period for storing the plurality of vehicle parameter values ​​in the one or more caches.The apparatus further includes a policy retrieval circuit configured to interpret vehicle policy data values ​​including at least a portion of a vehicle policy, and the parameter adjustment circuit is further configured to generate an expiration value in response to the vehicle policy data values. The parameter adjustment circuit is further configured to determine type values ​​of the plurality of vehicle parameter values ​​and generate an expiration value in response to the type values. The type values ​​correspond to at least one of engine data, control data, mission critical data, driving status data, or driving operation data. The type values ​​correspond to at least one of vehicle status values, vehicle mode values, diagnostic values, or fault values. 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 plurality of vehicle parameter values ​​via summarizing the plurality of vehicle parameter values.

[0071] An exemplary method includes steps of interpreting a plurality of vehicle parameter values, adjusting the plurality of vehicle parameter values ​​for storage in one or more cache devices, and storing the adjusted plurality of vehicle parameter values ​​in the one or more cache devices.

[0072] Certain additional aspects of the exemplary method are described below, any one or more of which may be present in certain embodiments. 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 onboard the vehicle. Each of the one or more cache devices onboard the vehicle is associated with a controller that is different from controllers associated with others 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, and wherein the one or more cache devices are located external to the vehicle. The one or more cache devices are based at least in part on a network cloud-based storage system. The method further includes determining a storage location value, wherein storing the adjusted vehicle parameter values ​​includes storing a first portion of the adjusted vehicle parameter values ​​in a first cache device of the one or more cache devices in response to the storage location value, and storing a second portion of the adjusted vehicle parameter values ​​in a second cache device of the one or more cache devices, wherein the first cache device is onboard the vehicle and the second cache device is located outside the vehicle. The method further includes generating expiration values ​​for the vehicle parameter values ​​configured to trigger selective expiration of the vehicle parameter values ​​in the one or more cache devices. The method of claim 350 further includes transmitting the expiration values ​​to the one or more cache devices. The method further includes selectively expiring the vehicle parameter values ​​in response to the expiration value. The expiration value is a time value corresponding to a time period for storing the vehicle parameter values ​​in the one or more caches. The method further includes interpreting a vehicle policy data value comprising at least a portion of a vehicle policy, wherein generating the expiration values ​​for the 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. Generating an expiration value for the plurality of vehicle parameter values ​​is responsive to the type value. The type value corresponds to at least one of engine data, position data, cabin 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.

[0073] An exemplary vehicle includes a vehicle communication system including: a policy manager circuit configured to interpret a data collection policy including a trigger condition, a vehicle data identifier configured to identify vehicle data to be captured in response to the occurrence of a trigger event, and a trigger evaluation data identifier configured to identify trigger evaluation data to be captured in response to the trigger condition; and an endpoint configured 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.

[0074] Certain further aspects of the exemplary vehicle 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 in response to a trigger evaluation data identifier and provide a trigger evaluation data stream. The filtering circuit is configured to determine the identified vehicle data stream in response to the vehicle data identifier. A vehicle data processing circuit configured to perform at least one of sampling the trigger evaluation data stream in response to sampling parameters of a data collection policy, normalizing a trigger evaluation data value format, or determining trigger evaluation data aggregation parameters in response to a plurality of trigger conditions of the data collection policy. 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 the trigger condition. The rotating buffer circuit is configured to store a second rotating time window of the identified vehicle data stream in response to the 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 the trigger condition, and the trigger evaluation circuit is configured to determine the occurrence of a trigger event in response to evaluating the trigger condition using the first rotating time window. a vehicle data storage circuit configured to store identified vehicle data from the identified vehicle data stream in response to a trigger event occurrence and a data collection policy, at least some of the identified vehicle data occurring before the trigger event occurs; a cloud interface configured to provide the identified vehicle data from the identified vehicle data stream in response to the trigger event occurrence and a transmission parameter value of the data collection policy; and a cloud interface configured to provide an alert response value in response to the trigger event occurrence, the alert response value including at least one of alert criteria, alert type, alert content, and alert location.The trigger evaluation circuitry is configured to simultaneously evaluate multiple trigger conditions of the data collection policy, and the trigger evaluation circuitry is configured to determine an occurrence of a trigger event as a function of the multiple trigger conditions.

[0075] An exemplary method includes operating a vehicle including a vehicle communication system including a policy manager circuit and an endpoint; interpreting, at the policy manager circuit, a data collection policy including a trigger condition, a vehicle data identifier configured to identify vehicle data to be captured in response to the occurrence of a trigger event, and a trigger evaluation data identifier configured to identify trigger evaluation data to be captured in response to the trigger condition; and providing, at the endpoint, a raw vehicle data stream including the trigger evaluation data stream and the identified vehicle data stream in response to the data collection policy.

[0076] Certain further aspects of the exemplary method are described below, any one or more of which may be present in certain embodiments. The vehicle communication system includes a filtering circuit, and the method includes determining, in the filtering circuit, a trigger evaluation data stream of the raw vehicle data stream in response to a trigger evaluation data identifier. Determining, in the filtering circuit, an identified vehicle data stream in response to the vehicle data identifier. The vehicle communication system includes a vehicle data processing circuit, and the method includes processing trigger evaluation data including at least one of sampling the trigger evaluation data stream in response to sampling parameters of a data collection policy, normalizing a trigger evaluation data value format, or determining trigger evaluation data aggregation parameters in response to a plurality of trigger conditions of the data collection policy. The vehicle communication system includes a rotating buffer circuit, and the method includes determining, in the rotating buffer circuit, a rotating time window in response to the trigger conditions and storing, in the rotating buffer circuit, the rotating time window of the trigger evaluation data. The rotating buffer circuit is configured to store a second rotating time window of the identified vehicle data stream in response to the data collection policy. The vehicle communication system includes a rotating buffer circuit and a trigger evaluation circuit, and the method includes storing, in the rotating buffer circuit, a first rotating time window of the trigger evaluation data stream in response to a trigger condition, and determining, in the trigger evaluation circuit, an occurrence of a trigger event in response to evaluating the trigger condition using the first rotating time window.The vehicle communication system includes a vehicle data storage circuit, and the method includes storing, in the vehicle data storage circuit, identified vehicle data of the identified vehicle data stream in response to the occurrence of the trigger event and a data collection policy, at least some of the identified vehicle data occurring before the occurrence of the trigger event.The vehicle communication system includes a cloud interface, and the method includes providing, at the cloud interface, the identified vehicle data of the identified vehicle data stream in response to the occurrence of the trigger event and a transmission parameter value of the data collection policy.The vehicle communication system includes a cloud interface, and the method includes providing, at the cloud interface, an alert response value in response to an occurrence of a trigger event, the alert response value including at least one of an alert criterion, an alert type, an alert content, and an 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 the occurrence of the trigger event in response to the multiple trigger conditions.

[0077] The exemplary vehicle includes a policy manager circuit configured to interpret a data collection policy including a trigger condition and a trigger evaluation data identifier, an endpoint configured to capture a trigger evaluation data stream in response to the trigger evaluation data identifier and the trigger condition, and a vehicle data interface configured to receive the trigger evaluation data stream.

[0078] Certain further aspects of the exemplary vehicle 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 configured to capture a plurality of trigger evaluation data values ​​of trigger evaluation data in response to a data collection policy. The endpoints are communicatively coupled to a plurality of networks configured to communicate using a plurality of communication protocols, and the endpoints are configured to capture a plurality of trigger evaluation data values ​​of trigger evaluation data from the plurality of networks in response to the data collection policy. 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 corresponding to a plurality of data types including at least two of a Controller Area Network (CAN) message, a CAN signal, an Ethernet packet, a vehicle location, a vehicle status, and a diagnostic trouble code. Capturing the trigger evaluation data stream includes at least one of receiving the trigger evaluation data stream from a data source communicatively coupled to the endpoint or requesting the trigger evaluation data stream from a data source communicatively coupled to the endpoint.

[0079] 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 state, and a trigger evaluation circuit configured to determine a trigger event occurrence according to the trigger state and trigger evaluation data, determine a trigger event termination, determine a data capture window according to the trigger event occurrence, the trigger event termination and the data collection policy, and capture identified vehicle data according to the data capture window and the vehicle data identifier.

[0080] Certain additional aspects of the exemplary vehicle are described below, any one or more of which may be present in certain embodiments. The trigger evaluation circuit determines the occurrence of a trigger event by evaluating trigger evaluation data with trigger conditions, where the trigger conditions define a relationship to a current value that may or may not be satisfied by the trigger evaluation data. The evaluation data includes at least one of a vehicle state, a vehicle status, a vehicle operating mode, or a vehicle discrete event. The identified vehicle data is generated by the vehicle before the trigger event occurs 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. The trigger evaluation circuit determines the occurrence of a trigger event in response to at least two of the plurality of trigger conditions. The plurality of trigger evaluation data values ​​correspond to a plurality of data types, including at least two of a Controller Area Network (CAN) message, a CAN signal, an Ethernet packet, a vehicle position, a vehicle status, and a diagnostic trouble code. The trigger evaluation data includes a virtual sensor value derived from the plurality of vehicle data values. The data capture window ends after a delay following the end of the event trigger in response to the data collection policy. The data collection policy includes a plurality of trigger conditions having a plurality of trigger types, the plurality of trigger types including at least two of a traffic light trigger, a vehicle status trigger, a timing trigger, a schedule trigger, a geofence trigger, an error trigger, an environmental trigger, or a user input trigger. The step of determining an occurrence of a trigger event is based on a first portion of the plurality of trigger conditions, the first portion including a first trigger having the first trigger type and a second trigger having the second trigger type. The step of determining an end of the trigger event is based on a second portion of the plurality of triggers, the second portion including the first trigger having the first trigger type and the second trigger having the second trigger type.

[0081] The exemplary apparatus includes a policy retrieval circuit configured to interpret a data collection policy including at least one requested vehicle property; a policy processing circuit configured to determine a property request value in response to the at least one requested vehicle property; a parameter retrieval circuit configured to interpret at least one vehicle parameter value in response to the property request value; and a parameter provision circuit configured to selectively transmit the at least one vehicle parameter value in response to the data collection policy.

[0082] Certain additional aspects of the exemplary apparatus are described below, any one or more of which may be present in certain embodiments. 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 accordance with 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 the data collection operation. The policy type includes an on-demand policy, and the parameter acquisition circuit is further configured to stop evaluating the data collection policy for the data collection operation in response to 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 ceasing evaluation of the data collection policy. The policy acquisition circuit is further configured to delete the data collection policy in response to the parameter providing circuit transmitting at least one vehicle parameter value corresponding to the data collection policy. The policy type includes at least one type selected from the group consisting of a downloaded policy, a factory policy, and a built-in policy. The policy acquisition circuit is further configured to implement a downloaded policy, if present. The policy acquisition circuit is further configured to ignore the factory policy and the built-in policy in response to the downloaded policy. The policy acquisition circuit is further configured to implement a matching portion of the factory policy, if present. The policy acquisition circuit is further configured to implement a matching portion of the factory policy, if present and if a downloaded policy is not present. The policy acquisition circuit is further configured to ignore the built-in policy. The policy acquisition circuit is further configured to implement a matching portion of the built-in policy, if present. The data collection policy further includes a transmission description value corresponding to at least one requested vehicle property. The transmission description value includes at least one value selected from values ​​consisting of a transmission priority value, a data storage description, a network zone utilization description, or an access point name (APN) value.The data collection policy further includes a data configuration value, and the policy processing circuit is further configured to determine a property request value in response to the data configuration value. The data collection policy further includes a trigger data description. The data collection policy further includes a policy priority value. The policy priority value includes at least one priority value selected from the group 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 circuit is further configured to selectively enable the data collection policy in response to the policy lifecycle description. The policy lifecycle description includes at least one description selected from the group consisting of a policy start time; a policy end time; a trigger data description including a collection criteria value for the data collection policy; an amount of data to be captured under the data collection policy; a number of data collection events to be captured under the data collection policy; or a number of trigger events for which data is to be captured under the data collection policy.

[0083] An exemplary cloud system includes: a request interface configured to interpret a plurality of response action values ​​from an external device; a policy creator circuit configured to determine a data collection policy in response to the plurality of response action values, the data collection policy including a vehicle data identifier; a cloud interface configured to receive identified vehicle data in response to the data collection policy; and a raw data manager circuit configured to store at least a portion of the received identified vehicle data, the at least a portion of the identified vehicle data including response vehicle data and identification data, wherein the request interface 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.

[0084] Certain additional aspects of the exemplary cloud system are described below, any one or more of which may be present in certain embodiments. The responsive vehicle data is encrypted using a first encryption key set and the identification data is encrypted using a second encryption key set. The request interface is further configured to obtain at least a portion of the responsive vehicle data using at least one key of the second encryption key set. No keys of the first encryption key set are stored on the cloud system. The identification data includes metadata specific to the plurality of responsive operation values.

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

[0086] Certain additional aspects of the exemplary cloud system are described below, any one or more of which may be present in particular embodiments. The raw data manager circuit is further configured to determine the requested portion of the stored collected data in response to comparing the identification portion to the vehicle data request 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.

[0087] An exemplary system includes a collected vehicle data storage circuit configured to store collected data from the vehicle; an external data collection interface configured to selectively provide vehicle data collection requests from an external device to the vehicle and to selectively provide at least a portion of the stored collected data from the collected vehicle data storage circuit in response to the vehicle data request from the external device; and means for separating at least a portion of the stored collected data and an encryption key for at least a portion of the stored collected data.

[0088] Certain further aspects of the exemplary system 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 vehicle data collection requests to the vehicle by providing the vehicle data collection requests to the collection vehicle data storage circuitry.

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

[0090] Certain additional aspects of the exemplary cloud system are described below, any one or more of which may be present in particular embodiments. The request interface is further configured to expose an application programming interface (API) to the external device and to interpret the vehicle data collection request in response to invocation of the API. The request interface is further configured to interpret the vehicle data request from the external device in response to invocation of the API, 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. The request interface is further configured to interpret the 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. 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 further configured to determine a data collection policy in response to the vehicle data collection request and the at least one additional vehicle data collection request. The policy creator circuit is further configured to determine a policy capability value in response to the vehicle data collection request and to selectively enable the determination of the data collection policy in response to the policy capability value. The policy creator circuitry is further configured to determine a policy capacity value in response to at least one parameter selected from the group consisting of 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 a data configuration value associated with the vehicle data collection request. The cloud system is further configured for the policy creator circuitry to determine the policy capacity value in response to the vehicle data collection request and the at least one additional vehicle data collection request, and to selectively enable at least one of determining a data collection policy or including at least one of the vehicle data collection request or the at least one additional vehicle data collection request in response to the policy capacity value.The policy creator circuitry is further configured to determine a policy capability value in response to at least one parameter selected from the group consisting of: a data storage size determined to support each of the vehicle data collection request and the at least one additional vehicle data collection request, a transmission volume value determined to support each of the vehicle data collection request and the at least one additional vehicle data collection request, a data availability value associated with each of the vehicle data collection request and the at least one additional vehicle data collection request, a data configuration value for each of the vehicle data collection request and the at least one additional vehicle data collection request, or a determination of a priority between the vehicle data collection request and the at least one additional vehicle data collection request. The cloud system is further configured for the policy creator circuitry to determine a policy authorization value in response to the vehicle data collection request, and to perform at least one operation selected from the group consisting of selectively enabling determination of a data collection policy or determining a data collection policy to support at least a portion of the vehicle data collection requests in response to the policy authorization value. 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 to determine the vehicle data collection request in response to a response from the user interface to the provided at least one use case value. The request interface is further configured to determine the at least one use case value in response to at least one of an entity type associated with the user interface, a permission value associated with the user interface, and a previous data collection policy determined for a user having the shared characteristic determined for the user interface.

[0091] An exemplary system includes: a policy manager configured to interpret at least two policy requests, each of the policy requests including a data collection description, the policy manager further configured to compile a policy according to a superset of data collection values ​​corresponding to each of the data collection descriptions; a data collection controller located on a vehicle and communicatively coupled to the policy manager, the data collection controller configured to collect data from at least two vehicle networks on the vehicle according to the policy; a data communication component communicatively coupled to the data collection controller, the data communication component configured to receive at least a portion of the collected data from the data collection controller and store at least a portion of the collected data in a data store; and a data request component communicatively coupled to the data communication component and a requesting application, the data request 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.

[0092] Certain additional aspects of the exemplary system are described below, any one or more of which may be present in particular embodiments. 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 before storing the at least a portion of the collected data. The data request component is further configured to decrypt the requested data with a master private key and detokenize the requested data, optionally before 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 to interpret at least one of the at least two policy requests in response to interaction with the user interface. The policy manager is further configured to interpret a use case value selection in response to interaction with the user interface and to interpret at least one of the at least two policy requests in response to interaction with the user interface in response to the use case value selection. The policy manager is further configured to provide at least two use case options to the user interface and to interpret a user case value selection in response to selection via the user interface of at least one of the at least two use case options. [Brief explanation of the drawings]

[0093] [Figure 1] FIG. 1 is a schematic diagram of an exemplary data collection system in accordance with certain embodiments of the present disclosure. [Figure 2] 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. [Figure 3] 1 is a schematic diagram of an exemplary off-vehicle device according to certain embodiments of the present disclosure. [Figure 4] FIG. 1 is a diagram of an exemplary internal and / or external application in accordance with certain embodiments of the present disclosure. [Figure 5A] FIG. 1 is a schematic diagram of an exemplary vehicle network infrastructure for a vehicle in accordance with certain embodiments of the present disclosure. [Figure 5B] FIG. 1 is a schematic diagram of an exemplary vehicle network infrastructure for a vehicle in accordance with certain embodiments of the present disclosure. [Figure 6] FIG. 2 is a schematic diagram of an exemplary edge gateway in accordance with certain embodiments of the present disclosure. [Figure 7] FIG. 1 is a schematic diagram of an exemplary Ethernet switch in accordance with certain embodiments of the present disclosure. [Figure 8] FIG. 1 is a schematic diagram of an exemplary Ethernet device in accordance with certain embodiments of the present disclosure. [Figure 9] FIG. 1 is a schematic diagram of an exemplary user consent controller in accordance with certain embodiments of the present disclosure. [Figure 10] FIG. 1 is a schematic diagram of an exemplary data collection controller in accordance with certain embodiments of the present disclosure. [Figure 11] FIG. 2 is a schematic diagram of an exemplary first partition according to certain embodiments of the present disclosure. [Figure 12] FIG. 2 is a schematic diagram of an exemplary second partition according to certain embodiments of the present disclosure. [Figure 13] FIG. 1 is a schematic diagram of an exemplary data collection system in accordance with certain embodiments of the present disclosure. [Figure 14] FIG. 2 is a schematic diagram of an exemplary automation manager in accordance with certain embodiments of the present disclosure. [Figure 15] 1 is a schematic diagram of an example implementation for an integrated IDS manager (ECU) according to certain embodiments of the present disclosure. [Figure 16] FIG. 2 is a schematic diagram of an exemplary shared storage controller in accordance with certain embodiments of the present disclosure. [Figure 17] FIG. 2 is a schematic diagram of another exemplary data collection system in accordance with certain embodiments of the present disclosure. [Figure 18] FIG. 1 is a diagram of an exemplary workflow according to certain embodiments of the present disclosure. [Figure 19] FIG. 1 is a schematic diagram of an exemplary containerized application environment in accordance with certain embodiments of the present disclosure. [Figure 20]FIG. 1 is a schematic diagram of an exemplary architecture implementation for a container-based application on a vehicle, in accordance with certain embodiments of the present disclosure. [Figure 21] FIG. 1 is a schematic diagram of another example architecture implementation for container-based applications on vehicles, in accordance with certain embodiments of the present disclosure. [Figure 22] 2 is a schematic diagram of an exemplary detail of a container according to certain embodiments of the present disclosure; [Figure 23] FIG. 1 is a diagram of a container networking implementation in accordance with certain embodiments of the present disclosure. [Figure 24] FIG. 2 is a diagram of an example AUTOSAR adaptive function state group in accordance with certain embodiments of the present disclosure. [Figure 25] FIG. 2 is a schematic diagram of an exemplary functional flow for enforcing container policies, in accordance with certain embodiments of the present disclosure. [Figure 26] FIG. 2 is a schematic diagram of an example implementation of a container manager in accordance with certain embodiments of the present disclosure. [Figure 27] FIG. 1 is a schematic diagram of an exemplary apparatus for implementing driver behavior and / or monitoring based policies for a vehicle, in accordance with certain embodiments of the present disclosure. [Figure 28] FIG. 2 is a schematic diagram of an exemplary driver information description according to certain embodiments of the present disclosure. [Figure 29] 10 is a flowchart illustrating an exemplary procedure for collecting data in response to a driver information description according to certain embodiments of the present disclosure. [Figure 30] 10 is a flowchart illustrating an example procedure for performing collection operations as a function of vehicle policy data values ​​and / or driver information descriptions according to certain embodiments of the present disclosure. [Figure 31] FIG. 1 is a schematic diagram of an exemplary apparatus for providing data collection operations as a function of vehicle policy data values ​​in accordance with certain embodiments of the present disclosure. [Figure 32] FIG. 2 is a schematic diagram of an exemplary surveillance data description in accordance with certain embodiments of the present disclosure. [Figure 33]1 is a flowchart illustrating an example procedure for implementing policies in response to fault and / or diagnostic values ​​for devices in a vehicle system, in accordance with certain embodiments of the present disclosure. [Figure 34] FIG. 1 is a schematic diagram of an exemplary apparatus for providing data collection operations as a function of vehicle policy data values, in accordance with certain embodiments of the present disclosure. [Figure 35] FIG. 1 is a schematic diagram of an exemplary endpoint performance description, according to certain embodiments of the present disclosure. [Figure 36] 1 is a flowchart illustrating an exemplary procedure for performing operations for adjusting data collection according to endpoint performance descriptions, in accordance with certain embodiments of the present disclosure. [Figure 37] 1 is a schematic diagram of an exemplary apparatus for providing data collection operations as a function of location description values ​​in accordance with certain embodiments of the present disclosure. [Figure 38] 1 is a schematic diagram of exemplary location descriptors according to certain embodiments of the present disclosure; [Figure 39] 10 is a flowchart illustrating an exemplary procedure for adjusting data collection as a function of location description values, according to certain embodiments of the present disclosure. [Figure 40] FIG. 10 is a diagram of exemplary operations involving adjusting the collection of vehicle data as a function of location description values, according to certain embodiments of the present disclosure. [Figure 41] FIG. 1 is a diagram of exemplary operations including initiation of vehicle data collection according to certain embodiments of the present disclosure. [Figure 42] FIG. 10 is a diagram of example operations including operations for preventing collection of vehicle data according to certain embodiments of the present disclosure. [Figure 43] FIG. 10 is a diagram of example operations involving adding or modifying metadata of collected vehicle data in accordance with certain embodiments of the present disclosure. [Figure 44] FIG. 10 is a diagram of example operations including adjusting priority values ​​of at least a portion of collected vehicle data according to certain embodiments of the present disclosure. [Figure 45] FIG. 1 is a schematic diagram of an exemplary apparatus for data collection operations in accordance with certain embodiments of the present disclosure. [Figure 46] FIG. 2 is a schematic diagram of exemplary vehicle status data in accordance with certain embodiments of the present disclosure. [Figure 47] 10 is a flowchart illustrating an exemplary procedure for scheduling data collection according to data type of the collected data, in accordance with certain embodiments of the present disclosure. [Figure 48] FIG. 1 is a schematic diagram of exemplary operations including operations for coordinating the collection of vehicle data according to certain embodiments of the present disclosure. [Figure 49] FIG. 1 is a schematic diagram of exemplary operations including operations for initiating collection of vehicle data according to certain embodiments of the present disclosure. [Figure 50] FIG. 1 is a schematic diagram of example operations including operations for preventing collection of vehicle data according to certain embodiments of the present disclosure. [Figure 51] 1 is a schematic diagram of exemplary operations including operations for adding and / or modifying metadata of collected vehicle data in accordance with certain embodiments of the present disclosure. [Figure 52] FIG. 10 is a schematic diagram of example operations including operations for adjusting priority values ​​of collected vehicle data according to certain embodiments of the present disclosure. [Figure 53] 10 is a flowchart illustrating an exemplary procedure for scheduling data collection according to data type of the collected data, in accordance with certain embodiments of the present disclosure. [Figure 54] FIG. 10 is a schematic diagram of example operations including determining a data type based on a providing endpoint of collected data, in accordance with certain embodiments of the present disclosure. [Figure 55] FIG. 10 is a schematic diagram of example operations including determining a data type based on a request endpoint for collected data, in accordance with certain embodiments of the present disclosure. [Figure 56] 1 is a schematic diagram of example operations including determining a data type based on a request entity for collected data, according to certain embodiments of the present disclosure. [Figure 57]FIG. 10 is a schematic diagram of example operations including determining a data type based on an application associated with an endpoint providing collected data, in accordance with certain embodiments of the present disclosure. [Figure 58] FIG. 10 is a schematic diagram of example operations including determining a data type based on a flow associated with an endpoint requesting collected data, in accordance with certain embodiments of the present disclosure. [Figure 59] FIG. 10 is a schematic diagram of example operations including determining a data type based on a flow associated with an endpoint providing collected data, in accordance with certain embodiments of the present disclosure. [Figure 60] FIG. 10 is a schematic diagram of example 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. [Figure 61] 10 is a schematic diagram of example operations including determining a data type based on a data type indicated in a policy, according to certain embodiments of the present disclosure. [Figure 62] FIG. 2 is a schematic diagram of exemplary collected data priority values, in accordance with certain embodiments of the present disclosure. [Figure 63] FIG. 2 is a schematic diagram of an exemplary in-vehicle data storage priority according to certain embodiments of the present disclosure. [Figure 64] FIG. 2 is a schematic diagram of exemplary transmission priorities according to certain embodiments of the present disclosure. [Figure 65] FIG. 2 is a schematic diagram of an exemplary in-vehicle transmission priority according to certain embodiments of the present disclosure. [Figure 66] 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. [Figure 67] 4 is a flowchart illustrating an exemplary procedure for dynamically configuring data collection for a vehicle according to certain embodiments of the present disclosure. [Figure 68] 4 is a flowchart illustrating an exemplary procedure for determining a vehicle status data collection change value according to certain embodiments of the present disclosure. [Figure 69]1 is a flowchart illustrating an exemplary procedure including operations for determining an event occurrence and determining a vehicle status data collection change in response to the event occurrence, according to certain embodiments of the present disclosure. [Figure 70] 4 is a flowchart illustrating an exemplary procedure including operations for determining a location description value and determining a vehicle status data collection change value, according to certain embodiments of the present disclosure. [Figure 71] FIG. 1 is a schematic diagram of exemplary operations including coordinating the collection of vehicle data in accordance with certain embodiments of the present disclosure. [Figure 72] FIG. 1 is a schematic diagram of exemplary operations including initiation of vehicle data collection according to certain embodiments of the present disclosure. [Figure 73] FIG. 1 is a schematic diagram of exemplary operations involving prevention of vehicle data collection according to certain embodiments of the present disclosure. [Figure 74] FIG. 1 is a schematic diagram of example operations involving adding and / or modifying metadata of collected vehicle data according to certain embodiments of the present disclosure. [Figure 75] FIG. 10 is a schematic diagram of example operations involving adjusting priority values ​​of collected vehicle data according to certain embodiments of the present disclosure. [Figure 76] FIG. 1 is a schematic diagram of example operations involving coordinating transmission of collected vehicle data according to certain embodiments of the present disclosure. [Figure 77] FIG. 1 is a schematic diagram of example operations including coordinating data storage of collected vehicle data according to certain embodiments of the present disclosure. [Figure 78] FIG. 1 is a schematic diagram of example operations involving coordinating formatting and / or processing of collected vehicle data according to certain embodiments of the present disclosure. [Figure 79] 4 is a flowchart illustrating an exemplary procedure for dynamically configuring data collection for a vehicle according to certain embodiments of the present disclosure. [Figure 80] 1 is a schematic diagram of an example operation involving determining an event occurrence as a function of failure data, in accordance with certain embodiments of the present disclosure. [Figure 81]1 is a schematic diagram of example operations involving determining an event occurrence according to certain embodiments of the present disclosure. [Figure 82] 1 is a schematic diagram of example operations involving determining an event occurrence according to certain embodiments of the present disclosure. [Figure 83] 1 is a schematic diagram of example operations including monitoring trigger evaluation data and determining an event occurrence based on a trigger condition and the trigger evaluation data, according to certain embodiments of the present disclosure. [Figure 84] FIG. 1 is a schematic diagram of an exemplary apparatus for implementing data collection utilizing policy hierarchies, in accordance with certain embodiments of the present disclosure. [Figure 85] FIG. 1 is a schematic diagram of an example apparatus that utilizes multiple policy types to perform vehicle data collection or other operations in accordance with certain embodiments of the present disclosure. [Figure 86] 1 is a flowchart illustrating an exemplary procedure for implementing policy enforcement on a vehicle, according to certain embodiments of the present disclosure. [Figure 87] 1 is a flowchart illustrating an exemplary procedure for implementing policy enforcement on a vehicle, according to certain embodiments of the present disclosure. [Figure 88] FIG. 2 is a schematic diagram of an exemplary policy hierarchy utilized in accordance with certain embodiments of the present disclosure. [Figure 89] FIG. 10 is a schematic diagram of another exemplary utilized policy hierarchy in accordance with certain embodiments of the present disclosure. [Figure 90] FIG. 10 is a schematic diagram of another exemplary utilized policy in accordance with certain embodiments of the present disclosure. [Figure 91] FIG. 10 is a schematic diagram of another exemplary utilized policy in accordance with certain embodiments of the present disclosure. [Figure 92] 10 is a flowchart illustrating an exemplary procedure for updating a data collection policy according to certain embodiments of the present disclosure. [Figure 93] 1 is a flowchart illustrating an exemplary procedure for implementing a policy hierarchy according to certain embodiments of the present disclosure. [Figure 94]1 is a flowchart illustrating an exemplary procedure for implementing a policy hierarchy according to certain embodiments of the present disclosure. [Figure 95] FIG. 1 is a schematic diagram of an exemplary apparatus for performing data collection operations utilizing shared storage for collected data, in accordance with certain embodiments of the present disclosure. [Figure 96] 4 is a flowchart illustrating an exemplary procedure for selectively storing collected data parameters in a vehicle, according to certain embodiments of the present disclosure. [Figure 97] 1 is a schematic diagram of exemplary operations including determining a parameter transmission schedule for stored parameters and selectively storing at least a portion of vehicle parameter values ​​according to certain embodiments of the present disclosure. [Figure 98] 10 is a schematic diagram of example operations including determining a parameter expiration schedule for stored parameters and selectively storing at least a portion of vehicle parameter values ​​according to certain embodiments of the present disclosure. [Figure 99] FIG. 10 is a schematic diagram of example operations including determining a reserved memory amount for stored parameters and selectively storing at least a portion of vehicle parameter values ​​according to certain embodiments of the present disclosure. [Figure 100] 10A-10C are schematic diagrams of example operations including deleting at least a portion of stored vehicle parameter values ​​according to certain embodiments of the present disclosure. [Figure 101] FIG. 1 is a schematic diagram of an example operation involving summarizing at least a portion of stored vehicle parameter values ​​according to certain embodiments of the present disclosure. [Figure 102] FIG. 10 is a schematic diagram of example operations including adjusting a reserved memory amount associated with stored vehicle parameters, according to certain embodiments of the present disclosure. [Figure 103] FIG. 1 is a schematic diagram of an example operation involving compressing at least a portion of stored vehicle parameters according to certain embodiments of the present disclosure. [Figure 104]FIG. 1 is a schematic diagram of example operations including determining the amount of data to be collected to support a vehicle parameter value according to certain embodiments of the present disclosure. [Figure 105] FIG. 10 is a schematic diagram of example operations including determining the amount of data to be collected to support trigger evaluation related to vehicle parameter values ​​according to certain embodiments of the present disclosure. [Figure 106] 5 is a schematic diagram of example operations including determining a transmission latency value associated with a vehicle parameter value according to certain embodiments of the present disclosure. [Figure 107] 5 is a schematic diagram of example operations including determining priority values ​​associated with vehicle parameter values ​​in accordance with certain embodiments of the present disclosure. [Figure 108] FIG. 1 is a schematic diagram of an example apparatus for performing data collection operations that enforce a data collection policy in accordance with certain embodiments of the present disclosure. [Figure 109] FIG. 2 is a schematic diagram of an exemplary data collection policy in accordance with certain embodiments of the present disclosure. [Figure 110] FIG. 2 is a schematic diagram of exemplary transmission description values ​​according to certain embodiments of the present disclosure. [Figure 111] FIG. 2 is a schematic diagram of exemplary policy priority values ​​according to certain embodiments of the present disclosure. [Figure 112] FIG. 2 is a schematic diagram of an exemplary policy lifecycle description in accordance with certain embodiments of the present disclosure. [Figure 113] 1 is a flowchart illustrating an exemplary procedure for collecting data according to a policy according to certain embodiments of the present disclosure. [Figure 114] FIG. 1 is a schematic diagram of an exemplary cloud system in accordance with certain embodiments of the present disclosure. [Figure 115] FIG. 1 illustrates an exemplary cloud system for obtaining selected data from a vehicle, according to certain embodiments of the present disclosure. [Figure 116] FIG. 1 is an exemplary schematic diagram of operations including data collection operations from a vehicle according to certain embodiments of the present disclosure. [Figure 117]FIG. 1 illustrates an exemplary procedure for separating response data to a vehicle data collection operation according to certain embodiments of the present disclosure. [Figure 118] FIG. 1 illustrates an exemplary procedure for separating response data to a vehicle data collection operation according to certain embodiments of the present disclosure. [Figure 119] FIG. 1 illustrates an exemplary system for retrieving selected data from a vehicle, in accordance with certain embodiments of the present disclosure. [Figure 120] FIG. 1 illustrates an exemplary procedure for identifying data, according to certain embodiments of the present disclosure. [Figure 121] FIG. 1 illustrates an exemplary cloud system for creating data collection policies in accordance with certain embodiments of the present disclosure. [Figure 122] FIG. 2 illustrates an exemplary policy creator circuit in accordance with certain embodiments of the present disclosure. [Figure 123] FIG. 2 illustrates an exemplary request interface in accordance with certain embodiments of the present disclosure. [Figure 124] FIG. 10 illustrates an exemplary procedure for operating a request interface according to certain embodiments of the present disclosure. [Figure 125] 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. [Figure 126] 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. [Figure 127] 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. [Figure 128] 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. [Figure 129] 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. [Figure 130]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. [Figure 131] FIG. 1 is an exemplary schematic diagram of providing automated vehicle operation based on data values ​​according to certain embodiments of the present disclosure. [Figure 132] FIG. 1 is an exemplary schematic diagram of providing automated vehicle operation based on data values ​​according to certain embodiments of the present disclosure. [Figure 133] FIG. 1 is an exemplary schematic diagram of providing automated vehicle operation based on data values ​​according to certain embodiments of the present disclosure. [Figure 134] FIG. 1 is an exemplary schematic diagram for performing a data collection operation according to certain embodiments of the present disclosure. [Figure 135] FIG. 1 illustrates an exemplary schematic diagram for vehicle data transmission operations with a cloud system and / or external devices, according to certain embodiments of the present disclosure. [Figure 136] FIG. 1 illustrates an exemplary procedure for managing vehicle transmission operations in accordance with certain embodiments of the present disclosure. [Figure 137] FIG. 1 illustrates an exemplary procedure for selectively transmitting collected data according to a selected transmission interval, in accordance with certain embodiments of the present disclosure. [Figure 138] FIG. 1 illustrates an exemplary procedure for selectively transmitting collected data depending on selected bandwidth utilization, according to certain embodiments of the present disclosure. [Figure 139] FIG. 1 illustrates an exemplary procedure for selectively transmitting collected data depending on the data type of the collected data, according to certain embodiments of the present disclosure. [Figure 140] FIG. 1 illustrates an exemplary procedure for selectively transmitting collected data depending on the impact of the transmission action on vehicle operation according to certain embodiments of the present disclosure. [Figure 141] FIG. 1 illustrates an exemplary procedure for selectively transmitting collected data depending on the power utilization impact of the transmission operation according to certain embodiments of the present disclosure. [Figure 142]FIG. 1 illustrates an exemplary procedure for selectively transmitting collected data as a function of a data transmission capacity value, in accordance with certain embodiments of the present disclosure. [Figure 143] FIG. 1 illustrates an exemplary procedure for selectively transmitting collected data depending on currently available transmission types, according to certain embodiments of the present disclosure. [Figure 144] FIG. 1 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. [Figure 145] FIG. 1 illustrates an exemplary procedure for selectively transmitting collected data depending on a success parameter of a transmission operation according to certain embodiments of the present disclosure. [Figure 146] FIG. 1 illustrates an exemplary procedure for selectively transmitting collected data as a function of a quality of service value for a transmission operation, consistent with certain embodiments of the present disclosure. [Figure 147] FIG. 1 is an exemplary schematic diagram for performing remote assist operations on a vehicle in accordance with certain embodiments of the present disclosure. [Figure 148] 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. [Figure 149] FIG. 1 illustrates an exemplary procedure for performing a remote action on a vehicle according to certain embodiments of the present disclosure. [Figure 150] FIG. 1 illustrates an exemplary procedure for performing actions on a vehicle, including remote assistance actions, in accordance with certain embodiments of the present disclosure. [Figure 151] FIG. 1 is a schematic diagram of an apparatus for collecting and / or managing vehicle data in accordance with certain embodiments of the present disclosure. [Figure 152] FIG. 2 is a schematic diagram of another apparatus for collecting and / or managing vehicle data in accordance with certain embodiments of the present disclosure. [Figure 153] FIG. 2 is a schematic diagram of another apparatus for collecting and / or managing vehicle data in accordance with certain embodiments of the present disclosure. [Fig. 154] FIG. 1 is a schematic diagram of another apparatus for collecting and / or managing vehicle data in accordance with certain embodiments of the present disclosure. [Figure 155]1 is a flowchart illustrating a method for collecting and / or managing vehicle data, according to certain embodiments of the present disclosure. [Figure 156] 156 is another flowchart illustrating the method of FIG. 155 in accordance with certain embodiments of the present disclosure. [Figure 157] 156 is another flowchart illustrating the method of FIG. 155 in accordance with certain embodiments of the present disclosure. [Figure 158] 10 is a flowchart illustrating another method for collecting and / or managing vehicle data, in accordance with certain embodiments of the present disclosure. [Figure 159] 159 is another flowchart illustrating the method of FIG. 158 in accordance with certain embodiments of the present disclosure. [Figure 160] FIG. 1 is a schematic diagram of an apparatus for data collection policy capture and enforcement in accordance with certain embodiments of the present disclosure. [Figure 161] FIG. 1 is a schematic diagram of another apparatus for capturing and enforcing data collection policies in accordance with certain embodiments of the present disclosure. [Figure 162] FIG. 162 is another schematic diagram of the device of FIG. 161 in accordance with a specific embodiment of the present disclosure. [Figure 163] FIG. 162 is another schematic diagram of the device of FIG. 161 in accordance with a specific embodiment of the present disclosure. [Fig. 164] FIG. 162 is another schematic diagram of the device of FIG. 161 in accordance with a specific embodiment of the present disclosure. [Figure 165] 1 is a flowchart illustrating a method for data collection policy capture and execution in accordance with certain embodiments of the present disclosure. [Figure 166] 166 is another flowchart illustrating the method of FIG. 165 according to certain embodiments of the present disclosure. [Figure 167] 166 is another flowchart illustrating the method of FIG. 165 according to certain embodiments of the present disclosure. [Figure 168] 166 is another flowchart illustrating the method of FIG. 165 according to certain embodiments of the present disclosure. [Figure 169] 166 is another flowchart illustrating the method of FIG. 165 according to certain embodiments of the present disclosure. [Figure 170]1 is a schematic diagram of an apparatus for data collection in a mixed network environment, in accordance with certain embodiments of the present disclosure. [Figure 171] FIG. 2 is a schematic diagram of another apparatus for data collection in a mixed network environment, in accordance with certain embodiments of the present disclosure. [Fig. 172] 1 is a flowchart illustrating a method for data collection in a mixed network environment in accordance with certain embodiments of the present disclosure. [Figure 173] 173 is another flowchart illustrating the method of FIG. 172 in accordance with certain embodiments of the present disclosure. [Fig. 174] FIG. 1 is a schematic diagram of an apparatus for managing a data collection process in accordance with certain embodiments of the present disclosure. [Figure 175] FIG. 1 is a schematic diagram of another apparatus for managing a data collection process in accordance with certain embodiments of the present disclosure. [Figure 176] FIG. 176 is another schematic diagram of the device of FIG. 175 in accordance with a specific embodiment of the present disclosure. [Figure 177] FIG. 176 is another schematic diagram of the device of FIG. 175 in accordance with a specific embodiment of the present disclosure. [Figure 178] 1 is a flowchart illustrating a method for managing a data collection process in accordance with certain embodiments of the present disclosure. [Figure 179] 179 is another flowchart illustrating the method of FIG. 178 in accordance with certain embodiments of the present disclosure. [Figure 180] FIG. 1 is a schematic diagram of an apparatus for data storage management in accordance with certain embodiments of the present disclosure. [Figure 181] FIG. 181 is another schematic diagram of the device of FIG. 180 in accordance with a specific embodiment of the present disclosure. [Figure 182] 1 is a flowchart illustrating a method for data storage management in accordance with certain embodiments of the present disclosure. [Figure 183] 183 is another flowchart illustrating the method of FIG. 182 in accordance with certain embodiments of the present disclosure. [Figure 184] 183 is another flowchart illustrating the method of FIG. 182 in accordance with certain embodiments of the present disclosure. [Figure 185]183 is another flowchart illustrating the method of FIG. 182 in accordance with certain embodiments of the present disclosure. [Figure 186] 183 is another flowchart illustrating the method of FIG. 182 in accordance with certain embodiments of the present disclosure. [Figure 187] FIG. 2 is a box diagram illustrating an exemplary user device in accordance with certain embodiments of the present disclosure. [Figure 188] 10 is a flowchart illustrating an exemplary user device-based data collection process in accordance with certain embodiments of the present disclosure. [Figure 189] 10 is a flowchart illustrating an exemplary user device-based data collection process in accordance with certain embodiments of the present disclosure. [Figure 190] FIG. 1 is a box diagram illustrating an exemplary cloud system in accordance with certain embodiments of the present disclosure. [Figure 191] 1 is a flowchart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure. [Figure 192] 1 is a flowchart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure. [Figure 193] 1 is a flowchart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure. [Figure 194] 1 is a flowchart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure. [Figure 195] 1 is a flowchart illustrating an exemplary cloud system-based data collection process according to certain embodiments of the present disclosure. [Figure 196] FIG. 1 is a box diagram illustrating an exemplary vehicle in accordance with certain embodiments of the present disclosure. [Figure 197] 1 is a flowchart illustrating exemplary vehicle-based data collection in accordance with certain embodiments of the present disclosure. [Figure 198] 1 is a flowchart illustrating exemplary vehicle-based data collection in accordance with certain embodiments of the present disclosure. [Figure 199]1 is a flowchart illustrating exemplary vehicle-based data collection in accordance with certain embodiments of the present disclosure. [Figure 200] 1 is a flowchart illustrating exemplary vehicle-based data collection in accordance with certain embodiments of the present disclosure. [Figure 201] FIG. 1 is a box diagram of an exemplary vehicle in accordance with certain embodiments of the present disclosure. [Figure 202] FIG. 2 is a box diagram of an exemplary data collection controller in accordance with certain embodiments of the present disclosure. [Figure 203] 1 is a flowchart illustrating an exemplary data collection process according to certain embodiments of the present disclosure. [Figure 204] 1 is a flowchart illustrating an exemplary data collection process according to certain embodiments of the present disclosure. [Figure 205] 1 is a flowchart illustrating an exemplary data collection process according to certain embodiments of the present disclosure. [Figure 206] FIG. 1 is a box diagram of an exemplary vehicle in accordance with certain embodiments of the present disclosure. [Figure 207] FIG. 2 is a box diagram of an exemplary data collection controller in accordance with certain embodiments of the present disclosure. [Figure 208] 1 is a flowchart illustrating an exemplary data collection process according to certain embodiments of the present disclosure. [Figure 209] 1 is a flowchart illustrating an exemplary data collection process according to certain embodiments of the present disclosure. [Figure 210] 1 is a flowchart illustrating an exemplary data collection process according to certain embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0094] Without limiting any other aspect of the present disclosure, aspects of the present disclosure may reduce and / or eliminate any one or more of the following: cost per entity added to a data collection system; baseline learning costs for new entities to implement applications that utilize collected data; costs of adapting to changes in vehicle network configuration; costs incurred to meet increased demand for data collection; costs to adapt to a changing regulatory environment; and / or costs to protect data and / or losses incurred for non-compliance or unauthorized use. Particular embodiments and / or aspects of the present disclosure may address one or more of the listed cost parameters. Particular embodiments and / or aspects of the present disclosure may increase one or more given cost parameters, but may nevertheless benefit from a reduced overall cost function for a target vehicle, vehicle type, entity, industry, etc. Particular embodiments and / or aspects of the present disclosure may increase one or more given cost parameters, but may provide other benefits, such as improved functionality. In certain embodiments, the improved functionality may be achieved at an increased cost, but at a lower cost than previously known systems configured to achieve similar improved functionality.

[0095] For the purpose of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings and described herein below. It will be understood that no limitation of the scope of the present disclosure is thereby intended. It will be further understood that the present disclosure includes any changes and modifications to the illustrated embodiments, and includes further applications of the principles disclosed herein that would normally occur to one skilled in the art to which the present disclosure pertains.

[0096] This disclosure describes systems, methods, and apparatus for performing data collection operations related to a vehicle. Certain embodiments described herein relate to a mixed vehicle network on a vehicle. An exemplary mixed vehicle network includes one or more CAN buses with multiple devices communicating via the CAN bus(es), one or more Ethernet networks with multiple devices communicating via the Ethernet network, and a network with communications from CAN to Ethernet and / or vice versa. The mixed network is not limited to CAN and Ethernet, but may include any one or more of, but not limited to, Local Interconnect Network (LIN), FlexRay, Media Oriented Systems Transport (MOST), and / or Low-Voltage Differential Signaling (LVDS). 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, two or more Ethernet networks (or zones) may be present, including mixed-capability Ethernet networks. Additionally or alternatively, in certain embodiments, the one or more networks present may include a wireless network such as a WiFi network (e.g., 802.11x standards such as a / b / g; n; and / or ac), a mobile standard network (e.g., 4G and / or 5G), Bluetooth communications, a Universal Serial Bus (USB) connection, and / or a fiber optic connection. The networks described are non-limiting examples, and any type of network and / or communication protocol is contemplated herein for a mixed vehicle network.

[0097] In certain embodiments, a mixed vehicular network includes one or more low-capability networks combined with one or more high-capability networks. What is considered low-capability depends on the application, the number of communicating devices, the types of communications allowed on the network, and the available network management (e.g., device registration, addition, or removal, message encryption, message customization, etc.) for the particular network and communications protocol being utilized. In certain embodiments, a mixed vehicular network includes two or more networks, where at least two of the networks present integration challenges. For example, one of the networks may only allow certain types of communications, require certain types of synchronous or asynchronous communications, only allow certain types of device connections, restrict the implementation of certain network topologies, or have other differences or limitations that make the use of a single network (or network type) across the entire vehicle undesirable or impractical.

[0098] The description herein utilizing off-vehicle, off-vehicle, and / or cloud-based interactions pertains to any external network communication of the vehicle, without limitation to wireless-based communication (e.g., mobile data, WiFi, and / or Bluetooth) to external devices. Communication to external devices can be via a general network (e.g., over the Internet), a WAN, a LAN, a mobile device in proximity to the vehicle, and / or combinations thereof. Certain systems and procedures described herein particularly contemplate external communications that occur during runtime operation of the vehicle, e.g., during an operating state in which the vehicle is performing a mission (e.g., while moving, performing operations while not moving, etc.). The disclosure herein further contemplates communications that may occur during any period, including during vehicle downtime and / or during a service event. The disclosure herein also contemplates communications that may occur over a wired communication channel, such as when the vehicle network is communicating with a service tool, on-board diagnostics (OBD) instrument, or other physically coupled device.

[0099] This specification refers to vehicle applications as a non-limiting example and for clarity. However, embodiments herein are applicable to other applications having similar problems 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 may further include endpoints residing in different or distributed network environments, as well as applications having older or legacy networking or communication systems that may be migrated to newer and / or more capable networking or communication systems (within a given system, as a class of systems, and / or as an industry). Exemplary and non-limiting embodiments include one or more of industrial equipment; robotic systems (including at least mobile robots, autonomous vehicle systems, and / or industrial robots); mobile applications (which may or may not be considered "vehicles"), and / or manufacturing systems. It will be understood that particular features, aspects, and / or advantages of the present disclosure may be applicable to any one or more of these applications and not to other of these applications, and that the application of particular features, aspects, and / or advantages of the present disclosure may vary depending on the operating conditions, constraints, and cost parameters of a particular application (e.g., operating costs, integration costs, operational costs, data communication and / or storage costs, service costs and / or downtime costs, etc.). Accordingly, whether the present disclosure relates to vehicles, vehicle systems, mobile applications, industrial devices, robotic systems, and / or manufacturing systems, each of these is also contemplated herein and may be applicable in particular embodiments and inapplicable in other particular embodiments, as will be understood by those of ordinary skill in the art having the benefit of this disclosure.

[0100] Flow, as used herein, should be understood broadly. Exemplary flows include related groups of data (e.g., speed data, temperature data, audiovisual data, navigation data, etc.), related groups of functions (e.g., between vehicle functions, off-vehicle functions such as service operations and / or data collection, aggregation between related vehicles, and / or combinations thereof related to a particular system), related groups of devices (e.g., door actuators), and / or related groups of applications. Flow, as used herein, provides a mechanized concept that can be utilized to associate specific data, specific endpoints, specific applications, and / or related functions in or off the vehicle. In particular embodiments, a controller can utilize flows to identify data sources, data destinations, permissions available in the flow, priority information associated with the flow, etc., and thereby perform specific data conditioning actions. In particular embodiments, utilization of flows enables a controller to perform separate operations that may involve the same endpoints to support desired network management. For example, a vehicle speed management application may have a high priority, and a speedometer endpoint may be associated with the vehicle speed management application. In this example, if the vehicle speed is being communicated to support a vehicle speed management application, the controller applies a high priority to the vehicle speed message. However, if the vehicle speed is being communicated to support a journey planning flow (e.g., the journey planning flow is present and does not have a high priority), the controller may apply a low priority to the vehicle speed message. In a further example, a failure of the vehicle controller, part of the network, or other off-nominal condition may result in the vehicle speed management application being transferred to another controller in the system, whereby the vehicle speed message is being communicated to support the vehicle speed management application (e.g., if a backup controller is on another network), and the controller may apply a high priority to the vehicle speed message.The use of flows and applications to organize the components of the system allows the same or similar information to be adjusted differentially by controllers to support various functions, allows for improved performance and security of network adjustment operations (e.g., reducing unnecessary cross-network traffic and providing information only when needed), and supports additional functionality over previously known systems such as redundancy support, distributed control, and granular cross-network messaging.

[0101] As used herein, a policy includes a description of the data to be collected, such as data parameters, collection rates, resolution information, and priority values ​​(e.g., ordering data collection values ​​for selection in response to an off-nominal condition where not all data collection parameters can be serviced). In certain embodiments, a policy further includes event information, which may be defined as a parameter- or quantity-based event (e.g., a given data value exceeds a threshold) and / or a categorical event (e.g., a particular fault code, operating condition or state, or vehicle location / jurisdiction occurs). In certain embodiments, a policy further includes data values ​​to be captured in response to the occurrence of an event, and / or an event response, such as an increase or decrease in data collection rate, a change in collection resolution, or other change in the data collection methodology, such as an increase or decrease in data collection rate, a change in collection resolution, or the like. In certain embodiments, an event response further includes a time frame associated with the event occurrence, e.g., a time period after the event occurrence utilizing an adjusted data collection scheme, and / or a time period prior to the event occurrence (e.g., utilizing a rolling buffer or other data collection operation to provide temporal information that can be captured after the event occurs). In certain embodiments, the change in the data collection scheme for an event may include multiple changes, such as changes 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 criteria for determining that the event is cleared. In certain embodiments, the change in the data collection scheme may be implemented based on an event-related clearing of the same or another event, such as until the next shutdown event of the vehicle, until a service technician clears the event, until a selected number of shutdown events occur, etc.

[0102] The use of a policy herein may refer to a partial policy, such as an implicit policy that would be implemented in response to a single data collection scheme from a single user, and a complete policy that is created, validated, and communicated to a vehicle after one or more partial policies are aggregated. The use of a policy herein may refer to an unvalidated policy, for example, after policies corresponding to multiple users have been aggregated, where the policy validation operation has not yet been completed (e.g., before it has been determined whether data collection implied by the policy can be performed). The use of a policy herein may refer to a previously applied policy (e.g., a policy that exists on a vehicle before an updated version of the policy is communicated to and / or implemented on the vehicle). The use of a policy herein may refer to an updated policy, for example, a validated policy that is pending communication to the vehicle 102 and / or that has been confirmed by the vehicle 102 (e.g., from the data collection controller 202).

[0103] 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 the off-vehicle 104 device communicatively coupled to one or more user devices 106. For example, the vehicle 102 may include a mixed network having multiple data-providing devices coupled to an on-vehicle network, e.g., having one or more devices coupled to a CAN network and one or more other devices coupled to an Ethernet network. The exemplary system allows a user (e.g., an application provider, fleet owner, manufacturer, customer, etc.) to access the off-vehicle device 104 and configure data collection performed from the vehicle 102 to the off-vehicle device 104. In a further example, the system allows access to at least a portion of the collected data for use in an application associated with the vehicle. In certain embodiments, the system provides authorization control for users and / or applications to ensure data collection requests are made appropriately. In certain embodiments, the system provides data collection control to ensure requested data communication is achievable and / or consumes reduced data communication resources. In certain embodiments, the system provides consent enforcement to ensure that appropriate consent (e.g., consent from a vehicle operator or owner) is provided before relevant data collection occurs. In certain embodiments, the system provides separation of specific vehicle information (e.g., data parameter names, communication protocol information, location and / or ID values ​​of data providers in a mixed network environment of vehicles) from data requesters and / or users, thereby alleviating the need for data requesters and / or users to learn and / or keep updated on specific vehicle information. In certain embodiments, the system provides separation of stored data collected from vehicles from systems that provide requested data to applications that utilize some of the data.In certain embodiments, the system provides integrated policy management to control data collection parameters from multiple concurrent data requesters and / or to provide enhanced policy management control to specific users, such as policy creators and / or policy controllers. In certain embodiments, the system provides enhanced policy creation and / or updates, whereby the system communicates with users in a manner configured to provide high-level feature descriptions to the users without requiring knowledge from the users regarding the specific vehicles and / or specific data utilized to support the corresponding high-level features. In certain embodiments, the system provides enhanced data communication between vehicles responsive to intermittent network access and / or intermittent network bandwidth availability, and communicates requested data from the vehicles to off-vehicle devices.

[0104] 2, an exemplary vehicle 102 is schematically depicted having 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 functions to on-board devices according to the policies, and perform appropriate data collection. The exemplary data collection controller 102 also communicates collected data to off-vehicle devices 104 and / or manages communications according to 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 sections of this disclosure that refer to FIGS. 5 and 10.

[0105] The example vehicle 102 further includes an inter-network switch 204 communicatively coupled to at least two networks on the vehicle 102. The example inter-network switch 204 is directly coupled to a plurality of devices 210 on a first network and is coupled to a second plurality of devices 208 on a second network, e.g., via communication with an edge gateway 206. Certain further and / or more detailed operations of the inter-network switch 204 are described in the portions of this disclosure that reference Figures 5 and 7. Certain further and / or more detailed operations of the devices 210 are described in the portions of this disclosure that reference Figures 5 and 8. Certain further and / or more detailed operations of the edge gateway 206 are described in the portions of this disclosure that reference Figures 5 and 6.

[0106] The example vehicle 102 further includes a user consent controller 212 communicatively coupled to the data collection controller 202 and / or the off-vehicle device 104. In certain embodiments, the user consent controller 212 can be an on-board device such as a vehicle display (e.g., a PAD or console device), and / or the user consent controller 212 can include a mobile application (e.g., a user's mobile device having a consent application operable thereon), a web-based application (e.g., a web application accessible to the user and related to the vehicle 102), and / or two or more thereof. Certain further and / or more detailed operation of the user consent controller 212 is described in the portions of this disclosure with reference to FIGS. 5 and 9. In the example of FIG. 2, external communication 214 is depicted, which can include communication to the off-vehicle device 104. The external communication 214 may be passed wirelessly (e.g., from an available transceiver on the vehicle communicating with the data collection controller 202 and / or the user consent controller 212) and / or by wired communication (e.g., a service tool, OBD device, etc. coupled to the network on the vehicle as a device 210 communicating with, for example, the network-to-network switch 204).

[0107] Referring to FIG. 3 , an exemplary off-vehicle device 104 is depicted. The exemplary off-vehicle device 104 is depicted generally as an integrated device with a manager and other components depicted to illustrate the interaction of the off-vehicle device 104's functional elements. The off-vehicle device 104 may be a distributed device, with aspects residing on multiple controllers, transceivers, servers, or the like. In certain embodiments, the off-vehicle device 104 may be implemented at least in part as 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, etc. In certain embodiments, aspects of the 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 the off-vehicle device 104 and interfaces with a second partition 304 that performs certain other operations of the off-vehicle device 104. In the example of FIG. 3, partitions 306 are depicted where communication across partitions 306 may be configured into interface specifications or other agreed-upon or implemented communication methods.

[0108] The example 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 the vehicle 102. The example network manager 312 interfaces with the data communications 308 component, for example, passing received vehicle data to the data communications 308 component. The example network manager 312 interfaces with a vehicle policy communications manager 310, for example, receiving data collection policies, policy updates, and / or providing consent communications between the vehicle policy communications manager 310 and the vehicle 102. In certain embodiments, the vehicle policy communications manager 310 receives processed policies from the policy manager 330 on the second partition 304 (and / or from the vehicle data request manager 342) and makes the policies available to the vehicle 102 and / or determines when to communicate the policies to the vehicle.

[0109] 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 users (e.g., devices 106 and / or internal applications 334), and the vehicle data request manager 342 aggregates the requested data into a set of parameters specific to a data collection that satisfies the data collection needs of all data requests in the policy. In certain embodiments, the policy manager 330 and / or the vehicle data request manager 342 perform policy validation to ensure that a given policy can be supported (e.g., the requesting user is authorized, parameters are available in the vehicle, and / or aggregated data collection that satisfies the policy can be achieved within available bandwidth limits) before the vehicle data request manager 342 provides the data request to the vehicle policy communication manager 310. In certain embodiments, the aggregated data collection set is stored in a data structure, such as an XML structure, a JSON data structure, an HTML data structure, or another selected data structure. In certain embodiments, the aggregated data collection set, including its associated data structures, comprises the policy that is sent to the vehicle 102. In certain embodiments, the data structure transmitted to the vehicle 102 includes, as part of the policy, an event description, priority information, and / or other information such as response information to off-nominal conditions such as intermittent network availability.

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

[0111] Exemplary policies utilized herein include policies provided by an external device that request a vehicle to collect a data set over a defined or short period of time and return the data to the external device. The data can be sent back to the external device within a defined time period set forth in the policy and / or according to a default time period for such policy operation, including sending the data back to the external device as soon as data collection is complete. Exemplary policies can be deleted, removed, or otherwise considered complete after a data collection event and / or after a number of consecutive data collection events. Such policies can be referred to as ad hoc policies, one-time policies (which can include one or more finite data collection events), improvised policies, single-use policies, emergency policies, or the like. Examples of the use of such policies include rapid response data collection (e.g., information collection in preparation for emergency event processing, updates, campaigns, or other planned changes to multiple vehicles; collection of a data set to train a model or artificial intelligence component; and / or data collection in any situation where use of the data is expected to occur within a finite time period and ongoing data collection for the policy is not desired).

[0112] Exemplary policies utilized herein include policies provided by an external device that request that a vehicle collect a data set over an extended period of time and / or continuously, with the collected data being transmitted back to the external device periodically and / or intermittently at intervals that can improve bandwidth utilization by selecting transmission times and / or enable compression operations on the data to reduce the amount of data transmitted. Exemplary policies may be retained for a defined period of time, until deleted by the external device, and / or until an event occurs (e.g., a research data collection operation, where the event is configured to establish that the vehicle is no longer associated with the study). The defined time period and / or event parameters for deleting the policy may be defined within the policy. Exemplary uses of such policies include research projects, continuous improvement projects (e.g., development of diagnostic or prognostic algorithms for a vehicle or related group of vehicles, continuous improvement of operational algorithms, etc.), ongoing analytical projects (e.g., analyzing large data sets to detect trends, changes within a related group of vehicles, and / or verify that changes to a related group of vehicles are having the expected effect), and / or projects where the time constant of the project output is long relative to the data rate typically received from low-utilization data transmission operations. Such policies may be referred to as research policies, analysis policies, non-emergency data policies, or the like.

[0113] Exemplary policies utilized herein include policies provided by an external device that request a vehicle to collect a data set over an extended period of time and, as the data is collected, transmit the data back to the vehicle in defined data blocks as each data block is collected and / or transmitted in a streaming manner. Exemplary policies may be retained for a defined period of time, until deleted by the external device, and / or until an event occurs (e.g., data utilized by an algorithm or process changes, the algorithm or process is discontinued, the algorithm or process is replaced by an updated algorithm or process, or the like). The defined period and / or event parameters for deleting the policy may be defined within the policy. Exemplary uses of such policies include real-time monitoring of vehicle conditions, implementation of diagnostic or predictive algorithms on a vehicle or related group of vehicles, and / or projects where the time constant of the project output is so short that low-utilization data transmission operations are insufficient to support the project or are insufficient 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.

[0114] The first partition 302 further includes a data store 320, which may be a raw data store that stores data provided by the data communications 308 component, and the data store 320 keeps the data isolated from the second partition 304 until collected data is requested, thereby segmenting the risks associated with data storage. For example, the first partition 302 may be controlled and / or operated by a first entity, and the second partition 304 may be controlled and / or operated by a second entity, thereby segmenting the risks associated with data storage. In certain embodiments, the data store 302 stores data in an encrypted format, which may be further configured to prevent the first entity operating the first partition 302 from accessing the data values ​​of the stored data. In certain embodiments, the data store 302 stores data associated with metadata values, such as vehicle information, timestamps, and data category descriptions, so that the appropriate data can be provided in response to a data request by the data request / processing 322 component.

[0115] The example second partition 304 further includes a consent manager 332 that determines whether consent is required for data values ​​in a policy and communicates with the user consent controller 312 and / or consent application 402 (see FIG. 12 ) to request and receive consent values. In particular embodiments, an application authorization data store 328 is utilized to store consent information, such as consent confirmations for current policies, pending policies, or the like. The application authorization data store 328 can further be utilized to determine policy aspects (e.g., data parameters, sampling rates, event values, and / or use case values) authorized for access by a particular user, user role, application 402, and / or according to other authorization schemes utilized.

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

[0117] 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, policy manager 330, which interfaces with an application or user, can provide a list of data elements, given event values, and / or predetermined response values ​​available in the system. In particular embodiments, the list can include interface elements such as drop-down lists, check boxes, or other interfaces that allow for quick selection of requested elements and ensure proper formatting of the requested elements. In particular embodiments, user and / or application authorization of requested elements can be performed during construction or input of the requested policy element; for example, policy manager 330 can hide unauthorized elements, display unauthorized elements in an alternative format (e.g., grayed out), and / or provide an alert or notification that unauthorized elements are currently included in the requested policy element. In particular embodiments, policy manager 330 can allow unauthorized elements for a policy request (and / or omit pre-screening for approval), whereby it precludes the creation of a policy based on the policy request if unauthorized elements are still present when validating the aggregated policy for an update (e.g., merging multiple policy requests from various users and / or applications into the aggregated policy). In particular embodiments, policy manager 330 can notify a user or application (e.g., a policy creator, policy controller, superuser, or the like) that validation of a policy request failed due to including unauthorized data requests, due to excessive communication bandwidth requirements, or for other reasons.In particular embodiments, policy manager 330 can identify which element of the policy request caused the validation failure and / or can provide the notified user or application with a communication to the user or application making the unauthorized request, an option to authorize the unauthorized request, or the like.

[0118] In certain embodiments, the operations of policy manager 330 include compiling multiple policy requests from users and / or applications (internal or external) into a unified policy structure. In certain embodiments, policy manager 330 (and / or vehicle data request manager 342) can provide a unified policy structure as a superset of data requests (e.g., aggregating data requests for given parameters) and further aggregate event requests and / or event responses if these aggregation operations can be consistent with achieving the events and responses within the individual policy requests. In certain embodiments, policy manager 330 can include consideration of data supersets when determining event responses; for example, if an event requests data to be taken in response to the event, but data has already been collected for another request in the policy, the event can be omitted and / or data collected can be reduced based on data availability.

[0119] In certain embodiments, policy manager 330 includes operations to validate the integrated policy structure, e.g., to ensure that a user and / or application is requesting only authorized data, to ensure that data parameters requiring consent have consent available (and / or communicate consent requirements to consent manager 332 for appropriate action), and / or to ensure that the vehicle's network bandwidth capabilities, vehicle data storage capabilities, or other parameters can meet the requirements of the integrated policy structure. In certain embodiments, policy manager 330 maintains updated “live” validation, e.g., validating potential integrated policy structures as policy requests are received from users and / or applications. In certain embodiments, policy manager 330 performs validation on demand, e.g., by a policy creator, which can be performed as a “build” of a policy or policy update. In certain embodiments, policy manager 330 utilizes default policies, e.g., when the vehicle is first manufactured.

[0120] In particular embodiments, after the policy is verified, the policy manager 330 may communicate the policy to the vehicle policy communication manager 310 for communication to the vehicle 102. Additionally or alternatively, the policy manager 330 may communicate the policy to the vehicle policy communication manager 310 in response to a request from a policy creator, a super user, or other authorized system user.

[0121] In particular embodiments, policy manager 330 or other system components can access policy data store 340, which can include previously validated policies, legacy policies, one or more default policies, and / or GUI parameters such as common names for data elements, user role descriptions, application role descriptions (e.g., a set of event values, event responses, and / or data values ​​available based on the application role, such as OEM, manufacturer, third party, etc.), example event values ​​and / or event responses, and vehicle data (e.g., nominal bandwidth description, storage information, etc.).

[0122] In particular embodiments, policy manager 330 provides users or applications with high-level descriptions, which in particular embodiments may be referred to as “use cases.” A use case may include one or more data collection elements, such as a group of parameters to be collected, and / or may further include one or more associated events and / or event responses. Selection of a use case may thereby be utilized to quickly build a policy request with predetermined information. The use cases presented to a user may be stored in data store 340 and / or may depend on the user's and / or application's roles and / or permissions. In particular embodiments, a use case may have an identifiable or generic name, such as “Routing Application Use Case,” “Passenger Car Standard Use Case,” “Haulage Vehicle Use Case,” etc. Data store 340 may have default use cases available and / or may include use cases created or built and / or made available by a policy creator, policy controller, super user, or the like. In particular embodiments, a user and / or application may have the ability to build a policy request and store that request as a use case for future implementation as a template, a baseline group of data collection parameters, or the like. In certain embodiments, the validation operations of policy manager 330 may utilize use cases (e.g., use cases utilize predetermined values ​​that are allowed or not allowed for a given vehicle, user, application, or the like) and / or the validation operations of policy manager 330 may evaluate individual elements implemented according to the use cases for validation. In certain embodiments, data values ​​implemented by the use cases may be displayed to the user and / or application or may be hidden from the user and / or application.

[0123] The example second partition 304 further includes one or more internal applications 334, e.g., applications created or implemented by operating entities associated with the second partition 304. The example second partition 304 further includes an application / user network manager 324, e.g., that performs load balancing operations and provides and / or receives communications to and from external applications using the communication interface 338. In particular embodiments, the application / user network manager 324 performs operations to implement a user interface or graphical user interface with external users and / or applications.

[0124] The example off-vehicle device 104 implements agreement communication 344, policy communication 346, and / or data communication 336 to manage communications between partitions 302, 304. The communications 344, 346, 336 may include standardized interfaces and / or protocols, for example, allowing a given partition 302, 304 to operate independently from updates or changes to other partitions.

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

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

[0127] 5A and 5B, an exemplary vehicle network infrastructure for a vehicle 102 is schematically depicted. The exemplary vehicle 102 includes an Ethernet switch in communication with a plurality of Ethernet-based devices (e.g., sensors, actuators, and / or controllers in communication with an Ethernet network), an edge gateway device (e.g., that interacts with a second network, such as a CAN or a second Ethernet network, and provides parameters to the first network or the Ethernet network), a data collection controller, a plurality of Ethernet devices, and a user consent controller.

[0128] Referring to FIG. 6 , an example edge gateway 206 is depicted. The example edge gateway 206 includes a CAN data collection policy manager that receives data collection commands from a data collection controller. The CAN data collection policy manager directs CAN data collection from CAN devices 208 to support the data collection commands and provides Ethernet communication parameters to an Ethernet switch to support the data collection. Use of the edge gateway 206 supports mixed network operation, allowing, in certain embodiments, the off-vehicle device 104 to operate without requiring knowledge of which devices are present on the CAN, Ethernet, or other networks. The example edge gateway 206 also includes CAN processing components, such as a CAN IP component that interprets the CAN addresses of each CAN component 208, a CAN message receiver that interprets CAN messages to determine data values, and a CAN message filter that supports downsampling of CAN messages to reduce network traffic within the vehicle network while supporting policy. For example, if parameters are provided over the CAN at a 20 ms rate but policy requires only a 1-second sampling rate for the parameters, the CAN message filter can filter out over-sampling of messages. In certain embodiments, other components can perform downsampling in addition to or instead of the CAN message filter. For example, an Ethernet switch and / or a data collection controller can perform the appropriate downsampling. The location of the downsampling can depend on policy specifications (e.g., if a parameter may be sampled faster due to an event, the CAN message filter can provide data at the highest rate that may be needed, allowing another component to downsample when the high rate is not needed, and / or the CAN message filter can respond to an event and downsample appropriately based on the situation).The example CAN gateway 206 further includes a CAN message capture component, e.g., passing CAN sampled data and / or buffering CAN sampled data until passed. The example 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 packaging one or more of the CAN messages into a single Ethernet packet). The example CAN gateway further includes an Eth IP component, which communicates the encapsulated CAN messages to the appropriate addresses on the Ethernet network. In particular embodiments, messages are passed in both directions, e.g., allowing the CAN data collection policy manager to receive the appropriate portions of the current policy, allowing the edge gateway to receive event data indicators (e.g., that a given event has occurred), and the like. In particular embodiments, a mixed network may include different network types than the CAN-Ethernet mix and / or may include networks with different protocols (e.g., packet sizes, leading / trailing bits, etc.), and the edge gateway may accordingly include the appropriate components.

[0129] Referring to FIG. 7 , an exemplary Ethernet switch 204 is depicted. The exemplary Ethernet switch 204 includes an Ethernet packet filter component for, for example, downsampling and / or filtering out unwanted packets (e.g., event-responsive data provided by Ethernet devices and / or edge gateways during periods of operation when the events are not active), and an Ethernet packet interceptor. The exemplary Ethernet packet interceptor obtains selected data from the Ethernet network. In certain embodiments, the Ethernet switch 204 performs operations such as port switching or other routing operations. The exemplary Ethernet switch 204 communicates with the data collection controller 202, the edge gateway 206, and one or more Ethernet devices 210.

[0130] Referring to FIG. 8 , an exemplary Ethernet device 210 is depicted. In certain embodiments, the Ethernet device 210 manages the implementation of policies associated with a particular device using an ECU policy manager (electronic control unit) that determines data transmission values ​​according to the policy, including, for example, data rate, resolution, and / or data response to events. In certain embodiments, the ECU manager performs event detection (e.g., reading Ethernet parameters and determining whether an event is active). In certain embodiments, the ECU manager receives event status and manages only data transmission requirements according to the event status. The Ethernet device 210 further includes a data collector, which can downsample, adjust the resolution of data values, and / or provide multiple data values ​​(e.g., within packets and / or with timestamps for later matching in the data collection controller 202 and / or off-vehicle device 104). The exemplary Ethernet device 210 also includes a data transmitter that provides packets to an Eth IP, which manages the addressing, transmission, and / or reception of the associated packets. The example Ethernet device 210 can be associated with a particular component to, for example, control Ethernet communications according to policies for the associated component. Additionally or alternatively, the Ethernet device 210 can be part of the component (e.g., managing Ethernet communications for the component, which can participate in aspects of data collection to support policies) and / or part of a controller associated with the component. The example Ethernet device 210 is in communication with an Ethernet network and / or an Ethernet switch 204.

[0131] Referring to FIG. 9 , an exemplary user consent controller 212 is depicted. The user consent controller 212 can be part of and / or associated with an on-board user input device, such as a console (e.g., a touchscreen interface) accessible to the vehicle operator. In certain embodiments, the user consent controller 212 can be omitted and / or reside in another portion of the system, for example, as an application for a mobile device, a web portal or other interface for a connected device, or the like. For example, if the owner of the vehicle and / or associated data is separate from the operator and / or for the operator's convenience, an alternative interface can be provided for consent communications. In one example, the operator utilizes a mobile device with an installed application to perform consent operations, for example, with a login or authentication operation that confirms association with the vehicle. In another example, an authoritative owner or agent accesses an application or web portal, for example, a fleet manager with web-based access on a computing device and / or mobile application associated with the vehicle. In certain embodiments, user consent can be provided for multiple vehicles within a single interface (e.g., a web application that lists a group of vehicles) and / or with a single action (e.g., approving a policy update for a selected group of vehicles). In certain embodiments, a user consent application (see, e.g., FIG. 4) can be used in combination with or as an alternative to user consent controller 212.

[0132] 10 , an exemplary data collector controller 202 having multiple components configured to functionally perform the operations of the data collector controller 202 is illustrated. The data collector controller 202 includes a vehicle OTA client (over-the-air) that receives policy updates, policies, and / or policy notifications from the off-vehicle device 104. The exemplary vehicle OTA client communicates the policies, policy updates, and / or policy notifications to the policy manager. In particular embodiments, the policies can be provided from the off-vehicle device 104 via an MQTT broker (see FIG. 11 ), allowing the vehicle 102 to subscribe to policy updates and immediately receive notification that updated policies are available without having to communicate the complete policy to the vehicle 102 until the vehicle 102 is ready to receive and / or implement the policy. In particular embodiments, the policy manager can download the policy updates and store them for later implementation. In certain embodiments, the policy manager may command the download of the policy only when the vehicle 102 is in a state that enforces the policy (e.g., during shutdown operation, steady state operation, or the like).

[0133] An example policy manager can validate policies and ensure their enforcement, for example, by performing checks based on vehicle-specific information that may not be available to the policy manager 330 on the off-vehicle device 104. For example, if a policy requests data collection from a nonexistent device, requests network traffic (on any network in the vehicle, through an Ethernet switch, or at some other component of the vehicle network) that is not possible or does not comply with vehicle requirements, and / or requests a type of information that the vehicle 102 cannot provide (e.g., an unavailable sampling rate and / or resolution), the policy manager can reject the policy and / or provide notification to the off-vehicle device 104 that the policy has been rejected. In certain embodiments, the policy manager can be configured to partially implement a policy, for example, by implementing higher-priority data collection elements from part of the policy and rejecting other lower-priority data collection elements, and / or replacing a portion of a currently implemented policy that has a lower priority than the high-priority portion of the updated policy. However, in certain embodiments, the policy manager can be configured to either accept or reject the new or updated policy 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 be configured to communicate information regarding the partial implementation of the policy to the off-vehicle device 104 (e.g., a flag indicating only partial compliance and / or further information such as which parameters are not serviced and / or alternatively available or offered service levels).

[0134] In particular embodiments, the policy manager parses policy elements and communicates relevant elements to policy managers throughout the system (e.g., to edge gateways, Ethernet switches, Ethernet devices, and / or other components, including the data collection controller 202, as described below). The example data collection controller 202 includes a data receiver component that receives data responsive to policies (and / or planned responses when an event condition is detected) from the Ethernet network (e.g., utilizing an Eth IP component) and / or from other components on the vehicle 102 (e.g., from a user consent controller). The data receiver provides the data to a pre-processing component, which may determine virtual sensor or modeled values, adjust data sample rates (e.g., perform filtering operations), adjust resolution values, and the like. In particular embodiments, the pre-processing component may perform certain operations in support of event detection, such as determining secondary state values ​​that inform event state determination, rejecting or tagging data based on the presence of a fault code, or the like.

[0135] The example data collection controller 202 includes a cache component that performs short-term data storage and supports information capture, such as a rolling buffer that enables parameter processing and / or events that can trigger short-term historical data restoration (e.g., a trigger indicating an accident, component failure, or the like, where historical data is desired when an event is detected). The example cache component can respond to commands from the cache controller, receive parsed cache instructions to support a policy, and / or adjust cache operations depending on the current operating state of the vehicle 202. In certain embodiments, the size of the cache and / or other available storage can affect the data collection controller 202's ability to meet the requirements of a policy. For example, if a large number of events for a policy result in significant consumption of cache memory, the policy manager can determine that the current configuration of the vehicle 202 cannot meet the policy. In particular embodiments, for example, if multiple part numbers of cache components with different cache sizes exist within a group of vehicles, and / or if a vehicle-specific condition exists (e.g., a portion of the cache memory is faulty or otherwise unavailable), a policy manager with higher level knowledge about a particular vehicle relative to the policy manager 330 on the off-vehicle device 104 may determine that the policy cannot be validated if the policy manager 330 approves the policy. In particular embodiments, a trigger condition evaluator receives parsed information from the policy manager indicating the event detection criteria, and the trigger condition evaluator determines which event condition exists as a function of the event detection criteria and the cached and / or ingested data. In particular embodiments, event detection may be performed in other components as described throughout this disclosure, such as in an edge gateway policy manager and / or in an Ethernet device policy manager.In particular embodiments, the policy manager of the data collection controller 202 determines which devices have sufficient information available to perform the action of event detection and provides the parsed elements of the policy to the appropriate components. Thus, in particular embodiments, the trigger condition evaluator may reference a state value that indicates whether a given event condition has occurred rather than directly detecting the parameters used to determine whether the event has occurred. In particular embodiments, one device may perform primary event detection, and another component (e.g., the trigger condition evaluator) may perform secondary detection of the same event, providing a system that responds to detect an event when, for example, a primary sensor indicating an event fails but a backup sensor detects the event's occurrence.

[0136] The example data collection controller 202 includes an ingestion component that provides parameters for storage. In certain embodiments, the ingestion component can respond to commands from a trigger condition evaluator, for example, indicating that a trigger condition (event) is active, and pull further information from a cache component (e.g., buffering values ​​available in the cache) to support policy enforcement. The example data collection controller 202 includes a storage component that stores the captured data for transmission to the off-vehicle device 104. The example storage component utilizes non-volatile memory, such as FLASH memory, to allow stored data that has not been transmitted to be preserved upon power loss. The example data collection controller 202 includes a storage controller that provides storage commands to the storage component to support policy enforcement and / or support certain operating conditions of the vehicle 202, such as intermittent loss of network communication to the off-vehicle device 104 and / or intermittent ability to communicate data to the off-vehicle device 104 (e.g., when higher priority resources utilize available bandwidth and / or when data communication limitations, such as data plan restrictions, exist). In certain embodiments, storage of data collection parameters is performed until a storage device component is filled, at which point a portion of the data is purged (e.g., the oldest data, the lowest priority data, and / or the 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 can be configured to keep data that satisfies a higher percentage of the policy requests available. In certain embodiments, the correspondence of data elements to various policy requests is not available to the data storage controller 202, and other criteria are used to determine which data to purge or expire. In certain embodiments, the portion of the data to be purged can additionally or alternatively be compressed and / or summarized to reduce storage utilization. In certain embodiments, the portion of the data to be purged can be downsampled to reduce storage utilization.In certain embodiments, the amenability of particular data elements to compression, summarization, and / or downsampling (amenability may include the required consumption of processing power, the descriptive value of the data in compressed, summarized, or downsampled form relative to the underlying data, or similar considerations) may be taken into account in determining commands from the storage controller in response to a full (or filling) storage component. In certain embodiments, commands to compress, summarize, and / or downsample data in response to a full or filling storage component may also be provided as part of a policy, and / or the policy may include instructions regarding techniques to be utilized for compressing, summarizing, and / or downsampling data when displayed. In certain embodiments, the policy may further include thresholds (e.g., storage value thresholds, time remaining until storage is full, etc.) that indicate when storage purge, compression, summarization, and / or downsampling operations are performed.

[0137] 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 can be configured to determine the amount of available storage based on historical information, such as utilization of the storage component over time, and / or network availability for transferring collected data to the off-vehicle device 104. In certain embodiments, the storage support for the cache component can be defined in a policy. In certain embodiments, the storage support for the cache component may not be utilized. In certain embodiments, the availability of storage support for the cache component can be taken into account by the policy manager in validating the policy.

[0138] In certain embodiments, the data collection controller 202 includes an encryption component configured to encrypt data transmitted to the off-vehicle device 104. In certain embodiments, the data collection controller 202 includes a compression component configured to compress data transmitted to the off-vehicle device 104. The compression can be lossy or lossless, and the type of compression can be determined according to the type of data, a descriptive value of the compressed data, and / or can be determined by a policy. The data collection controller 202 further includes a transmission component configured to transmit the collected data to the off-vehicle device 104, and a transmission controller component that configures transmissions to mediate between competing transmission resources of the vehicle 102 (e.g., to compare relative data priority to other transmission elements, schedule transmissions according to data planning, vehicle operating conditions, and / or support virtual channels utilized by the transceiver), for example, to support a selected data protocol. In certain embodiments, the transmission controller can respond to parsed elements of the policy indicating a data plan value (which can vary between certain data elements, e.g., a first data element associated with a first requester having a first data plan and a second data element associated with a second requester having a second data plan), a transmission priority, and / or a vehicle operating state associated with any of the above.

[0139] 11 , an example first partition 302 is depicted having multiple components configured to functionally perform the operations of the first partition 302. The example first partition 302 includes a load balancing / proxy controller 312 (e.g., a network manager) configured to communicatively interact with the data collection controller 202. The example load balancing / proxy controller 312 interacts using policy communication 1106, consent communication 1108, and data communication 1104 between the vehicle 102 and the off-vehicle device 104. The communications 1104, 1106, 1108 include primary data communication, authentication, validation, etc.

[0140] The exemplary first partition 302 further includes an http component 1102 configured to package received data into a selected data structure for storage (e.g., http in the example of FIG. 11 ). The exemplary first partition 302 further includes a data communications component 308 configured to package the data for storage, and may further include a crypto engine (e.g., utilizing a temporary vehicle key) that decrypts the received data so that the first partition 302 cannot access the data values, a tokenization / anonymization component that reversibly replaces sensitive data with a token, and an encryption component that encrypts the data with a master public key (e.g., the data request / processing component 322 has the master private key). In certain embodiments, the data communications component 308 associates metadata with the stored data so that requests from the data request / processing component 322 can be answered with corresponding data. The exemplary first partition 302 stores the data in raw data storage 320 for access, as authorized, by internal applications 334 and external applications 402.

[0141] The example first partition 302 further includes an MQTT broker that publishes updated policies so that subscribing devices (e.g., data collection controllers 202) receive notification that updated policies are available. In particular embodiments, the first partition 302 can push updated policies to the vehicles 202, and / or the vehicles 202 can periodically request whether policy updates are available and / or can request policy updates in response to particular events (e.g., particular operating conditions, service events, network availability events, etc.).

[0142] 12 , the example second partition 304 includes a policy creator component 1202 for performing operations such as compiling, implementing, creating, and / or storing policies for use in the system. In particular embodiments, the policy creator component 1202 is further configured to publish policy updates, e.g., updating policies to a small number of vehicles before sending policy updates to a larger number of vehicles. The example second partition 304 also includes a data request / processing component 322 having a data processing engine that decrypts received data from the first partition 302 using a master private key, a detokenizing component that recovers tokenized information in the received data, and an encryption component that re-encrypts the data with a temporary key (if authorized) for sharing the data with an 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, and multiple external applications 402, such as a vehicle twin dashboard, a third-party application (of any type), a mobile application, a web-based application, a user consent application, and / or a policy creator user interface.

[0143] The exemplary second partition 304 further includes an application registration portal and application approval workflow components (collectively 1204) that interface with applications and proposed applications to ensure proper authorization, enforce application standards, and the like. The application registration portal and application approval workflow components 1204 further interact with an application authorization database 328 to record application registrations and ensure authorization of access to applications. While the example of Figure 13 depicts authorization communications 1206, authorization communications can be sent between other components of the second partition 304 other than those depicted.

[0144] In certain embodiments, one or more data stores described herein are used to store raw vehicle messages and data and may further include metadata or other information to identify the data at a selected time, such as vehicle identification, a timestamp, an identifier for the data, and / or any other information that enables a system to access the contents of the raw data store at a selected time and utilize the contents of the raw data store for one or more purposes described herein. Raw data may refer to vehicle data communicated off-vehicle (e.g., for a selected period of time) that is stored locally on the vehicle when the data is presented, such as from the data collection controller 202 (see FIG. 2). In certain embodiments, data, such as compressed data, downsampled data, summarized data, aggregated data, or the like, may be at least partially processed and still constitute raw data as described herein. In certain embodiments, data may be meaningfully processed, such as data determined from models, virtual sensors, or the like, and still constitute raw data as described herein. For example, outputs of virtual sensors or models describing basic vehicle parameters such as vehicle speed, ambient air temperature, or the like, may be stored as raw data for use by applications 402, 334 (see FIG. 4, for example). A description of utilizing raw data may include data utilized in a manner as provided by the vehicle and / or as presented to an application 402, 334 as available basic vehicle parameters. A given data value (e.g., vehicle position) may be treated as raw data for a particular system and / or purpose, but not for another system and / or purpose.

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

[0146] Embodiments of the present disclosure provide systems, apparatuses, and methods for operating and / or managing vehicle automation features and / or functions. Embodiments herein enable the addition, deployment, configuration, and / or update of vehicle automation features and / or functions without coding (e.g., algorithm development, compilation, and / or updates of computer-readable instructions, operating system modifications, and / or firmware updates). Embodiments herein enable the addition, deployment, configuration, and / or update of vehicle automation functions using an index of automation recipes, operator interaction, and / or interaction with applications that further interface with operators, owners, service personnel, manufacturers, fleet personnel, and / or OEMs. Embodiments herein support flexible trigger management, initiation, and / or update of vehicle automation features and / or functions, and execution of vehicle automation features and / or functions.

[0147] Embodiments of the present disclosure provide systems, apparatus, and methods for managing and / or operating vehicle remote control augmentations. Embodiments herein enable reduced and / or latency-free vehicle-to-external network communications, for example, utilizing low-power persistent vehicle-to-cloud communications. Embodiments herein enable extensive control capabilities for customer support, customer service, business analytics, manufacturer / OEM application differentiation, consumer applications, customization features, and / or aftermarket features. Embodiments herein enable implementation of remote control augmentations utilizing programmable complex control procedures with high capabilities for secure access to vehicle networks, devices, endpoints, and / or flows, as well as access to auxiliary aspects to enable implementation of high-capability features (e.g., determining support vehicle status, conditions, etc., and / or ensuring mission function is not impaired).

[0148] Embodiments of the present disclosure provide systems, apparatuses, and methods for consistent implementation of an intrusion detection system (IDS) across a network of mobile applications, and may further include integrated implementations across all networks of a mobile application and / or a selected subset of networks. Embodiments of the present disclosure further include implementations of an IDS for mobile applications having external connectivity and data communication and / or functionality that operates at least partially on external devices (e.g., fleet computing devices, cloud servers, etc.). Embodiments of the present disclosure include implementations of an IDS for Ethernet, CAN, and / or vehicle cloud IDS. Embodiments of the present disclosure include generating and / or communicating incident reports, data logs, activity / response descriptions, and / or alerts, and generating data utilized in the incident reports, data logs, activity / response descriptions, and / or alerts. Embodiments of the present disclosure include providing the incident reports, data logs, activity / response descriptions, and / or alerts to selected devices and / or communication flows, including on-vehicle devices, off-vehicle devices, and / or devices associated with a selected entity (e.g., operator, owner, fleet personnel, manufacturer, OEM, service personnel, monitoring application or service, etc.). Embodiments herein include operations for implementing rule-based incident response to IDS operations. Embodiments herein include dynamic configuration and / or updating of IDS operations.

[0149] Embodiments of the present disclosure provide systems, apparatuses, and methods for managing and / or operating shared network storage for mobile applications having multiple associated data storage devices, and / or may further include multiple data storage devices 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 endpoints, devices, applications, and / or flows on a network 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 encryption of at least the stored data. Embodiments herein provide authentication, access control, and auditing of shared network storage operations, including at least scheduled operations according to policy, authorization of participating devices, etc. Embodiments herein provide data lifecycle management of shared storage data, including at least policy enforcement, data retention schemes, and / or prioritization among determined operational states of devices, endpoints, applications, flows, associated services, data types, and / or mobile applications.

[0150] Implementations of the present disclosure are provided as a service-oriented architecture (SOA), enabling 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, and reduced inconvenience due to warranty and / or recall-related work. As used herein, SOA includes the operation of devices, endpoints, applications, and / or flows publishing (e.g., service providers) the availability of services (e.g., available data values, actuator actions, and / or functions) and subscribing (e.g., service requesters) or otherwise requesting available services. Services can be selectively published (e.g., published only to subscribers with sufficient permissions and / or published only by providers with sufficient permissions). Services can have separate permissions on both the publishing and requesting sides, e.g., owners, manufacturers, OEMs, bodybuilders, fleet operators, third-party applications, etc., have separate permissions to publish and / or request services. The service provider and / or requestor may be on-board or off-board.

[0151] Today, traditional vehicle functions are implemented as mission-specific, monolithic code tightly coupled to the underlying middleware, operating system, and hardware of a specific controller (e.g., ECU). SOA architectures enable new applications to reuse data or functionality provided by existing applications across the network, regardless of which ECU they reside on, which network they are associated with, the underlying hardware, OS, middleware, and programming language used. SOA decouples control logic from sensor data and actuators, enabling applications and control functions to be ported to different ECUs. SOA also improves the scalability of overall system functionality by allowing both service providers and consumers to be added / removed and enabled / disabled based on performance, cost tradeoffs, and system changes (e.g., operating conditions, permission changes, subscription changes, etc.). SOA also allows features to be easily added or removed as they become available, decoupling the timing of features from manufacturing or dealer readiness events.

[0152] An exemplary SOA supports the use of AUTOSAR ARA::COM-compliant API interfaces and further includes its extensions. Exemplary characteristics of ARA::COM modules without extensions include the use of a distributed architecture (e.g., each service provider and requester manages the offer, discovery, connection, and interaction with the other party) and, correspondingly, the absence of a readily available method for monitoring or controlling service management activities such as discovery, publishing, subscribing, service start / stop, and / or activity reporting for debugging, diagnostics, or analysis. The lack of centralized management results in excess network traffic, unavailability of services across the network, the requirement that each device individually adapt to service changes, and the lack of an authorization scheme or security for publishing and / or subscribing to services. Furthermore, under ARA::COM, many aspects of the service interface must be statically defined before or during the compilation operation (e.g., service ID, IP address, port number, etc.). Therefore, changing any of the static values ​​requires modifying and recompiling the code, which is tedious and error-prone. Furthermore, the static local registry of a given ECU in different applications across mobile applications can become out of sync due to various error conditions, and recovery from such situations can take a long time or fail completely, resulting in extensive downtime, mission failures, and / or expensive service operations to reconfigure the vehicle's ECUs.

[0153] Exemplary embodiments include a centralized controller for implementing a service-oriented software infrastructure for mobile applications (e.g., SOA). Exemplary functionality includes centralized management of all services (and / or all managed services) in a vehicle using policies maintained and deployed from the cloud. In certain embodiments, all or a portion of the policies can be maintained and / or deployed from an external device coupled to the vehicle, such as a service tool, an OBD device, etc. In certain embodiments, all or a portion of the policies can be maintained and deployed from a user device that can be coupled via the cloud, a web application, a hardware connection (e.g., USB cable, OBD port connection, etc.), and / or another connection, such as a WiFi or Bluetooth connection. In certain embodiments, the ability and / or permissions to update and / or deploy policies may vary depending on the updating entity (e.g., manufacturer, service, owner, warranty implementer, 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. An exemplary centralized controller implements dynamic updates to policies, which can add, update, remove, enable, and / or disable service providers, requesters, service parameters, specific subscriptions, and / or public parameters for services. In particular embodiments, the centralized controller can support policies that utilize, at least in part, static configurations (e.g., cloud connectivity is unavailable or currently unavailable). In particular embodiments, the centralized controller is configured to provide policy information and stores the policies in a data structure that can be stored in a memory location (e.g., flash memory) separate from the OS, boot, or other operational sectors of the centralized controller, allowing parameters to be updated without interrupting basic operations.In certain embodiments, the separation of the policy information may be physical (e.g., a separate memory storage device) and / or logical (e.g., a memory address separate from the base operational address). In certain embodiments, the storage of the policy information may be performed in whole or in part as a shared network storage operation.

[0154] An exemplary centralized controller provides service visibility to a cloud or external tool. For example, the centralized controller can determine and / or store a service map of all services provided and / or consumed on the vehicle. The specific service map shared with the requesting device can be configured according to the requester's permissions (e.g., a clear view for the manufacturer, service entity, fleet owner, security officer, compliance officer, etc.). The exemplary centralized controller determines a log of key service activities in the vehicle (e.g., adding or removing a service, changing subscriptions, changing data providers to a service, etc.). The activities that are key service activities may vary depending on the requester and / or the purpose for using the activity log, and the content of the log can be determined and / or tailored accordingly depending on the requesting device and / or entity. Additionally or alternatively, the sharing of the log and / or the content of the shared log can be configured according to the requester's permissions. The activity log can be utilized for debugging, diagnostics, auditing, compliance determinations, or other purposes.

[0155] Exemplary modes of service connection include full service discovery, publish / subscribe data, and full dynamic connection; assumed service originating but providing publish / subscribe data, and partially dynamic connection; and / or assumed service originating, no publish / subscribe data, and static connection. In particular embodiments, the mode applied to a service connection may be configured according to the authorization of the service connection and / or may be utilized in response to off-nominal behavior (e.g., a service connection may be authorized for full service discovery, but if a service discovery failure occurs, the centralized controller may provide partially dynamic connection as a fallback behavior, and further provide static connection as a fallback behavior if the search for publish / subscribe data fails).

[0156] An exemplary centralized controller operates the SOA manager as a predefined service provider that all endpoints can trust (e.g., consistent network addresses, etc.). Dynamic behavior is managed through the storage of configuration information, including policy information. If the SOA manager determines that an error exists (e.g., an endpoint appears to have moved, gone missing, or becomes intermittently available), the SOA manager responds to the non-nominal condition by querying and restoring configuration information and service connection state.

[0157] The exemplary centralized controller performs security operations for service connections, such as requesting an identifying certificate from a service endpoint before allowing the service connection. The exemplary centralized controller operates a security engine with storage information that defines certificate generation, storage, and validation. The exemplary SOA manager allows or blocks service connections and / or specific operations on service connections based on policies, configuration information, and permissions associated with the service endpoints. Policy information can be dynamically updated.

[0158] The exemplary centralized controller includes an SOA manager that runs extensions on top of selected APIs, such as the ARA::COM module, and also acts as a service provider. The SOA manager configures, controls, and monitors service-oriented communications in the vehicle based on policy and configuration information. The exemplary centralized controller also includes an SOA PLUGIN SDK that includes libraries used by any applications participating in SOA communications, where the library functions communicate with the SOA manager to determine control information, implement controls, and report status and activity to the SOA manager. The exemplary SOA PLUGIN SDK also includes tools to modify the generated client proxy and server skeleton code to support dynamic configuration of service parameters.

[0159] Referring to FIG. 13 , an exemplary system schematically illustrates communication between a centralized controller (ECU), an SOA manager, an SOA PLUGIN, and vehicle controllers (e.g., ECU, ADAS) and external devices (e.g., the cloud). The depicted endpoints (e.g., ECU, ADA) are shown as client or server applications for purposes of illustration. It will be understood that a given application can be a client, a server, or both, depending on the service, the vehicle's operating state, etc. An "IVN" is an in-vehicle network layer and 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. It will be understood that an IVN can encompass mixed networks, such as an Ethernet network and a CAN network, and one or more networks can interface with the SOA manager using a configurable edge gateway or other interface device.

[0160] An exemplary centralized controller includes an AUTOSAR adaptive communication management module (e.g., including IPC, SOMEIP, and / or other protocol bindings), an SOA manager integrated with an ARA::COM module, and an SOA PLUGIN library and code generation tool.

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

[0162] Examples of the present disclosure provide the ability to provide frequent feature upgrades for mobile applications, adding or removing features, and personalized configuration of features. 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.

[0163] Exemplary embodiments allow users to create custom trigger-action rules to automate the vehicle environment, enabling previously unavailable in-vehicle functionality. For example, embodiments herein include customer control of adjustments to cabin temperature, lighting, infotainment, seats, windows, sunroof, cabriolet top, driving modes, and / or any other actuators or vehicle interfaces in response to voice commands, smartphone input, in-vehicle buttons, and / or detected vehicle operating conditions or events.

[0164] An exemplary system includes a centralized controller having an automation manager that determines customized behaviors, including triggering actions (e.g., voice commands; operator input values, such as from an application, personal device, vehicle operator input, and / or vehicle display input; vehicle operating conditions; detected events; and / or combinations thereof). The exemplary automation manager monitors vehicle status to determine whether a triggering action has occurred and commands customized behaviors in response to the occurrence of the triggering action. In certain embodiments, the automation manager may limit the implementation of customized behaviors depending on vehicle conditions (e.g., an “open door” command to open the driver's door may include conditions such as zero vehicle speed, which may be implemented by the user providing the customized behavior or may be implemented elsewhere in the system). In certain embodiments, interactions with certain actuators (e.g., direct vehicle start commands) may be prohibited and / or require additional approval or authorization. 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 the implementing actuator (e.g., if the vehicle has auto-start functionality available on the vehicle, then the customization operation would request implementation of the auto-start functionality rather than providing a direct command to the vehicle's starter), which may have different permissions than those associated with the direct command of the underlying actuator. In certain embodiments, the customized operation data is stored in memory storage on the system, such as configuration information. In certain embodiments, the automation manager restricts the configuration of the customized operation based on the permissions and / or authorizations of the configuration entity (e.g., owner, operator, manufacturer, third-party application provider, etc.) and / or according to permissions associated with the data elements accessed and / or actuators commanded as part of the customized operation.

[0165] To illustrate some of the types of operations that can be supported by embodiments of the present disclosure, exemplary operations are described below. The exemplary operations are non-limiting, and the exemplary automation manager is enabled to respond to any input that can be provided as a network communication and / or a data parameter stored in a computer-readable medium and provide any response that 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.).

[0166] An exemplary customized action includes setting the passenger seat heat in response to the driver double-tapping the driver seat heat switch to set the passenger seat heat. An exemplary action is to return the driver seat heat switch to control the driver seat heat after a short delay (e.g., a few seconds). This exemplary action allows for convenient setting of the passenger seat heat from the driver's side.

[0167] Exemplary customized actions include configuring multiple vehicle aspects in response to a command such as "Hey car, start my morning commute." By way of example, configured vehicle aspects may include tuning the radio to a selected station and volume, setting a preselected navigation destination (e.g., office), setting a vehicle performance mode (e.g., fuel economy mode), setting a driver's seat position (e.g., forward / reverse, height, tilt, lumbar support, etc.), and / or setting HVAC parameters (e.g., selected interior temperature). In certain embodiments, customized actions may further include interactions based on ambient or external conditions, such as utilizing different radio stations depending on the day of the week, adjusting HVAC settings based on ambient temperature, or adjusting navigation depending on the number of people in the vehicle.

[0168] Exemplary customized actions include actions for configuring multiple vehicle aspects in response to system conditions, such as the vehicle's approach to the driver's home at night. In an example, the customized actions implement a workflow that dims the headlights, lowers the radio volume, turns on the lights, sends a message to the home automation system to open the garage door, and retracts the side mirrors as the car enters the garage. In certain embodiments, the vehicle's approach to the 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 network.

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

[0170] An exemplary automation manager (or vehicle automation manager) allows a user to create any trigger-action rule that can be executed on the vehicle, such as by a centralized controller. For example, a user can create a trigger-action rule that automatically turns on high beam headlights when driving at night and there are no oncoming vehicles. An exemplary general flow description of customized operation includes the following:

[0171] Users access an app on their mobile phone or web browser and use it to create custom trigger-action rules or enable pre-defined ones created by the OEM.

[0172] Trigger action rules are sent to the cloud, and activated trigger action rules are aggregated as "recipe" on the cloud side.

[0173] The cloud pushes the recipes to the vehicle through the Vehicle Update Controller (VUC) (e.g., stores configuration information related to the customization operation).

[0174] 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.

[0175] Accounting data (such as the number of times a trigger action rule was executed, trigger event detection, trigger event data, and / or events where an action was triggered but suppressed based on operating conditions) is sent back to the cloud where it can be further reviewed, for example, from a phone app and / or other monitoring application.

[0176] It can be seen that the vehicle automation manager allows users to enrich their vehicle experience without waiting for the feature request, approval, and update process. An 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, a vehicle brand owner (e.g., a manufacturer or OEM) or other sponsor or responsible party can implement trigger-action rules to provide updates or features more quickly and / or more frequently to many users, or even specific users.

[0177] As an example, a Vehicle Automation Manager (VAM) receives recipes from the cloud as input and executes trigger-action rules within the recipe. 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 state, vehicle status, video / audio, driving logs, etc. Some conditions take the trigger's input values ​​and determine whether a certain condition is met.

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

[0179] Referring to FIG. 14, an exemplary automation manager is schematically depicted 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 / WebSocket, etc. The VAM controls vehicle automation based on the recipes and includes 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 trigger execution engine). The automation manager operations, such as those of FIG. 14, can include vehicle automation actions, event-triggered actions, remote control actions, and / or any configurable actions that occur in response to applications, features, triggers, or other automation applications created by manufacturers, OEMs, fleet owners, vehicle owners, vehicle operators, and / or third parties.

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

[0181] In the example of Figure 14, the trigger manager (e.g., as the automation / remote manager in the example of Figure 14) manages triggers from various trigger-related clients, such as vehicle automation, remote control, and / or data collection trigger flows. The example of Figure 14 also includes a data listener that receives data related to the triggers, which may be obtained from any location in the vehicle, such as the CAN bus; Ethernet packets (including EthCC packets with status information such as vehicle location); a diagnostic manager providing DET errors, RDBI data, fault codes, etc.; a system manager (e.g., providing vehicle power status information); a time manager (e.g., providing a current time value); and / or any other information, such as from the SOA.

[0182] In the example of FIG. 14, the data cache stores data for condition evaluation including, for example, buffered data, intermediate parameters, etc.

[0183] 14, the condition evaluation runtime is an engine that evaluates conditions based on trigger values ​​in a cache and determines whether a trigger condition is met depending on the evaluation. Condition evaluation supports any type of analysis or decision operation, including at least the following: basic logical operators (e.g., AND, OR, numeric comparison, etc.); appropriate formatting (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, reducer, min / max, bucket, filtering, integration, derivation, and / or frequency analysis operations, etc.).

[0184] In the example of FIG. 14 , the task execution engine executes actions defined in an action catalog (e.g., actuators adjusted according to customized behavior). Example and non-limiting actions include turning on lights, turning on and / or adjusting HVAC, turning on the ignition, etc. Embodiments of the present disclosure are capable of accessing any actuator reachable through any network, including actuators provided on two or more networks (e.g., Ethernet for one actuator and CAN for another actuator). In certain embodiments, actions include requests for actuator operation (e.g., to another controller having direct control of the actuator), actions requesting the execution of an exposed service, and / or actions with complex interactions that may also reside on multiple other controllers. For example, an action may include adjusting the ambient environment for the current user, which may include, for example, determining the identity of the current user, her preferences, and interacting with multiple controllers and / or flows to adjust the environment, such as seat position, HVAC settings, wireless channel, etc.

[0185] In particular embodiments, the automation manager advertises one or more customized actions as services (e.g., they may be selectable by a requester of the customized action, may be defined in a policy, etc.). In particular embodiments, the automation manager's components, circuitry, controllers, and / or engines may be shared in whole or in part with other managers, such as a remote control manager, and / or may respond to other managers using APIs, library calls, or other interaction interfaces, for example, to determine whether specified data groups and trigger logic (e.g., passed to the automation manager from the other managers) indicate (e.g., as determined by a condition evaluation runtime) that a trigger event has occurred, and / or to perform actions provided by the other managers (e.g., passed to the automation manager from the other managers as action requests) that are implemented (e.g., operated by a task execution engine to move actuators and / or provide appropriate commands to other controllers).

[0186] Implementations of the present disclosure provide for 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. Implementations of the present disclosure provide ease of implementation of customizable behaviors even when data providers and / or actuators are distributed across two or more network types, and do not require the provider for the customizable behaviors to have knowledge of the current configuration of the networks on the vehicle.

[0187] Embodiments of the present disclosure provide the ability to perform remote control operations for mobile applications. Remote control operations for certain functions can be hard-coded into ECU software—for example, simple operations such as starting / stopping the engine, locking / unlocking doors, opening / closing windows and / or sunroofs, etc. However, adding or modifying such functions after production is complete requires code modification and validation, which may include requalifying one or more ECUs participating in the remote function and / or the software build on those ECUs. Embodiments of the present disclosure allow for the configuration of remote control operations for mobile applications at any point in the vehicle's lifecycle, and further allow for the configuration, updating, and fixing of included remote operations at the time of manufacture. Additionally or alternatively, in the presence of a more robust remote control implementation as described herein, previously hard-coded features can be implemented as dynamic functions as described herein.

[0188] An exemplary system for executing remote control and configuration operations includes operating a mobile application control unit in a powered mode during a shutdown vehicle operating state. In certain embodiments, the controller executing the remote control operations includes providing granular power control of centralized controllers and / or other ECUs on the vehicle, leaving only those controllers necessary to execute the remote control operations powered, and operating those controllers and associated hardware components (e.g., boards, chips, cores, voltages, clocks, etc.) in a low-power state capable of receiving remote control commands and configuration requests. In certain embodiments, a remote control manager determines that a vehicle shutdown operation is active and leaves aspects of the vehicle hardware responsive to the remote control command and / or configuration request powered. In certain embodiments, the remote control manager powers down controllers and hardware not necessary for the remote control command and / or configuration request in response to the vehicle shutdown operation. The exemplary remote control manager receives the remote control operation and / or configuration request, wakes up the controllers or hardware necessary to execute the requested function, and then returns the vehicle controllers or hardware to a low-power state.

[0189] Exemplary operations of the remote control manager for performing a vehicle shutdown operation include: · Turn off all controllers except the ECU and cellular modem configured to perform remote control functions; · Stopping all applications and processes in the ECU except those necessary to perform remote control functions; · Stopping all but one core of the ECU and reducing the ECU clock frequency, for example to the minimum allowed value; Determine if any of the following are running, and if not, initiate one of the following (a combination of cloud support and functional / performance testing will indicate which of these is best for your specific application); · Long polling requests; Event requests sent by the server; ·WebSocket request; or HTTP / 2 server push request Putting the cellular modem into low-power mode so that it can receive messages from the server; Exemplary operations of the remote control manager in response to a received remote control request include: · Process message requests and, based on those 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.) required to execute the request (e.g., trigger evaluation engine, task execution engine, etc.); · Turning on enough controllers, such as actuator controllers and other ECUs, to provide control actions corresponding to remote control requests (Ethernet switches, configurable edge gateways, etc.); · Execute remote control requests.

[0190] Upon completion of the remote control request, which may include feedback regarding the operations to service the remote control request (e.g., an acknowledgment, a success indicator, a failure value, etc.), the example remote control manager returns the vehicle to the state of the vehicle when the request was received or to another vehicle status specified in the request.

[0191] An exemplary remote control manager monitors battery levels. In response to the battery charge state 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 a message to an external device (e.g., a cloud, a web application, a user device such as a smartphone) to alert the user of the condition. In certain embodiments, in response to policy, the remote control manager can start the vehicle's prime mover and charge the battery to a second threshold (e.g., a selected amount above the first threshold and / or to a fully charged state). In certain embodiments, the remote control manager shuts down the vehicle and disables remote control support in response to the battery charge falling to the first threshold or another charge value (e.g., below the first threshold). In certain embodiments, the user can be prompted and / or requested to start the vehicle to recharge the battery, for example, in response to a message sent when the battery charge state falls below the first threshold. In certain embodiments, in response to policy and / or user input, the remote control manager maintains the remote function active below a first threshold.

[0192] An exemplary system includes a centralized controller having a remote control manager that determines remote control actions, including command values ​​requesting operation of a remote control function (e.g., from activating a customized response and / or selecting a user-configured response from an application). The exemplary remote control manager activates the controllers necessary to execute the remote control function and performs the function in response to the command. In certain embodiments, the remote control manager accesses a trigger evaluation engine and a task execution engine (e.g., as part of the vehicle automation components of the vehicle, such as those depicted in FIG. 14) to determine that vehicle conditions are consistent with executing an action (e.g., no obstructions to windows or doors to close, no people are in close proximity to the vehicle before starting, etc.) and / or to execute a function to be performed as a remote control action. In certain embodiments, the remote control manager includes or accesses a trigger evaluation engine and / or task execution engine that are separate from other components of the system. This allows the remote control manager to execute a remote control action and / or determine that all or part of a remote control action cannot or is unlikely to be executed. Customized remote control actions, like 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 execution of remote control actions depending on the vehicle status. In certain embodiments, interactions with certain actuators can be prohibited and / or require additional authorization or permission. In certain embodiments, interactions with certain actuators (e.g., a vehicle start command) may embody a request to a vehicle application or flow rather than a direct command of an implementing actuator (e.g., if the vehicle has auto-start functionality available on the vehicle, then the customization action would request implementation of the auto-start functionality rather than providing a direct command to the vehicle's starter), which may have different permissions than those associated with the underlying direct command of the actuator.

[0193] In certain embodiments, the customized remote control operation data is stored in memory storage on the system, such as with configuration information and / or as part of a policy. In certain embodiments, the automation manager restricts the configuration of the customized operation based on the permissions and / or authorizations of the configuration entity (e.g., owner, operator, manufacturer, third-party application provider, etc.) and / or according to permissions associated with the data elements accessed and / or actuators commanded as part of the customized operation.

[0194] To illustrate some types of remote control operations that can be supported by embodiments of the present disclosure, exemplary operations are described below. The exemplary operations are non-limiting, and the exemplary remote control manager is capable of responding to any input that can be provided as a network communication and / or a data parameter stored on a computer-readable medium, and providing any response that 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.).

[0195] An exemplary operation includes receiving a customer configuration of a scheduled acclimatization, where the remote control operation includes starting the HVAC system to a selected state (e.g., a selected temperature and / or use of defrost to keep windows clear) at a scheduled time (e.g., 7:00 AM) on a selected day (e.g., a weekday). In certain embodiments, the customer can configure the operation using an application (e.g., a third-party application), using a cloud or web-based interface, and / or using an application provided by the manufacturer, dealer, etc. In certain embodiments, the operator selects a recipe for the remote control operation (e.g., which may include prompts to set specific parameters and / or may only be instructions or approvals to turn features on or off). In certain embodiments, the operator builds a customized remote control operation, which may be based, for example, on customized operation features present in the vehicle and available in the recipe and / or built entirely by the user interacting with an interface that allows for input of the operation to be performed, any conditions to apply, any threshold settings, etc.

[0196] Exemplary operations include an EV reactive grid compensation mode whereby the electric vehicle is electrically coupled to the grid and the electricity provider utilizes the vehicle's bidirectional charger (e.g., to smooth out power demand spikes). In certain embodiments, the EV reactive grid compensation mode can include scheduling (e.g., time of day, vehicle charging target, day of week, associated pairings thereof, etc.) and / or can be toggled on or off (e.g., turning the feature on long-term when the operator goes on vacation).

[0197] An example operation includes the remote control manager responding to a progressive preconditioning command to heat the vehicle's cabin in a selected sequence, such as using the HVAC to bring the cabin air to a desired temperature and then activating a heated steering wheel and / or heated seat function.

[0198] Exemplary operations include the steps of the remote control manager responding to a user setting request and adjusting vehicle settings (e.g., steering column position, ambient light color, interior / dash light brightness, UI / UX style selection, etc.) in response to the user setting request.

[0199] Exemplary operations include vehicle management to reduce vehicle management settings (e.g., valet mode, borrowed vehicle mode, a set mode for a child of a parent owner when driving the vehicle, etc.), vehicle speed limits, location limits (e.g., limits with a defined area such as a 500m geofence perimeter from the launch location, city limits, and / or outside a defined area such as a state border, another city limit, total distance from the launch location, etc.), etc. The vehicle management setting application limits can be actual application limits (e.g., maximum speed, performance value, etc.) or notification limits (e.g., typically geographic limits can be implemented as notification limits rather than stopping limits), and a notification is sent to the owner and / or selected devices when the vehicle management setting limit is exceeded (and / or tested against the actual application limit, etc.).

[0200] Exemplary operations include, for example, a security mode that requests data from cameras, microphones, vehicle displays, dashboards, etc., as required by the security mode. In certain embodiments, a user can select one or more devices (e.g., particular cameras and / or locations within or relative to the vehicle) and can receive streaming video and / or snapshots from the selected devices. In certain embodiments, the security mode enables data requests from devices communicatively coupled to the vehicle, such as security cameras of a home security system in communication with the vehicle (see, e.g., customization operations above).

[0201] Example actions include personalized actions, such as, for example, playing "Happy Birthday to You" and / or activating cabin lights when the driver enters the vehicle on their birthday. Additionally or alternatively, the personalized action can be any type of action, such as, for example, playing a song or playlist selected for a given calendar date, day of the week, etc., reminding the driver of a calendar event (e.g., a link to a calendar function on a smartphone, etc.) upon entering the vehicle, anniversaries, etc., and / or reminding the driver of a scheduled stop (e.g., picking up groceries when entering the vehicle to return home from work), etc.

[0202] Example and non-limiting remote control operations allow for determining complex conditions (e.g., utilizing CAN data, location, time, date, etc.) in either determining the conditions for performing the remote control operation and / or performing the remote control operation. Example and non-limiting remote control operations include a scheduled sequence of multiple operations, including determining the conditions when a first scheduled operation is completed and a next operation is to be performed.

[0203] Example and non-limiting remote control actions include performing one or more of the following: sending a note to an operator, displaying a note on the vehicle display, and / or announcing a note over a speaker; taking snapshots from one or more cameras and sending them to the operator and / or requester; allowing a third-party service (e.g., a mobile refueling, vehicle service, and / or delivery company) access to the vehicle location and door status, but under certain conditions (e.g., selected times of day, until the completion of an event, and / or in response to the third-party service's proximity to the vehicle); initiating startup actions on the vehicle, controller, head unit, etc. when an operator approaches; reacting to environmental changes by defrosting the vehicle (e.g., in response to frost accumulation, determination of ambient temperature, etc.); and / or running scheduled tests for diagnostic purposes (e.g., running active diagnostic tests when the operator is away from the vehicle to reduce the impact of the tests on the vehicle's mission).

[0204] Exemplary remote control actions include preconditions, tasks, and / or status reports. Preconditions include any combination of vehicle status, CAN signals, Ethernet packets, information stored in a computer-readable medium (e.g., log information, trip information, and / or other vehicle information stored in a memory location), time and / or date, location, etc., used as precondition trigger conditions for the remote action, and can be configured as complex logical expressions and further configured based on multiple conditions. Tasks include actions that can be performed using CAN signals, Ethernet packets, or other network communications, including at least any of the actions described above under customized actions. Status reports include confirmation information, confirmation that an action was performed and / or notification that an action was not performed, associated data, confirmation data, usage data related to the remote control action, etc. 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 the operation, a service representative may receive a more detailed status report including parameters related to the operation, and a manufacturer may receive a detailed status report with personally identifiable information removed (e.g., to aggregate reliability data while allowing data storage and aggregation without managing personally identifiable information). The presence and / or content of prerequisites, tasks, and / or status reports may be provided and / or updated by user input, policy, and / or configuration information.

[0205] The exemplary remote control solution supports different element combinations of a remote control request, for example, as reflected in the exemplary code snippet for the request. If (preCondition1 is true) { do(Task1); report(Status1); If (preCondition2 is true) { do(Task2); report(Status2); do(Task3); report(Status3); ......

[0206] The example remote control solution supports specifying the final vehicle status (the state the vehicle should return to) after all remote control functions are completed (driving state, cabin settings, charging state, etc.). This vehicle status can be different from the vehicle status when the request was received, and is configurable and programmable just like tasks.

[0207] Referring again to FIG. 14 , an exemplary remote control manager is depicted schematically and, although part of the centralized controller in the example embodiment, the remote control manager can be a separate device and / or located on another device. The interface to the CAN controller can be 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 description. The task execution engine and / or trigger evaluation engine can be located, in whole or in part, in another device or controller, such as an automation manager, can be shared between the remote control manager and the automation manager, and / or the remote control manager and automation manager can each have a separate trigger evaluation engine and / or task execution engine (if present).

[0208] 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 automobiles become connected and more applications and services gain legitimate access to vehicles, the attack surface increases. To make matters worse, "bad actors" are increasingly turning to hacking into vehicle infrastructure to steal personal information or intellectual property, extort money using ransomware, or disrupt vehicle operations.

[0209] Network firewalls are a fundamental requirement for network security. Layer 5-7 "proxy" firewalls add more advanced protection but are still insufficient to defend against advanced attacks. Intrusion detection systems can identify suspicious behavior that appears to be genuine activity by trusted entities. However, using multiple IDS solutions from different vendors in different parts of the network makes it difficult to provide consistent and complete security across the entire system. A single, integrated IDS solution is most effective because it provides complete visibility into all traffic—incoming, outgoing, and internal—allowing it to inspect data flows across the entire 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.

[0210] OEMs benefit from enhanced security features, faster response to intrusions, and greater customer loyalty, while customers benefit from safer vehicles and more personal data protection.

[0211] To illustrate some of the types of operations that can be supported by embodiments of the present disclosure, exemplary operations are described below. The exemplary operations are non-limiting, and an exemplary unified IDS manager can detect intrusive operations that access or attempt to access a network according to any aspect of the present disclosure.

[0212] An exemplary unified IDS manager can monitor DNS, HTTP, and HTTPS access from any endpoint within the vehicle and detect ECUs in the vehicle that have been infected with ransomware and / or spyware, causing the ECU to begin downloading malicious software packets and / or uploading private or proprietary data to external servers over secure connections. In this embodiment, by maintaining visibility of the traffic to the unified IDS manager (e.g., a centralized controller), problems can be detected quickly and communications with external rogue servers can be blocked.

[0213] An exemplary unified IDS manager allows for urgent software updates to be made to ECUs, for example, to patch vulnerabilities observed by researchers, third parties, and / or during operation. The unified IDS manager also allows for monitoring communications from vulnerable ECUs and blocking or mitigating them until the vulnerability is fixed. In an embodiment, a vulnerability may be discovered in a mission-critical ECU, or in another ECU in the vehicle, and the vulnerability may be exploited to gain access to the mission-critical ECU. In an embodiment, centralized management of network communications allows for superior mitigation of vulnerabilities, rapid implementation of updates in a single location (e.g., a centralized controller), and configuration files, policy information, certificate information, etc., can be stored outside of the base operating system, allowing many updates to be made without significant downtime for implementation of updates and / or validation or re-certification of ECUs when major software builds are otherwise required.

[0214] The exemplary unified IDS manager detects incoming communications (e.g., from malicious actors on a cellular network) requesting vehicle propulsion system access, which may be on the CAN bus. The exemplary unified IDS manager detects the attack, prevents the requested access to the CAN bus, and / or provides an alert to a customer and / or a monitoring service.

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

[0216] From a technical point of view, a centralized intrusion detection system, where signals / packets and messages are analyzed and processed in the same place, is fundamental for early detection of potential attack vectors and for creating a safer and more secure vehicle environment.

[0217] The example integrated IDS manager provides mechanisms and policies for inspecting traffic within the vehicle as well as traffic entering and leaving the vehicle. Internal traffic consists of automotive Ethernet data and CAN data.

[0218] Inspecting Internal Traffic Detect malfunctioning, modified, and / or malicious ECUs Detect anomalies in vehicle functions and provide context External traffic inspection Inspects outgoing and incoming traffic to detect unconfigured protocols Inspects incoming and outgoing traffic protocols such as DNS and HTTP to identify user behavior and detect suspicious behavior and policy violations. Inspect HTTPS headers for domain access and certificate violations

[0219] An exemplary integrated IDS manager would use protocol analysis, signature-based, and anomaly-based techniques to detect intrusions. The integrated IDS would have the ability to securely send alerts based on configuration. Alerts can be used to trigger further action, such as stopping connections or notifying relevant users or services. Anomalies can also be logged, which can be used for further analysis.

[0220] Referring to FIG. 15 , an implementation for an 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 a port on an Ethernet network, for example, as encapsulated CAN messages, which can include processed payload data, added frame data (e.g., timestamps or other metadata), CAN frame data included or removed, and / or processed CAN frame data. In a particular embodiment, a CAN exporter provides compressed metadata to the integrated IDS manager to conserve bandwidth.

[0221] An exemplary integrated IDS manager analyzes three types of traffic (e.g., in the Packet Parsing block). The example packet parsing block includes parsers for the Ethernet, IP, ARP, ICMP, TCP, UDP, HTTP, HTTPS, DNS, CAN, and EthXX protocols. Any protocol can be supported as needed. The 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 efficiently detected. An example of a violation that can be detected by protocol analysis is an invalid TCP flag combination caused by a port scanning application running on the ECU.

[0222] An example of an integrated IDS manager is a connection management block that analyzes security vulnerabilities at the connection level. The definition of a "connection" depends on the protocol being considered. The connection management maintains the association of various connections, such as: Ethernet / VLAN (Source MAC, Destination MAC, VLAN ID) IP (source and destination addresses, protocols) TCP / UDP (source and destination addresses, source and destination ports, and protocols)

[0223] A connection database is maintained to keep track of all connections. Metadata and statistics collection is performed to analyze and update the connection database. Whenever a new connection is detected, it is added to the connection database and packet statistics are updated. For all subsequent packets of a given connection, the statistics are simply updated. Any metadata extracted from the packets is also added to the connection database. For example, the state of a TCP connection is metadata kept in the connection database for TCP connections. TCP reassembly, if necessary, is done as part of this block.

[0224] The signature-based detection block performs signature-based detection checks against known attacks by examining the data using known signatures or rules for known attacks. The rules are enforced on a packet-by-packet and also at the connection level. For example, a DNS packet over 512 bytes is a violation. The signatures are configured or optimized for vehicular traffic and are designed to target and detect vehicle-related attacks. They will have a low memory footprint.

[0225] The Anomaly-Based Detection block operates on communications when clearly defined rules are not available and / or as a rationality check, and is primarily used for unknown violations. A traffic baseline is maintained using traffic patterns (either learned from data or using ethDB), and deviations from the baseline trigger a violation. A feedback scheme is used to learn from the detection results and reduce false positives.

[0226] The Log and Alert Management block records detected events. Some of the events will result in an alert, depending on the severity and / or frequency of the event. Examples of alerts include selected information about the event, such as: Timestamp ID Importance level Protocols - 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 upon request. Logs are sent via secure HTTPS. The Integrated IDS Manager provides configuration services to allow remote clients to control IDS functionality. Examples of configuration options include: - Enabling or disabling IDS functions IDS functionality: Configuring the severity of various events to generate alerts that are sent to remote collectors Signature-based IDS rule configuration Inclusion or exclusion of specific data sets in intrusion detection Aspects of the unified IDS manager may be implemented externally, such as in a cloud application, and / or the cloud application or other external application may selectively communicate with the unified IDS manager to support one or more functions such as: Managing IDS policies in a given vehicle Collecting IDS alerts from a given vehicle and (potentially) passing them to a selected location (e.g., a Security Operations Center (SOC)) for further processing. Provide secure access to alerts, events and notifications to relevant stakeholders for further action.

[0227] An example of an integrated IDS also inspects external traffic. External traffic refers to traffic entering or leaving the vehicle. A firewall operating on this traffic can block all connections based on rules, but the firewall is limited by rules. While the vehicle network is static and rules are easy to establish, one of the ECUs (e.g., any controller, processor, and / or computing device on the vehicle) may become infected with some intrusive software, which could result in the following:

[0228] An infected ECU can connect to authorized servers and waste bandwidth on external network connections.

[0229] Infected ECUs and software can overwhelm cloud servers and launch DDoS attacks on them.

[0230] The software controls the vehicle and could be subject to attacks such as ransomware.

[0231] They could install spyware, collect data inside the car, and violate the privacy of passengers.

[0232] Firewalls operate based on rules and do not look for patterns of abnormal behavior. The integrated capabilities of IDS and firewalls are complementary and both are essential to ensure the highest level of security.

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

[0234] Table 1 Example of data / metadata from an integrated IDS TIFF2023516760000002.tif135157

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

[0236] As OEMs enhance vehicles with advanced features and rich content, the amount of data in vehicles is growing exponentially. This data needs to be stored in the vehicle, either temporarily or long-term, before it can be consumed or transmitted elsewhere. Unfortunately, in traditional E / E architectures, memory is embedded in the ECU and generally not accessible to other ECUs, making data sharing, protection, and storage difficult. Centralized and / or distributed shared storage enables the centralization of vehicle functions and hardware resources, reducing the complexity and cost of storing larger amounts of data, reducing redundancy in stored data, and more.

[0237] Shared network storage enables more efficient data collection, storage, and sharing by in-vehicle apps and services, more effective data security and backup, and new solutions such as over-the-air (OTA). OEMs can benefit from reduced overall memory costs, improved safety 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 vehicle input costs.

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

[0239] An exemplary shared storage controller includes storing vehicle status information, such as camera footage from a camera 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., a customer receives a notification that her parked car has been crashed and requests that the data be stored, which may include prompting the customer to store the data) and / or according to event detection rules (e.g., a rule indicating that the camera data buffer is to be stored in response to detecting an impact while parked, etc.). In an embodiment, the customer may subsequently retrieve (and / or provide to an insurance carrier, police, etc.) data including video footage from the minutes prior to the impact.

[0240] An exemplary shared storage controller includes steps for storing configuration information for ECUs in the system, such as images of software installation updates for head units. In an example, if an ECU fails to update and the customer indicates that the vehicle's operation is preferable to another attempt at that time, the ECU with the failed update can revert to a previous installation and an image with the update is stored for installation at a later time. In certain embodiments, the shared storage controller may delete the image with the update program after successful installation of the update program for the ECU.

[0241] An exemplary shared storage controller includes downloading media (e.g., movies, games, music, audiobooks, etc.), for example, when cellular data is readily available, when WiFi or another relatively unlimited external data connection is available, and / or upon request by a user. In embodiments, a request for downloaded media can be made using a user device (e.g., a mobile device, a web application, etc.) and / or a vehicle display such as a head unit. In embodiments, a passenger can then watch movies, play games, or otherwise access the media without being interrupted by a slow or intermittent cellular connection and / or without incurring cellular download costs. In embodiments, 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 (e.g., rolling out older or least used media to make space for additional downloads, etc.).

[0242] An exemplary shared storage controller caches data for external communication, e.g., collected data according to policies, event detection, and / or data collection requests, and communicates the data at a later time. Thus, external data communication can ...

Claims

1. 1. An apparatus comprising: a policy retrieval circuit configured to interpret vehicle policy data values ​​including a location description value; a policy processing circuit configured to generate parsed policy data, the parsed policy data including a vehicle data collection description, in response to and based at least in part on the vehicle policy data values; a policy enforcement circuit configured to collect vehicle data from one or more endpoints in at least one network zone of the vehicle in response to the parsed policy data; An apparatus comprising:

2. The apparatus of claim 1 , wherein the location description values ​​include at least one description selected from the following descriptions: a geographic location value, a jurisdiction value, a relative location value, or a defined geographic area value.

3. The apparatus of claim 1 , wherein the policy enforcement circuitry is further configured to regulate the collection of the vehicle data as a function of the location description value.

4. The apparatus of claim 3 , 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.

5. The apparatus of claim 3 , 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.

6. The apparatus of claim 3 , wherein the policy enforcement circuitry is further configured to adjust a format of at least a portion of the vehicle data depending on the location description value.

7. The apparatus of claim 3 , wherein the policy enforcement circuitry is further configured to modify collected parameters in response to the location description values.

8. The apparatus of claim 3 , 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.

9. The apparatus of claim 3 , 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.

10. The apparatus of claim 9 , wherein the priority comprises an in-vehicle data storage priority.

11. The apparatus of claim 9 , wherein the priority comprises a transmission priority.

12. The apparatus of claim 9 , wherein the priorities include an in-vehicle transmission priority corresponding to at least one network zone of the vehicle.

13. the vehicle policy data values ​​further include vehicle status data; The vehicle further comprises: 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, the policy enforcement circuitry is further configured to adjust the collecting of the vehicle data in response to the vehicle status data collection change value; or the vehicle data transmission circuitry is further configured to adjust the transmission of at least a portion of the collected vehicle data in response to the vehicle status data collection change value. a vehicle status data adjustment circuit, The apparatus of claim 1 further comprising:

14. The apparatus of claim 13 , wherein the vehicle status data conditioning circuitry is further configured to interpret the vehicle status data collection change value as a function of a location description value.

15. The apparatus of claim 14 , wherein the location description values ​​include at least one description selected from the following descriptions: a geographic location value, a jurisdiction value, a relative location value, or a defined geographic area value.

16. The apparatus of claim 14 , wherein the policy enforcement circuitry prevents collection of at least a portion of the vehicle data responsive to the vehicle status data collection change value.

17. The apparatus of claim 14 , wherein the policy enforcement circuitry initiates collection of at least a portion of the vehicle data responsive to the vehicle status data collection change value.

18. The apparatus of claim 14 , wherein the policy enforcement circuitry adjusts a 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.

19. The apparatus of claim 14 , wherein the policy enforcement circuitry adjusts a priority associated with at least a portion of the vehicle data responsive to the vehicle status data collection change value.

Images