EP4097923A1 - Système, procédé et appareil pour la gestion de collecte de données de véhicule - Google Patents

Système, procédé et appareil pour la gestion de collecte de données de véhicule

Info

Publication number
EP4097923A1
EP4097923A1 EP21764127.3A EP21764127A EP4097923A1 EP 4097923 A1 EP4097923 A1 EP 4097923A1 EP 21764127 A EP21764127 A EP 21764127A EP 4097923 A1 EP4097923 A1 EP 4097923A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
value
data
policy
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21764127.3A
Other languages
German (de)
English (en)
Other versions
EP4097923A4 (fr
Inventor
Yu Fang
Yixiang Chen
Xuanran Zong
Robin Reed
Troy Michael TRENCHARD
Thurston Zhu
Sudhir Ramphal DHANKHAR
Jeffrey Chou
Felipe Andres Valdes VALENZUELA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sonatus Inc
Original Assignee
Sonatus Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/027,167 external-priority patent/US11411823B2/en
Application filed by Sonatus Inc filed Critical Sonatus Inc
Publication of EP4097923A1 publication Critical patent/EP4097923A1/fr
Publication of EP4097923A4 publication Critical patent/EP4097923A4/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H04L12/2827—Reporting to a device within the home network; wherein the reception of the information reported automatically triggers the execution of a home appliance functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/41—Flow control; Congestion control by acting on aggregated flows or links
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Definitions

  • U.S. Application Serial No. 17/027,167 claims benefit of priority to the following provisional applications: U.S. Application Serial No. 62/903,462, filed September 20, 2019 entitled SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK (SONA-0001-P01); U.S. Application Serial No. 62/911,249 filed October 5, 2019 entitled SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK (SONA- 0002-P01); U.S. Application Serial No.
  • U.S. Application Serial No. 17/027,187 claims benefit of priority to the following provisional applications: U.S. Application Serial No. 62/903,462, filed September 20, 2019 entitled SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK (SONA-OOOl-POl); U.S. Application Serial No. 62/911,249 filed October 5, 2019 entitled SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK (SONA- OOOl-POl); U.S. Application Serial No.
  • Vehicle communication networks are utilized to connect sensors, actuators, controllers, user interfaces, rider personal devices, trailers, and communication devices throughout a vehicle.
  • Recent trends have been increasing the burden on these vehicle communication networks, with more devices being connected, more data passing between devices, lower latency requirements to meet vehicle performance, safety, and emissions requirements, and added vehicle features.
  • consumers expect increasing connectivity, reduced driver burden, and features that increase the burdens on vehicle communication networks. These trends are expected to continue, and to accelerate, for the foreseeable future.
  • CAN Controller Area Network
  • CAN Controller Area Network
  • a modem vehicle may have multiple network buses, with specific commands and communications available, and limited customization and data speed available.
  • CAN buses typically operate at up to about 1 Mbps, with high capability CAN buses operating up to about 10 Mbps. Additionally, CAN buses experience latency greater than 25 ms, and generally higher from about 60 ms to 500 ms, depending upon the configuration, the traffic on the CAN, the priority for particular messages, and the like.
  • Data collection from vehicles includes a number of additional challenges.
  • data collection operations are subject to regulation and liability risks, especially with data collection that may include private or personally identifiable information.
  • Data collectors including entities that may have ownership or possession of sensitive data are subject to risk while holding data, for example in the event of inadvertent or malicious access to the data.
  • vehicle data being collected, a large amount of data may be collected, and a large number of purposes for collecting the data may be present, increasing the risks relative to other general data storage applications. Accordingly, it may be desirable to control data collection, storage, and access, to reduce risks, and it may further be desirable to include verification of data access, partitioning or other exclusion of data when the data is not being used, and the like.
  • applications utilizing the data continue to increase in sophistication and capability, increasing the data demand for the limited available transfer resources, and increasing the cost and complexity of logistical control and storage of the transferred data.
  • higher capability pathing or operation algorithms related to the vehicle increasing automation of vehicle functions, increasing demand for prognostic determinations and/or maintenance support, and increasing media streams (both the number of media streams and the quality of those media streams) all drive for increased demand in data rates, stored data amounts, and the number of entities or applications accessing the stored data.
  • the increasing number of entities or applications accessing the data increases the likelihood that individual data requests will overlap - for example with multiple entities requesting the same or similar data. Further, the increasing number of entities or applications accessing the data increases the likelihood that members of the accessing group will share similar authorization levels, such that the data access for individual members of the entity or application group require data management.
  • regulations regarding sensitive data are increasing, which increases the data management requirements of the system generally, but also increases the likelihood that data management may be subjected to multiple constraints at a given time, and/or changing constraints over time as regulations change.
  • the complex environment of presently known and transitioning vehicle network architectures increase the complexity of data access for individual entities that, without certain aspects of the present disclosure, may otherwise be required to determine requesting parameter specifications for particular data elements, and to update those requesting parameters as vehicle network architectures evolve.
  • the aggregate cost to the automotive support market increases non-linearly, as each of the entities incurs the costs to track requesting parameter specifications.
  • the trajectory of additional entities requesting data access is moving toward entities that are positioned further away in the technological knowledge space from core automotive functions, and accordingly the intricacies and idiosyncrasies of vehicle and/or automotive applications, including on-vehicle network configurations, specific data descriptions, data requesting and communication protocols, industry standards or customs for presenting information, and the like, are becoming less well known on average for each incremental new entity, further increasing the cost volume function (e.g., the cost over time for a given entity to meet desired data collection deliverables, where the given entity may be an automotive manufacturer, and/or a vehicle market, a geographic market, and/or an industry such as the automotive industry, the passenger car industry, etc.).
  • cost volume function e.g., the cost over time for a given entity to meet desired data collection deliverables, where the given entity may be an automotive manufacturer, and/or a vehicle market, a geographic market, and/or an industry such as the automotive industry, the passenger car industry, etc.
  • COST # of entities * basic learning cost * adapting to transition cost trajectory * data trajectory cost * regulatory adaptation cost * data access/storage liability cost
  • COST # of entities * basic learning cost * adapting to transition cost trajectory * data trajectory cost * regulatory adaptation cost * data access/storage liability cost
  • the described COST function is anon-limiting notional example to demonstrate how various challenges and complications with regard to presently known systems interact and synergize to increase the costs to meet future data collection functions for vehicle applications.
  • the cost parameters described are not intended to cover all costs related to the challenges present for the automotive data collection industry or presently known systems. Parameters may be averages or other complex functions, and the values of particular parameters will generally not be known with specificity.
  • the units of the COST may be expressed in monetary values, as a resource (e.g., engineering hours, computation time, etc.) to meet data collection targets over time, as another non-monetary unit such as equivalent emissions, customer satisfaction, risk incurred, public perception losses or gains, etc.
  • a resource e.g., engineering hours, computation time, etc.
  • another non-monetary unit such as equivalent emissions, customer satisfaction, risk incurred, public perception losses or gains, etc.
  • the # of entities parameter reflects generally the number of entities accessing vehicle data over time;
  • the basic learning cost reflects the costs for new entities to leam the specifics of data collection requirements and protocols for a specific vehicle, vehicle type, market, etc.;
  • the adapting to transition cost trajectory reflects the costs to adapt to changing vehicle network configurations, including network types and organization;
  • the data trajectory cost reflects the increasing demand for data collection from relevant vehicles over time, including data communication, storage, and resulting functional consequences such as not being able to support a desired application or costs to enhance data communication infrastructure;
  • the regulatory adaptation cost reflects the costs associated with an increasing number of regulations, an increasing number of regulatory frameworks, and/or an increasing number of regulating entities;
  • the data access/storage liability cost reflects the costs incurred for compliance and security of data, and/or losses incurred due to data breaches, unauthorized use, or the like.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including a driver information description; a policy processing circuit structured to generate, in response to and based at least in part on the vehicle policy data value, parsed policy data that includes a vehicle data collection description; and a policy execution circuit structured to collect vehicle data from one or more end points of at least one network zone of a vehicle in response to the parsed policy data.
  • the one or more end points include end points positioned on at least two network zones of the vehicle.
  • the driver information description includes a description of vehicle data to be collected based on a driver characteristic.
  • the policy execution circuit is further structured to interpret driver information corresponding to a present driver of the vehicle, and to collect vehicle data in response to a comparison of the driver characteristic with the driver information corresponding to the present driver of the vehicle.
  • the driver information description includes a description of monitoring data for a driver of the vehicle.
  • the driver information description further includes the description of monitoring data for the driver based on a driver characteristic.
  • the driver information description further includes a trigger condition, and wherein the policy execution circuit is further structured to collect vehicle data further in response to the trigger condition.
  • the trigger condition includes at least one condition selected from the conditions consisting of an event detection condition; a 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.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including a device condition description; a policy processing circuit structured to generate, in response to and based at least in part on the vehicle policy data value, parsed policy data that includes a vehicle data collection description; and a policy execution circuit structured to collect vehicle data from one or more end points of at least one network zone of a vehicle in response to the parsed policy data.
  • the one or more end points include end points positioned on at least two network zones of the vehicle.
  • the device condition description includes a description of vehicle data to be collected based on at least one of a device fault value or a device diagnostic value.
  • the device condition description includes a description of monitoring data for a device of the vehicle.
  • the vehicle data collection includes a description of the monitoring data for the device based on at least one of a device fault value or a device diagnostic value.
  • the device corresponds to the at least one of a device fault value or a device diagnostic value.
  • the device includes a separate device from a device corresponding to the 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 condition 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 for a separate device from a device corresponding to the at least one of a device fault value or a device diagnostic value.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including an end point performance description; a policy processing circuit structured to generate, in response to and based at least in part on the vehicle policy data value, parsed policy data that includes a vehicle data collection description; and a policy execution circuit structured to collect vehicle data from one or more end points of at least one network zone of a vehicle in response to the parsed policy data.
  • the one or more end points include end points positioned on at least two network zones of the vehicle.
  • the end point performance description includes a first data value to be collected in response to a target end point being in a first condition, and a second data value to be collected in response to the target end point being in a second condition.
  • the target end point in the first condition includes a first vehicle configuration
  • the target end point in the second condition includes a second vehicle configuration.
  • the target end point in the second condition includes the target end point determined to be in an off-nominal condition.
  • the off-nominal condition includes at least one condition selected from the conditions consisting of: a failed condition, a faulted condition, a non-responsive condition, or a lost communication condition.
  • the target end point in the first condition includes a first target end point configuration, and wherein the target end point in the second condition includes a second target end point configuration.
  • the first data value includes data to be collected from a first end point group, and wherein the second data value includes data to be collected from a second end point group.
  • the first end point group and the second end point group include at least one distinct data value for collection.
  • the first end point group and the second end point group include at least one distinct end point.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including a location description value; a policy processing circuit structured to generate, in response to and based at least in part on the vehicle policy data value, parsed policy data that includes a vehicle data collection description; and a policy execution circuit structured to collect vehicle data from one or more end points of at least one network zone of a vehicle in response to the parsed policy data.
  • 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 execution circuit is further structured to adjust the collection of vehicle data in response to the location description value.
  • the policy execution circuit is further structured to prevent collection of at least a portion of the vehicle data in response to the location description value.
  • the policy execution circuit is further structured to commence collection of at least a portion of the vehicle data in response to the location description value.
  • the policy execution circuit is further structured to adjust a formatting of at least a portion of the vehicle data in response to the location description value.
  • the policy execution circuit is further structured to change parameters collected in response to the location description value.
  • the policy execution circuit is further structured to add or modify metadata to at least a portion of the vehicle data in response to the location description value.
  • the policy execution circuit is further structured 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-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.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including vehicle status data; a policy processing circuit structured to generate, in response to and based at least in part on the vehicle policy data value, parsed policy data that includes a vehicle data collection description; a policy execution circuit structured to collect vehicle data from one or more end points of at least one network zone of a vehicle in response to the parsed policy data; and a vehicle data transmission circuit structured to transmit at least a portion of the collected vehicle data in response to a data type of the collected vehicle data.
  • 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 aggregated data type.
  • the policy execution circuit is further structured to adjust the collection of vehicle data in response to the data type of the collected vehicle data.
  • the policy execution circuit is further structured to prevent collection of at least a portion of the vehicle data in response to the data type of the collected vehicle data.
  • the policy execution circuit is further structured to commence collection of at least a portion of the vehicle data in response to the data type of the collected vehicle data.
  • the policy execution circuit is further structured to adjust a formatting of at least a portion of the vehicle data in response to the data type of the collected vehicle data.
  • the policy execution circuit is further structured to adjust a priority associated with at least a portion of the vehicle data in response to a location description 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 is further structured to adjust a priority associated with at least a portion of the vehicle data in response to the data type of the collected vehicle data.
  • 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 policy execution circuit is further structured to determine the data type of the collected vehicle data in response to at least one of: an end point providing an associated vehicle data; an end point requesting the associated vehicle data; an entity requesting the associated vehicle data; an application associated with an end point providing the associated vehicle data; an application associated with a request of the vehicle data; a flow associated with an end point providing the associated vehicle data; a flow associated with a request of the vehicle data; or an indicated data type provided in the vehicle policy data value for the vehicle data.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including vehicle status data; a policy processing circuit structured to generate, in response to and based at least in part on the vehicle policy data value, parsed policy data that includes a vehicle data collection description; a policy execution circuit structured to collect vehicle data from one or more end points of at least one network zone of a vehicle in response to the parsed policy data; a vehicle data transmission circuit structured to transmit at least a portion of the collected vehicle data; and a vehicle status data adjustment circuit structured to interpret a vehicle status data collection change value, and wherein at least one of: the policy execution circuit further structured to adjust collecting vehicle data in response to the vehicle status data collection change value; or the vehicle data transmission circuit further structured to adjust transmitting the at least a portion of the collected vehicle data in response to the vehicle status data collection change value.
  • the vehicle status data adjustment circuit is further structured to interpret the vehicle status data collection change value in response to an operating condition of the vehicle.
  • the vehicle status data adjustment circuit is further structured to interpret the vehicle status data collection change value in response to an event occurrence.
  • the vehicle status data adjustment circuit is further structured 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 wherein the vehicle status data adjustment circuit is further structured to determine the event occurrence in response to the trigger condition.
  • the trigger condition includes at least one condition selected from the conditions consisting of: an event detection condition; a vehicle status value; or a vehicle operating condition value.
  • the vehicle status data adjustment circuit is further structured 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 execution circuit is responsive to the vehicle status data collection change value to prevent collection of at least a portion of the vehicle data in response to the location description value.
  • the policy execution circuit is responsive to the vehicle status data collection change value to commence collection of at least a portion of the vehicle data in response to the location description value.
  • the policy execution circuit is responsive to the vehicle status data collection change value to adjust a formatting of at least a portion of the vehicle data in response to the location description value.
  • the policy execution circuit is responsive to the vehicle status data collection change value 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-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 is responsive to the vehicle status data collection change value to adjust a priority of the at least a portion of the collected vehicle data in response to the location description value.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including vehicle status data, and to update a data collection policy in response to the vehicle policy data value; a policy processing circuit structured to generate, in response to and based at least in part on the updated data collection policy, parsed policy data that includes a vehicle data collection description; a policy execution circuit structured to collect vehicle data from one or more end points of at least one network zone of a vehicle in response to the parsed policy data; and a vehicle data transmission circuit structured to transmit at least a portion of the collected vehicle data.
  • the data collection policy includes a built-in policy, wherein the vehicle policy data value includes one of a factory policy or a downloaded policy, and wherein the policy acquisition circuit is further structured 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, wherein the vehicle policy data value includes one of a factory policy or a downloaded policy, and wherein the policy acquisition circuit is further structured to update the data collection policy by: generating an update policy by adding compatible portions of the built-in policy to a policy determined in response to the vehicle policy data value; and replacing the data collection policy with the update policy.
  • the data collection policy includes a factory policy, wherein the vehicle policy data value includes a downloaded policy, and wherein the policy acquisition circuit is further structured 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 factory policy, wherein the vehicle policy data value includes a downloaded policy, and wherein the policy acquisition circuit is further structured to update the data collection policy by: generating an update policy by adding compatible portions of the factory policy to a policy determined in response to the vehicle policy data value; and replacing the data collection policy with the update policy.
  • the policy acquisition circuit is further structured 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 circuit is further structured to update the data collection policy by removing the appended requested policy in response to at least one of: a data collection event of collected vehicle data responsive to the appended requested policy; a data transmission event of collected vehicle data responsive to the appended requested policy; a policy cancel value provided by an external device; a change in a subscription status of an entity providing the vehicle policy data value; or a change in an authorization status of an entity providing the vehicle policy data value.
  • the vehicle policy data value further includes a trigger condition, and wherein the policy execution circuit is further structured to collect vehicle data further in response to the trigger condition.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including at least one requested vehicle property; a parameter acquisition circuit structured to interpret a plurality of vehicle parameter values, responsive to the at least one requested vehicle property, from a plurality of providing end points, each of the plurality of providing end points on at least one network zone of a vehicle; and a parameter storage circuit structured 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 are stored on a storage end point distinct from an associated one of the providing end points for the at least a first portion of the stored vehicle parameter values.
  • the parameter storage circuit is further structured to selectively store the at least a portion of the plurality of vehicle parameter values on a single storage end point.
  • the apparatus further including a storage management circuit structured to determine a parameter transmission schedule for stored vehicle parameter values, and wherein the parameter storage circuit is further structured to selectively store the at least a portion of the plurality of vehicle parameter values in response to the parameter transmission schedule.
  • the apparatus further including a storage management circuit structured to determine a parameter expiration schedule for stored vehicle parameter values, and wherein the parameter storage circuit is further structured to selectively store the at least a portion of the plurality of vehicle parameter values in response to the parameter expiration schedule.
  • the parameter storage circuit is further structured to perform at least one operation responsive to the parameter expiration schedule selected from the operations 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 a reserved memory amount associated with at least a portion of the stored vehicle parameter values.
  • the parameter storage circuit is further structured to determine a reserved memory amount associated with at least a portion of the plurality of vehicle parameter values, and to perform the selectively storing the at least a portion of the plurality of vehicle parameter values in response to the reserved memory amount.
  • the parameter storage circuit is further structured to determine the reserved memory amount by performing at least one operation selected from the operations consisting of: determining an amount of data to be collected to support the at least a portion of the plurality of vehicle parameter values; determining an amount of data to be collected to support a trigger evaluation associated with the at least a portion of the plurality of vehicle parameter values; or determining a transmission latency value associated with the at least a portion of the plurality of vehicle parameter values.
  • the parameter storage circuit is further structured to determine the reserved memory amount in response to a priority value associated with the at least a portion of the vehicle parameter values.
  • the priority value includes an on-vehicle data storage priority.
  • the priority value includes a transmission priority.
  • the priority value includes a priority associated with an end point providing the at least a portion of the vehicle parameter values.
  • the priority value includes a priority associated with an end point requesting the at least a portion of the vehicle parameter values.
  • the priority value includes a priority associated with an entity requesting the at least a portion of the vehicle parameter values.
  • the priority value includes a priority associated with an application requesting the at least a portion of the vehicle parameter values.
  • the priority value includes a priority associated with an application associated with an end point requesting the at least a portion of the vehicle parameter values.
  • the priority value includes a priority associated with a flow requesting the at least a portion of the vehicle parameter values.
  • the priority value includes a priority associated with a flow associated with an end point requesting the at least a portion of the vehicle parameter values.
  • An example apparatus includes a container acquisition circuit structured to interpret a plurality of container application values, each including an application operable on an end point of a vehicle; a container security circuit structured to interpret an authorization value associated with each of the plurality of container application values; and a container orchestration circuit structured to interpret a container policy, and to determine operation 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.
  • 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 values consisting of: 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 structured to distribute the plurality of container application values across a number of end points of the vehicle.
  • the container orchestration circuit is further structured to distribute the plurality of container application values to balance workloads of a plurality of controllers including the number of end points.
  • the container orchestration circuit is further structured to distribute the plurality of container application values responsive to workloads of a plurality of controllers including the number of end points.
  • the container orchestration circuit is further structured to distribute the plurality of container application values to balance network communication loads of a plurality of network zones of the vehicle.
  • the container orchestration circuit is further structured to distribute the plurality of container application values responsive to network communication loads of a plurality of network zones of the vehicle.
  • the container security circuit is further structured to determine the 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 structured to determine the authorization value in response to an authorization requirement associated with operations of each of the plurality of container application values.
  • the container security circuit is further structured to determine the authorization requirement in response to an input data value of each of the plurality of container application values.
  • the container security circuit is further structured to determine the authorization requirement in response to an output data value of each of the plurality of container application values.
  • the container security circuit is further structured to determine the authorization requirement in response to an actuator command value of each of the plurality of container application values.
  • the container security circuit is further structured to determine the authorization requirement in response to a memory support value of 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 structured to determine the authorization requirement in response to a processing support value of each of the plurality of container application values.
  • the container acquisition circuit is further structured to interpret an additional container application value, and wherein the container orchestration circuit is further structured to update the operation parameters for the plurality of container application values and the additional container application value in response to an added container application value.
  • the container orchestration circuit is further structured to distribute the added container application value to a selected end point of the vehicle in response to a capability of the selected end point to perform the added container application value.
  • the container orchestration circuit is further structured to change a distribution of the plurality of container application values across a number of end points of the vehicle in response to the added container application value.
  • the container acquisition circuit is further structured to interpret an enable value for at least one of the plurality of container values, and wherein the container orchestration circuit is further structured to determine the operation parameters in response to the enable value.
  • the container orchestration circuit is further structured to interpret a vehicle operating condition, and to determine the operation parameters in response to the vehicle operating condition.
  • the container orchestration circuit is further structured to interpret a vehicle configuration value, and to determine the operation parameters in response to the vehicle configuration value.
  • An example apparatus includes an automated operation circuit structured to interpret an automated operation value including an automated operation description for a vehicle; an automation manager circuit structured to determine a trigger description value in response to the automated operation value, the trigger description value including a trigger condition value and a trigger response value; a trigger evaluation circuit structured to determine a trigger event occurrence in response to the trigger condition value and at least one vehicle data value; and a trigger execution circuit structured to execute a trigger response in response to the trigger event occurrence.
  • the trigger response includes at least one operation selected from the operations consisting of: performing a data collection operation; providing an actuator command value; or enabling operation of a pre-configured feature on a controller of the vehicle.
  • the trigger response includes providing a high priority response for 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 automated operation value includes a selection from a number of pre-configured automated operation values.
  • the automation manager circuit is further structured to determine an authorization value associated with the automated operation value, and to selectively determine the trigger description value in response to the authorization value.
  • the automation manager circuit is further structured to determine the trigger description value as a persistent value.
  • the automation manager circuit is further structured to determine the trigger description value as a limited execution value.
  • the automation manager circuit is further structured to maintain a receiver of the vehicle in a selected power mode during selected operating conditions of the vehicle.
  • the automation manager circuit is further structured to maintain at least one controller of the vehicle in a selected power mode during selected operating conditions of the vehicle.
  • the automation manager circuit is further structured to maintain the at least one controller of the vehicle in the selected power mode in response to a content of the trigger description value.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including at least one requested vehicle property; a parameter acquisition circuit structured to interpret a plurality of vehicle parameter values, responsive to the at least one requested vehicle property, from a plurality of providing end points, each of the plurality of providing end points on at least one network zone of a vehicle; and a vehicle data transmission circuit structured to selectively transmit at least a portion of an collected vehicle data.
  • the vehicle data transmission circuit is further structured to selectively transmit the at least a portion of the collected vehicle data by selecting a transmission interval for the at least a portion of the collected vehicle data.
  • the vehicle data transmission circuit is further structured to select the transmission interval in response to at least one of: an interval provided in the vehicle policy data value; an interval responsive to a priority of the at least a portion of the collected vehicle data; an interval responsive to an availability description for transmitting resources for the at least a portion of the collected vehicle data; an interval responsive to a historical transmission availability for the vehicle; or an operating condition of the vehicle.
  • the vehicle data transmission circuit is further structured to selectively transmit the at least a portion of the collected vehicle data by selecting a bandwidth utilization for the at least a portion of the collected vehicle data.
  • the vehicle data transmission circuit is further structured to select the bandwidth utilization in response to at least one of: a bandwidth utilization provided in the vehicle policy data value; a bandwidth utilization responsive to a priority of the at least a portion of the collected vehicle data; a bandwidth utilization responsive to an availability description for transmitting resources for the at least a portion of the collected vehicle data; an interval responsive to a historical transmission availability for the vehicle; or an operating condition of the vehicle.
  • the vehicle data transmission circuit is further structured to selectively transmit the at least a portion of the collected vehicle data by selecting a transmission interval in response to a data type of the at least a portion of the collected vehicle data.
  • the vehicle data transmission circuit is further structured to selectively transmit the at least a portion of the collected vehicle data in response to a vehicle operational impact of transmission operations.
  • the vehicle data transmission circuit is further structured to selectively transmit the at least a portion of the collected vehicle data in response to a power utilization impact of transmission operations.
  • the vehicle data transmission circuit is further structured to selectively transmit the at least a portion of the collected vehicle data in response to a data transmission capacity value.
  • the data transmission capacity value includes at least one data transmission capacity value selected from the values consisting of: a data transmission capacity associated with a time interval; a data transmission capacity associated with an entity related to the 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 related to the at least a portion of the collected vehicle data; a data transmission capacity associated with an application of the vehicle related to the at least a portion of the collected vehicle data; or a data transmission capacity associated with a vehicle function related to the at least a portion of the collected vehicle data.
  • the vehicle data transmission circuit is further structured to selectively transmit the at least a portion of the collected vehicle data in response to a currently available transmission type.
  • the vehicle data transmission circuit is further structured to selectively transmit the at least a portion of the collected vehicle data by selecting a data transmission chunk size for the 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 structured 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 to a priority of the at least a portion of the collected vehicle data; a transmission chunk size responsive to an availability description for transmitting resources for the at least a portion of the collected vehicle data; a transmission chunk size responsive to a historical transmission availability for the vehicle; or an operating condition of the vehicle.
  • the vehicle transmission circuit is further structured to adjust the selectively transmitting the at least a portion of the collected vehicle data in response to a success parameter for transmitting operations.
  • the vehicle transmission circuit is further structured to adjust the selectively transmitting the at least a portion of the collected vehicle data in response to a quality of service parameter for transmitting operations.
  • An example apparatus includes a remote access execution circuit structured 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 translation circuit structured to determine a property request value in response to the at least one requested vehicle property; a parameter acquisition circuit structured to interpret a plurality of vehicle parameter values in response to the property request value; a parameter conditioning circuit structured to generate, in response to the property request value, vehicle property data from the plurality of vehicle parameter values, the vehicle property data corresponding to at least one the requested vehicle property; and wherein the remote access execution circuit is further structured to transmit the vehicle property data to the requesting device.
  • the apparatus further including a converged network device (CND) structured 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.
  • CND converged network device
  • the apparatus further includes wherein the remote access request value further includes a vehicle function value; wherein the property translation circuit is further structured to determine an actuator command value in response to the vehicle function value; and a remote operation circuit structured to provide the actuator command value to an endpoint of a network zone of a vehicle.
  • the apparatus further includes a converged network device (CND) structured to regulate communications between a first network zone having a first network endpoint and a second network zone having a second network endpoint and including the network zone of the vehicle; wherein the first network endpoint provides at least a portion of the plurality of vehicle parameter values; and wherein the second network endpoint includes an actuator responsive to the actuator command value.
  • CND converged network device
  • the property translation circuit is further structured to determine the actuator command value by performing at least one operation selected from the operations consisting of: determining the actuator command value as a sequence of actuator commands corresponding to a diagnostic test operation; determining the actuator command value as a sequence of actuator commands corresponding to a remote control operation; or determining the actuator command value as at least one actuator command responsive to the vehicle function value.
  • the apparatus further including an additional plurality of endpoints distributed across at least the first network zone and the second network zone, wherein the additional plurality of endpoints each provide at least a portion of the plurality of vehicle parameter values.
  • the apparatus further including an additional plurality of endpoints distributed across at least the first network zone and the second network zone, wherein the additional plurality of endpoints each include 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 values consisting of: an authorization value of the requesting device; a data collection description including the at least one requested vehicle property; a trigger description value including a trigger condition and a trigger response value, and wherein the parameter acquisition circuit is further structured to generate at least a portion of the vehicle property data from the plurality of vehicle parameter values further 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 values consisting of: an authorization value of the requesting device; a trigger description value including a trigger condition and a trigger response value, and wherein the remote operation circuit is further structured to provide the actuator command value further in response to the trigger description value; and a policy priority value.
  • An example apparatus includes a vehicle event graphical user interface (GUI) configured to interpret a trigger description value from a user, the trigger description value 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: at least a portion of the identified vehicle data; or an alert response value determined in response to the alert execution description.
  • GUI vehicle event graphical user interface
  • the GUI is configured to display a 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 use template identifiers, and wherein the GUI determines the portion based on at least one of an authorization value and a location value.
  • the location value corresponds to at least one of: location of the apparatus and a location of a vehicle.
  • the GUI is configured to display a plurality of vehicle use template identifiers, and wherein the GUI is configured to indicate a portion of the plurality of vehicle use template identifiers are unavailable based on a vehicle data collection parameter value.
  • the GUI is configured to display a vehicle use template including a plurality of vehicle data identifiers based on an authorization value.
  • the alert response value includes at least one of: an alert criterion, an alert type, an alert content, and an alert location.
  • the request circuit is configured to reject the trigger description value in response to a vehicle data collection parameter value.
  • the vehicle data collection parameter value indicates the identified vehicle data cannot be captured by a vehicle.
  • the trigger description value includes a plurality of trigger conditions including the trigger condition, and wherein the identified vehicle data is to be captured in response to the plurality of trigger conditions.
  • the plurality of trigger conditions use a plurality of vehicle data types.
  • An example 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, the trigger description value including a trigger condition; determining 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 receiving at least one of at least a portion of the identified vehicle data or an alert response value determined in response to the alert execution description.
  • An example 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 identified vehicle data in response to the data collection policy, or an alert response value in response to the data collection policy.
  • 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 user device request and at least one of an authorization value or a location value.
  • the plurality of response action values includes a plurality of evaluation collection parameter values corresponding to a common vehicle data source, and wherein the policy creator circuit is configured to determine an evaluation collection parameter value for the data collection policy in response to the response to the plurality of evaluation collection parameter values.
  • the plurality of evaluation collection parameter values include a plurality of different frequencies, and wherein the evaluation 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 to be 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 an execution parameter value. The validation circuit determines the execution parameter value by determining vehicle data identified by the rejected response action value cannot be captured by a vehicle.
  • An authorization circuit configured to tag a data collection policy in response to an authorization value, wherein the authorization value indicates a source of one of the plurality of response action values is not authorized to receive the identified vehicle data.
  • a first partition including the request interface, the policy creator circuit, and the cloud interface; and a second partition including: a vehicle data storage circuit configured to store the identified vehicle data from a vehicle, and a second cloud interface configured to provide the identified vehicle data to the first cloud interface in response to a vehicle data request.
  • the identified vehicle data is encrypted while stored with the vehicle data storage circuit, and wherein the first partition is not configured to decrypt the identified vehicle data stored with 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 provide a vehicle data query result in response to the metadata.
  • An example 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 one of: at least a portion of identified vehicle data in response to the data collection policy, or an alert response value in response to the data collection policy.
  • An example 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 a vehicle data collection parameter; and a trigger evaluation circuit configured to receive the trigger condition in response to the collection validation value.
  • 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 a vehicle data collection parameter; and a trigger evaluation circuit configured to receive the trigger condition in response to the collection validation value.
  • the trigger evaluation circuit is configured to determine a trigger event occurrence in response to the trigger condition, and wherein 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 the vehicle is structured to provide the trigger evaluation data.
  • a 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 collection validation value.
  • the vehicle communication system stops executing the data collection policy in response to at least one of an updated authorization value or an updated location value.
  • An example apparatus includes a parameter acquisition circuit structured to interpret a vehicle parameter value; a property translation circuit structured to interpret a property request value, the property request value defining, at least in part, a requested vehicle property; and a parameter conditioning circuit structured to generate, in response to the property request value, vehicle property data from the vehicle parameter value, the vehicle property data corresponding to the requested vehicle property.
  • the apparatus further includes a requestor verification circuit structured to determine, in response to and based at least in part on the property request value, an entity authorization value; and a vehicle property provisioning circuit structured to transmit the vehicle property data in response to the entity authorization value.
  • the apparatus includes a subscription circuit structured to add a requesting entity to a subscriber data list in response to the property request value; wherein the vehicle property provisioning circuit is further structured to transmit the vehicle property data to the requesting entity in response to the subscriber data list.
  • the apparatus further includes a vehicle property provisioning circuit structured to transmit the vehicle property data in response to the property request value.
  • a converged network device structured to regulate communications between a first network zone having a first vehicle sensor and a second network zone having a second vehicle sensor; wherein the vehicle parameter value is generated by at least one of the first and the second vehicle sensor.
  • the parameter acquisition circuit is structured to interpret a plurality of vehicle parameter values; and the parameter conditioning circuit structured to generate the vehicle property data from the plurality of vehicle parameter values; wherein a first vehicle parameter value of the plurality is from the first vehicle sensor and a second vehicle parameter value of the plurality is from the second vehicle sensor.
  • the first network zone and the second network zone are of distinct 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 feature value; or a vehicle location value.
  • the vehicle parameter value includes at least one of: a network utilization value for a network zone of the vehicle; a raw network message from a network zone of the vehicle; a network address for an endpoint on a network zone of the vehicle; a memory storage description of a controller of the vehicle; a value from an end point on a controller area network (CAN); a value from an end point 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 property includes at least one of: a drivetrain component speed value; a drive shaft speed value; a drive shaft torque value; a selected gear value; a battery state of health value; a battery state of charge value; or a battery power throughput value.
  • the parameter conditioning circuit is structured to generate, in response to the property request value, a virtual vehicle property value from two one or more vehicle parameter values, wherein 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 motive power efficiency value; an event occurrence value; or a listing of previous vehicle locations.
  • 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 rate value; a remaining life value for a component; a time to maintenance value for a component; or a diagnostic counter value.
  • the virtual vehicle property value includes at least one of: a listing of one or more user activated features; an average vehicle runtime value; or an estimated vehicle operating cost value.
  • the vehicle property data is of a different format than the vehicle parameter value.
  • An example method includes interpreting a vehicle parameter value; interpreting a property request value that defines, at least in part, a requested vehicle property; and generating, in response to the property request value, vehicle property data from the vehicle parameter value, the vehicle property data corresponding to the requested vehicle property.
  • the method further includes determining, in response to and based at least in part on the property request value, an entity authorization value; and transmitting the vehicle property data in response to the entity authorization value.
  • the method further includes adding a requesting entity to a subscriber data list in response to the property request value; wherein 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 communications between a first network zone having a first vehicle sensor and a second network zone having a second vehicle sensor; and generating the vehicle parameter value by at least one of the first and the second vehicle sensors.
  • Interpreting a vehicle parameter value includes interpreting a plurality of vehicle parameter values; generating vehicle property data is based, at least in part, on the plurality of vehicle parameter values; and a first vehicle parameter value of the plurality is from the first vehicle sensor and a second vehicle parameter value of the plurality is from the second vehicle sensor.
  • the first network zone and the second network zone are of distinct 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 feature value; or a vehicle location value.
  • the vehicle parameter value includes at least one of: a network utilization value for a network zone of the vehicle; a raw network message from a network zone of the vehicle; a network address for an endpoint on a network zone of the vehicle; a memory storage description of a controller of the vehicle; a value from an end point on a controller area network (CAN); a value from an end point 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 property includes at least one of: a drivetrain component speed value; a drive shaft speed value; a drive shaft torque value; a selected gear value; a battery state of health value; a battery state of charge value; or a battery power throughput value.
  • a parameter conditioning circuit is structured to generate, in response to the property request value, a virtual vehicle property value from two one or more vehicle parameter values, wherein 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 motive power efficiency value; an event occurrence value; or a listing of previous vehicle locations.
  • the virtual vehicle property value includes at least one of: a listing of one or more user activated features; an average vehicle runtime value; or an estimated vehicle operating cost value.
  • the vehicle property data is of a different format than the vehicle parameter value.
  • An example method includes interpreting, at a first vehicle, a first property request value that defines, at least in part, a requested vehicle property; generating, at the first vehicle and in response to the first property request value, first vehicle property data from a first plurality of vehicle parameter values of the first vehicle, the first vehicle property data corresponding to the requested vehicle property; interpreting, at a second vehicle, a second property request value corresponding to the requested vehicle property; and generating, at the second vehicle and in response to the second property request value, second vehicle property data from a second plurality of vehicle parameter values of the second vehicle, the second vehicle property data corresponding to the requested vehicle property.
  • 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 the first plurality of vehicle parameter values via a first vehicle sensor and a second vehicle sensor, the first vehicle sensor disposed on a first network of the first vehicle and the second vehicle sensor disposed on a second network of the first vehicle, the first network of a distinct type from the second network; and generating the second plurality of vehicle parameter values via a third vehicle sensor and a fourth vehicle sensor, the third vehicle sensor disposed on a third network of the second vehicle and the fourth vehicle sensor disposed on the fourth network of the second vehicle, the third network of a distinct type of the fourth network; wherein at least one of the first and second networks is distinct from at least one of the third and fourth networks.
  • the method further includes generating the first plurality of vehicle parameter values via a first vehicle sensor disposed on a first network of the first vehicle; and generating the second plurality of vehicle parameter values via a second vehicle sensor disposed on a second network of the second vehicle; wherein the second network is of a distinct type from the first network.
  • An example apparatus includes a policy acquisition circuit structured to interpret a vehicle policy data value including at least a portion of a vehicle policy; a policy processing circuit structured to generate, in response to and based at least in part on the vehicle policy data value, parsed policy data that includes of one or more vehicle sub-policies of the vehicle policy; and a policy execution circuit structured to collect vehicle data from one or more vehicle sensors in response to the parsed policy data.
  • the policy processing circuit is further structured to determine from the vehicle policy data value a type value of the vehicle policy, wherein the type value is at least one of a passive policy or an active policy.
  • the policy execution circuit is further structured to: passively collect the vehicle data in response to the type value being a passive policy.
  • the policy execution circuit is further structured to: actively collect the vehicle data in response to the type value being an active policy.
  • the policy execution circuit is further structured to: transmit a begin collection command value to actively collect the vehicle data.
  • the policy execution circuit is further structured to: generate, based at least in part on the collected vehicle data, a vehicle property value to actively collect the vehicle data.
  • the policy execution circuit is further structured to: transmit a query value to actively collect the vehicle data.
  • the apparatus further includes a memory device structured to store the collected vehicle data.
  • the apparatus further includes a converged network device (CND) structured to regulate communications 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 distinct types.
  • the policy execution circuit is further structured to delegate collection of the vehicle data to one or more vehicle controllers via transmitting at least some of the parsed policy data to the one or more vehicle controllers.
  • the apparatus further includes a collected data acquisition circuit structured to interpret the vehicle data collected by the one or more vehicle controllers.
  • the apparatus further includes a collected data provisioning circuit structured to transmit the collected vehicle data.
  • An example method includes interpreting a vehicle policy data value including at least a portion of a vehicle policy; generating, in response to and based at least in part on the vehicle policy data value, parsed policy data that includes of 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.
  • the method further includes determining, from the vehicle policy data value, a type value of the vehicle policy, wherein the type value is at least one of a passive policy or an active policy.
  • Collecting the vehicle data includes passively collecting the vehicle data in response to the type value.
  • Collecting the vehicle data includes actively collecting the vehicle data in response to the type value.
  • Actively collecting the vehicle data includes transmitting a begin collection command value.
  • Actively collecting the vehicle data includes generating a vehicle property value based at least in part on the collected vehicle data. Actively collecting the vehicle data includes transmitting a query value.
  • the method further includes regulating communications 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 distinct types.
  • Collecting vehicle data includes: delegating collection of the vehicle data to one or more vehicle controllers via transmitting at least some of the parsed policy data to the one or more vehicle controllers.
  • the method further includes interpreting the vehicle data collected by the one or more vehicle controllers.
  • the method further includes transmitting the collected vehicle data.
  • An example apparatus includes a converged network device (CND) structured 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 is generated by the first and the second network endpoints; a parameter acquisition circuit structured to interpret the plurality of vehicle parameter values; a property translation circuit structured to interpret a property request value that includes at least a portion of a requested vehicle property; and a parameter conditioning circuit structured to generate, in response to the property request value, vehicle property data from the plurality of vehicle parameter values, the vehicle property data corresponding to the requested vehicle property.
  • CND converged network device
  • the apparatus further including a parameter provisioning circuit structured to transmit the vehicle property data.
  • the first network zone and the second network zone are of distinct types.
  • the first network zone includes a controller area network (CAN).
  • the first and the second network endpoints are vehicle sensors.
  • the plurality of vehicle parameter values directly corresponds to the requested vehicle property.
  • the plurality of vehicle parameter values includes at least one of: a vehicle speed value; a prime mover speed value; a prime mover torque value; a user actuated vehicle feature value; or a vehicle location value.
  • the plurality of vehicle parameter values includes at least one of: a network utilization value for a network zone of the vehicle; a raw network message from a network zone of the vehicle; a network address for an endpoint on a network zone of the vehicle; a memory storage description of a controller of the vehicle; a value from an end point on a controller area network (CAN); a value from an end point 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 property includes at least one of: a drivetrain component speed value; a drive shaft speed value; a drive shaft torque value; a selected gear value; a battery state of health value; a battery state of charge value; or a battery power throughput value.
  • the parameter conditioning circuit is structured to generate, in response to the property request value, a virtual vehicle property value from two one or more vehicle parameter values, wherein 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 motive power efficiency value; an event occurrence value; or a listing of previous vehicle locations.
  • the virtual vehicle property value includes at least one of: a listing of one or more user activated features; an average vehicle runtime value; or an estimated vehicle operating cost value.
  • the vehicle property data is of a different format than the plurality of vehicle parameter values.
  • An example method includes regulating 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 is generated by the first and the second network endpoints; interpreting the plurality of vehicle parameter values; interpreting a property request value that defines, at least in part, a requested vehicle property; and generating, in response to the property request value, vehicle property data from the plurality of vehicle parameter values, the vehicle property data corresponding to the requested vehicle property.
  • the method further includes transmitting the vehicle property data.
  • the first network zone and the second network zone are of distinct types.
  • the first network zone includes a controller area network (CAN).
  • the first and the 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 includes at least one of: a vehicle speed value; a prime mover speed value; a prime mover torque value; a user actuated vehicle feature value; or a vehicle location value.
  • the plurality of vehicle parameter values includes at least one of: a network utilization value for a network zone of the vehicle; a raw network message from a network zone of the vehicle; a network address for an endpoint on a network zone of the vehicle; a memory storage description of a controller of the vehicle; a value from an end point on a controller area network (CAN); a value from an end point 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 property includes at least one of: a drivetrain component speed value; a drive shaft speed value; a drive shaft torque value; a selected gear value; a battery state of health value; a battery state of charge value; or a battery power throughput value.
  • a parameter conditioning circuit is structured to generate, in response to the property request value, a virtual vehicle property value from two one or more vehicle parameter values, wherein 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 motive power efficiency value; an event occurrence value; or a listing of previous vehicle locations.
  • the virtual vehicle property value includes at least one of: a listing of one or more user activated features; an average vehicle runtime value; or an estimated vehicle operating cost value.
  • the vehicle property data is of a different format than the plurality of vehicle parameter values.
  • An example apparatus includes a parameter acquisition circuit structured to interpret a vehicle parameter value; a property translation circuit structured to interpret a property request value, the property request value defining, at least in part, a requested vehicle property; and a parameter conditioning circuit structured to generate, in response to the property request value, modified vehicle parameter data from the vehicle parameter value, the modified vehicle parameter data corresponding to the requested vehicle property.
  • the modified vehicle parameter data includes a virtual vehicle property value.
  • the virtual vehicle property value is based at least in part two or more of vehicle parameter values.
  • the parameter conditioning circuit includes a formatting circuit structured to format the vehicle parameter value to a desired format of the requested vehicle property such that the modified vehicle parameter data has the desired format.
  • the desired format is based at least in part on a network protocol.
  • the desired format is based at least in part on storage of the vehicle parameter value in a non-transitory computer readable medium.
  • the desired format is based at least in part on a compression standard.
  • the parameter conditioning circuit includes a unit conversion circuit structured to convert one or more units of the vehicle parameter value to one or more desired units of the requested vehicle property such that the modified vehicle parameter data has the desired one or more units.
  • the parameter conditioning circuit includes a sampling circuit structured to adjust a sampling rate of the vehicle parameter value to a desired sampling rate of the requested vehicle property such that the modified vehicle parameter data has the desired sampling rate.
  • the sampling circuit is structured to up-sample the vehicle parameter value.
  • the sampling circuit is structured to down-sample the vehicle parameter value.
  • An example method includes interpreting a vehicle parameter value; interpreting a property request value, the property request value defining, at least in part, a requested vehicle property; and generating, in response to the property request value, modified vehicle parameter data from the vehicle parameter value, the modified vehicle parameter data corresponding to the requested vehicle property.
  • Generating the modified vehicle parameter data includes generating a virtual vehicle property value; wherein the modified vehicle parameter data includes the virtual vehicle property value.
  • the virtual vehicle property value is based at least in part two or more vehicle parameter values.
  • the method further includes formatting the vehicle parameter value to a desired format of the requested vehicle property such that the modified vehicle parameter data has the desired format.
  • Formatting the vehicle parameter value includes generating a network protocol packet structured to transport the vehicle parameter value.
  • Formatting the vehicle parameter value includes modifying the vehicle parameter value for storage in a non-transitory computer readable medium. Modifying the vehicle parameter value includes compressing the vehicle parameter value.
  • the method further includes converting one or more units of the vehicle parameter value to one or more desired units of the requested vehicle property such that the modified vehicle parameter data has the desired one or more units.
  • the method further includes adjusting a sampling rate of the vehicle parameter value 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 value includes up- sampling the vehicle parameter value. Adjusting the sampling rate of the vehicle parameter value includes down-sampling the vehicle parameter value.
  • An example apparatus includes a parameter acquisition circuit structured to interpret a plurality of vehicle parameter values; a parameter conditioning circuit structured to condition the plurality of vehicle parameter values for storage in one or more cache devices; and a parameter storage circuit structured to store the conditioned plurality of vehicle parameter values in the one or more cache devices.
  • the parameter conditioning circuit is further structured to determine a storage location value; the parameter storage circuit is further structured to store the conditioned plurality of vehicle parameter values in response to the storage location value; and the one or more cache devices are disposed onboard a vehicle. Each of the one or more cache devices disposed onboard the vehicle is associated with a controller that is distinct from controllers associated with the other of the one or more cache devices.
  • the parameter conditioning circuit is further structured to determine a storage location value; the parameter storage circuit is further structured to store the conditioned plurality of vehicle parameter values in response to the storage location value; and the one or more cache devices are disposed offboard a vehicle.
  • the one or more cache devices are based at least in part on a network cloud-based storage system.
  • the parameter conditioning circuit is further structured to determine a storage location value; and the parameter storage circuit is further structured to, in response to the storage location value, store: a first portion of the conditioned plurality of vehicle parameter values on a first cache device of the one or more cache devices; and a second portion of the conditioned plurality of vehicle parameter values on a second cache device of the one or more cache devices; wherein the first cache device is disposed onboard a vehicle and the second cache device is disposed offboard the vehicle.
  • the parameter conditioning circuit is further structured to generate an expiration value for the plurality of vehicle parameter values structured to trigger a selective expiration of the plurality of vehicle parameter values in the one or more cache devices.
  • the parameter storage circuit is further structured to transmit the expiration value to the one or more cache devices.
  • the parameter storage circuit is further structured to selectively expire the plurality of vehicle parameter values responsive to the expiration value.
  • the expiration value is a time value corresponding to a period of time to store the plurality of vehicle parameter values in the one or more caches.
  • the apparatus further includes a policy acquisition circuit structured to interpret a vehicle policy data value including at least a portion of a vehicle policy; wherein the parameter conditioning circuit is further structured to generate the expiration value responsive to the vehicle policy data value.
  • the parameter conditioning circuit is further structured to determine a type value of the plurality of vehicle parameter values; and generate the expiration value responsive to the type value.
  • the type value corresponds to at least one of engine data, control data, mission critical data, motive status data, or motive operational data.
  • the type value corresponds to at least one of vehicle state value, a vehicle mode value, a diagnostic value, or a fault value.
  • the parameter conditioning circuit is further structured to condition the plurality of vehicle parameter values via compressing the plurality of vehicle parameter values.
  • the parameter conditioning circuit is further structured to condition the plurality of vehicle parameter values via summarizing the plurality of vehicle parameter values.
  • An example method includes interpreting a plurality of vehicle parameter values; conditioning the plurality of vehicle parameter values for storage in one or more cache devices; and storing the conditioned plurality of vehicle parameter values in the one or more cache devices.
  • the method further includes determining a storage location value; where storing the conditioned plurality of vehicle parameter values is responsive to the storage location value; and the one or more cache devices are disposed onboard a vehicle. Each of the one or more cache devices disposed onboard the vehicle is associated with a controller that is distinct from controllers associated with the other of the one or more cache devices.
  • the method further includes determining a storage location value; where storing the conditioned plurality of vehicle parameter values is responsive to the storage location value; and the one or more cache devices are disposed offboard a 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 conditioned plurality of vehicle parameter values is responsive to the storage location value and includes: storing a first portion of the conditioned plurality of vehicle parameter values on a first cache device of the one or more cache devices; and storing a second portion of the conditioned plurality of vehicle parameter values on a second cache device of the one or more cache devices; wherein the first cache device is disposed onboard a vehicle and the second cache device is disposed offboard the vehicle.
  • the method further includes generating an expiration value for the plurality of vehicle parameter values structured to trigger a selective expiration of the plurality of vehicle parameter values in the one or more cache devices.
  • the method of claim 350 further includes transmitting the expiration value to the one or more cache devices.
  • the method further includes selectively expiring the plurality of vehicle parameter values responsive to the expiration value.
  • the expiration value is a time value corresponding to a period of time to store the plurality of vehicle parameter values in the one or more caches.
  • the method further includes interpreting a vehicle policy data value including at least a portion of a vehicle policy; wherein generating the expiration value for the plurality of vehicle parameter values is responsive to the vehicle policy data value.
  • the method further includes determining a type value of the plurality of vehicle parameter values; where generating the 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; location data; vehicle cabin environmental data; or infotainment console data.
  • Conditioning the plurality of vehicle parameter values includes compressing the plurality of vehicle parameter values.
  • Conditioning the plurality of vehicle parameter values includes summarizing the plurality of vehicle parameter values.
  • An example 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 a trigger event occurrence, and a trigger evaluation data identifier configured to identify trigger evaluation data to be captured in response to the trigger condition; and an end point configured to provide a raw vehicle data stream including a trigger evaluation data stream and an identified vehicle data stream in response to the data collection policy.
  • a filtering circuit configured to determine the trigger evaluation data stream of the raw vehicle data stream in response to trigger evaluation data identifier and provide the 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 sample the trigger evaluation data stream in response to a sampling parameter of the data collection policy, normalize a trigger evaluation data value format, or determine a trigger evaluation data aggregation parameter 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, wherein the rotating buffer circuit determines 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.
  • a 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 a trigger evaluation circuit configured to determine a trigger event occurrence in response to evaluating the trigger condition using the first rotating time window.
  • a vehicle data storage circuit configured to store identified vehicle data of the identified vehicle data stream in response to the trigger event occurrence and the data collection policy, wherein at least a portion of the identified vehicle data occurred before the trigger event occurrence.
  • a cloud interface configured to provide identified vehicle data of the identified vehicle data stream in response to the trigger event occurrence and transmission parameter value of the data collection policy.
  • a cloud interface configured to provide an alert response value in response to the trigger event occurrence, wherein the alert response value includes at least one of an alert criterion, an alert type, an alert content, and an alert location.
  • the trigger evaluation circuit is configured to evaluate a plurality of trigger conditions of the data collection policy simultaneously, and wherein the trigger evaluation circuit is configured to determine the trigger event occurrence in response to a plurality of trigger conditions.
  • An example method includes operating a vehicle including a vehicle communication system including a policy manager circuit and an endpoint; interpreting, with 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 a trigger event occurrence, and a trigger evaluation data identifier configured to identify trigger evaluation data to be captured in response to the trigger condition; and providing, with the end point, a raw vehicle data stream including a trigger evaluation data stream and an identified vehicle data stream in response to the data collection policy.
  • the vehicle communication system includes a filtering circuit, and wherein the method includes determining, with the filtering circuit, the trigger evaluation data stream of the raw vehicle data stream in response to trigger evaluation data identifier. Determining, with the filtering circuit, the identified vehicle data stream in response to the vehicle data identifier.
  • the vehicle communication system includes a vehicle data processing circuit, wherein the method includes processing the trigger evaluation data including at least one of: sampling the trigger evaluation data stream in response to a sampling parameter of the data collection policy, normalizing a trigger evaluation data value format, or determining a trigger evaluation data aggregation parameter in response to a plurality of trigger conditions of the data collection policy.
  • the vehicle communication system includes a rotating buffer circuit, the method includes determining, with the rotating buffer circuit, a rotating time window in response to the trigger condition; and storing, with the rotating buffer circuit, the rotating time window of 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, the method includes storing, with the rotating buffer circuit, a first rotating time window of the trigger evaluation data stream in response to the trigger condition; and determining, with the trigger evaluation circuit, a trigger event occurrence in response to evaluating the trigger condition using the first rotating time window.
  • the vehicle communication system includes a vehicle data storage circuit, the method includes storing, with the vehicle data storage circuit, identified vehicle data of the identified vehicle data stream in response to the trigger event occurrence and the data collection policy, wherein at least a portion of the identified vehicle data occurred before the trigger event occurrence.
  • the vehicle communication system includes a cloud interface, the method includes providing, with the cloud interface, identified vehicle data of the identified vehicle data stream in response to the trigger event occurrence and transmission parameter value of the data collection policy.
  • the vehicle communication system includes a cloud interface, the method includes providing, with a cloud interface, an alert response value in response to the trigger event occurrence, wherein the alert response value includes at least one of an alert criterion, an alert type, an alert content, and an alert location.
  • the trigger evaluation circuit is configured to evaluate a plurality of trigger conditions of the data collection policy simultaneously, and wherein the trigger evaluation circuit is configured to determine the trigger event occurrence in response to a plurality of trigger conditions.
  • An example 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.
  • a plurality of endpoints including the first endpoint communicatively coupled to an ethemet switch, and wherein at least a portion of the plurality of endpoints are configured to capture a plurality of trigger evaluation data values of the trigger evaluation data in response to the data collection policy.
  • the end point is communicatively coupled to a plurality of networks configured to communicate using a plurality of communication protocols, and wherein the end point is configured to capture a plurality of trigger evaluation data values of the 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 evaluation to be evaluated by a plurality of trigger conditions of the data collection policy, wherein the trigger evaluation data identifiers correspond to a plurality of data types including at least two of a controller area network (CAN) message, a CAN signal, an ethemet 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 end point, or requesting the trigger evaluation data stream from a data source communicatively coupled to the endpoint.
  • CAN controller area network
  • An example vehicle includes a policy manager circuit configured to interpret a data collection policy including a vehicle data identifier and a trigger configured to define a trigger condition; a trigger evaluation circuit configured to: determine a trigger event occurrence in response to a trigger condition and trigger evaluation data, determine a trigger event termination, determine a data capture window in response to the trigger event occurrence, trigger event termination, and the data collection policy, and capture identified vehicle data in response to the data capture window and the vehicle data identifier.
  • the trigger evaluation circuit determines the trigger event occurrence by evaluating the trigger evaluation data using the trigger condition, wherein the trigger condition defines a relationship with a present value that may be satisfied or unsatisfied 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 occurrence 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 trigger event occurrence 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 ethemet packet, a vehicle location, a vehicle status, and a diagnostic trouble code.
  • the trigger evaluation data includes a virtual sensor value derived from a plurality of vehicle data values.
  • the data capture window terminates after a delay following the event trigger termination 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 signal trigger, a vehicle status trigger, a timing trigger, a schedule trigger, a geofence trigger, an error trigger, an environment trigger, or a user input trigger.
  • Determining the trigger event occurrence is based on a first portion of the plurality of trigger conditions, the first portion including a first trigger having a first trigger type and a second trigger having a second trigger type.
  • Determining the trigger event termination is based on a second portion of the plurality of triggers, and wherein the second portion includes a first trigger having a first trigger type and a second trigger having a second trigger type.
  • An example apparatus includes a policy acquisition circuit structured to interpret a data collection policy including at least one requested vehicle property; a policy processing circuit structured to determine a property request value in response to the at least one requested vehicle property; a parameter acquisition circuit structured to interpret at least one vehicle parameter value in response to the property request value; and a parameter provisioning circuit structured to selectively transmit the at least one vehicle parameter value in response to the data collection policy.
  • the data collection policy further includes a policy type, and wherein the parameter acquisition circuit is further structured to interpret the at least one vehicle parameter value in response to the policy type.
  • the policy type includes a persistent policy, and wherein the parameter acquisition circuit is further structured to persistently evaluate the data collection policy for data collection operations.
  • the policy type includes an on demand policy, and wherein the parameter acquisition circuit is further structured to discontinue evaluating the data collection policy for data collection operations in response to fulfilling a data collection cycle of the data collection policy.
  • the policy acquisition circuit is further structured to delete the data collection policy in response to the parameter acquisition circuit discontinuing the evaluating the data collection policy.
  • the policy acquisition circuit is further structured to delete the data collection policy in response to the parameter provisioning circuit transmitting the at least one vehicle parameter value corresponding to the data collection policy.
  • the policy type includes at least one type selected from the types consisting of downloaded policy; a factory policy; a built-in policy.
  • the policy acquisition circuit is further structured to implement the downloaded policy if present.
  • the policy acquisition circuit is further structured to ignore the factory policy and the built-in policy, if the downloaded policy is present.
  • the policy acquisition circuit is further structured to implement a compatible portion of the factory policy if present.
  • the policy acquisition circuit is further structured to implement the factory policy if present, and further if the downloaded policy is not present.
  • the policy acquisition circuit is further structured to ignore the built-in policy.
  • the policy acquisition circuit is further structured to implement a compatible portion of the built-in policy if present.
  • the data collection policy further includes a transmission description value corresponding to the at least one requested vehicle property.
  • the transmission description value includes at least one value selected from the 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 wherein the policy processing circuit is further structured to determine the property request value in response to the data configuration value.
  • the data collection policy further includes a triggered 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 values consisting of: a data collection priority value; a data storage priority value; or a transmission priority value.
  • the policy acquisition circuit is further structured to determine a policy capability value, and to selectively enable the data collection policy in response to the policy capability value.
  • the policy acquisition circuit is further structured to determine a policy authorization value, and to selectively enable the data collection policy in response to the policy authorization value.
  • the data collection policy includes a policy life cycle description, and wherein the policy acquisition circuit is further structured to selectively enable the data collection policy in response to the policy life cycle description.
  • the policy life cycle description includes at least one description selected from the descriptions consisting of: a policy start time; a policy end time; a triggered 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 wherein data is to be captured under the data collection policy.
  • An example cloud system includes a request interface configured to interpret a plurality of response action values from an external device; a policy creator circuit structured to determine a data collection policy in response to the plurality of response action values, the data collection policy including a vehicle data identifier; and a cloud interface configured to receive identified vehicle data in response to the data collection policy; a raw data manager circuit structured to store at least a portion of the received identified vehicle data, the at least a portion of the identified vehicle data including responsive vehicle data and identification data; and wherein the request interface is further configured to interpret a vehicle data request, and to retrieve at least a portion of the responsive vehicle data from the raw data manager circuit in response to the vehicle data request, and to provide the retrieved data to the external device.
  • the responsive vehicle data is encrypted utilizing a first encryption key set
  • the identification data is encrypted utilizing a second encryption key set.
  • the request interface is further configured to retrieve the at least a portion of the responsive vehicle data utilizing at least one key of the second encryption key set. No keys from the first encryption key set are stored on the cloud system.
  • the identification data includes metadata specific to the plurality of response action values.
  • An example cloud system includes a raw data manager circuit structured to store collected data from a vehicle, wherein the stored collected data includes a payload portion encrypted using a first encryption key set and an encrypted identification portion 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 utilizing only the second encryption key set.
  • the raw data manager circuit is further structured to determine the requested portion of the stored collected data in response to comparing the identification portion to a vehicle data request value.
  • the raw data manager circuit is further structured to determine the requested portion of the stored collected data in response to a hash check operation performed on the requested portion of the stored collected data.
  • An example system includes a collected vehicle data storage circuit structured to store collected data from a vehicle; an external data collection interface configured to: selectively provide vehicle data collection requests from an external device to the vehicle; and selectively provide at least a portion of the stored collected data from the collected vehicle data storage circuit in response to a vehicle data request from the external device; and a means for separating at least a portion of the stored collected data from an encryption key for the at least a portion of the stored collected data.
  • An example cloud system includes a request interface configured to interpret a vehicle data collection request for at least one identified vehicle; a policy creator circuit structured 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 to receive responsive vehicle data from the at least one identified vehicle; and a raw data manager circuit structured to store at least a portion of the responsive vehicle data.
  • the request interface is further configured to expose an application programming interface (API) to an external device, and to interpret the vehicle data collection request in response to an exercise of the API.
  • API application programming interface
  • the request interface is further configured to interpret a vehicle data request from the external device in response to an exercise of the API, to retrieve at least a portion of the responsive vehicle data from the raw data manager circuit in response to the vehicle data request, and to provide the retrieved data to the external device.
  • the request interface is further configured to interpret a vehicle data request from an external device, to retrieve at least a portion of the responsive vehicle data from the raw data manager circuit in response to the vehicle data request, and to provide the retrieved 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 wherein the policy creator circuit is further structured to determine the 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 structured to determine a policy capability value in response to the vehicle data collection request, and to selectively enable determining the data collection policy in response to the policy capability value.
  • the policy creator circuit is further structured to determine the policy capability value in response to at least one parameter selected from the parameters consisting of: a data storage size determined to support the vehicle data collection request; a transmission amount 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 further includes wherein the policy creator circuit is further structured to determine a policy capability value in response to the vehicle data collection request and the at least one additional vehicle data collection request; and to selectively enable, in response to the policy capability value, at least one of: determining the data collection policy, or including at least one of the vehicle data collection request or the at least one additional vehicle data collection request.
  • the policy creator circuit is further structured to determine the policy capability value in response to at least one parameter selected from the parameters 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 amount 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 associated with each of the vehicle data collection request and the at least one additional vehicle data collection request; or a priority determination between the vehicle data collection request and the at least one additional vehicle data collection request for any one or more of the foregoing.
  • the cloud system further includes wherein the policy creator circuit is further structured to determine a policy authorization value in response to the vehicle data collection request, and to perform at least one operation, in response to the policy authorization value, selected from the operations consisting of: selectively enabling the determining the data collection policy; or determining the data collection policy to support at least a portion of the vehicle data collection request.
  • the request interface is configured to provide at least one use case value to a user interface, each use case value including a vehicle data collection template, and determining the vehicle data collection request in response to responses 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 permissions value associated with the user interface; and previous data collection policies determined for users having a shared characteristic determined for the user interface.
  • An example system includes a policy manager structured to interpret at least two policy requests, each of the policy requests including a data collection description, the policy manager further structured to compile a policy in response to a superset of data collection values corresponding to each of the data collection descriptions; a data collection controller positioned on a vehicle and communicatively coupled to the policy manager, wherein the data collection controller is structured to collect data from at least two vehicle networks on the vehicle in response to the policy; a data communications component communicatively coupled to the data collection controller, the data communications component structured to receive at least a portion of the collected data from the data collection controller, and to store the at least a portion of the collected data on a data store; and a data request component communicatively coupled to the data communications component and to a requesting application, wherein the data request component is structured 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.
  • the data communications component is further structured to tokenize the at least a portion of the collected data, and to encrypt the at least a portion of the collected data with a master public key before the storing the at least a portion of the collected data.
  • the data request component is further structured to decrypt the requested data with a master private key, and to detokenize the requested data, before providing the selectively requested data to the data application.
  • the policy manager is further structured to provide a user interface to one of a user or policy creation application, and to interpret at least one of the at least two policy requests in response to interactions with the user interface.
  • the policy manager is further structured to interpret a use case value selection in response to interactions with the user interface, and to interpret at least one of the at least two policy requests in response to interactions with the user interface in response to the use case value selection.
  • the policy manager is further structured to provide at least two use case options to the user interface, and to interpret the user case value selection in response to a selection via the user interface of at least one of the at least two use case options.
  • FIG. 1 is a schematic diagram of an example data collection system according to certain embodiments of the present disclosure
  • FIG. 2 is a schematic diagram of an example vehicle having aspects of a data collection system according to certain embodiments of the present disclosure
  • FIG. 3 is a schematic diagram of an example off-vehicle device according to certain embodiments of the present disclosure.
  • FIG. 4 is a diagram of example internal and/or external applications according to certain embodiments of the present disclosure.
  • FIGs. 5A and 5B depict a schematic diagram of an example vehicle network infrastructure for a vehicle according to certain embodiments of the present disclosure
  • Fig. 6 is a schematic diagram of an example edge gateway according to certain embodiments of the present disclosure
  • Fig. 7 is a schematic diagram of an example ethemet switch according to certain embodiments of the present disclosure.
  • FIG. 8 is a schematic diagram of an example ethemet device according to certain embodiments of the present disclosure.
  • FIG. 9 is a schematic diagram of an example user consent controller according to certain embodiments of the present disclosure.
  • FIG. 10 is a schematic diagram of an example data collector controller according to certain embodiments of the present disclosure.
  • FIG. 11 is a schematic diagram of an example first partition according to certain embodiments of the present disclosure.
  • Fig. 12 is a schematic diagram of an example second partition according to certain embodiments of the present disclosure.
  • FIG. 13 is a schematic diagram of an example data collection system according to certain embodiments of the present disclosure.
  • Fig. 14 is a schematic diagram of an example automation manager according to certain embodiments of the present disclosure.
  • Fig. 15 is a schematic diagram of an example implementation for a unified IDS manager (ECU) according to certain embodiments of the present disclosure
  • Fig. 16 is a schematic diagram of an example shared storage controller according to certain embodiments of the present disclosure
  • FIG. 17 is a schematic diagram of another example data collection system according to certain embodiments of the present disclosure.
  • Fig. 18 is diagram of an example workflow according to certain embodiments of the present disclosure.
  • FIG. 19 is a schematic diagram of an example containerized application environment according to certain embodiments of the present disclosure.
  • FIG. 20 is a schematic diagram of an example architecture implementation for container based applications on a vehicle according to certain embodiments of the present disclosure
  • FIG. 21 is a schematic diagram of another example architecture implementation for container based applications on a vehicle according to certain embodiments of the present disclosure.
  • Fig. 22 is a schematic diagram of example details of a container according to certain embodiments of the present disclosure.
  • FIG. 23 is a diagram of an example container networking implementation according to certain embodiments of the present disclosure.
  • FIG. 24 is a diagram of an example AUTOSAR adaptive function state group according to certain embodiments of the present disclosure.
  • FIG. 25 is a schematic diagram of an example function flow to enforce a container policy according to certain embodiments of the present disclosure
  • FIG. 26 is a schematic diagram of an example implementation of a container manager according to certain embodiments of the present disclosure.
  • Fig. 27 is a schematic diagram of an example apparatus for implementing a policy based on driver behavior and/or monitoring of a driver for a vehicle according to certain embodiments of the present disclosure
  • Fig. 28 is a schematic diagram of an example driver information description according to certain embodiments of the present disclosure.
  • Fig. 29 is a flow chart depicting an example procedure for collecting data in response to a driver information description according to certain embodiments of the present disclosure
  • Fig. 30 is a flow chart depicting an example procedure for performing collection operations responsive to a vehicle policy data value and/or driver information description according to certain embodiments of the present disclosure
  • FIG. 31 is a schematic diagram of an example apparatus for providing data collection operations in response to a vehicle policy data value according to certain embodiments of the present disclosure
  • Fig. 32 is a schematic diagram of an example monitoring data description according to certain embodiments of the present disclosure.
  • Fig. 33 is a flow chart depicting an example procedure for implementing a policy responsive to fault and/or diagnostic values for device(s) in a vehicle system according to certain embodiments of the present disclosure
  • Fig. 34 is a schematic diagram of an example apparatus for providing data collection operations in response to a vehicle policy data value according to certain embodiments of the present disclosure
  • Fig. 35 is a schematic diagram of example end point performance descriptions according to certain embodiments of the present disclosure.
  • Fig. 36 is a flow chart depicting an example procedure for performing operations to adjust data collection in response to an end point performance description according to certain embodiments of the present disclosure
  • Fig. 37 is a schematic diagram of an example apparatus for providing data collection operations in response to a location description value according to certain embodiments of the present disclosure
  • Fig. 38 is a schematic diagram of an example location description value according to certain embodiments of the present disclosure.
  • Fig. 39 is a flow chart depicting an example procedure for adjusting data collection in response to a location description value according to certain embodiments of the present disclosure
  • Fig. 40 is a diagram of an example operation that includes adjusting collection of the vehicle data in response to the location description value according to certain embodiments of the present disclosure
  • Fig. 41 is a diagram of an example operation that includes commencing collection of vehicle data according to certain embodiments of the present disclosure
  • Fig. 42 is a diagram of an example operation that includes an operation to prevent collection of vehicle data according to certain embodiments of the present disclosure
  • Fig. 43 is a diagram of an example operation that includes adding or modifying metadata of the collected vehicle data according to certain embodiments of the present disclosure
  • Fig. 44 is a diagram of an example operation that includes adjusting a priority value of at least a portion of the collected vehicle data according to certain embodiments of the present disclosure
  • Fig. 45 is a schematic diagram of an example apparatus for data collection operations according to certain embodiments of the present disclosure.
  • Fig. 46 is a schematic diagram of an example vehicle status data according to certain embodiments of the present disclosure.
  • Fig. 47 is a flow chart depicting an example procedure to schedule data collection in response to a data type of the collected data according to certain embodiments of the present disclosure
  • Fig. 48 is a schematic diagram of an example operation that includes an operation to adjust the collection of the vehicle data according to certain embodiments of the present disclosure
  • Fig. 49 is a schematic diagram of an example operation that includes an operation to commence collection of vehicle data according to certain embodiments of the present disclosure
  • Fig. 50 is a schematic diagram of an example operation that includes an operation to prevent collection of vehicle data according to certain embodiments of the present disclosure
  • Fig. 51 is a schematic diagram of an example operation that includes an operation to add and/or modify metadata of collected vehicle data according to certain embodiments of the present disclosure
  • Fig. 52 is a schematic diagram of an example operation that includes an operation to adjust a priority value of collected vehicle data according to certain embodiments of the present disclosure
  • Fig. 53 is a flow chart depicting an example procedure to schedule data collection in response to a data type of the collected data according to certain embodiments of the present disclosure
  • Fig. 54 is a schematic diagram of an example operation that includes determining data type(s) based on a providing end point for the collected data according to certain embodiments of the present disclosure
  • Fig. 55 is a schematic diagram of an example operation that includes determining data type(s) based on a requesting end point for the collected data according to certain embodiments of the present disclosure
  • Fig. 56 is a schematic diagram of an example operation that includes determining data type(s) based on a requesting entity for the collected data according to certain embodiments of the present disclosure
  • Fig. 57 is a schematic diagram of an example operation that includes determining data type(s) based on an application associated with an end point providing the collected data according to certain embodiments of the present disclosure
  • Fig. 58 is a schematic diagram of an example operation that includes determining data type(s) based on a flow associated with an end point requesting the collected data according to certain embodiments of the present disclosure
  • Fig. 59 is a schematic diagram of an example operation that includes determining data type(s) based on a flow associated with an end point providing the collected data according to certain embodiments of the present disclosure
  • Fig. 60 is a schematic diagram of an example operation that includes determining data type(s) based on an application associated with an end point requesting the collected data according to certain embodiments of the present disclosure
  • Fig. 61 is a schematic diagram of an example operation that includes determining data type(s) based on a data type indicated in a policy according to certain embodiments of the present disclosure
  • Fig. 62 is a schematic diagram of an example collected data priority value according to certain embodiments of the present disclosure.
  • Fig. 63 is a schematic diagram of an example on-vehicle data storage priority according to certain embodiments of the present disclosure.
  • Fig. 64 is a schematic diagram of an example transmission priority according to certain embodiments of the present disclosure.
  • Fig. 65 is a schematic diagram of an example on-vehicle transmission priority according to certain embodiments of the present disclosure.
  • Fig. 66 is a schematic diagram of an example apparatus to provide data collection operations in response to vehicle status data according to certain embodiments of the present disclosure
  • Fig. 67 is a flow chart depicting an example procedure to dynamically configure data collection for a vehicle according to certain embodiments of the present disclosure
  • Fig. 68 is a flow chart depicting an example procedure to determine a vehicle status data collection change value according to certain embodiments of the present disclosure
  • Fig. 69 is a flow chart depicting an example procedure that includes an operation to determine an event occurrence, and an operation to determine a vehicle status data collection change in response to the event occurrence, according to certain embodiments of the present disclosure;
  • Fig. 70 is a flow chart depicting an example procedure that includes an operation to determine a location description value, and an operation to determine a vehicle status data collection change value, according to certain embodiments of the present disclosure
  • Fig. 71 is a schematic diagram of an example operation that includes adjusting collection of vehicle data according to certain embodiments of the present disclosure
  • Fig. 72 is a schematic diagram of an example operation that includes commencing collection of vehicle data according to certain embodiments of the present disclosure
  • Fig. 73 is a schematic diagram of an example operation that includes preventing collection of vehicle data according to certain embodiments of the present disclosure
  • Fig. 74 is a schematic diagram of an example operation that includes adding and/or modifying metadata of collected vehicle data according to certain embodiments of the present disclosure;
  • Fig. 75 is a schematic diagram of an example operation that includes adjusting a priority value of collected vehicle data according to certain embodiments of the present disclosure
  • Fig. 76 is a schematic diagram of an example operation that includes adjusting transmission of collected vehicle data according to certain embodiments of the present disclosure
  • Fig. 77 is a schematic diagram of an example operation that includes adjusting data storage of collected vehicle data according to certain embodiments of the present disclosure
  • Fig. 78 is a schematic diagram of an example operation that includes adjusting formatting and/or processing of collected vehicle data according to certain embodiments of the present disclosure
  • Fig. 79 is a flow chart depicting an example procedure to dynamically configure data collection for a vehicle according to certain embodiments of the present disclosure
  • Fig. 80 is a schematic diagram of an example operation that includes determining an event occurrence in response to fault data according to certain embodiments of the present disclosure
  • Fig. 81 is a schematic diagram of an example operation that includes determining an event occurrence according to certain embodiments of the present disclosure
  • Fig. 82 is schematic diagram of an example operation that includes determining an event occurrence according to certain embodiments of the present disclosure
  • Fig. 83 is a schematic diagram of an example operation that includes an operation to monitor trigger evaluation data, and to determine an event occurrence based on a trigger condition and the trigger evaluation data, according to certain embodiments of the present disclosure
  • Fig. 84 is a schematic diagram of an example apparatus to implement data collection utilizing a policy hierarchy according to certain embodiments of the present disclosure
  • Fig. 85 is a schematic diagram of an example apparatus for utilizing multiple policy types to exercise vehicle data collection or other operations according to certain embodiments of the present disclosure
  • Fig. 86 is a flow chart depicting an example procedure for implementing policy execution on a vehicle according to certain embodiments of the present disclosure
  • Fig. 87 is a flow chart depicting an example procedure for implementing policy execution on a vehicle according to certain embodiments of the present disclosure
  • Fig. 88 is a schematic diagram of an example utilized policy hierarchy according to certain embodiments of the present disclosure.
  • Fig. 89 is a schematic diagram of another example utilized policy hierarchy according to certain embodiments of the present disclosure.
  • Fig. 90 is a schematic diagram of another example utilized policy according to certain embodiments of the present disclosure.
  • FIG. 91 s a schematic diagram of another example utilized policy according to certain embodiments of the present disclosure.
  • Fig. 92 is a flow chart depicting an example procedure to update a data collection policy according to certain embodiments of the present disclosure
  • Fig. 93 is a flow chart depicting an example procedure to implement a policy hierarchy according to certain embodiments of the present disclosure
  • Fig. 94 is a flow chart depicting an example procedure to implement a policy hierarchy according to certain embodiments of the present disclosure
  • Fig. 95 is a schematic diagram of an example apparatus for performing data collection operations utilizing a shared storage for collected data according to certain embodiments of the present disclosure
  • Fig. 96 is a flow chart depicting an example procedure for selectively storing collected data parameters on a vehicle according to certain embodiments of the present disclosure
  • Fig. 97 is a schematic diagram of an example operation that includes an operation to determine a parameter transmission schedule for stored parameters, and an operation to selectively store at least a portion of vehicle parameter values, according to certain embodiments of the present disclosure
  • Fig. 98 is a schematic diagram of an example operation that includes an operation to determine a parameter expiration schedule for stored parameters, and an operation to selectively store at least a portion of vehicle parameter values, according to certain embodiments of the present disclosure
  • Fig. 99 is a schematic diagram of an example operation that includes an operation to determine a reserved memory amount for stored parameters, and an operation to selectively store at least a portion of vehicle parameter values in response to the reserved memory amount, according to certain embodiments of the present disclosure
  • Fig. 100 is a schematic diagram of an example operation that includes deleting at least a portion of stored vehicle parameter values according to certain embodiments of the present disclosure
  • Fig. 101 is a schematic diagram of an example operation that includes summarizing at least a portion of the stored vehicle parameter values according to certain embodiments of the present disclosure
  • Fig. 102 is a schematic diagram of an example operation that includes adjusting a reserved memory amount associated with stored vehicle parameters according to certain embodiments of the present disclosure
  • Fig. 103 is a schematic diagram of an example operation that includes compressing at least a portion of stored vehicle parameters according to certain embodiments of the present disclosure
  • Fig. 104 is a schematic diagram of an example operation that includes determining an amount of data to be collected to support vehicle parameter values according to certain embodiments of the present disclosure
  • Fig. 105 is a schematic diagram of an example operation that includes determining an amount of data to be collected to support a trigger evaluation associated with vehicle parameter values according to certain embodiments of the present disclosure
  • Fig. 106 is a schematic diagram of an example operation that includes determining a transmission latency value associated with vehicle parameter values according to certain embodiments of the present disclosure
  • Fig. 107 is a schematic diagram of an example operation that includes determining a priority value associated with vehicle parameter values according to certain embodiments of the present disclosure
  • FIG. 108 is a schematic diagram of an example apparatus for performing data collection operations implementing a data collection policy according to certain embodiments of the present disclosure
  • Fig. 109 is a schematic diagram of an example data collection policy according to certain embodiments of the present disclosure.
  • Fig. 110 is a schematic diagram of an example transmission description value according to certain embodiments of the present disclosure.
  • Fig. 111 is a schematic diagram of an example policy priority value according to certain embodiments of the present disclosure.
  • Fig. 112 is a schematic diagram of an example policy life cycle description according to certain embodiments of the present disclosure.
  • Fig. 113 is a flow chart depicting an example procedure to collect data pursuant to a policy according to certain embodiments of the present disclosure
  • Fig. 114 is a schematic diagram of an example cloud system according to certain embodiments of the present disclosure.
  • Fig. 115 depicts an example cloud system for retrieving selected data from a vehicle according to certain embodiments of the present disclosure
  • Fig. 116 depicts an example schematic diagram of an operation that includes an operation for data collection operations from a vehicle according to certain embodiments of the present disclosure
  • Fig. 117 depicts an example procedure for separating responsive data to a vehicle data collection operation according to certain embodiments of the present disclosure
  • Fig. 118 depicts an example procedure for separating responsive data to a vehicle data collection operation according to certain embodiments of the present disclosure
  • Fig. 119 depicts an example system for retrieving selected data from a vehicle according to certain embodiments of the present disclosure
  • Fig. 120 depicts an example procedure for identifying data according to certain embodiments of the present disclosure
  • Fig. 121 depicts an example cloud system for preparing data collection policies according to certain embodiments of the present disclosure
  • Fig. 122 depicts an example policy creator circuit according to certain embodiments of the present disclosure
  • Fig. 123 depicts an example request interface according to certain embodiments of the present disclosure
  • Fig. 124 depicts an example procedure for operating a request interface according to certain embodiments of the present disclosure
  • Fig. 125 depicts an example schematic to operate a container-based implementation of one or more control aspects of a vehicle according to certain embodiments of the present disclosure
  • Fig. 126 depicts an example schematic to operate a container-based implementation of one or more control aspects of a vehicle according to certain embodiments of the present disclosure
  • Fig. 127 depicts an example schematic to operate a container-based implementation of one or more control aspects of a vehicle according to certain embodiments of the present disclosure
  • Fig. 128 depicts an example schematic to operate a container-based implementation of one or more control aspects of a vehicle according to certain embodiments of the present disclosure
  • Fig. 129 depicts an example schematic to operate a container-based implementation of one or more control aspects of a vehicle according to certain embodiments of the present disclosure
  • Fig. 130 depicts an example schematic to operate a container-based implementation of one or more control aspects of a vehicle according to certain embodiments of the present disclosure
  • Fig. 131 depicts an example schematic to provide automated vehicle operations based on data values according to certain embodiments of the present disclosure
  • Fig. 132 depicts an example schematic to provide automated vehicle operations based on data values according to certain embodiments of the present disclosure
  • Fig. 133 depicts an example schematic to provide automated vehicle operations based on data values according to certain embodiments of the present disclosure
  • Fig. 134 depicts an example schematic for performing data collection operations according to certain embodiments of the present disclosure
  • Fig. 135 depicts an example schematic for transmission operations of vehicle data with a cloud system and/or an external device according to certain embodiments of the present disclosure
  • Fig. 136 depicts an example procedure to manage transmission operations of a vehicle according to certain embodiments of the present disclosure
  • Fig. 137 depicts an example procedure for selectively transmitting collected data in response to a selected transmission interval according to certain embodiments of the present disclosure
  • Fig. 138 depicts an example procedure for selectively transmitting collected data in response to a selected bandwidth utilization according to certain embodiments of the present disclosure
  • Fig. 139 depicts an example procedure for selectively transmitting collected data in response to a data type of the collected data according to certain embodiments of the present disclosure
  • Fig. 140 depicts an example procedure for selectively transmitting collected data in response to a vehicle operational impact of transmission operations according to certain embodiments of the present disclosure
  • Fig. 141 depicts an example procedure for selectively transmitting collected data in response to a power utilization impact of transmission operations according to certain embodiments of the present disclosure
  • Fig. 142 depicts an example procedure for selectively transmitting collected data in response to a data transmission capacity value according to certain embodiments of the present disclosure
  • Fig. 143 depicts an example procedure for selectively transmitting collected data in response to a currently available transmission type according to certain embodiments of the present disclosure
  • Fig. 144 depicts an example procedure for selectively transmitting collected data in response to a selected data transmission chunk size according to certain embodiments of the present disclosure
  • Fig. 145 depicts an example procedure for selectively transmitting collected data in response to a success parameter for transmitting operations according to certain embodiments of the present disclosure
  • Fig. 146 depicts an example procedure for selectively transmitting collected data in response to a quality of service value for transmitting operations according to certain embodiments of the present disclosure
  • Fig. 147 depicts an example schematic for implementing remote assistance operations for a vehicle according to certain embodiments of the present disclosure
  • Fig. 148 depicts an example schematic for a cloud system in communication with a vehicle according to certain embodiments of the present disclosure
  • Fig. 149 depicts an example procedure for performing remote operations for a vehicle according to certain embodiments of the present disclosure
  • Fig. 150 depicts an example procedure for performing operations for a vehicle including remote assistance operations according to certain embodiments of the present disclosure
  • Fig. 151 is a schematic drawing of an apparatus for collecting and/or managing vehicle data according to certain embodiments of the present disclosure
  • Fig. 152 is a schematic diagram of another apparatus for collecting and/or managing vehicle data according to certain embodiments of the present disclosure.
  • Fig. 153 is a schematic diagram of another apparatus for collecting and/or managing vehicle data according to certain embodiments of the present disclosure.
  • Fig. 154 is a schematic diagram of another apparatus for collecting and/or managing vehicle data according to certain embodiments of the present disclosure.
  • Fig. 155 is a flow chart depicting a method for collecting and/or managing vehicle data, according to certain embodiments of the present disclosure
  • Fig. 156 is another flow chart depicting the method of Fig. 155 according to certain embodiments of the present disclosure.
  • Fig. 157 is another flow chart depicting the method of Fig. 155, according to certain embodiments of the present disclosure.
  • Fig. 158 is a flow chart depicting another method for collecting and/or managing vehicle data according to certain embodiments of the present disclosure.
  • Fig. 159 is another flow chart depicting the method of Fig. 158 according to certain embodiments of the present disclosure
  • Fig. 160 is a schematic diagram of an apparatus for data collection policy intake and execution according to certain embodiments of the present disclosure
  • Fig. 161 is a schematic diagram of another apparatus for data collection policy intake and execution according to certain embodiments of the present disclosure.
  • Fig. 162 is another schematic diagram of the apparatus of Fig. 161 according to certain embodiments of the present disclosure.
  • FIG. 163 is another schematic diagram of the apparatus of Fig. 161 according to certain embodiments of the present disclosure.
  • Fig. 164 is another schematic diagram of the apparatus of Fig. 161 according to certain embodiments of the present disclosure.
  • Fig. 165 is a flow chart depicting a method for data collection policy intake and execution according to certain embodiments of the present disclosure
  • Fig. 166 is another flow chart depicting the method of Fig. 165 according to certain embodiments of the present disclosure.
  • Fig. 167 is another flow chart depicting the method of Fig. 165 according to certain embodiments of the present disclosure.
  • Fig. 168 is another flow chart depicting the method of Fig. 165 according to certain embodiments of the present disclosure.
  • Fig. 169 is another flow chart depicting the method of Fig. 165 according to certain embodiments of the present disclosure.
  • Fig. 170 is a schematic diagram of an apparatus for data collection in a mixed network environment according to certain embodiments of the present disclosure
  • Fig. 171 is a schematic diagram of another apparatus for data collection in a mixed network environment according to certain embodiments of the present disclosure.
  • Fig. 172 is a flow chart depicting a method for data collection in a mixed network environment according to certain embodiments of the present disclosure
  • FIG. 173 is another flow chart depicting the method of Fig. 172 according to certain embodiments of the present disclosure.
  • Fig. 174 is a schematic diagram of an apparatus for data collection process management according to certain embodiments of the present disclosure.
  • Fig. 175 is a schematic diagram of another apparatus for data collection process management according to certain embodiments of the present disclosure.
  • Fig. 176 is another schematic diagram of the apparatus of Fig. 175 according to certain embodiments of the present disclosure
  • Fig. 177 is another schematic diagram of the apparatus of Fig. 175 according to certain embodiments of the present disclosure
  • Fig. 178 is a flow chart depicting a method for data collection process management according to certain embodiments of the present disclosure
  • Fig. 179 is another flow chart depicting the method of Fig. 178 according to certain embodiments of the present disclosure.
  • Fig. 180 is a schematic diagram of an apparatus for data storage management according to certain embodiments of the present disclosure.
  • Fig. 181 is another schematic diagram of the apparatus of Fig. 180 according to certain embodiments of the present disclosure.
  • Fig. 182 is a flow chart depicting a method for data storage management according to certain embodiments of the present disclosure
  • Fig. 183 is another flow chart depicting the method of Fig. 182 according to certain embodiments of the present disclosure.
  • Fig. 184 is another flow chart depicting the method of Fig. 182 according to certain embodiments of the present disclosure.
  • Fig. 185 is another flow chart depicting the method of Fig. 182 according to certain embodiments of the present disclosure.
  • Fig. 186 is another flow chart depicting the method of Fig. 182 according to certain embodiments of the present disclosure.
  • Fig. 187 is a box diagram illustrating an exemplary user device according to certain embodiments of the present disclosure.
  • FIGs. 188-189 are flowcharts illustrating exemplary user device-based data collection processes according to certain embodiments of the present disclosure
  • Fig. 190 is a box diagram illustrating an exemplary cloud system according to certain embodiments of the present disclosure.
  • Figs. 191-195 are flowcharts illustrating exemplary cloud system-based data collection processes according to certain embodiments of the present disclosure
  • Fig. 196 is a box diagram illustrating an exemplary vehicle according to certain embodiments of the present disclosure.
  • FIGs. 197-200 are flowcharts illustrating exemplary vehicle-based data collection according to certain embodiments of the present disclosure
  • Fig. 201 is a box diagram of an exemplary vehicle according to certain embodiments of the present disclosure
  • Fig. 202 is a box diagram of an exemplary data collection controller according to certain embodiments of the present disclosure
  • FIGs. 203-205 are flowcharts illustrating exemplary data collection processes according to certain embodiments of the present disclosure.
  • Fig. 206 is a box diagram of an exemplary vehicle according to certain embodiments of the present disclosure.
  • Fig. 207 is a box diagram of an exemplary data collection controller according to certain embodiments of the present disclosure.
  • FIGs. 208-210 are flowcharts illustrating exemplary data collection processes according to certain embodiments of the present disclosure.
  • aspects of the disclosure herein reduce and/or eliminate any one or more of: a cost per entity added to a data collection system, a basic learning cost for a new entity to implement an application utilizing collected data, an adaptation cost to changing vehicle network configuration(s), a cost incurred to meet the increasing demand for data collection, a cost to adapt to a changing regulatory environment, and/or a cost to secure data and/or losses incurred for breaches or unauthorized use. Certain embodiments and/or aspects of the disclosure herein may address one or more of the described cost parameters.
  • Certain embodiments and/or aspects of the disclosure herein may increase one or more given cost parameters, but nevertheless be beneficial by decreasing the overall cost function for a target vehicle, vehicle type, entity, industry, etc. Certain embodiments and/or aspects of the disclosure herein may increase one or more given cost parameters, but provide other benefits such as improved functionality. In certain embodiments, improved functionality may be achieved at an increased cost, but at a lower cost than previously known systems configured to achieve a similar improved functionality.
  • Example mixed vehicle networks include a network having one or more CAN buses with a number of devices communicating over the CAN bus(es), and one or more ethemet networks with a number of devices communicating over the ethemet network, and communication that crosses from CAN to ethemet and/or vice- versa.
  • Mixed networks are not limited to CAN and ethemet, and may include, without limitation, any one or more of a local interconnect network (LIN), FlexRay, Media Oriented Systems Transport (MOST), and/or low-voltage differential signaling (LVDS).
  • LIN local interconnect network
  • MOST Media Oriented Systems Transport
  • LVDS low-voltage differential signaling
  • Currently available ethemet networks are highly capable, having bandwidth ratings between 100 Mbps to 25 Gbps, and latency values between 5 ms to 20 ps (0.02 ms).
  • more than one ethemet network may be present, and may include mixed capability ethemet networks.
  • one or more networks present may include wireless networks such as a WiFi network (e.g., an 802.1 lx standard such as a/b/g; n; and/or ac), a mobile standard network (e.g., 4G and/or 5G), Bluetooth communications, universal serial bus (USB) connections, and/or fiber optic connections.
  • WiFi network e.g., an 802.1 lx standard such as a/b/g; n; and/or ac
  • a mobile standard network e.g., 4G and/or 5G
  • Bluetooth communications e.g., Bluetooth communications, universal serial bus (USB) connections, and/or fiber optic connections.
  • USB universal serial bus
  • the mixed vehicle network includes one or more low- capability networks combined with one or more high-capability networks.
  • the capability that is considered low-capability depends upon the application, the number of devices that are in communication, the types of communication that are allowed on the network, and the available network management (e.g., registration, addition, or removal of devices, encryption of messages, customization of messages, etc.) for the particular network and communication protocols being utilized.
  • the mixed vehicle network includes more than one network, where at least two of the networks present an integration challenge.
  • one of the networks may only allow certain types of communications, require certain types of synchronous or asynchronous communications, only allow connection of certain types of devices, limit the implementation of certain network topologies, or have other differences or limitations that render utilization of a single network (or network type) throughout the vehicle undesirable or impractical.
  • the description herein utilizing off-vehicle, extra-vehicle, and/or cloud-based interactions references any external network communications of the vehicle, including without limitation wireless-based communications (e.g., mobile data, WiFi, and/or Bluetooth) to external devices. Communications to external devices may be to a general network (e.g., over the internet), a WAN, a LAN, a mobile device in proximity to the vehicle, and/or combinations of these. Certain systems and procedures described herein particularly contemplate run-time operations of the vehicle, for example external communications occurring during operating conditions wherein the vehicle is executing a mission (e.g., moving, performing operations while not moving, etc.).
  • a mission e.g., moving, performing operations while not moving, etc.
  • the disclosure herein further contemplates communications that may occur during any period, including during down-time of the vehicle and/or during service events.
  • the disclosure herein further contemplates communications that may occur through wired communication channels, such as when the vehicle network is in communication with a service tool, on-board diagnostics (OBD) instrument, or other physically coupled device.
  • OBD on-board diagnostics
  • Example 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 (that may be considered “vehicles”, or not) and/or manufacturing systems. It will be understood that certain features, aspects, and/or benefits of the present disclosure are applicable to any one or more of these applications, not applicable to others of these applications, and the applicability of certain features, aspects, and/or benefits of the present disclosure may vary depending upon the operating conditions, constraints, cost parameters (e.g., operating cost, integration cost, operating cost, data communication and/or storage costs, service costs and/or downtime costs, etc.) of the particular application.
  • cost parameters e.g., operating cost, integration cost, operating cost, data communication and/or storage costs, service costs and/or downtime costs, etc.
  • An example flow includes a related group of data (e.g., speed data, temperature data, audio-visual data, navigation data, etc.), a related group of functions (e.g., among vehicle functions, extra vehicle functions such as service operations and/or data collection, aggregations between related vehicles, and/or combinations of these that are related for a particular system), a related group of devices (e.g., door actuators), and/or a related group of applications.
  • Flows as used herein, provide an organizing concept that may be utilized to relate certain data, certain end points, certain applications, and/or related functions of the vehicle or apart from the vehicle.
  • a controller can utilize a flow to identify a data source, a data destination, permissions available for the flow, priority information related to the flow, or the like, to implement certain data regulating operations here.
  • the utilization of the flow allows the controller to perform separate operations that may involve the same end points to support the desired network management.
  • a vehicle speed management application may have a high priority, and a speedometer end point may be associated with the vehicle speed management application.
  • the controller applies a high priority to the vehicle speed message.
  • the controller may apply a lower priority to the vehicle speed message.
  • a failure of a vehicle controller, portion of a network, or other off-nominal condition may result in the migration of the vehicle speed management application to another controller in the system, whereby the vehicle speed message is being communicated (e.g., where the backup controller is on another network) to support the vehicle speed management application, and the controller may apply a higher priority to the vehicle speed message.
  • the utilization of flows and applications to organize the components of the system allows for the same or similar information to be regulated by the controller in a differential manner to support various functions, allowing for improvements in the performance and security of network regulation operations (e.g., reducing unnecessary cross-network traffic, and providing information only as needed), and supports additional functionality relative to previously known systems, such as redundancy support, distributed control, and granular cross-network messaging.
  • a policy includes a description of data to be collected, such as data parameters, collection rates, resolution information, priority values (e.g., ordering data collection values for selection in response to off-nominal conditions where not all data collection parameters can be serviced, etc.).
  • a policy further includes event information, which may be stipulated as parameter or quantitative based events (e.g., a given data value exceeds a threshold, etc.), and/or categorical events (e.g., a particular fault code, operational condition or state, or vehicle location/jurisdiction occurs).
  • a policy further includes an event response, such as data values to be captured in response to the occurrence of the event, and/or other changes in the data collection scheme such as increased or reduced data collection rates, changes in collected resolution, or the like.
  • an event response further includes a time frame associated with the event occurrence, for example a time period after the event occurrence to utilize the adjusted data collection scheme, and/or a time period preceding the event occurrence (e.g., utilizing a rolling buffer or other data collection operation, providing temporary information that can subsequently be captured if the event occurs).
  • changes to the data collection scheme for an event can include multiple changes - for example changes over a period of time, further changes based upon the progression of the event (e.g., if the event severity gets worse), and/or criteria to determine that an event is cleared.
  • changes to a data collection scheme may be implemented based on event related clearance of the same or another event, for example implementing a data collection change until a next shutdown event of the vehicle, until a service technician clears the event, for a selected number of shutdown events occurs, or the like.
  • the utilization of a policy herein may reference a partial policy, for example the implied policy that would be implemented in response to a single data collection scheme from a single user, wherein the full policy is prepared, verified, and communicated to the vehicle after one or more partial policies are aggregated.
  • the utilization of a policy herein may reference an unverified policy, for example after a policy responsive to a number of users is aggregated, but verification operations of the policy are not yet completed (e.g., before it is determined if the data collection implied by the policy can be performed).
  • the utilization of a policy herein may reference a previously applied policy (e.g., a policy present on a vehicle before an updated version of the policy is communicated to the vehicle and/or implemented on the vehicle).
  • the utilization of a policy herein may reference an updated policy, for example a verified policy that is pending for communication to the vehicle 102 and/or confirmed by the vehicle 102 (e.g., from the data collection controller 202).
  • an example system having a vehicle 102 communicatively coupled to an off-vehicle device 104.
  • the example system includes the off- vehicle 104 device(s) communicatively coupled to one or more user devices 106.
  • the vehicle 102 may include a mixed network having a number of data providing devices coupled to network(s) on the vehicle, for example with one or more devices coupled to a CAN network, and one or more other devices coupled to an ethemet network.
  • the example system allows for users (e.g., application providers, fleet owners, manufacturers, customers, etc.) to access the off-vehicle 104 device, configuring data collection to be implemented from the vehicle 102 to the off-vehicle device 104.
  • the system allows for access to at least a portion of the collected data for utilization in an application relating to the vehicle.
  • the system provides for authorization control for users and/or applications to ensure that data collection requests are properly made.
  • the system provides for data collection control to ensure that requested data communications are achievable, and/or consume reduced data communication resources.
  • the system provides for consent implementation to ensure appropriate consent (e.g., from an operator or owner of the vehicle) is provided before relevant data collection is performed.
  • the system provides for isolation of specific vehicle information (e.g., data parameter names, communication protocol information, locations and/or ID values of data providers in a mixed network environment of the vehicle) from data requestors and/or users, thereby alleviating the data requestor and/or user from having to leam the specific vehicle information and/or keeping that information updated.
  • specific vehicle information e.g., data parameter names, communication protocol information, locations and/or ID values of data providers in a mixed network environment of the vehicle
  • the system provides for isolation of stored data collected from the vehicle from a system providing requested data to applications utilizing portions of the data.
  • the system provides for integrated policy management controlling data collection parameters from a number of simultaneous data requestors, and/or providing enhanced policy management controls to certain users such as policy creators and/or policy controllers.
  • the system provides for enhanced policy creation and/or updating, whereby the system communicates with a user in a manner structured to provide the user with high level functionality descriptions, without requiring knowledge from the user about the specific vehicle and/or specific data utilized to support the corresponding high level functionality.
  • the system provides for enhanced data communication to and from the vehicle that is responsive to intermittent network access, and/or intermittent network bandwidth availability, to communicate requested data from the vehicle to an off-vehicle device.
  • the example vehicle includes a data collection controller 202 that is configured to accept a policy from an off-vehicle device 104, and to propagate functionality in response to the policy to on-vehicle devices to perform appropriate data collection.
  • the example data collection controller 102 further communicates the collected data to the off-vehicle device 104, and/or manages communication in response to intermittent network availability and/or intermittent network bandwidth availability.
  • the example vehicle 102 further includes an inter-network switch 204 that is communicatively coupled to at least two networks on the vehicle 102.
  • the example inter network switch 204 is directly coupled to a number of devices 210 on a first network, and coupled to a second number of devices 208 on a second network, for example via communications with an edge gateway 206.
  • Certain further and/or more detailed operations of the inter-network switch 204 are described in the portion of the disclosure referencing Figs. 5 and 7.
  • Certain further and/or more detailed operations of the devices 210 are described in the portion of the disclosure referencing Figs. 5 and 8.
  • Certain further and/or more detailed operations of the edge gateway 206 are described in the portion of the disclosure referencing Figs. 5 and 6.
  • the example vehicle 102 further includes a user consent controller 212 that is communicatively coupled to the data collection controller 202 and/or to the off-vehicle device 104.
  • the user consent controller 212 may be an on-vehicle device such as a vehicle display (e.g., a PAD or console device), and/or the user consent controller 212 may be a mobile application (e.g., a mobile device of the user having a consent application operable thereon), a web-based application (e.g., a web application accessible to the user and relating to the vehicle 102), and/or may include more than one of these.
  • external communications 214 may include communications to the off-vehicle device 104.
  • the external communications 214 may be passed wirelessly (e.g., from an available transceiver on the vehicle and in communication with the data collection controller 202 and/or the user consent controller 212), and/or may be passed through a wired communication (e.g., a service tool, OBD device, or the like coupled to a network on the vehicle, for example as a device 210 in communication with the inter-network switch 204).
  • a service tool e.g., OBD device, or the like
  • an example off-vehicle device 104 is depicted.
  • the example off-vehicle device 104 is depicted schematically as an integrated device having managers and other components depicted thereon to illustrate the interaction of functional elements of the off-vehicle device 104.
  • the off-vehicle device 104 may be a distributed device, having aspects present on a number of controllers, transceivers, servers, or the like.
  • the off-vehicle device 104 may be implemented at least partially as a cloud- based device, for example utilizing or communicating with a web-based and/or cloud-based service, such as Amazon Web Services (AWS), Microsoft Azure web services, Cloudflare network services, or the like.
  • AWS Amazon Web Services
  • Azure Microsoft Azure web services
  • Cloudflare network services or the like.
  • aspects of the off-vehicle device 104 may be segregated and/or distributed across more than one service, dedicated server, and/or computing device.
  • 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.
  • the example of Fig. 3 depicts a partition 306, where communications across the partition 306 may be configured to an interface specification or other agreed upon or implemented communication scheme.
  • the example partition 302 includes a network manager 312 that performs load management functions and manages communication 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 a data communications 308 component, for example passing vehicle data received 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.
  • the vehicle policy communications manager 310 receives processed policies from a policy manager 330 (and/or from a vehicle data request manager 342) on the second partition 304, makes the policy available to the vehicle 102, and/or determines the timing of when to communicate the policy to the vehicle.
  • the example vehicle data request manager 342 determines data to be collected in response to a policy provided by the policy manager 330.
  • a policy includes a number of data requests from users (e.g., devices 106 and/or internal applications 334), and the vehicle data request manager 342 aggregates the requested data into a set of specific parameters for data collection that meet the data collection needs of all data requests in the policy.
  • the policy manager 330 and/or the vehicle data request manager 342 perform policy verification, ensuring that a given policy can be supported (e.g., the requesting user is authorized, the parameter is available on the vehicle, and/or the aggregated data collection to meet the policy can be achieved within the bandwidth limits available) before the vehicle data request manager 342 provides the data requests to the vehicle policy communications manager 310.
  • 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 other selected data structure.
  • the aggregated data collection set, including the relevant data structure comprises the policy to be sent to the vehicle 102.
  • the data structure to be sent to the vehicle 102 includes other information, such as event descriptions, priority information, and/or response information to off-nominal conditions such as intermittent network availability, as a part of the policy.
  • Embodiments of the present disclosure provide for systems, apparatuses, and methods for providing a service oriented architecture (SOA) and management of SOA features and functions.
  • SOA embodiments herein are capable to support multiple types of services, such as data services and/or functional services.
  • SOA embodiments herein are capable to support multiple types of service participants, including without limitation manufacturers, OEMs, customers, operators, owners, service personnel, fleet managers (e.g., service, dispatch, compliance, etc.), SOA service requestors, SOA service providers, and/or third-party applications.
  • Embodiments herein are capable to support SOA operations over multiple networks, including one or more vehicle networks, vehicle networks having mixed network types, external networks, and/or cloud based networks.
  • Embodiments herein are capable to support multiple network protocols, including for devices or participants as SOA service providers and/or SOA service requestors, including at least SOME/IP, MQTT, HTTP, CAN, LIN, FlexRay, MOST, TTP, and/or LVDS network protocols.
  • Embodiments herein are capable to support reliable, secure, and convenient SOA service implementations, including service discovery, recovery, maintenance, and/or updates to available services provided and/or requested.
  • An example policy includes a policy provided by an external device that requests a vehicle to collect a set of data over a defined period of time, or short period of time, and to send the data back to the external device.
  • the data may be sent back to the external device within a defined time period stated in the policy, and/or according to a default time period for such policy operations, and may include sending the data back to the external device as soon as the collection of the data is complete.
  • the example policy may be deleted, removed, or otherwise considered complete after the data collection event, and/or after a successive number of data collection events.
  • Such a policy may be referenced as an ad hoc policy, a one-time policy (which may include one or more finite data collection events), an impromptu policy, a single-use policy, an emergency policy, or the like.
  • Example uses of such a policy include rapid response data collection (e.g., handling for an emergency event; information collection to prepare for an update, campaign, or other planned change to a number of vehicles; collection of a data set for training a model or an artificial intelligence component; and/or data collection under any circumstance where the use of the data is expected to be performed within a finite period of time, and ongoing data collection for the policy is not desired).
  • An example policy includes a policy provided by an external device that requests the vehicle to collect a set of data over an extended period of time, and/or on an ongoing basis, where the collected data is sent back to the external device periodically and/or intermittently at intervals that allow for improved utilization of bandwidth by selecting transmission times and/or allowing for compression operations on the data to reduce communicated data volumes.
  • the example policy may be kept for a defined period, kept until removed by the external device, and/or kept until an event occurs (e.g., a research data collection operation, where the event is configured to establish that the vehicle is no longer relevant to the research).
  • the defined period and/or event parameters to delete the policy may be defined within the policy.
  • Example uses of such a policy include research projects, continuous improvement projects (e.g., development of diagnostic or prognostic algorithms for a vehicle or a related group of vehicles, continuous improvement of operational algorithms, etc.), ongoing analysis projects (e.g., analyzing a large data set to detect trends, changes within a related group of vehicles, and/or verify that a change to the related group of vehicles is having an expected effect), and/or projects where a time constant of the project output is long relative to data rates typically received from low utilization data transmission operations.
  • Such a policy may be referenced as a research policy, an analysis policy, a non urgent data policy, or the like.
  • An example policy includes a policy provided by an external device that requests a vehicle to collect a set of data over an extended period of time, and send the data back to the external device the vehicle as the data is collected, in defined data blocks as each data block is collected, and/or in a streaming fashion.
  • the example policy may be kept for a defined period, kept until removed by the external device, and/or kept until an event occurs (e.g., a change in an algorithm or process utilizing the data, where the data utilized by the algorithm or process changes, where the algorithm or process is discontinued, where the algorithm or process is replaced by an updated algorithm or process, or the like).
  • the defined period and/or event parameters to delete the policy may be defined within the policy.
  • Example uses of such a policy include real-time monitoring of vehicle conditions, implementation of diagnostic or prognostic algorithms for a vehicle or a related group of vehicles, and/or projects where a time constant of the project output is short enough that low utilization data transmission operations are not sufficient to support the project, or to support the project with acceptable performance.
  • a policy may be referenced as a real-time monitoring policy, an urgent data policy, an immediate data policy, or the like.
  • the first partition 302 further includes a data store 320, which may be a raw data store that stores the data provided by the data communications 308 component the data store 320 keeps the data segregated from the second partition 304 until the collected data is requested, thereby segmenting the risk incurred from data storage.
  • the first partition 302 may be controlled by and/or operated by a first entity
  • the second partition 304 may be controlled by and/or operated by a second entity, whereby the partition 306 segments the risk associated with the data storage.
  • the data store 302 stores the data in an encrypted format, which may further be configured such that the first entity operating the first partition 302 cannot access the data values of the stored data.
  • the data store 302 stores the data associated with metadata values, such as vehicle information, time stamps, data category descriptions, or the like, such that appropriate data can be supplied responsive to a data request by the data request/processing 322 component.
  • the example second partition 304 further includes a consent manager 332 that determines whether consent for data values in a policy are required, and communicates with the user consent controller 312 and/or a consent application 402 (reference Fig. 12) to request and receive consent values.
  • an application authorization data store 328 is utilized to store consent information, such as consent confirmations for a current policy, pending policy, or the like.
  • the application authorization data store 328 may further be utilized to determine policy aspects (e.g., data parameters, sampling rates, event values, and/or use case values) that are authorized for access by specific users, user roles, applications 402, and/or in accordance with other authorization schemes to be utilized.
  • the example second partition 330 further includes a policy manager 330 that receives inputs from users and/or applications to determine a requested policy, policy update, policy change, or the like.
  • the policy manager 330 interfaces with user devices 106, external applications 402, and/or internal applications 334 via an API engine 326 to determine the requested data collection, events, priorities, etc. to be utilized in determining the policy.
  • a user or application may provide a requested policy as a data structure to the policy manager 330, for example a formatted data XML, JSON, HTML, or other data structure that includes formatted descriptions of the requested policy elements.
  • the policy manager 330 provides a user interface to a user or application to provide for rapid, convenient, and/or reliable formatting for policy requests.
  • the policy manager 330 interfacing with an application or user may provide a list of data elements, predetermined event values, and/or predetermined response values, that are available in the system.
  • the list may include interface elements such as dropdown lists, check boxes, or other interfaces allowing for rapid selection of requested elements, and ensuring proper formatting of the requested elements.
  • user and/or application authorization of requested elements may be performed during construction or entry of the requested policy elements - for example the policy manager 330 may hide unauthorized elements, display unauthorized elements in an alternative format (e.g., grayed out), and/or provide an alert or notification that an unauthorized element is presently contained within the requested policy elements.
  • the policy manager 330 may allow unauthorized elements into the policy request (and/or omit pre-screening of authorization), where the policy manager 330 will reject creation of a policy based on the policy request if unauthorized elements are still present at a time of verifying an integrated policy for updating (e.g., integrating a number of policy requests from various users and/or applications into an integrated policy).
  • the policy manager 330 may notify a user or application (e.g., a policy creator, policy controller, a super-user, or the like) that a verification of a policy request has failed, whether due to inclusion of an unauthorized data request, due to excessive communication bandwidth requirements, or otherwise.
  • the policy manager 330 may identify which element of the policy request caused the verification failure, and/or may provide the notified user or application with options, such as a communication to the user or application making the unauthorized request, an option to authorize the unauthorized request, or the like.
  • operations of the policy manager 330 include operations to compile a number of policy requests from users and/or applications (internal or external) into an integrated policy structure.
  • the policy manager 330 (and/or the vehicle data request manager 342) provides the integrated policy structure as a super-set of the data requests (e.g., consolidating data requests for a given parameter), and may further consolidate event requests and/or event responses where those consolidation operations can be made consistent with achieving the events and responses within the individual policy requests.
  • the policy manager 330 may include consideration of the data super-set in determining event responses - for example where an event is requesting data to be taken in response to an event, but the data is already being collected for another request within the policy, the event may be omitted and/or the data collected may be reduced to account for the availability of the data.
  • the policy manager 330 includes operations to verify the integrated policy structure, for example to ensure that users and/or applications are only requesting authorized data, to ensure that data parameters requiring consent have the consent available (and/or communicating the consent requirement to the consent manager 332 for appropriate action), and/or to ensure that network bandwidth capabilities of the vehicle, data storage capabilities of the vehicle, or other parameters can meet the requirements of the integrated policy structure.
  • the policy manager 330 keeps an updated “live” verification, for example verifying a potential integrated policy structure as policy requests are received from users and/or application.
  • the policy manager 330 performs a verification upon request, for example by a policy creator, which may be performed as a “build” of a policy or policy update.
  • the policy manager 330 utilizes a default policy, for example when a vehicle is first manufactured.
  • the policy manager 330 may communicate the policy to the vehicle policy communications manager 310 for communication to the vehicle 102. Additionally or alternatively, the policy manager 330 may communicate the policy to the vehicle policy communications manager 310 in response to a request from a policy creator, super-user, or other authorized system user.
  • the policy manager 330 or other system components may access a policy data store 340, which may include previously verified 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 upon an application role such as OEM, Manufacturer, 3 rd part, etc.), example event values and/or event responses, and/or vehicle data (e.g., nominal bandwidth descriptions, storage information, etc.).
  • a policy data store 340 may include previously verified 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 upon an application role such as OEM, Manufacturer, 3 rd part, etc.), example event values and/or event responses, and/or vehicle data (e.g., nominal bandwidth descriptions, storage information, etc.).
  • the policy manager 330 provides a high level description to a user or application, which in certain embodiments may be referenced as a “use case.”
  • 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. The selection of the use case can thereby be utilized to quickly build a policy request having predetermined information therein.
  • the use case presented to the user may be stored in the data store 340, and/or may depend upon the role and/or authorizations of the user and/or application.
  • a use case may have an identifiable or common name, such as “routing application use case,” “passenger car standard use case,” “delivery vehicle use case,” etc.
  • the data store 340 may have default use cases available, and/or may include use cases created or constructed, and/or made available by a policy creator, policy controller, super-user, or the like.
  • a user and/or application may have the capability to build a policy request, and save the request as a use case for future implementation as a template, baseline group of data collection parameters, or the like.
  • verification operations of the policy manager 330 may utilize the use case (e.g., utilizing a pre-determined value that for a given vehicle, user, application, or the like, that a use case is authorized or unauthorized), and/or verification operations of the policy manager 330 may evaluate the individual elements populated in response to the use case for verification.
  • the data values populated by the use case may be displayed to the user and/or application, or may be hidden from the user and/or application.
  • the example second partition 304 further includes one or more internal applications 334 - for example applications created or implemented by an operating entity associated with the second partition 304.
  • the example second partition 304 further includes an application/user network manager 324, for example that performs load balancing operations, and provides communications to and/or receives communications from external applications using a communication interface 338.
  • the application/user network manager 324 performs operations to implement a user interface or graphical user interface with external users and/or applications.
  • the example off-vehicle device 104 implements consent communications 344, policy communications 346, and/or data communication 336 to manage communication between the partitions 302, 304.
  • the communications 344, 346, 336 may include standardized interface and/or protocols, for example such that a given partition 302, 304 can be operated independently from updates or changes to the other partition.
  • the example of Fig. 3 depicts two partitions 302, 304, although in certain embodiments the off-vehicle device 104 may be an integrated device, and/or aspects of the partitions 302, 304 may have additional partitions, and/or a different distribution of components between partitions.
  • example internal applications 334 and/or external applications 402 are depicted.
  • the present 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 a number of user devices 106, which may be communicatively coupled to the system through a network interface 406, which may include one or more aspects such as an internet connection, a mobile communication interface, a proprietary network interface, or the like.
  • 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.
  • an application 402 may be operated without an interfacing user device 106 (e.g., a data scraper, AI component, or the like), and/or may be operated selectively interfacing with a user device 106 at certain times or operating conditions, and operating independently of a user device 106 at other times or operating conditions.
  • an interfacing user device 106 e.g., a data scraper, AI component, or the like
  • an example vehicle network infrastructure for a vehicle 102 is schematically depicted.
  • the example vehicle 102 includes an ethemet switch in communication with a number of ethemet based devices (e.g., sensors, actuators, and/or controllers in communication with an ethemet network), an edge gateway device (e.g., interacting with a second network such as a CAN or second ethemet network, and providing parameters to the first network or ethemet network), a data collection controller, a number of ethemet devices, and a user consent controller.
  • ethemet switch in communication with a number of ethemet based devices (e.g., sensors, actuators, and/or controllers in communication with an ethemet network), an edge gateway device (e.g., interacting with a second network such as a CAN or second ethemet network, and providing parameters to the first network or ethemet network), a data collection controller, a number of ethemet devices, and a user consent controller
  • the example Edge Gateway 206 includes a CAN data collection policy manager, which receives data collection commands from the data collection controller.
  • the CAN data collection policy manager instructs CAN data collection from CAN devices 208 to support the data collection commands, and provides ethemet communication parameters to the ethemet switch to support the data collection.
  • the utilization of the Edge Gateway 206 supports mixed network operation, and in certain embodiments allows the off-vehicle device 104 to operate without requiring knowledge of which devices are present on the CAN, ethemet, or other network.
  • the example Edge Gateway 206 further includes CAN processing components, such as a CAN IP component that interprets CAN addresses of respective CAN components 208, a CAN message receiver that interprets CAN messages to determine the data values therein, and CAN message filter that supports, for example, down sampling of CAN messages to reduce network traffic within the vehicle network while supporting the policy. For example, if a parameter is provided on the CAN at a 20 ms rate, but the policy requires only a 1 sec sampling rate for the parameter, then the CAN message filter can expunge excess sampling of the message.
  • other components may perform down sampling in addition to, or instead of, a CAN message filter.
  • the ethemet switch and/or the data collection controller may perform appropriate down sampling.
  • the location of the down sampling may depend on the specifics of the policy (e.g., if a parameter may occasionally be sampled faster due to an event, then the CAN message filter may provide data at the highest rate that could be required, allowing another component to down sample when the higher rate is not required, and/or the CAN message filter may be responsive to the event, down sampling appropriately based one the circumstances).
  • the example CAN Gateway 206 additionally includes a CAN message capture, for example passing the CAN sampled data and/or buffering the CAN sampled data until it is passed.
  • the example CAN Gateway further includes a CAN2Eth Encap component, that encapsulates the captured CAN message into an ethemet message (e.g., including leading and/or trailing message data, and/or packaging one or more of the CAN messages into a single ethemet packet).
  • the example CAN Gateway further includes an Eth IP component, which communicates the encapsulated CAN messages to the appropriate address on the ethemet network.
  • messages are passed in both directions, for example allowing the CAN data collection policy manager to receive appropriate portions of the current policy, allowing the Edge Gateway to receive event data indicators (e.g., than a given event has occurred), and the like.
  • a mixed network may include different network types than a CAN-ethemet mix, and/or may include networks with distinct protocols (e.g., packet sizes, leading/trailing bits, etc.), where the Edge Gateway includes appropriate components therefore.
  • the example ethemet switch 204 includes an ethemet packet filter component, for example to perform down sampling and/or to reject un-needed packets (e.g., data responsive to an event provided by an ethemet device and/or the Edge Gateway during an operating period where the event is not active) and an ethemet packet interceptor.
  • the example ethemet packet interceptor retrieves selected data from the ethemet network.
  • the ethemet switch 204 performs operations such as port switching or other routing operations.
  • the example ethemet switch 204 is in communication with the data collection controller 202, the Edge Gateway 206, and one or more ethemet devices 210.
  • the ethemet device 210 manages policy implementation relevant to the specific device, for example utilizing an ECU policy manager (electronic control unit) that determines data transmission values responsive to the policy, including data rates, resolution, and/or data response to events.
  • the ECU manager performs event detection (e.g., reading ethemet parameters and determining whether the event is active).
  • the ECU manager receives an event status, and manages only the data transmission requirements responsive to the event status.
  • the ethemet device 210 further includes a data collector, which may down sample, adjust resolutions of data values, and/or provide multiple data values (e.g., within a packet, and/or time stamped for later matching in the data collection controller 202 and/or off-vehicle device 104).
  • the example ethemet device 210 further includes a data transmitter that provides packets to an Eth IP, where the Eth IP manages addressing, sending, and/or receiving of associated packets.
  • the example ethemet device 210 may be associated with a specific component, for example controlling ethemet communications responsive to the policy for the associated component.
  • the ethemet device 210 may be a part of the component (e.g., managing ethemet communications for the component that may be in addition to the data collection aspects supporting the policy) and/or may be a part of a controller associated with the component.
  • the example ethemet device 210 is in communication with the ethemet network, and/or the ethemet switch 204.
  • the user consent controller 212 may be a part of, and/or may be associated with, an on-vehicle user input device such as a console (e.g., a touch screen interface) accessible to the vehicle operator.
  • the user consent controller 212 may be omitted, and/or may be in another part 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.
  • an alternate interface may be provided for consent communications.
  • an operator utilizes a mobile device having an application installed thereon for performing consent operations, for example having a login or authentication operation that confirms the association with the vehicle.
  • an owner or agent having authority accesses an application or web portal - for example a fleet manager having a web based access on a computing device and/or a mobile application associated with the vehicle.
  • user consent can be provided for multiple vehicles within a single interface (e.g., a web application listing a group of vehicles) and/or with a single action (e.g., approving a policy update for a selected group of vehicles).
  • a user consent application e.g., reference Fig. 4 may be used in conjunction with, or as an alternative to, the user consent controller 212.
  • an example data collector controller 202 having a number of components thereon, and configured to functionally execute operations of the data collector controller 202 is schematically depicted.
  • 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 example vehicle OTA client communicates the policy, policy update, and/or policy notification to the policy manager.
  • the policy may be provided from the off-vehicle device 104 through an MQTT broker (reference Fig.
  • the policy manager may download a policy update and store it for later implementation.
  • the policy manager may command a download of the policy only when the vehicle 102 is in a condition to implement the policy (e.g., during a shutdown operation, during steady state operation, or the like).
  • the example policy manager verifies the policy, for example performing checks based on vehicle specific information that may not be available to the policy manager 330 on the off-vehicle device 104, to ensure the policy can be implemented. For example, if the policy requires data collection from device that is not present, requires network traffic (on either network of the vehicle, through the ethemet switch, or at some other component of the vehicle network) that is not possible or otherwise not compliant with the requirements of the vehicle, and/or requires a type of information that the vehicle 102 cannot provide (e.g., a sampling rate and/or resolution that is not available), the policy manager may reject the policy and/or provide a notification to the off-vehicle device 104 that the policy was rejected.
  • vehicle specific information may not be available to the policy manager 330 on the off-vehicle device 104
  • the policy manager may be configured to partially implement the policy, for example implementing higher priority data collection elements from one part of the policy and rejecting other lower priority data collection elements, and/or replacing part of a currently implemented policy having a lower priority than a high priority portion of the updated policy.
  • the policy controller may be configured to either accept or reject a new or updated policy in the whole.
  • the policy manager may be configured to communicate information about 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 being serviced, and/or a level of service available or being provided instead).
  • information about the partial implementation of the policy e.g., a flag indicating only partial compliance, and/or further information such as which parameters are not being serviced, and/or a level of service available or being provided instead.
  • the policy manager parses the policy elements and communicates relevant elements to policy managers throughout the system (e.g., to the Edge Gateway, ethemet switch, ethemet devices, and/or other components with the data collection controller 202 as described following).
  • the example data collection controller 202 includes data receiver component(s) that receive data responsive to the policy (and/or planned for response if an event condition is detected) from the ethemet network (e.g., utilizing an Eth IP component) and/or other components on the vehicle 102 (e.g., from the user consent controller).
  • the data receivers provide the data to a pre-processing component, which may determine virtual sensor or modeled values, adjust data sample rates (e.g., performing filtering operations), adjust resolution values, and the like.
  • the pre processing component may perform certain operations that support event detection, such as determining secondary state values that inform the event status determination, reject or tag data based on fault codes present, or the like.
  • the example data collection controller 202 includes a caching component that performs short-term data storage, for example to allow for parameter processing, and/or to support information capture such as rolling buffers where an event may trigger short-term past data recovery (e.g., a trigger indicating an accident, a component failure, or the like where past data is desirable when the event is detected).
  • the example caching component may be responsive to commands from cache controller, which may receive parsed caching instructions to support the policy, and/or may adjust caching operations in response to the current operating conditions of the vehicle 202.
  • the size of the cache and/or other available storage may affect the ability of the data collection controller 202 to meet the requirements of a policy.
  • the policy manager may determine that the current configuration of the vehicle 202 cannot meet the policy.
  • the policy manager having superior information about the specific vehicle relative to the policy manager 330 on the off-vehicle device 104, may make a determination that the policy cannot be verified where the policy manager 330 approved the policy.
  • the trigger condition evaluator receives parsed information from the policy manager indicating event detection criteria, and the trigger condition evaluator determines which event conditions are present in response to the event detection criteria and the cached and/or captured data.
  • event detection may be performed in other components as described throughout the present disclosure, such as at the Edge Gateway policy manager and/or at the Ethernet device policy manager.
  • the policy manager of the data collection controller 202 determines which device has sufficient information available to fulfill operations of the event detection, and provides parsed elements of the policy to the appropriate component. Accordingly, in certain embodiments, the trigger condition evaluator may reference a state value indicating whether a given event condition has occurred, rather than perform a direct detection of the parameters utilized to determine whether an event has occurred.
  • one device may perform primary event detection, and another component (e.g., the trigger condition evaluator) may perform a secondary detection of the same event, for example providing a system that is responsive to detect an event when a primary sensor indicating the event has failed, but a backup sensor to detect the occurrence of the event.
  • another component e.g., the trigger condition evaluator
  • the example data collection controller 202 includes a capture component that provides the parameters for storage.
  • the capture component is responsive to commands from a trigger condition evaluator, for example indicating that a trigger condition (event) is active, and may pull further information from the caching component (e.g., buffered values available in the cache) to support the implementation of the policy.
  • the example data collection controller 202 includes a storage component that stores the captured data for transmission to the off-vehicle device 104.
  • An example storage component utilizes non-volatile memory, such as FLASH memory, allowing for stored data that has not been transmitted to be saved in the event of power loss.
  • the example data collection controller 202 includes a storage controller that provides storage commands for the storage component to support implementation of the policy, and/or to support specific 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., where higher priority resources are utilizing available bandwidth, and/or where data communication limits exist, such as a data plan limitation).
  • storage of data collection parameters is performed until the store component is full, wherein some of the data is purged (e.g., oldest data, lowest priority data, and/or least utilized data).
  • the storage controller may be configured to keep the data that meets the higher percentage of the available policy requests.
  • data element correspondence to various policy requests is not available at the data storage controller 202, and other criteria are utilized to determine which data will be purged or expired.
  • a portion of the data to be purged may additionally or alternatively be compressed and/or summarized to reduce utilization of the storage.
  • a portion of the data to be purged may be down sampled to reduce utilization of the storage.
  • the amenability of certain data elements to compression, summarization, and/or down sampling may be considered in determining the commands from the storage controller in response to a full (or filling) storage component.
  • commands to compress, summarize, and/or down sample data in response to a full or filling storage component may be provided as a part of the policy, and/or the policy may further includes instructions for techniques to be utilized for the compression, summarization, and/or down sampling of data when indicated.
  • the policy may further include thresholds (e.g., storage value thresholds, time remaining until storage is full, etc.) indicating when storage purging, compression, summarization, and/or down sampling operations are to be performed.
  • thresholds e.g., storage value thresholds, time remaining until storage is full, etc.
  • the storage controller is configured to support cache operations by utilizing a portion of the storage available on the storage component.
  • the storage controller may be configured to determine an amount of storage than can be utilized based on historical information such as usage fractions of the storage component over time, and/or network availability to transfer collected data to the off-vehicle device 104.
  • storage support for the caching component may be defined within the policy. In certain embodiments, storage support for the caching component may not be utilized. In certain embodiments, the availability of storage support for the caching component may be considered by the policy manager in operations to verify the policy.
  • the data collection controller 202 includes an encryption component configured to encrypt data to be transmitted to the off-vehicle device 104.
  • the data collection controller 202 includes a compression component configured to compress data to be transmitted to the off-vehicle device 104.
  • the compression may be lossy or lossless compression, and the compression type may be determined according to the type of data, the descriptive value of the data after compression, and/or may be determined by the policy.
  • the data collection controller 202 further includes a transmit component configured to transmit collected data to the off-vehicle device 104, and a transmission controller component to configure the transmission, for example to support selected data protocols, to mediate between competing transmission resource of the vehicle 102 (e.g., comparing relative data priority to other transmission elements, scheduling transmission according to a data plan, vehicle operating condition, and/or to support a virtual channel utilized on a transceiver).
  • a transmit component configured to transmit collected data to the off-vehicle device 104
  • a transmission controller component to configure the transmission, for example to support selected data protocols, to mediate between competing transmission resource of the vehicle 102 (e.g., comparing relative data priority to other transmission elements, scheduling transmission according to a data plan, vehicle operating condition, and/or to support a virtual channel utilized on a transceiver).
  • the transmission controller is responsive to parsed elements of the policy indicating data plan values (which may differ between specific data elements - for example where a first data element is associated with a first requestor having a first data plan, and where a second data element is associated with a second requestor having a second data plan), transmission priorities, and/or vehicle operating conditions related to any of the foregoing.
  • an example first partition 302 is depicted having a number of components configured to functionally execute 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.
  • a load balancing/proxy controller 312 e.g., a network manager
  • the example load balancing/proxy controller 312 interacts utilizing policy communications 1106, consent communications 1108, and data communications 1104 between the vehicle 102 and the off-vehicle device 104.
  • the communications 1104, 1106, 1108 include primary data communications, authentications, confirmations, and the like.
  • the example first partition 302 further includes an http component 1102 configured to package the received data into a selected data structure (e.g., http for the example of Fig.
  • the example first partition 302 further includes a data communications component 308 configured to package the data for storage, and may further include a crypto engine that decrypts the received data (e.g., utilizing a temporary vehicle key), a tokenization/anonymization component that recoverably replaces sensitive data with a token, and an encryption component that encrypts the data with a master public key (e.g., where the data request/processing component 322 has the master private key), such that the first partition 302 cannot access the data values.
  • the data communications component 308 associates metadata with the stored data such that a request from the data request/processing component 322 can be answered with the corresponding data.
  • the example first partition 302 stores the data into a raw data storage 320 for access, as authorized, by internal applications 334 and external applications 402.
  • the example first partition 302 further includes an MQTT broker that publishes an updated policy, such that subscribing devices (e.g., a data collection controller 202) receive a notification that an updated policy is available.
  • the first partition 302 may push updated policies to a vehicle 202, and/or the vehicle 202 may periodically request whether a policy update is available, and/or request policy updates in response to certain events (e.g., certain operating conditions, service events, network availability events, etc.).
  • an example second partition 304 includes a policy creator component 1202, for example to perform operations to compile, implement, create, and/or store policies for utilization in the system.
  • the policy creator component 1202 is further configured to roll out policy updates, for example updating a policy to a small number of vehicles before sending the policy update to a larger number of vehicles.
  • the example second partition 304 further includes the data request/processing component 322 having a data processing engine that decrypts received data from the first partition 302 utilizing a master private key, a de-tokenization component that restores tokenized information within the received data, and an encryption component that re-encrypts the data with a temporary key for sharing of the data with an application and/or user device requesting the data (if authorized).
  • the example of Fig. 12 includes an internal application 334 such as a vehicle twin application being operate for a corresponding vehicle 202, and a number of external applications 402, such as a vehicle twin dashboard, a 3 rd party application (of any type), a mobile application, a web based application, a user consent application, and/or a policy creator user interface.
  • the example second partition 304 further includes an application registration portal, and an application approval workflow component (together - 1204) that interfaces with applications and proposed applications to ensure proper authorization, enforce application standards, and the like.
  • the application registration portal, and the application approval workflow component 1204 further interact with the application authorization database 328 to record application registrations, and ensure authorization of accessing applications.
  • authorization communications 1206 are depicted, although authorization communications may pass between other components of the second partition 304 beyond those depicted.
  • one or more data stores described herein are utilized 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 identifications, time stamps, identifiers for the data, and/or any other information allowing the system to access content of the raw data store at a selected time and utilize the content of the raw data store for one or more purposes described herein.
  • Raw data may reference vehicle data communicated off-vehicle, stored locally on the vehicle (e.g., for a selected period of time), as the data is presented such as from a data collection controller 202 (reference Fig. 2).
  • data may be processed at least partially, for example compressed data, down-sampled data, summary data, aggregated data, or the like, and may still constitute raw data as set forth herein.
  • data may be significantly processed - for example data determined from a model, virtual sensor, or the like, and may still constitute raw data as set forth herein.
  • an output of a virtual sensor or model describing a basic vehicle parameter such as vehicle speed, ambient air temperature, or the like, may be stored as raw data for utilization by applications 402, 334 (e.g., reference Fig. 4).
  • the description utilizing raw data may include data that is utilized in a manner as provided by the vehicle, and/or data utilized in a manner that is presented to applications 402, 334 as basic vehicle parameters that are available for utilization.
  • a given data value (e.g., vehicle location) may be treated as raw data for a particular system and/or for a particular purpose, and not treated as raw data for another system and/or purpose.
  • Embodiments of the present disclosure provide for systems, apparatuses, and methods for providing container management, including operating and managing container run-time operations for embedded environments such as a mobile application.
  • Example operations include providing container management for mobile applications having more than one network on-vehicle, and/or mixed networks on the vehicle.
  • Embodiments herein provide for virtual network construction and configuration, intra-container communication, and inter container communication.
  • Embodiments herein provide for container registry, deployment, and orchestration.
  • Embodiments herein provide for container monitoring, recovery, and/or updating.
  • Embodiments herein provide for dynamic configuration of a configurable edge gateway (e.g., interfacing to CAN network, LVDS network, electrical signal zone, etc.), dynamic data collection from edge networks, dynamic signal to service mapping for edge networks, and/or programming/configuration of cross-network communications with reduced latency using a communications engine or other implementing circuit or controller.
  • a configurable edge gateway e.g., interfacing to CAN network, LVDS network, electrical signal zone, etc.
  • dynamic data collection from edge networks e.g., dynamic signal to service mapping for edge networks
  • dynamic signal to service mapping for edge networks e.g., dynamic signal to service mapping for edge networks
  • programming/configuration of cross-network communications e.g., programming/configuration of cross-network communications with reduced latency using a communications engine or other implementing circuit or controller.
  • Embodiments of the present disclosure provide for systems, apparatuses, and methods for operating and/or managing vehicle automation features and/or functions.
  • Embodiments herein allow for the addition, deployment, configuration, and/or updating of vehicle automation features and/or functions without coding (e.g., algorithm development, compiling, and/or updating of computer readable instructions, operating system changes, and/or firmware updates).
  • Embodiments herein allow for the addition, deployment, configuration, and/or updating of vehicle automation features utilizing an index of automation recipes, interactions with an operator, and/or interactions with an application that further interfaces with an operator, owner, service personnel, manufacturer, fleet personnel, and/or OEM.
  • Embodiments herein support management, initiation, and/or updating of flexible triggers for vehicle automation features and/or functions, and/or execution of vehicle automation features and/or functions.
  • Embodiments of the present disclosure provide for systems, apparatuses, and methods for managing and/or operating vehicle remote control enhancements.
  • Embodiments herein allow for reduced latency and/or no latency vehicle-external network communications, for example utilizing low power persistent vehicle-cloud communications.
  • Embodiments herein allow for extensive control functions for customer support, customer service, business analysis, manufacturer/OEM application differentiation, consumer applications, customized features, and/or aftermarket features.
  • Embodiments herein allow for implementation of remote control enhancements utilizing programmable complex control procedures, with high capability for secure access to vehicle networks, devices, end points, and/or flows, and for access to ancillary aspects to allow for implementation of high capability features (e.g., determining supporting vehicle states, conditions, etc., and/or capabilities to ensure mission functions are not inhibited).
  • high capability features e.g., determining supporting vehicle states, conditions, etc., and/or capabilities to ensure mission functions are not inhibited.
  • Embodiments of the present disclosure provide for systems, apparatuses, and methods for consistent implementation of intrusion detection systems (IDS) across networks of a mobile application, and may further include implementation of a unified across all networks and/or a selected sub-set of network of the mobile application.
  • Embodiments of the present disclosure further include implementation of IDS for mobile applications having external connections and data communication, and/or functionality operated at least in part on an external device (e.g., fleet computing device, cloud server, etc.).
  • Embodiments of the present disclosure include implementation of 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/or generating data to be utilized in incident reports, data logs, activity/response descriptions, and/or alerts.
  • Embodiments of the present disclosure include providing 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 selected entities (e.g., operator, owner, fleet personnel, manufacturer, OEM, service personnel, monitoring applications or services, etc.).
  • Embodiments herein include operations to implement rule based incident response to IDS operations.
  • Embodiments herein include dynamic configuration and/or updating of IDS operations.
  • Embodiments of the present disclosure provide for systems, apparatuses, and methods for management and/or operation of shared network storage for a mobile application having a number of data storage devices associated therewith, and/or may further include where the number of data storage devices are distributed across at least two networks and/or across networks of a mixed network for the mobile application.
  • Embodiments include a unified storage shared by multiple applications, flows, processors, circuits, end points, devices, services, and the like.
  • Embodiments herein provide for network file system access to end points, devices, applications, and/or flows on the networks of the mobile application.
  • Embodiments herein provide for an overlaid database service for shared stored data, and/or portions thereof.
  • Embodiments herein provide for selected encryption schemes for shared stored data, including at least encryption of data at rest.
  • Embodiments herein provide for authentication, access control, and auditing of shared network storage operations, including at least scheduled operations according to a policy, permissions of participating devices, etc.
  • Embodiments herein provide for data life cycle management of shared stored data, including at least: implementation of policies; data retention schemes; and/or prioritization between devices, end points, applications, flows, related services, datatypes, and/or determined operating conditions of the mobile application.
  • Implementations of the present disclosure are provided as a service oriented architecture (SOA), faster development, code reuse, reduced complexity, and easier deployment.
  • OEMs benefit from reduced development costs, improved time-to-market, reduced warranty expenses, and recall expenses.
  • Customer benefits include vehicles with more capabilities, feature upgrades after purchase, and less inconveniences due to work associated with warranties and/or recalls.
  • a SOA includes operations for devices, end points, applications, and/or flows to publish (e.g., a service provider) the availability of a service (e.g., data values, actuator operations, and/or functions available), and to subscribe (e.g., a service requestor) or otherwise request an available service.
  • Services may be selectively published (e.g., only to subscribers having sufficient permissions, and/or only by providers having sufficient permissions). Services may have distinct permissions on both the publication and request side, for example with owners, manufacturers, OEMs, body builders, fleet operators, third-party applications, etc. having distinct permissions to publish and/or request services. Service providers and/or requestors may be on-vehicle or off- vehicle.
  • Previously known vehicle functions today are implemented as mission-specific, monolithic code that is tightly coupled with underlying middleware, operating system, and hardware of a particular controller (e.g., ECU).
  • a SOA architecture allows new applications to re-use either data or function provided by existing applications across the network, regardless which ECU they reside in, which network they are associated with, the underlying hardware, OS, middleware, and the programming language used.
  • the utilization of a SOA decouples the control logic from sensor data and actuator, thus making applications and control functions portable to different ECUs.
  • the utilization of a SOA increases the scalability of the overall system functions because both service providers and consumers could be added/subtracted or enabled/disabled based on performance, cost tradeoff, and changes to the system (e.g., operating conditions, change in permissions, change in subscriptions, etc.). Additionally, the utilization of a SOA allows for the timing of a feature to be de-coupled from the manufacturing event or dealer preparation event, as features can be readily added or removed when the feature is available.
  • An example SOA supports utilization of AUTOSAR ARA::COM compliant API interface, and further includes extensions thereto.
  • Example characteristics of the ARA::COM module, without extensions, include the utilization of a distributed architecture (e.g., each service provider and requester manages offers, finding, connecting, and interaction with counterparts), and accordingly there is no readily available way to monitor or control service management activities such as discover, publication, subscription, starting/stopping of services, and/or reporting of activity for debugging, diagnostics, or analysis.
  • the lack of central management results in extraneous network traffic, unavailability of inter-network services, requirements that each device adapt individually to changes in services, and lack of permissions scheming or security for publication and/or subscription of services.
  • ARA::COM numerous aspects of the service interface must be defined statically (e.g., service ID, IP address, port number, etc.) before or during compiling operations. Accordingly, changing any of the static values requires modifying and recompiling the code, which is cumbersome and error prone. Additionally, the static local registry of a given ECU in different applications across the mobile application may become out of sync due to various error conditions, and recovery from such a situation may take a long time, fail completely, and may thereby result in extensive down time, failure of the mission, and/or expensive service operations to reconfigure the ECU(s) of the vehicle.
  • statically e.g., service ID, IP address, port number, etc.
  • An example embodiment includes a centralized controller for implementing a service-oriented software infrastructure for a mobile application (e.g., a SOA).
  • Example capabilities include central management of all services (and/or all managed services) in the vehicle using policies that are maintained and deployed from the cloud.
  • all or a portion of the policies may be maintained and/or deployed from an external device coupled to the vehicle, such as a service tool, OBD device, etc.
  • all or a portion of the policies may be maintained and deployed from a user device, which may be coupled through the cloud, a web application, a hardware connection (e.g., a USB cable, OBD port coupling, etc.), and/or another connection such as a WiFi or Bluetooth connection.
  • a hardware connection e.g., a USB cable, OBD port coupling, etc.
  • the capabilities and/or permissions to update and/or deploy policies may vary by the updating entity (e.g., manufacturer, service, owner, warranty implementer, etc.) and/or by the access type (e.g., cloud, web application, hardware connection, etc.).
  • An example policy defines parameters such as service parameters, service access permission, and/or service connection modes.
  • An example centralized controller implements dynamic updates to the policy, which can add, update, delete, enable, and/or disable service providers, requestors, service parameters, specific subscriptions, and/or publication parameters for a service.
  • the centralized controller is at least partially capable to support a policy utilizing a static configuration (e.g., where cloud connectivity is unavailable, or not presently available).
  • the centralized controller stores the policy in a data structure configured to provide the policy information, and capable to be stored in a separate memory location (e.g., a flash memory) from OS, boot-up, or other operating sectors of the centralized controller allowing for updates to the parameters without interruption of base operation.
  • the separation of policy information may be physical (e.g., a distinct memory store device) and/or logical (e.g., memory addresses separated from the base operation addresses).
  • storage of the policy information may be executed, in whole or part, as a shared network storage operation.
  • An example centralized controller provides for visibility of services to a cloud or external tool.
  • the centralized controller may determine and/or store a service map of all services offered and/or consumed on the vehicle.
  • the specific service map shared with the requesting device may be configured according to the permissions of the requestor (e.g., distinct views for a manufacturer, service entity, fleet owner, security personnel, compliance personnel, etc.).
  • An example centralized controller determines a log of key service activities in the vehicle (e.g., addition or removal of a service, a change in subscriptions, a change in a data provider to a service, etc.).
  • the activities that are key service activities may vary according to the requestor and/or purpose for using the activity log, and accordingly the content of the log may be determined and/or adjusted according to the requesting device and/or entity.
  • the sharing of the log, and/or the content of the shared log may be configured according to the permissions of the requestor.
  • the activity log may be utilized for debugging, diagnostics, auditing, compliance determination, or other purposes.
  • Example modes for service connection include: full service discovery, with publication/subscription data, and a fully dynamic connection; no service discovery, but provided publication/subscription data, and a partially dynamic connection; and/or no service discovery, no publication/subscription data, and a static connection.
  • the mode applied to a service connection may be configured according to the permissions of the service connection, and/or may be utilized as responses to off-nominal operation (e.g., a service connection may be authorized for full service discovery, but a failure of service discovery occurs, the centralized controller may provide the partially dynamic connection as a fail-back operation, and may further provide the static connection as a fail-back operation if the publication/subscription data retrieval fails).
  • An example centralized controller operates an SOA manager as a pre-defmed service provider that all end points can rely upon (e.g., consistent network address, etc.). Dynamic operations are managed through storage of configuration information including the policy information. In response to off-nominal conditions, such as where the SOA manager determines an error is present (e.g., an end point appears to be moved, missing, or intermittently available), the SOA manager queries configuration information and service connection states to recover.
  • An example centralized controller performs security operations for service connections, such as requiring identification certificates from service end points before allowing the service connection to be exercised.
  • An example centralized controller operates a security engine having stored information defining the generation, storage, and verification of certificates.
  • the example SOA manager grants or blocks a service connection, and/or specific operations on a service connection, based on the policy, configuration information, and permissions associated with the service end point.
  • the policy information can be updated dynamically.
  • An example centralized controller includes the SOA manager operating extensions on top of a selected API, such as an ARA::COM module, and further operates as a service provider.
  • the SOA manager configures, controls, and monitors service-oriented communications in vehicle, based on the policy information and configuration information.
  • An example centralized controller further includes an SOA plugin SDK, including a library to be used by any application participating in SOA communication, where the library functions communicate with the SOA manager to determine control information, enforce control, and report status and activities to the SOA manager.
  • the example SOA plugin SDK further includes a tool to modify generated client proxy and server skeleton code to support dynamic configuration of service parameters.
  • FIG. 13 an example system schematically depicts the centralized controller (ECU), an SOA manager, SOA plugins, and communication between vehicle controllers (e.g., ECU, ADAS) and external devices (e.g., cloud).
  • vehicle controllers e.g., ECU, ADAS
  • external devices e.g., cloud
  • End points depicted are shown as a client or server application for purposes of the description. It will be understood that a given application may be a client, a server, or both depending upon the service, vehicle operating conditions, and the like.
  • the “IVN” is the in-vehicle network layer, and may be a physical layer (e.g., a number of physical end point connections and network hardware), a logical layer (e.g., ports or virtual ports of an Ethernet network), or combinations of these. It will be understood that the IVN may encompass a mixed network, for example an Ethernet network and a CAN network, where one or more networks may interface with the SOA Manager utilizing a configurable edge gateway or other interfacing device.
  • a physical layer e.g., a number of physical end point connections and network hardware
  • a logical layer e.g., ports or virtual ports of an Ethernet network
  • the IVN may encompass a mixed network, for example an Ethernet network and a CAN network, where one or more networks may interface with the SOA Manager utilizing a configurable edge gateway or other interfacing device.
  • An example centralized controller includes an AUTOSAR adaptive communication management module (e.g., including IPC, SOMEIP, and/or other protocol binding), the SOA manager integrated with an ARA:: COM module, and an SOA Plugin library and code generation tool.
  • AUTOSAR adaptive communication management module e.g., including IPC, SOMEIP, and/or other protocol binding
  • the SOA manager integrated with an ARA:: COM module
  • SOA Plugin library and code generation tool e.g., including IPC, SOMEIP, and/or other protocol binding
  • An example centralized controller includes an SOA manager provided in a controller of the vehicle, where the SOA manager runs on top of a separate ARA: : COM module, and the SOA Plugin library and code generation tool.
  • Examples of the present disclosure provide for the ability to provide frequent feature upgrades, addition or removal of features, and a personalized configuration of features for a mobile application.
  • An example embodiment enables customized vehicle behavior by providing a simple, flexible, automation capability.
  • An example embodiment includes an interface and integration tools allowing developers and users to quickly and easily create custom workflows that manipulate vehicle features based on user input and vehicle state.
  • Example embodiments allow users to create custom trigger-action rules to automate the vehicle environment, and to allow in-vehicle capabilities that were not previously available.
  • An example system includes a centralized controller having an automation manager that determines a customized operation including a trigger-action (e.g., a voice command; an operator input value such as from an application, personal device, vehicle operator input, and/or vehicle display input; vehicle operating condition; detected event; and/or combinations of these).
  • a trigger-action e.g., a voice command; an operator input value such as from an application, personal device, vehicle operator input, and/or vehicle display input; vehicle operating condition; detected event; and/or combinations of these.
  • the example automation manager monitors vehicle conditions to determine if the trigger-action has occurred, and commands the customized operation in response to the trigger-action occurrence.
  • the automation manager may limit implementation of the customized operation in response to vehicle conditions (e.g., an “open door” command that opens the driver door may include a condition such as zero vehicle speed, which may be implemented by the user providing the customized operation or otherwise enforced elsewhere in the system).
  • vehicle conditions e.g., an “open door” command that opens the driver door may include a condition such as zero vehicle speed, which may be implemented by the user providing the customized operation or otherwise enforced elsewhere in the system.
  • interactions with certain actuators e.g., a direct vehicle start command
  • interactions with certain actuators may embody a request to an application or flow of the vehicle, rather than a direct command of the implementing actuator (e.g., where the vehicle has an automated starting function available on the vehicle, whereby the customized operation requests implementation of the automated starting function, rather than providing a direct command to the starter of the vehicle), which may have permissions that are distinct from permissions associated with the direct command of the underlying actuators.
  • customized operation data are stored in a memory storage on the system, such as with configuration information.
  • the automation manager limits configuration of the customized operation based on permissions and/or authorizations of the configuring entity (e.g., owner, operator, manufacturer, 3 rd party application provider, etc.), and/or according to permissions associated with data elements accessed and/or actuators commanded as a part of the customized operation.
  • the configuring entity e.g., owner, operator, manufacturer, 3 rd party application provider, etc.
  • Example operations are described following to illustrate a few operations of a type supportable by embodiments of the present disclosure.
  • the example operations are non- limiting, and an example automation manager is capable to respond to any input capable of being provided as a network communication and/or data parameter stored on a computer readable medium, and to provide any response capable of being commanded to any actuator in the system, including actuators under the control of another controller in the system (e.g., a vehicle display, system speakers, vehicle powertrain, etc.).
  • An example customized operation includes an operation to set the passenger’s seat heating in response to a driver tapping a driver’s seat heating switch twice and setting the passenger’s seat heating.
  • the example operation returns the driver’s seat heating switch to control of the driver’s side heating after a brief delay (e.g., a few seconds).
  • the example operation allows the driver to conveniently set the passenger seat heating from the driver’s side of the vehicle.
  • An example customized operation includes an operation to configure a number of vehicle aspects in response to a command, such as “Hey car, start my morning commute.”
  • configured vehicle aspects may include tuning the radio to a selected station and volume, setting a pre-selected navigation destination (e.g., an office), setting the performance mode of the vehicle (e.g., fuel economy mode), setting the driver’s seat position (e.g., forward/reverse, height, tilt, lumbar support, etc.), and/or setting HVAC parameters (e.g., selected cabin temperature).
  • a customized operation may include further interactions based on ambient or external conditions, such as utilizing a different radio station depending upon the day of the week, adjusting HVAC settings based on ambient temperature, adjusting navigation according to a number of people in the vehicle, and the like.
  • An example customized operation includes an operation to configure a number of vehicle aspects in response to a system condition, such as an approach of the vehicle to the driver’s home at night.
  • the customized operation implements a workflow that dims the headlights, lowers the radio volume, sends a message to a home automation system to turn on lights and open the garage door, and retracts the side mirrors as the car pulls into the garage.
  • the approach of the vehicle to the driver’s home at night may be determined by any operations, such as determining from GPS coordinates, direct interaction with a network of the home automation system, etc.
  • An example customized operation includes an operation to configure a number of vehicle aspects in response to an input, such as a hard coded button on a vehicle display.
  • An example includes setting an HVAC system of the vehicle to a desired temperature in response to the hard coded button, without having to navigate a climate control system, utilize multiple button presses, and/or turn related knobs where visibility may be lacking (e.g., the vehicle is dark) and/or the driver does not want to utilize attention to find and focus on the related knobs.
  • An example automation manager (or vehicle automation manager) allows users to create arbitrary trigger-action rules which can be executed on the vehicle, such as by the centralized controller. For instance, the user could create a trigger-action rule that would automatically turn on the high-beam headlights when there is no oncoming traffic while driving at night.
  • An example schematic flow description of the customized operation includes:
  • the user accesses an app on her phone or web browser and uses it to create custom trigger-action rules, or enable predefined ones created by the OEM;
  • the trigger-action rules are sent to the cloud, and the enabled trigger-action rules are consolidated as a “recipe” on the cloud side;
  • the cloud pushes the recipe to the vehicle through the vehicle update controller (VUC) (e.g., storing configuration information related to customized operations);
  • VUC vehicle update controller
  • the trigger evaluation engine receives the latest recipe, it analyzes each rule in the recipe and executes each rule in a controlled and isolated manner;
  • Accounting data (such as the number of times a trigger-action rule has been executed, trigger event detections, trigger event data, and/or events where the action is triggered but suppressed based on operating conditions, etc.) is sent back to the cloud, where it can be further reviewed, e.g., from the phone app and/or other monitoring application
  • the vehicle automation manager allows users to enrich their vehicle experience without waiting for a feature request, approval, and update process.
  • the example vehicle automation manager further allows the user to leverage their own creativity and/or the creativity of 3 rd party application providers to implement improved vehicle interactions.
  • a Vehicle Automation Manager takes recipes from the cloud as inputs and executes the trigger-action rules in the recipes.
  • Each trigger-action rule is composed of triggers, conditions, and actions.
  • the triggers are the inputs to the rule that encompass signals from the CAN bus, time, location, diagnostic states, vehicle status, video/audio, driving log, etc.
  • Conditions take trigger input values and decide if certain conditions are met.
  • the conditions are described using a custom syntax, in order to express complex logical conditions, such as multi-level AND/OR logic, comparators, and advanced utility functions to calculate sum/mean/stddev etc. If the conditions are met, then the corresponding actions will be executed, and/or requested (but may be blocked due to operating conditions, etc.).
  • the actions could include calling services in the SOA or sending CAN signals to the CAN ECUs.
  • an example automation manager is schematically depicted, and positioned on a centralized controller.
  • the VUC receives recipes (and/or configuration information describing a customized operation) from the cloud using MQTT/HTTP/Web Socket, etc.
  • the VAM controls the vehicle automation based on the recipes, and includes a lexical engine to parse the recipes, and a rule engine to orchestrate the rule execution by leveraging a trigger evaluation engine and a task execution engine (and/or a trigger execution engine).
  • Operations of the automation manager such as in Fig. 14 may include vehicle automation operations, event trigger operations, remote control operations, and/or any configurable operations performed in response to an application, feature, trigger, or other automated application created by a manufacturer, OEM, fleet owner, vehicle owner, vehicle operator, and/or a third party.
  • An example trigger evaluation engine takes triggers as inputs and evaluates the trigger conditions based on the trigger values.
  • the trigger values can come from any network, such as a CAN bus, for example using a configurable edge gateway to adjust the routing table to retrieve the signal values dynamically.
  • the values could also come from other Ethernet ECUs through a SOA, from other modules on the centralized controller (e.g., Diagnostic Server), or raw video/RADAR/LiDAR streams over Ethernet.
  • the centralized controller may further share the data collection performed for customized operations with other aspects of the system, such as data collection operations for other purposes, and/or between multiple customized operations utilizing at least some of the same trigger data parameters, thereby reducing redundant requests for the same data parameters.
  • data collection may be a separate operation that may additionally be based on a trigger condition, and/or data collection may be performed as a customized operation.
  • the trigger manager e.g., as the automation/remote manager in the example of Fig. 14
  • a data listener that receives data related to the triggers, which may be taken from any location in the vehicle, such as: a CAN bus; Ethernet packets (including EthCC packets having state information such as vehicle location); a diagnostic manager providing DET errors, RDBI data, fault codes, etc.; a system manager (e.g., providing vehicle power state information); a time manager (e.g., providing a current time value); and/or any other information such as from the SOA.
  • a data listener that receives data related to the triggers, which may be taken from any location in the vehicle, such as: a CAN bus; Ethernet packets (including EthCC packets having state information such as vehicle location); a diagnostic manager providing DET errors, RDBI data, fault codes, etc.; a system manager (e.g., providing vehicle power state information); a time manager (e.g., providing a current time value); and/or any other information such as from the SOA.
  • the data cache stores the data for condition evaluation, for example including buffered data, intermediate parameters, etc.
  • the condition evaluation runtime is an engine to evaluate the conditions based on the trigger values in the cache, and to determine whether the trigger condition is met in response to the evaluation.
  • basic logical operators e.g., AND, OR, numerical comparisons, etc.
  • nested logical expressions with appropriate formatting e.g., ((X > 5 &
  • the task execution engine performs actions defined in the action catalog (e.g., the actuators to be adjusted according to the customized operation).
  • Example and non-limiting actions include turning on a light, turning on and/or adjusting the HVAC, turning on the ignition, etc.
  • Embodiments of the present disclosure are capable to access any actuator that is reachable through any network, including actuators provided on more than one network (e.g., an Ethernet for one actuator, and a CAN for the other actuator).
  • actions include a request for operation of an actuator (e.g., to another controller having direct control of the actuator), actions to request a published service be performed, and/or actions having complex interactions which may further be present on more than one other controller.
  • an action includes adjusting the ambient environment for the current user, which may include interacting with multiple controllers and/or flows, for example to determine a current user identity, her preferences, and adjusting the environment such as seat position, HVAC settings, radio channels, etc.
  • the automation manager advertises one or more customized operations as a service (e.g., which may be selectable by the requestor of the customized operation, defined in a policy, etc.).
  • components, circuits, controllers, and/or engines of the automation manager are shared in whole or part with other managers such as a remote control manager, and/or may be responsive to other managers using an API, library calls, or other interaction interface, for example to determine whether a specified group of data and trigger logic (e.g., passed from the other manager to the automation manager) indicates that a trigger event has occurred (e.g., determined by the condition evaluation runtime), and/or to implement an operation provided by another manager (e.g., passed as an operation request from the other manager to the automation manager) to be implemented (e.g., operated by the task execution engine to move the actuator and/or provide appropriate commands to other controllers).
  • a specified group of data and trigger logic e.g., passed from the other manager to the automation manager
  • a trigger event e.g., determined by the condition
  • Implementations of the present disclosure provide for rapid development and deployment of customizable operations, automation implementation without coding and/or compilation requirements, access to customization for customers, 3 rd party applications, aftermarket suppliers, etc. Implementations of the present disclosure provide for ease of implementation of customizable operations even where data providers and/or actuators are distributed across more than one network type, and do not require that providers for customizable operations have knowledge of the present configuration of on vehicle networks. [000384] Examples of the present disclosure provide for the ability to perform remote control operations for a mobile application. Remote control operations for certain features may be hard-coded in the ECU software - for example simple operations such as start/stop operations of the engine, lock/unlock operations of the doors, open/close operations of the windows and/or sunroof, etc.
  • Embodiments of the present disclosure are capable to configure remote control operations of a mobile application at any point in the life cycle of the vehicle, and further allow for configuration, updating, and fixing of remote operations included at the time of manufacture. Additionally or alternatively, where a more robust remote control implementation is present such as set forth in the present disclosure, features that would previously be hard-coded may be implemented as a dynamic feature as set forth herein.
  • An example system for performing remote control and configuration operations includes operating a control portion of the mobile application in a powered mode during a shutdown vehicle operating condition.
  • a controller to perform remote control operations includes granular power control of the centralized controller and/or other ECUs on the vehicle, keeping only those controllers powered that are required to perform remote control operations, and providing for operation of those controllers and related hardware components (e.g., board, chip, core, voltage, clock, etc.) in a low power state that is capable to receive remote control commands and configuration requests.
  • a remote control manager powers determines that a vehicle shutdown operation is active, and keeps aspects of the vehicle’s hardware powered that are responsive to a remote control command and/or configuration request.
  • the remote control manager powers down controllers and hardware that are not needed for remote control command and/or configuration requests in response to the vehicle shutdown operation.
  • the example remote control manager receives a remote control operation and/or configuration request, and wakes up any controllers or hardware required to perform the requested functions, and then returns the vehicle controllers or hardware to a low power state.
  • Example operations of the remote control manager to perform a vehicle shutdown operation include:
  • Example operations of the remote control manager in response to a received remote control request include:
  • Start applications e.g., controllers, circuits, etc.
  • request e.g., trigger evaluation engine, task execution engine
  • controllers sufficient to provide control operations to service the remote control request (e.g., an Ethernet switch, configurable edge gateway, etc.), including actuator controllers, other ECUs, etc.
  • the example remote control manager Upon completion of the remote control request, which may include feedback about the operation to service the remote control request (e.g., acknowledgement, success indicator, fault value, etc.), the example remote control manager returns the vehicle to the vehicle’s state when the request was received, or to another vehicle state as specified in the request.
  • An example remote control manager monitors the battery level. In response to the battery charge condition falling below a threshold value, the remote control manager can perform actions according to a policy and/or configuration information. For example, the remote control manager may wake up the ECU and the cellular modem, and send a message to an external device (e.g., a cloud, web application, user device such as a smart phone, etc.) to alert the user to the condition.
  • an external device e.g., a cloud, web application, user device such as a smart phone, etc.
  • the remote control manager may start a prime mover of the vehicle, and charge the battery to a second threshold value (e.g., higher than the first threshold value by a selected amount, and/or a fully charged condition). 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 value or another charge value (e.g., lower than the first threshold value). In certain embodiments, the user is prompted and/or can request that the vehicle be started to recharge the battery, for example in response to the message sent when the battery charge condition falls below the first threshold value. In certain embodiments, depending upon a policy and/or a user input, the remote control manager keeps the remote feature active below the first threshold value.
  • a second threshold value e.g., higher than the first threshold value by a selected amount, and/or a fully charged condition.
  • the remote control manager shuts down the vehicle and disables remote control support in response to the battery charge falling to the first threshold value or another charge value (e.g., lower than
  • An example system includes a centralized controller having a remote control manager that determines a remote control operation including a command value (e.g., activating a customized response, and/or from a user selecting a configured response from an application) that requests operation of the remote control function.
  • the example remote control manager activates required controllers to execute the remote control function, and performs the function in response to the command.
  • the remote control manager accesses a trigger evaluation engine and a task execution engine (e.g., as a part of a vehicle automation component of the vehicle, such as represented in Fig.
  • the remote control manager includes or accesses a trigger evaluation engine and/or task execution engine that is separate from other components of the system. The remote control manager thereby performs the remote control operation, and/or determines that all or a portion of the remote control operation cannot be performed, or is not going to be performed.
  • Customized remote control operations may be prepared as a part of a policy and/or in configuration information, similar to customized operations described preceding.
  • the remote control manager may limit implementation of the remote control operations in response to vehicle conditions.
  • interactions with certain actuators may be disallowed and/or require additional authorization or permission.
  • interactions with certain actuators e.g., the vehicle start command
  • interactions with certain actuators may embody a request to an application or flow of the vehicle, rather than a direct command of the implementing actuator (e.g., where the vehicle has an automated starting function available on the vehicle, whereby the customized operation requests implementation of the automated starting function, rather than providing a direct command to the starter of the vehicle), which may have permissions that are distinct from permissions associated with the direct command of the underlying actuators.
  • customized remote control operation data are stored in a memory storage on the system, such as with configuration information and/or as a part of a policy.
  • the automation manager limits configuration of the customized operation based on permissions and/or authorizations of the configuring entity (e.g., owner, operator, manufacturer, 3 rd party application provider, etc.), and/or according to permissions associated with data elements accessed and/or actuators commanded as a part of the customized operation.
  • the configuring entity e.g., owner, operator, manufacturer, 3 rd party application provider, etc.
  • Example operations are described following to illustrate a few remote control operations of a type supportable by embodiments of the present disclosure.
  • the example operations are non-limiting, and an example remote control manager is capable to respond to any input capable of being provided as a network communication and/or data parameter stored on a computer readable medium, and to provide any response capable of being commanded to any actuator in the system, including actuators under the control of another controller in the system (e.g., a vehicle display, system speakers, vehicle powertrain, etc.).
  • An example operation includes receiving a customer configuration of a scheduled acclimatization, where remote control operations include activating the HVAC system at a scheduled time (e.g., 7 AM) on selected days (e.g., weekdays), to a selected condition (e.g., a selected temperature, and/or utilization of defrost to ensure the windows are clear).
  • a scheduled time e.g. 7 AM
  • selected days e.g., weekdays
  • a selected condition e.g., a selected temperature, and/or utilization of defrost to ensure the windows are clear.
  • the customer may configure the operation using an application (e.g., a 3 rd party application), using a cloud or web-based interface, and/or using an application provided by a manufacturer, dealer, etc.
  • an operator selects a recipe for a remote control operation (e.g., which may include prompts to set certain parameters, and/or may be only an instruction or approval to turn a feature on or off).
  • a recipe for a remote control operation e.g., which may include prompts to set certain parameters, and/or may be only an instruction or approval to turn a feature on or off.
  • an operator builds a customized remote control operation, which may, for example, be based upon customized operation features present on the vehicle, available in a recipe, and/or may be built entirely by the user interacting with an interface to allow the entry of operations to be performed, any conditions to be applied, and settings for any thresholds, etc.
  • An example operation includes an EV reactive grid compensation mode, whereby an electric vehicle is electrically coupled to a grid, and whereby an electric provider utilizes a bidirectional charger of the vehicle (e.g., to level out power demand spikes).
  • the EV reactive grid compensation mode may include scheduling (e.g., time of day, charge target of the vehicle, days of the week, associated pairs of these, etc.) and/or may be toggled on or off (e.g., turning the feature on for an extended period when the operator goes on vacation).
  • An example operation includes the remote control manager responding to a progressive preconditioning command to heat the cabin of the vehicle in a selected order, such as using the HVAC to get cabin air to a desired temperature, then activating a heated steering wheel and/or heated seat function.
  • An example operation includes the remote control manager responding to a user setting request, and adjusting the vehicle configuration (e.g., steering column position, ambient light color, interior/dash light brightness, UI/UX style selection, etc.) in response to the user setting request.
  • An example operation includes a vehicle management setting (e.g., a valet mode, borrowed vehicle mode, configured mode for a child of the parent owner when driving the vehicle, etc.), for example to reduce a vehicle speed limit, a location limit (e.g., a geofence perimeter of 500 m from an activation location, limits with defined areas such as a city limit, and/or outside of defined areas such as a state line, another city limit, a total distance from an activation location, etc.).
  • a vehicle management setting e.g., a valet mode, borrowed vehicle mode, configured mode for a child of the parent owner when driving the vehicle, etc.
  • a location limit e.g., a geofence perimeter of 500 m from an activation location, limits with defined areas such as a city limit, and/or outside of defined areas such as a state line, another city limit, a total distance from an activation location, etc.
  • the applied limits for the vehicle management setting may be an actual applied limit (e.g., a maximum speed, performance value, etc.) or a notification limit (e.g., typically a geographic restriction may be implemented as a notification limit rather than a shutdown limit), where a notification is sent to the owner and/or to a selected device if a limit of the vehicle management setting is exceeded (and/or tested, such as with an actual applied limit).
  • an actual applied limit e.g., a maximum speed, performance value, etc.
  • a notification limit e.g., typically a geographic restriction may be implemented as a notification limit rather than a shutdown limit
  • An example operation includes a security mode, for example requesting data from a camera, microphone, vehicle display, dashboard, etc., in response to a request for the security mode.
  • the user can select one or more devices (e.g., specific cameras and/or locations within or relative to the vehicle), and can receive streaming video and/or a snapshot from the selected device(s).
  • the security mode allows for a data request from a device communicatively coupled to the vehicle, for example a security camera of a home security system in communication with the vehicle (e.g., see customized operations preceding).
  • An example operation includes a personalized operation, such as playing “Happy Birthday to You” and/or manipulating cabin lights upon the driver entering the vehicle on her birthday.
  • a personalized operation can be any type of operation such as: playing a selected song or play list on a given calendar date, day of the week, etc.; reminding an operator of a calendar event (e.g., linking to a calendar function of a smart phone, etc.), an anniversary, etc. upon entry to the vehicle; and/or reminding an operator of a scheduled stop (e.g., picking up groceries upon entering the vehicle to return home from work).
  • Example and non-limiting remote control operations allow for determination of complex conditions (e.g., utilizing CAN data, location, time, date, etc.), either in determining conditions for executing a remote control operation, and/or in performing the remote control operation.
  • Example and non-limiting remote control operations include a scheduled sequence of a number of operations, including determining conditions when a first scheduled operation is completed and a next operation should be performed.
  • Example and non-limiting remote control operations include performing one or more operations, such as: sending a note to the operator, showing the note on a vehicle display, and/or announcing the note on a speaker; taking a snapshot from one or more cameras and sending it to an operator and/or requestor; allowing a 3 rd party service (e.g., mobile re-fueling, vehicle service, and/or delivery company) to access vehicle location and door status, but only under specified conditions (e.g., selected times of the day, until the completion of an event, and/or in response to a proximity of the 3 rd party service to the vehicle); beginning start-up operations of the vehicle, a controller, the head unit, etc., as an operator approaches; reacting to environmental changes by defrosting the vehicle (e.g., in response to frost build-up, ambient temperature determination, etc.); and/or running a scheduled test for diagnostic purposes (e.g., running an active diagnostic test when the operator is away from the vehicle, reducing impact of the test on the
  • Example remote control operations include a prerequisite condition, a task, and/or a status report.
  • the prerequisite condition includes any combination of vehicle status, CAN signals, Ethernet packets, information stored on 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. to be utilized as a prerequisite trigger condition for the remote operation, and can further be configured as a complex logical expression and may further be based on a number of conditions.
  • the task includes an action that can be performed utilizing a CAN signal, Ethernet packet, or other network communication, including at least any action described under customized operation preceding.
  • the status report includes acknowledgement information, confirmation that an operation was performed and/or notification that an operation was not performed, related data, confirming data, utilization data related to the remote control operation, etc.
  • the content of the status report may vary with the recipient and/or requestor of the status report - for example the operator may receive a simple status report confirming the operation, a service personnel may receive a more detailed status report with associated parameters related to the operation, and a manufacturer may receive a detailed status report with personally identifiable information removed (e.g., to compile reliability data, while allowing for storage and aggregation of the data without having to manage personally identifiable information).
  • the presence and/or content of the prerequisite condition, task, and/or status report may be provided and/or updated by user input, policy, and/or configuration information.
  • An example remote control solution supports combinations of different elements of a remote control request, for example as reflected in the example code snippet for a request:
  • An example remote control solution supports the specification of a final vehicle state (to which the vehicle should return) after all the remote control functions are completed (e.g., an operating condition, interior cabin settings, a battery state of charge, etc.).
  • This vehicle state can be different than the vehicle state when the request was received. It is also configurable and programmable, similar to the task.
  • an example remote control manager is schematically depicted, being a part of a centralized controller in the example, although the remote control manager may be a distinct device, and/or positioned on another device.
  • the interface to the CAN controller may be performed through a configurable edge gateway.
  • the task execution engine and trigger evaluation engine is depicted as separate and dedicated to the remote control manager, solely for clarity of the present description.
  • the task execution engine and/or trigger evaluation engine may be positioned, in whole or part, with another device or controller such as an automation manager, shared between the remote control manager and the automation manager, and/or each of the remote control manager and automation manager (where present) may have separate trigger evaluation engine(s) and/or task execution engine(s).
  • An example system includes a unified intrusion detection system (IDS) manager structured to provide for unified vehicle side security of data, operational control, and network access.
  • the unified IDS manager may further include detection of cloud side or external vehicle access as set forth herein.
  • the attack surface increases. “Bad actors” are increasingly turning their attention to hacking into vehicle infrastructure because they perceive opportunities to steal personal information or intellectual property, extort money using ransomware, disrupt vehicle operation, or worse.
  • Network firewalls are a basic requirement for network security. Layer 5-7 “proxy” firewalls add a higher level of protection, but still are insufficient to protect against sophisticated attacks.
  • Intrusion Detection Systems can identify suspicious behavior that appears to be authentic activity by trusted entities.
  • using multiple IDS solutions from different vendors for different parts of the network makes it difficult to provide consistent and complete security across the system.
  • a single, Unified IDS solution is the most effective, because it has full visibility of all internal, inbound, and outbound traffic, so it can inspect data flows throughout the system and correlate seemingly unrelated events. In a vehicle, this includes monitoring various network traffic, such as CAN, Ethernet, and Wi-Fi traffic, as well as traffic through the cellular modem.
  • OEMs benefit from reinforced security features, faster reaction times to intrusions, and higher loyalty from their customers.
  • Customers benefit from more secure vehicles and personal data protection.
  • Example operations are described following to illustrate a few operations of a type supportable by embodiments of the present disclosure.
  • the example operations are non- limiting, and an example unified IDS manager is capable to detect intrusive operations accessing or attempting to access a network according to any aspect of the disclosure herein.
  • An example unified IDS manager monitors DNS, HTTP, and HTTPS accesses from any end point in the vehicle, allowing for detection of an ECU in the vehicle that has been infected with ransomware and/or spyware, where the ECU begins downloading malicious software packets and/or uploading private or proprietary data via a secure connection to an outside server.
  • maintaining traffic visibility to the unified IDS manager (such as through a centralized controller) allows for rapid detection of the issue, and blocking of the communication with the external rogue server.
  • An example unified IDS manager allows for an urgent software update to an ECU, for example to patch a vulnerability that is discovered by an investigator, 3 rd party, and/or observed during operation.
  • the unified IDS manager further allows for communications from the vulnerable ECU to be monitored, blocking or mitigating the vulnerability until it is corrected.
  • the vulnerability may be discovered on a mission-critical ECU, or on another ECU of the vehicle, where the vulnerability could be exploited to gain access to a mission-critical ECU.
  • the central management of the network communications allows for superior mitigation operations to the vulnerability, rapid implementation of updates to a single location (e.g., a centralized controller), and configuration files, policy information, certificate information, and the like may be stored outside of the base operating system, allowing for many updates to be performed without requiring substantial downtime to implement an update and/or validation or re-certification of ECUs that may otherwise require such if the primary software build is otherwise required to be updated.
  • a single location e.g., a centralized controller
  • configuration files, policy information, certificate information, and the like may be stored outside of the base operating system, allowing for many updates to be performed without requiring substantial downtime to implement an update and/or validation or re-certification of ECUs that may otherwise require such if the primary software build is otherwise required to be updated.
  • An example unified IDS manager detects incoming communications requesting vehicle propulsion system access (e.g., from a bad actor over a cellular network), which may be on a CAN bus.
  • An example unified IDS manager detects the attack, prevents the requested access to the CAN bus, and/or provides an alert to a customer and/or monitoring service.
  • An example unified IDS manager has configurable detection information, such as communication request counts or the like, where the configurable detection information is stored as configuration information apart from base operations of the unified IDS manager. Accordingly, detection parameters of the unified IDS manager can be updated dynamically and without extended downtime for implementation, allowing for rapid and convenient adjustment of detection thresholds (e.g., reducing thresholds to increase sensitivity, and/or increasing thresholds to reduce false positive detections).
  • detection thresholds e.g., reducing thresholds to increase sensitivity, and/or increasing thresholds to reduce false positive detections.
  • An example unified IDS manager provides mechanisms and policies to inspect traffic that is internal to the vehicle, and also traffic entering and exiting the vehicle.
  • the internal traffic consists of in-vehicle Ethernet data and CAN data.
  • An example unified IDS manager uses Protocol Analysis, Signature-based and Anomaly -based techniques, to detect intrusions.
  • Unified IDS will have the ability to send out alerts securely based on the configuration.
  • the alerts can be used to take further action, such as terminating connections or notifying the relevant users or services. It can also log the anomalies and the logs can be used for further analysis.
  • a unified IDS manager may be operated on any type of network traffic, including at least Ethernet traffic, CAN data, and/or external traffic.
  • a configurable edge gateway provides CAN traffic to a port of the Ethernet network, for example as encapsulated CAN messages, which may include processed payload data, added frame data (e.g., time stamps or other metadata), with CAN frame data included or removed, and/or with processed CAN frame data.
  • the CAN exporter provides compressed metadata to the unified IDS manager to save bandwidth.
  • An example unified IDS manager parses the three types of traffic (e.g., at Packet Parsing block).
  • the example Packet Parsing block includes parsers for Ethernet, IP, ARP, ICMP, TCP, UDP, HTTP, HTTPS, DNS, CAN, and EthXX protocols. Any protocol may be supported as needed.
  • the example unified IDS manager includes a Protocol Analysis block that checks for protocol errors and flags violations. A protocol violation could be caused by a misconfigured or malicious ECU, and this is an efficient way to detect intrusions, if they can be detected in this block. An example of a violation that can be detected using protocol analysis is invalid TCP flag combinations resulting from port scanning applications running on an ECU.
  • An example unified IDS manager includes a Connection Management block that analyzes security vulnerabilities at the connection level.
  • the definition of ‘connection’ depends on the protocol being considered.
  • the Connection Management maintains various connection associations, such as:
  • TCP/UDP Source, Destination Addresses, Source Port, Destination Port, and Protocol
  • a connection database is maintained to track all connections.
  • the Metadata and Statistics Collection performs analysis and updates the connection database. Whenever a new connection is detected, it is added to the connection database, and the packet statistics are updated. For all subsequent packets of a given connection, the stats are just updated. Any metadata that is extracted from the packet is also added to the connection database. For example, the state of a TCP connection is the metadata maintained in the connection database for the TCP connection. TCP reassembly, if needed, is done as part of this block.
  • the Signature Based Detection block performs signature-based detection checks for known attacks by examining the data using known signatures or rules for the known attacks.
  • the rules are run on a per-packet basis and are also run at the connection level. For example, a DNS packet larger than 512 bytes would be a violation.
  • the signatures are configured or optimized for vehicular traffic and are designed for targeted detection of attacks pertinent to the vehicles. They will have a low memory footprint.
  • the Anomaly Based Detection block operates on communications whenever well- defined rules are not available, and/or as a rationality check, and is mainly used for unknown violations.
  • a baseline of the traffic is maintained using the traffic patterns (either learned from the data or using ethDB) and any deviation from the baseline triggers a violation.
  • a feedback scheme is used to leam from the detections and to decrease the number of false positives.
  • the Logging and Alert Management block logs events that are detected. Some of the events will result in alerts, depending on the severity and/or frequency of the event.
  • Example alerts include selected information about the event, such as:
  • a complete log of all the events in the system is maintained in nonvolatile memory, which may be sent to the cloud, a service tool, and/or to the OBD port upon demand.
  • the logs are sent via secure HTTPS.
  • the unified IDS manager provides configuration service so that a remote client can control the IDS feature.
  • Example configuration options include: • Activate or deactivate IDS functionality
  • aspects of the unified IDS manager may be implemented externally, such as in a cloud application, and/or a cloud application or other external application may selectively communicate with the unified IDS manager to support one or more features, such as:
  • An example unified IDS additionally inspects external traffic.
  • External traffic consists of traffic entering and exiting the vehicle. Even though the firewall operating on this traffic can block all connections based on the rules, the firewall is limited by the rules.
  • the vehicle network is static and rules can be easily formulated but it is possible that one of the ECUs (e.g., any controller, processor, and/or computing device on the vehicle) may get infected by some intrusive software and could result in the following:
  • the infected ECU could connect to the allowed servers and waste bandwidth on the external network connection.
  • the software could install some spyware and collect data in the vehicle compromising the privacy of the occupants
  • Firewall operation is based on the rules and does not look at patterns of anomalous behavior. So unified IDS and Firewall functions are complementary and both are essential for ensuring the highest level of security.
  • the table above shows some of the data and metadata items collected and maintained for various protocols for detecting intrusions.
  • the table is not exhaustive, and the elements can be configured according to the relevant protocols and intrusion types to be detected.
  • Shared Network Storage enables more efficient data collection, storage and sharing by in-vehicle apps and services, more effective data security and backups, and new solutions like OTA (over the air). OEMs will benefit from lower overall memory costs, increased safety and performance, and increased revenues and profits from new, high-value applications and services. Customers will benefit from new data-rich features (e.g., Sentry Mode), flexible content downloads for entertainment, personal storage options (e.g., personal photos), and reduced input costs to the vehicle.
  • Sentry Mode e.g., Sentry Mode
  • Example operations of a shared storage controller are provided for illustrative purposes.
  • An example shared storage controller includes storing vehicle condition information, such as camera footage for cameras related to the vehicle, which may be stored in a rolling data buffer.
  • vehicle condition information such as camera footage for cameras related to the vehicle
  • the contents of the buffer may be preserved upon a request (e.g., a customer receives a notification that her parked car has been hit, and requests preservation of the data which may include prompting the customer to preserve the data), and/or may be preserved according to event detection rules (e.g., a rule indicating to save the camera data buffer in response to an impact detection while parked, etc.).
  • event detection rules e.g., a rule indicating to save the camera data buffer in response to an impact detection while parked, etc.
  • the customer can then retrieve (and/or provide to an insurance provider, police, etc.) the data including video recordings for a few minutes before the impact.
  • An example shared storage controller includes preserving configuration information for an ECU in the system, for example an image of a software installation update for the Head Unit.
  • the ECU having the failed update can revert to the previous installation, and the image having the update is stored for installation at a later time.
  • the shared storage controller may delete the image having the update after a later successful installation of the update for the ECU.
  • An example shared storage controller includes downloading media (e.g., a movie, game, music, audio book, etc.), for example when cellular data is readily available, where WiFi or another relatively unlimited external data connection is available, and/or upon request by a user.
  • the request for the downloaded media may be made with a user device (e.g., a mobile device, web application, etc.) and/or a vehicle display such as the Head Unit.
  • the passengers can then watch the movie, play the game, or otherwise access the media without interruption by slow or intermittent cellular connectivity, and/or without incurring cellular download costs.
  • the shared storage controller may delete the downloaded media based on rules provided in configuration information and/or a policy, after a selected period of time, based on available space (e.g., rolling out older or least used media to make room for additional downloads, etc.).
  • An example shared storage controller caches data for external communication, for example collected data according to a policy, event detection, and/or a data collection request, and communicates the data at a later time. Accordingly, external data communications can be time shifted, for example to allow for more efficient use of cellular communications, to take advantage of an opportunistic high capability connection such as a WiFi, and/or to manage intermittent data interruptions (e.g., traveling through a tunnel).
  • the cached data is deleted after later communication, and/or may be deleted according to data priority, policy, or other considerations, if the cache is filled before the data is communicated.
  • configuration information, rules, and/or policy may indicate that certain data values should be compressed, summarized, and/or otherwise processed to reduce the storage space of the data, if the full data cannot be communicated before the cache is filled.
  • other available data spaces that are unutilized such as media storage space, preserved configuration information space, or any other available data space as disclosed herein, may be utilized in whole or part before deletion of collected data, for example allowing for a temporary increase of the data collection cache.
  • An example shared storage controller provides storage for a learning system, for example where large amounts of data are stored to collect and analyze driving behavior, vehicle performance, settings, environmental data, etc. to support learning operations to adjust to a customer driving style and/or to improve performance of an ADAS system.
  • the data may be stored until a low cost transmission network, such as a WiFi, is available.
  • new ECU software can be further abstracted from the underlying hardware - enabling a consolidated architecture where vehicle applications run on a few high performance ECUs.
  • Embodiments of the present disclosure include an architecture that includes a secure centralized vehicle memory (optionally, through an expansion slot) and/or additional user-provided memory, such as a USB drive (which is both cost-effective and highly flexible). This allows users to store large amounts of data which is accessible from multiple sources which, in embodiments, may be through an in-vehicle network, external network, and/or other interfaces.
  • an example shared storage controller is depicted, which is depicted as interfacing with an ECU in the example of Fig. 16 (although a given embodiment may include a number of ECUs and/or the shared storage controller may be positioned, in whole or part, on one or more ECUs).
  • An example shared storage controller includes an in- vehicle storage server that enables multiple applications from different ECUs to store or retrieve data to/from the shared storage.
  • An example shared storage includes a centralized storage, such as a centralized flash drive.
  • the shared storage may be distributed among a number of devices, where the centralization of the storage is a logical organization rather than a physical organization. Nevertheless, in certain embodiments the shared storage is a physical organization, whether in a single device or a small number of centralized devices.
  • the storage server is communicatively coupled to the in-vehicle network (IVN), and is capable of storing data in selected formats, for distinct file systems, and/or configured data objects and structures.
  • Example file systems e.g., formatting and addressing, decisions regarding which data is stored in what locations, etc.
  • vehicle data e.g., user data, and/or video files (e.g., generated for during monitoring operations, data captures after events, etc.).
  • Example data objects include data collection objects (e.g., data structures holding collected data in a selected format), machine learning data (e.g., training data, feature vectors, neural parameters, etc.), and shared resources (e.g., data caches, configuration information, policy data, and/or any other shared resource data from ECUs on the system).
  • the storage server provides one or more dedicated partitions of the shared storage, which may be virtual partitions or physical partitions (or a combination, for example providing a physical partition for ECUs having a large stable demand for storage resources, and virtual partitions for transient demands, uncertain demands, and/or during transient operating conditions to allow easier movement of storage capacity between ECUs).
  • the storage server adjusts a size of a partition, allowing for reduced waste of utilized shared storage.
  • the storage server provides for shared partitions, which may be shared between all ECUs and/or a subset of ECUs (e.g., grouping ECUs by function, data formats, data storage duty cycle matching and/or de- synchronization, etc.).
  • An example shared storage controller includes an authentication and authorization manager, which grants or denies access to ECUs to any specific container, for example based on policies (e.g., interfacing with the Policy Manager), configuration information, priority associated with the ECU and/or a flow associated with the ECU, etc.
  • the authentication and authorization manager provides access to data storage capacity based on permissions, policy, priority, and the like.
  • the authentication and authorization manager may provide access to write to: a partition, a folder and/or subfolders, a file, etc.
  • the authentication and authorization manager may separate reading rights from writing rights.
  • the increased storage may be provided, if available, and/or taken from lower priority shared data storage utilizers.
  • snapshots, backups (full or partial), and/or cached data targeted for external communication may be stored in the shared storage.
  • the shared storage may be of any size, for example 16 GB, 32 GB, 64 GB, or any other value.
  • Certain considerations for determining a shared storage size include, without limitation: the number of ECUs on the system and the net storage need for the ECUs beyond their internal storage capability; the amount of data collection to be performed on the vehicle, the types of data to be stored, and the profile of available data communication to external devices (e.g., bandwidth, costs, and/or the magnitude and extent of likely low bandwidth periods or high bandwidth periods); the distributions of ECUs across separate networks; the amount of data communication expected between ECUs on separate networks; the bandwidth available on in-vehicle networks to support network cross-communications between ECUs on the separate networks; and/or the likely number and data requirements for consumer or 3 rd party features that may require data storage (e.g., for media buffering, pre-downloads, data collection, etc.). Referencing Table 2, typical sizing for video files is depicted for reference.
  • An example operating system for the shared storage controller includes a Linux operating system, although any operating system may be utilized.
  • example data services include: NAS server operations including file system protocols such as NFS, SMB, and/or FTP; an object store for object-based storage; and/or a database server for storing custom database tables and indexes.
  • NAS server operations including file system protocols such as NFS, SMB, and/or FTP
  • object store for object-based storage
  • database server for storing custom database tables and indexes.
  • Embodiments of the disclosure may use non relational databases, e.g., a key/value pair database.
  • the shared storage controller is configured to compress data as it is ingested, which may be configured according to the type of data (e.g., lossless compression for highly digitized data and/or data where compression loss is undesirable and/or will not meet requirements for the data; and/or lossy compression, for example where loss of information is acceptable, for highly continuous/varying data, etc.).
  • the shared storage controller is configure to perform deep compression of cold data - for example data that is not likely to be utilized by an ECU on the system in the near term, which may also relieve vehicle control ECUs from deep compression tasks that may be highly intensive for processing and/or I/O resources.
  • the shared storage controller is configured to encrypt data at rest.
  • the shared storage controller is configured to age out data, to remove unneeded data, and/or to enforce a data retention policy.
  • An example shared storage controller is configured to back up snapshot data in response to connectivity to an external backup device (e.g., a cloud server) and/or available bandwidth to communicate the snapshot data.
  • Example embodiments provide for expanded effective storage capacity of all ECUs on the vehicle, through both cost savings that allow for resources to dedicate to centralized storage, reduction of wasted storage space, and balancing of aggregate storage needs to provide greater certainty of the whole system storage needs versus highly variable individual ECU storage requirements that must be managed with individual storage capabilities associated with each device.
  • Example embodiments provide for ease of scalability in storage capacity and performance, where relatively few resources can greatly expand available storage for the system.
  • Example embodiments provide for data isolation, with app-specific and/or ECU-specific partitions, and secure access management between ECUs.
  • Example embodiments provide for centralized secure storage of data, and simplification of data security management (e.g., reducing the requirement to configure and verify individual ECUs to ensure secure storage of related data).
  • An example system includes the provisioning client to be used as a proxy between apps running on individual ECUs and the authentication and authorization manager in the shared storage.
  • An example system includes data clients (e.g., NFS, SMB, Object Store) for the apps to use as a proxy for sending and receiving data to and from the shared storage.
  • data clients e.g., NFS, SMB, Object Store
  • the growth of advanced vehicle functionality combined with pressures to reduce costs have combined to the point where typical vehicle configurations include a large number of ECUs, for example up to 150 ECUs.
  • an example system supports consolidation of vehicle features and control operations into a reduced number of more powerful ECUs. Additionally, the example system supports migration from legacy implementations with a multitude of ECMs, to sequential progression toward consolidation of features over time, over the life cycle of a vehicle, over a number of model years of a vehicle, etc.
  • Containerized applications can easily be added, combined, and moved to create feature sets for different models and trim levels, update vehicle features, and even relocate applications between servers for reliability and power management.
  • a Container Orchestration Policy is created to specify:
  • Container migration strategy e.g., where to run the container in order to save power, or in case of a hardware failure
  • the example Container Orchestration Controller receives the policy and enforces it by harnessing the following other modules:
  • Container Security Controller this module enforces the access control, authorization, and accounting of the container execution.
  • the container has to pass the access control and authorization check in order to be eligible to the container runtime.
  • container running statistics will be collected and sent back to the cloud.
  • Container Runtime this module provides an Open Container Initiative (OCI) and Container Runtime Interface (CRI) compliant container runtime optimized for embedded environments.
  • Example implementations of a containerized application are provided following.
  • the examples are illustrative of certain implementation features that are possible according to the present disclosure, and are not limiting.
  • An example implementation includes containerized applications downloaded (e.g., OTA) and installed on the VFAS ECU with the most available resources (e.g., CPU, memory, and/or I/O) and/or the VFAS ECU whereby installation of the containerized application will provide the least restriction relative to a limiting one of the available resources, and/or a VFAS ECU having sufficient resources to implement the particular containerized application.
  • Example implementations include moving containerized applications that have already been installed, and/or balancing the overall load of containerized applications between available ECUs.
  • An example implementation includes utilizing containerized applications combined to create feature sets for different models and/or trim levels of a vehicle.
  • An implementation includes adding or removing features, and/or providing upgraded versions of a feature, to provide an upgrade to a vehicle, and/or to implement control operations for a new model year of a vehicle.
  • An example implementation includes an operation to deploy a containerized application to support specific features for a particular user. For example, a significant data collection operation may be performed by a containerized application operating on an ECU of the vehicle, thereby able to process the data, which may provide improved data collection response (e.g., begin utilizing the collected data more quickly) and/or able to process the data, providing for a reduced amount of data that needs to be communicated via limited external data communication resources.
  • an implementation includes an operation to deploy a containerized application to support a specific feature (e.g., a subscription based feature), and an operation to remove the containerized application in response to an expiration of the subscription, for example to free system resources.
  • a specific feature e.g., a subscription based feature
  • An example implementation includes organizing a distribution of containerized applications on ECUs in response to a network utilization of the containerized applications, for example to reduce network utilization on busy or low capability networks, and/or to shift utilization from a low capability network to a higher capability network.
  • An example implementation is positioned on an electric vehicle to support an energy saving mode (e.g., utilized when batteries reach a selected state of charge) by deactivating non-critical features, reducing resource utilization such as processor operations, and/or consolidating features onto fewer ECUs to allow certain ECUs to be de-powered completely.
  • an energy saving mode e.g., utilized when batteries reach a selected state of charge
  • An example implementation includes positioning containerized application between ECUs to distribute system risk, for example placing critical vehicle applications into different containers than less critical applications (e.g., to reduce potential conflicts and/or prioritizing allocation of resources).
  • critical applications are provided with redundancy (e.g., present on more than one ECU), such that a failure of the ECU does not cause a loss of the application, as the application can be executed from a backup version on another ECU.
  • a critical application is migrated from a first ECU having a failure or a performance decrease to another ECU. The migration may be on vehicle, for example when communication can still be established with the reduced performance ECU, and/or the migrated containerized application may be migrated by downloading another version from the cloud server.
  • a non-critical application may be migrated, shut down, and/or be allocated reduced resources in response to the failure and/or performance decrease of the ECU.
  • Lightweight containers require less server resources than hypervisors and virtual machines with embedded operating systems, and require negligible additional processing or memory compared to non-virtualized applications.
  • Benefits for the OEM of using containers include reduced hardware costs, faster time-to-market for features and vehicles, lower development costs, and more reliable applications and systems.
  • Example benefits for implementation of a containerized application model include: [000466] Containers under Docker are built with a microservice focus. This removes the burdensome infrastructure layers and helps optimize application delivery and workflow. [000467] Through container repositories/registries such as Docker Hub, the deployment process could be simplified, and applications could be checked-in/out, turning infrastructure into code.
  • Container images are decoupled from the traditional, heavyweight host OS, so they are now portable, running in any container runtime environment that supports them. This helps enable true hybrid deployment capabilities.
  • Container adoption introduce challenges into traditional applications such as automotive control implementations, since management of container-based infrastructure requires completely different methods of operating, and the workflows oftentimes ran counter to long-established norms.
  • Some additional challenges of container adoption include:
  • End-to-end control of the operating environment can be problematic — the rich ecosystem of infrastructure management tools developed over decades largely does not translate to the container-based world.
  • Containers allow in-vehicle software to be decoupled from hardware, allowing for available hardware resources to be assigned more easily, and developed independently from other software that could share resources.
  • a containerized application environment would enable the deployment of different applications based on different trim vehicle levels on the same hardware platform.
  • FIG. 20 an example architecture implementation for container based applications on a vehicle is schematically depicted.
  • the example architecture of Fig. 20 improves the workflow when multiple vendors are involved in an ECU development.
  • Containers provide clear separation between their functional modules. The suppliers are free to choose the middleware, whether it is AUTOSAR Adaptive or ad-hoc middleware, that best fit their interests.
  • FIG. 21 an example alternate architecture implementation for container based applications on a vehicle is schematically depicted.
  • the features are self-contained inside a container that brings at least two clear advantages.
  • First, the features can be easily upgraded individually with zero-downtime impact on other features.
  • Second, the feature set can be easily expanded or customized for different vehicle trims/levels.
  • the diagram below shows how to customize a full trim vehicle to an intermediate trim. All it needs is a simple change in the Container Orchestration Policy that decides what container to enable.
  • Each container can either use AUTOSAR Adaptive to realize all the middleware functionalities, or use ad-hoc middleware, such as SOME/IP, DBus, Systemd, and so on.
  • middleware such as SOME/IP, DBus, Systemd, and so on. The decision should be made on a case-by-case basis, and it should be based on the container functions and their coupling with AUTOSAR Adaptive.
  • each feature container can associate a container manifest, which is defined and controlled by the OEM.
  • the manifest dictates how much resources (e.g., CPU/memory) should be allocated to the container, as well as determining the container privilege level (set through AppArmor profile).
  • FIG. 22 a schematic diagram of certain details of a container is depicted.
  • An example implementation includes all containers dynamically joining the same network to facilitate SOA. Logically, each container runs like an individual ECU directly attached to a virtual Ethernet backbone.
  • FIG. 23 a container networking example implementation is schematically depicted.
  • This new virtualized network should adapt the network configuration when a container joins or leaves the network to allow the new container to connect with others.
  • a couple of new technologies are required to empower this, including MAC learning, Dynamic ARP, IgmpSnooping, DHCP, and their security counterparts. These new networking technologies will be enabled by Advanced Network Management of embodiments of the present disclosure.
  • AUTOSAR Adaptive defines interfaces and organizes the responsibilities in each module in order to provide an application runtime environment:
  • Function group is a set of applications with independent state
  • Execution dependency defines program startup order to ensure a process will start after the processes it depends on. Execution dependency is defined per function group to prevent failing a function group shall not impact the other function group
  • ara::per provides key-value pair storage and file-proxy available to applications
  • AUTOSAR Adaptive was designed to support traditional applications on POSIX-compliant operating systems, and it was not designed to support containerized applications.
  • An example implementation expands and enhances support for containers.
  • Containers on top of AUTOSAR Adaptive offers isolation enforcement for adaptive applications.
  • the Adaptive platform suggests guidelines to make applications portable, it does NOT specify an OS level architecture to achieve proper isolation.
  • An example implementation utilizes Linux namespaces, enabling a process and its children to have different views of the underlying system.
  • An example implementation includes applying OS level virtualization to the adaptive platform.
  • Container features are implemented in the form of a plugin library, and platform applications (e.g., Execution Management functional cluster) can enable the features.
  • platform applications e.g., Execution Management functional cluster
  • Function Group 1 (FG1) and Function Group 2 (FG2) have independent states and they can run simultaneously. There is no execution dependency configured between them.
  • FG1 defines Function Group State of ⁇ Off, Running ⁇
  • FG2 defines Function Group State of ⁇ Off, Running, Fallback, Diag ⁇
  • Container isolation features shall be configured per Function Group.
  • the following sequence diagram depicts how container features are enabled as part of AUTOSAR Adaptive Function Group States.
  • the Container Manager implements OS level isolation features (e.g., namespaces) and manages policies.
  • OS level isolation features e.g., namespaces
  • the ECU will download and execute the policies that specify the list of applications to be configured and the container features to be enabled. Policies can differ by vehicle or groups of vehicles, and policies can be applied for both the first installation and later policy updates. Referencing Fig. 26, an example implementation of a container manager is schematically depicted.
  • Accessible file system directories [000511] Range of uid/gid mapping [000512] Resource assignment
  • AUTOSAR Adaptive Persistency shall integrate with container plugin library
  • AUTOSAR Adaptive Update and Configuration Manager shall integrate with container plugin library
  • an example apparatus 2700 is depicted for implementing a policy based on driver behavior and/or monitoring of a driver for a vehicle (or selected group of vehicles).
  • the example apparatus 2700 may be included, in whole or part, with any system, apparatus, and/or device described throughout, and aspects of the apparatus 2700 may implement all or a portion of any operations, procedures, methods, and/or functions as set forth throughout the present disclosure.
  • aspects of the apparatus 2700 may be embodied on the vehicle, on any controller of the vehicle (e.g., a CEG, CES, CND, and/or any controller and/or end point of the vehicle), external to the vehicle (e.g., on a cloud server or computing device, on an external computing device such as a service tool, manufacturing tool, OEM tool, service device, external user device such as an administrator, service, operator, owner, application, or the like), and/or on a device interfacing with any of these - whether through a network (e.g., a LAN, proprietary network, etc.), physical access to a port (e.g., an OBD port, service port, CAN connection, Ethernet port, etc.), wireless access to the vehicle, through a cloud or internet connection, and/or through a cellular connection to the vehicle.
  • a network e.g., a LAN, proprietary network, etc.
  • a port e.g., an OBD port, service port, CAN connection, Ethernet port, etc
  • the example apparatus 2700 includes a controller 2702, depicted as a single device for illustration, but which may be a single device or a distributed device.
  • the description of the apparatus 2700 depicts a number of circuits configured to functionally execute operations of the apparatus 2700.
  • the circuits are each depicted as a single device for clarity of illustration, but a given circuit may be distributed among devices, and/or combined in whole or part with other devices.
  • example embodiments of devices set forth throughout the present disclosure include any one or more of: any sensor present on the vehicle and/or communicative coupling to any such sensor (e.g., an electrical interface, LIN interface, A/D processing of a sensor signal, etc.); any actuator present on the vehicle and/or communicative coupling to any such actuator (e.g., electrical interface, LIN interface, command interface to the actuator, feedback interface from the actuator, etc.); any controller and/or computing device on the vehicle, cloud server, external device, etc., including processing resources, storage resources, I/O resources, and/or communication resources thereof; instructions stored on a computer readable medium, where the instructions are configured such that a computing device executing the instructions thereby performs one or more operations of the device; and/or access to any one
  • the example apparatus 2700 includes a policy acquisition circuit 2704 structured to interpret a vehicle policy data value 2710 including a driver information description 2712.
  • the example vehicle policy data value 2710 may include a policy provided to the vehicle, for example as described throughout the present disclosure, a parsed portion thereof (e.g., a processed policy with portions of the policy relevant to the apparatus 2700 provided to and/or made available to the apparatus 2700, etc.).
  • the vehicle policy data value 2710 includes one or more of: data to be collected from the vehicle; features to be enabled or disabled on the vehicle; configuration of feature parameters (e.g., set point values, available ranges configurable by the operator, minimum or maximum values to be enforced, display settings, data collection time ranges, sampling rates, storage amounts, etc.); and/or triggering conditions for any of the foregoing (e.g., data values, events, thresholds, etc.
  • the driver information description 2712 may include any one or more of: a driver role (e.g., part-time, full-time, employee, contractor, commercial license type, owner, etc.); a driver identifier (e.g., identification of a specific driver; identification of whether a driver belongs to a specified group of drivers; identification of a classification of the driver, etc.); and/or a driver state value (e.g., operating at a certain number of hours into a driving event; having a certain driver performance value or category; having a certain fuel efficiency performance value or category, etc.).
  • a driver role e.g., part-time, full-time, employee, contractor, commercial license type, owner, etc.
  • a driver identifier e.g., identification of a specific driver; identification of whether a driver belongs to a specified group of drivers; identification of a classification of the driver, etc.
  • a driver state value e.g., operating at a certain number of hours into a driving event; having a certain driver
  • the vehicle policy data value 2710 including the driver information description 2712 provides for adjustments to data collection and/or monitoring parameters in response to a range of driver related conditions that may be of interest, and allows for configuration of features, changes in monitored values, changes in data collection operations, etc. based upon any selected driver criteria, such as the type of driver, past performance of the driver, events detected related to the driver, and the like. It can also be seen that the vehicle policy data value 2710 including the driver information description 2712 allows for monitoring, configuration, and/or data collection operations to be utilized for a given driver regardless of the vehicle - for example configuring a vehicle for driver preferences, data monitoring, display values, and the like, even where a driver switches vehicles.
  • the vehicle policy data value 2710 can automatically adjust collection, monitoring, and configuration operations without taking in any new policy information - for example where an apparatus 2700 is configured to perform one set of operations for drivers that are “owners” and another set of operations for drivers that are “operators.”
  • the vehicle policy data value 2710 can be downloaded from an external device (e.g., from a cloud server, external device coupled to the vehicle through a port, WiFi, etc., and/or from a driver associated device such as a mobile device carried by the driver), either in whole or relevant portions thereof, allowing for configuration of the collection, monitoring, and/or configuration operations specific to the particular driver.
  • data specific to the driver may be kept after the driver switches to another vehicle (e.g., preserving history, performance, and/or other individualized data on the vehicle) - for example to allow for a reduction in the data to be collected from the vehicle policy data value 2710 if the driver returns to the original vehicle.
  • data specific to the driver may be removed immediately after the driver switches to another vehicle, and/or kept for a period of time and expired after a selected time period, event, confirmation that the driver is using another vehicle, etc.
  • the configuration of whether data specific to the driver is kept, deleted, migrated to another vehicle, saved on a cloud server, and/or expiration criteria for such data, may be included within the vehicle policy data value 2710.
  • the example apparatus 2700 includes a policy processing circuit 2706 that generates, in response to and based at least in part on the vehicle policy data value 2710, parsed policy data that includes a vehicle data collection description 2714.
  • the description utilizing parsed policy data includes consideration that a policy herein may include any one or more of: parameters to be collected; storage allocation for collected parameters; transmission resource allocation for collected parameters; priority values associated with collection instances (e.g., a group of parameters to be collected together, time ranges for collection of the group of parameters, etc.) including priority for collection operations, utilization of on-vehicle network resources, utilization of off-vehicle transmission resources, utilization of processing resources (e.g., to configure and/or provide parameters, to process and/or format parameters, and/or to perform expiration processing such as summarization, aggregation, and/or compressing operations where applicable); utilization of storage resources (e.g., cache storage, buffer storage, rolling buffer storage, and/or shared storage resources, including resources for collected data, intermediate processing data related to the
  • the parsed policy data includes portions of the vehicle policy data value 2710 that are parsed for the vehicle (e.g., determining parameter names, end point locations, sample rates, units, formatting, etc. specified for collected data) and provided to or made accessible to end points of the vehicle that provide the responsive data, perform supporting operations for the data, process the data, and/or store the data.
  • the policy processing circuit 2706 determines how the formatting of the collected data should be performed based on the requested data criteria (e.g., sampling rates, units, metadata, etc.) and the available responsive data on the vehicle.
  • the policy processing circuit 2706 manages translation between the external data request made (e.g., “ambient temperature”) and the data on the vehicle which is responsive to the external data request made - for example allowing successful operation regardless of the configuration of network zones and/or end points on the vehicle, the version of parameters, controls, or interfaces on the vehicle, and the like.
  • the external data request made e.g., “ambient temperature”
  • the data on the vehicle which is responsive to the external data request made - for example allowing successful operation regardless of the configuration of network zones and/or end points on the vehicle, the version of parameters, controls, or interfaces on the vehicle, and the like.
  • the policy processing circuit 2706 is capable of updating the parsed policy data, for example in response to a change in the vehicle configuration (e.g., an end point moves from one network zone to another network zone, a parameter name changes on a controller of the vehicle, a parameter formatting changes on the vehicle - for example using a different unit, bit depth, resolution, sampling rate, etc.), and/or a parameter source changes (e.g., a parameter provided by a first controller is now provided by a second controller, and/or an off-nominal condition such as a sensor failure, fault condition, etc. causes a parameter source to change) - which may be performed, in certain embodiments, without an update to the vehicle policy data value 2710.
  • a change in the vehicle configuration e.g., an end point moves from one network zone to another network zone, a parameter name changes on a controller of the vehicle, a parameter formatting changes on the vehicle - for example using a different unit, bit depth, resolution, sampling rate, etc.
  • a parameter source changes e.g.
  • the policy passed to the vehicle may result in a first parsed policy data at a first time, and a second parsed policy data at a second time, without a change in the policy passed to the vehicle.
  • both the first parsed policy data and the second parsed policy data may be responsive to the policy passed to the vehicle, although performance relative to the policy may vary (e.g., if a second source of a parameter is inferior or superior to the original source in some manner).
  • the second parsed policy data may not be fully responsive to the policy passed to the vehicle - for example when a requested parameter is no longer available, a requesting entity providing at least a portion of the policy passed to the vehicle no longer has sufficient authorization, etc.
  • the operations of the policy processing circuit 2706, and the implementation of the policy passed to the vehicle - whether utilizing parsed policy data or another implementation - are not specific to the apparatus 2700, and any devices referenced throughout the present disclosure may perform similar implementation operations, including any devices that perform any one or more of: receive and/or process a policy passed to the vehicle; prepare end points of the vehicle to support data collection, data collection support, trigger evaluation, storage operations, feature configuration, transmission operations, and/or automated operations; determine priority values related to data types, associated flows, associated applications, associated vehicle functions, requesting and/or providing end points, and/or requesting and/or providing entities for collected data, processing of collected data, storage of collected data, and/or transmission of collected data.
  • receive and/or process a policy passed to the vehicle prepare end points of the vehicle to support data collection, data collection support, trigger evaluation, storage operations, feature configuration, transmission operations, and/or automated operations; determine priority values related to data types, associated flows, associated applications, associated vehicle functions, requesting and/or providing end points, and/or requesting and
  • a vehicle policy data value 2710 may additionally or alternatively be referenced as a policy of any type, a data request, an automated operation value, a trigger description value, an actuator command value, a remote access request value, or similar terminology as will be understood in the particular context.
  • the example apparatus 2700 includes a policy execution circuit 2708 structured to collect vehicle data 2722 from one or more end points 2716 of at least one network zone (e.g., first network zone 2718 and second network zone 2720 in the example of Fig. 27) of a vehicle in response to the parsed policy data.
  • the example policy execution circuit 2708 provides the collected vehicle data 2722 responsive to the vehicle policy data value 2710, which may be stored, transmitted, utilized to determine whether a trigger event is detected (e.g., triggering further data collection, an automated response, a change in data collection parameters, etc.), or utilized in any other operations as set forth throughout the present disclosure.
  • An example apparatus 2700 includes the end points 2716 (e.g., end points providing data for collection, and/or responding to actuation commands in the vehicle policy data value 2710) positioned on at least two different network zones of the vehicle.
  • An example drier information description 2712 includes a driver characteristic, for example to be compared to present driver information 2714 (e.g., describing a driver role, driver identification, historical and/or performance data for the driver, etc.) to adjust the vehicle policy data value 2710 and/or to perform collection operations pursuant to the vehicle policy data value 2710 that are responsive to characteristics of the present driver of the vehicle.
  • An example policy execution circuit 2708 interprets the present driver information 2714, comparing it to a driver characteristic of the driver information description 2712, and collects the vehicle data 2722 in response to the comparison - for example tailoring the parameters collected, features configured, formatting of collected data, etc. in response to the comparison.
  • An example driver information description 2712 includes a description of monitoring data for a driver of the vehicle - for example tailoring monitoring parameters (e.g., speed, location, utilization of features, driving performance parameters, etc.) to the driver role, specific identified driver, and/or any other driver characteristic.
  • an example driver information description 2712 includes a trigger condition 2806, where the policy execution circuit 2708 collects vehicle data 2722 based on the trigger condition 2806 and/or driver characteristic 2802.
  • the vehicle data collected in response to the trigger condition 2806 may be specified vehicle data 2804 provided in the vehicle data collection description 2714.
  • the trigger condition 2806 may indicate an event or data value to collect the vehicle data 2804, for example in response to a high speed event, a high acceleration event, an extended operating period of the vehicle, detection of a fault condition or diagnostic value, etc.
  • the utilization of the trigger condition 2806 and/or driver characteristic 2802 allows for data collection in response to activity of interest on the vehicle, and further in response to a characteristic of the driver such as years of experience, driver role, location of the driver (e.g., a home location, current location, licensing location, etc.).
  • Example and non-limiting trigger condition(s) 2806 include one or more of: an event detection condition (e.g., parameter values and/or processed parameter values indicating an event has occurred); a driver characteristic value (e.g., data collection in response to a driver condition, a change in the driver condition such as hours of activity or a status change); a driver classification value (e.g., license type, performance indicator, experience indicator, ownership type, etc.); and/or a driver performance value (e.g., efficiency performance, safe operation performance, feature utilization performance, etc.).
  • the collected vehicle data 2722 includes data collected in response to the determination of an event occurrence based on a comparison of some of the collected data values to the trigger condition 2806.
  • an example procedure 2900 for collecting data in response to a driver information description for example to provide driver monitoring and/or collection of data based on a driver characteristic is schematically depicted.
  • the example procedure 2900 includes an operation 2902 to interpret a vehicle policy data value including a driver information description, and an operation 2904 to generate a vehicle data collection description in response to the vehicle policy data value.
  • the example procedure 2900 further includes an operation 2906 to collect vehicle data from end points of the vehicle in response to the vehicle data collection description.
  • the collected data may be stored, used to determine whether a trigger condition has been met and/or an event has occurred, transmitted in whole or part to an external device (e.g., associated with an entity and/or application providing the vehicle policy data value or relevant portions thereof), and/or may be expired according to criteria in the vehicle policy data value.
  • an external device e.g., associated with an entity and/or application providing the vehicle policy data value or relevant portions thereof
  • an example procedure 2906 for performing collection operations responsive to the vehicle policy data value and/or driver information description is schematically depicted.
  • the example procedure 2906 includes an operation 3002 to determine whether a trigger condition is met, and in response to the operation 3002 determining “YES”, the procedure 2906 includes an operation 3004 to commence and/or adjust data collection operations.
  • the procedure 2906 includes an operation 3006 to stop collecting data, to continue collecting data in a previous configuration (e.g., not changing collection operations), and/or to continue checking for the trigger condition (e.g., return to operation 3002).
  • an example apparatus 3100 is depicted to provide data collection operations in response to a vehicle policy data value, including commencing, changing, and/or stopping data collection operations based on fault codes from devices on the vehicle.
  • fault code values e.g., as determined by control operations, provided by relevant devices such as sensors, actuators, etc., and/or as determined from other parameters such as diagnostic algorithms, rationality checks, comparisons to other data values, etc.
  • fault counters e.g., managing data used in fault determination, such as incrementing or decrementing counters or the like
  • a diagnostic value e.g., an output of a diagnostic operation such as “PASS”, “FAIL”, “SUSPECT”, etc., and/or intermediate values that may indicate a diagnostic operation has a preliminary indication of off-nominal operation even if the diagnostic operation has not yet diagnosed a failure, and/or that may indicate the diagnostic operation has a preliminary indication that an off
  • the example apparatus 3100 further includes the policy acquisition circuit 2704 that interprets the vehicle policy data value 2710 including a device condition description 3102, for example indicating which fault and/or diagnostic parameters, and/or which devices, are to be utilized to commence, change, and/or stop data collection operations.
  • the example apparatus 3100 operates similarly to apparatus 2700, for example determining parsed policy data responsive to the vehicle policy data value 2710 and the device condition description 3102.
  • the example apparatus 3100 allows for configuration of data collection operations responsive to any device in the system, for example any end point, sensor, actuator, control operation, or the like, and allows for the tailoring of data collection responsive to fault activity generally (e.g., collecting specified data whenever a fault occurs, and/or whenever a fault occurs from a group of faults that are of interest) and/or to specific fault activity (e.g., collecting specified data based on the specific fault - for example to determine if highly correlated faults have also occurred and/or may occur soon, to gather specific information related to the fault to determine a root cause of the fault, and/or to capture historical information preceding the fault occurrence).
  • fault activity generally
  • specific fault activity e.g., collecting specified data based on the specific fault - for example to determine if highly correlated faults have also occurred and/or may occur soon, to gather specific information related to the fault to determine a root cause of the fault, and/or to capture historical information preceding the fault occurrence.
  • the operations of the apparatus 3100 may be utilized to support alternate operations (e.g., determining whether to utilize a substitute data value, control operation, or the like responsive to the fault occurrence); to support knowledge generation related to the vehicle and/or a group of vehicles (e.g., to accumulate the collected data with data from other vehicles and/or previous occurrences of the fault on the current vehicle, which may be utilized to improve the design, improve prognostication of faults, and/or improve service and/or diagnostic operations responsive to the fault occurrence); and/or for any other purpose (e.g., warranty execution and/or response, provision of alerts and/or notifications to the operator, service personnel, a fleet owner, etc.).
  • alternate operations e.g., determining whether to utilize a substitute data value, control operation, or the like responsive to the fault occurrence
  • knowledge generation related to the vehicle and/or a group of vehicles e.g., to accumulate the collected data with data from other vehicles and/or previous occurrences of the fault on the current vehicle, which may be utilized
  • An example device condition description 3102 includes a description of vehicle data to be collected based on at least one of a device fault value or a device diagnostic value (e.g., collecting data in response to the fault value or diagnostic value becoming active, becoming inactive, having a counter value begin incrementing, decrementing, or achieving a selected value, etc.).
  • a device fault value or a device diagnostic value e.g., collecting data in response to the fault value or diagnostic value becoming active, becoming inactive, having a counter value begin incrementing, decrementing, or achieving a selected value, etc.
  • the utilization of the device condition description 3102 allows for responsive activity to the fault or diagnostic value, for example performing data collection for a fault value based on a time since the fault value was last activated and/or last deactivated, responsive to a collection of fault values (e.g., beginning data collection when three fault values out of a selected group of twenty fault values have become active), and/or responsive activity to an intermediate value utilized in a fault and/or diagnostic operation, such as counters, threshold comparisons, and the like, which may show activity prior to the fault or diagnostic value being cleared, confirmed, etc.
  • a collection of fault values e.g., beginning data collection when three fault values out of a selected group of twenty fault values have become active
  • an intermediate value utilized in a fault and/or diagnostic operation such as counters, threshold comparisons, and the like, which may show activity prior to the fault or diagnostic value being cleared, confirmed, etc.
  • the vehicle data collection description 2714 is determined in response to the vehicle policy data value 2710, and includes a description of vehicle data to be collected based on the criteria within the vehicle policy data value 2710.
  • the vehicle policy data value 2710 may collect data related to a device associated with device condition description 3102, but may additionally or alternatively collect data associated with any other device on the vehicle.
  • an apparatus 3100 may be configured to collect data related to a faulted device, such as vehicle speed data related to a faulted speed sensor (e.g., where the vehicle speed data may capture outputs of the faulted speed sensor, and/or other related data such as a voltage supply to the speed sensor, etc.), and/or collect other data not related to the faulted speed sensor (e.g., current gear of the vehicle, power supply values throughout the system of the vehicle, multimedia activity data, etc.), that may be utilized in any manner as described.
  • vehicle speed data related to a faulted speed sensor e.g., where the vehicle speed data may capture outputs of the faulted speed sensor, and/or other related data such as a voltage supply to the speed sensor, etc.
  • other data not related to the faulted speed sensor e.g., current gear of the vehicle, power supply values throughout the system of the vehicle, multimedia activity data, etc.
  • An example description of the monitoring data includes at least one data value such as: a fault condition 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.
  • an example monitoring data description 3201 for example utilized with apparatus 3100, include device fault and/or diagnostic values 3202, which may be for the device of the device condition description 3102, or for another device on the vehicle.
  • the example of Fig. 32 includes the vehicle data collection description 2714 having vehicle data for collection 2804, and in the example further having monitoring data 3204, for example related to the device of the device condition description 3102 or another device of the vehicle.
  • monitoring data 3204 and/or collection operations are responsive to trigger conditions, for example as described in relation to Fig. 28.
  • an example procedure 3300 for implementing a policy responsive to fault and/or diagnostic values for device(s) in a vehicle system is schematically depicted.
  • the example procedure 3300 includes an operation 3302 to interpret a vehicle policy data value including a device condition description, and an operation 3304 to generate a vehicle data collection description in response to the vehicle policy data value.
  • the example procedure 3300 further includes an operation 3306 to collect vehicle data from end points of the vehicle in response to the vehicle data collection description.
  • an example apparatus 3400 is depicted to provide data collection operations in response to a vehicle policy data value, including commencing, changing, and/or stopping data collection operations based on end point performance description(s) for end points of the vehicle.
  • operations of the apparatus 3400 allow for selected data collection, and/or adjustments of collected data, based on indications of capability of the end point, changes to the end point, and/or a configuration of the vehicle that can be determined based on the end point performance (e.g., a sensor or actuator capability that provides an indication that the vehicle is provided in a certain configuration - for example the presence of a particular sensor, and/or an output value or resolution provided by the sensor, may indicate that a particular vehicle configuration, feature set, performance rating, etc. is present on the vehicle).
  • a sensor or actuator capability that provides an indication that the vehicle is provided in a certain configuration - for example the presence of a particular sensor, and/or an output value or resolution provided by the sensor, may indicate that a particular vehicle configuration, feature set, performance rating, etc. is present on the vehicle.
  • the example apparatus 3400 includes the policy acquisition circuit 2704 that interprets a vehicle policy data value 2710 including an end point performance description 3402, and a policy processing circuit 2706 that generates parsed policy data including a vehicle data collection description 2714, based at least in part on the vehicle policy data value 2710.
  • the apparatus 3400 otherwise operates similarly to apparatus 2700 and apparatus 3100.
  • Example and non-limiting vehicle data for collection 2714 examples include: end point and/or end point groups 3504 (e.g., end point locations, sources for parameters, and/or end points of interest where data should be collected in response to the performance condition of the end point(s) of the end point performance description 3402); data value(s) for collection 3506 (e.g., values of interest based on the performance description, confirming and/or verifying values, values that may be utilized to diagnose and/or prognosticate a performance change, and/or values to determine a consequence of the end point performance, mitigating actions for the end point performance, and/or to determine if related end points, applications, flows, or the like have been or will be affected by the end point performance); a collected data formatting and/or processing description 3508 (e.g., formatting and/or processing operations that should be performed in response to the end point performance, for example where the sampling rate, data resolution, bit depth, units, parameter names, metadata, or the like should be adjusted based on the end point performance); a collected data
  • An example end point performance description 3402 includes a first data value to be collected in response to a target end point being in a first condition, and a second data value to be collected in response to the target end point being in a second condition.
  • the utilization of the first condition and the second condition allows for changing the data to be collected based on any condition of the end point, including at least a type of the end point, a status of the end point (e.g., nominal, passed, failed, suspect, etc.), and/or another aspect of the vehicle that is indicated by the condition of the end point.
  • An example apparatus 3400 includes the target end point in the first condition indicating a first vehicle configuration, and the target end point in the second condition indicating a second vehicle configuration.
  • An example apparatus 3400 includes the target end point in the second condition indicating the target end point is determined to be in an off-nominal condition, such as: a failed condition, a faulted condition, a non-responsive condition, and/or a lost communication condition.
  • An example apparatus 3400 includes the target end point in the first condition indicating a first target end point configuration (e.g., a sensor type, actuator type, version of a related application, flow, and/or control operation, etc.), and where the target end point in the second condition includes a second target end point configuration.
  • a first target end point configuration e.g., a sensor type, actuator type, version of a related application, flow, and/or control operation, etc.
  • the first data value includes data to be collected from a first end point group (e.g., the target end point in the first condition indicates that the vehicle data collection description 2714 is directed to a group of parameters from the first end point group, which may include the target end point or not), and the second data value includes data to be collected from a second end point group (e.g., the target end point in the second condition indicates that the vehicle data collection description 2714 is directed to a group of parameters from the second end point group, which may include the target end point or not).
  • the first end point group and the second end point group may include one or more, or all, of the same end points, with the differences between the first end point group and the second end point group being limited to the overall parameter selection for collection from each end point group.
  • end point group may include a single end point - for example and without limitation, a highly capable controller managing a large number of sensors, actuators, and/or control operations, may have a large number of parameters available, such that the parameters expressed by the first end point group and/or the second end point group may all be available from the single highly capable end point.
  • the first end point group and the second end point group include at least one distinct data value (e.g., data values for collection from the first end point group have at least one different value from data values for collection from the second end point group) for collection.
  • the first end point group and the second end point group include at least one distinct end point (e.g., end points making up the first end point group have at least one different end point from end points making up the second end point group).
  • differences between the first end point group and the second end point group are present, additionally or alternatively, in other dimensions than the data values or the end points, for example priority values, formatting values, processing values, sampling rates, etc.
  • Figs. 34-35 are described, for purposes of illustration, with regard to data collection operations responsive to an end point performance description. Additionally or alternatively, operations of an apparatus 3400 may adjust one or more of: feature parameters; enabling or disabling features; commencing and/or stopping data collection; and/or activating one or more actuators, in response to the end point performance description.
  • an example procedure 3600 for performing operations to adjust data collection in response to an end point performance description is schematically depicted.
  • the example procedure 3600 includes an operation 3602 to interpret a vehicle policy data value in response to an end point performance description, and an operation 3604 to generate a vehicle data collection description - for example based on parsed policy data from the vehicle policy data value.
  • the example procedure 3600 further includes an operation 3606 to collect vehicle data from end points of the vehicle in response to the vehicle data collection description.
  • an example apparatus 3700 is depicted to provide data collection operations in response to a location description value, including commencing, changing, and/or stopping data collection operations based on location values associated with the vehicle.
  • operations of the apparatus 3700 allow for selected data collection, and/or adjustments of collected data, based on a location of the vehicle - for example within a geographic area, jurisdiction, relative to a specified location, and/or within a defined boundary.
  • Example differences between locations that may be relevant to data collection operations include, without limitation: differences in transmission resource availability; differences in vehicle service availability; differences in parameter names, units, industry standards, or other conventions relating to expected data formatting; differences in reliability (e.g., where geographic regions are known to cause differences in reliability, for example due to varying ambient conditions, road conditions, etc., and/or as determined by an artificial intelligence and/or machine learning component, which may indicate reliability differences between locations without the system necessarily having knowledge of the reason for the differences); differences in contractual obligations relating to the location; differences in warranty implementation relating to the location; differences in legal posture relating to the location (e.g., speed limits, weight limits, allowability of utilization of certain features such as cruise control, engine braking, automated driving, etc.); and/or differences in legal posture relating to the data per se based on the location (e.g., varying privacy laws, liability laws, emissions regulations, tracking and/or reporting, etc.).
  • location variable data collection accordingly supports a number of objectives.
  • One of skill in the art having the benefit of the present disclosure and information ordinarily available when contemplating a particular system, including a system having an apparatus 3700 included therewith, can readily determine location description values 3702 of interest, and adjustments to the vehicle data collection description 2714 responsive to the location description values 3702.
  • Figs. 37-38 are described, for purposes of illustration, with regard to data collection operations responsive to a location description value 3702. Additionally or alternatively, operations of an apparatus 3700 may adjust one or more of: feature parameters; enabling or disabling features; commencing and/or stopping data collection; and/or activating one or more actuators, in response to the location description value 3702.
  • the example apparatus 3700 includes a policy acquisition circuit 2704 that interprets a vehicle policy data value 2710 including the location description value 3702, and a policy processing circuit 2706 that generates parsed policy data including a vehicle data collection description 2714 based, at least in part, on the vehicle policy data value 2710.
  • the example apparatus 3700 includes a policy execution circuit 2708 that collects vehicle data (e.g., provided as collected vehicle data 2722) from end points 2716 of network zone(s) of the vehicle in response to the parsed policy data.
  • Example implementations of the apparatus 2700 include capturing selected data based on the location description value 3702, stopping the collection of selected data based on the location description value 3702, changing a source of collected data (e.g., which end point provides a particular data value - such as a change in which sensor provides the value, a change from a directly detected value to a virtually determined value or vice versa, collecting a value to avoid or allow utilization of one or more network zones for the data value, and/or collecting a value to avoid or allow utilization of one or more features, flows, applications, etc.
  • a source of collected data e.g., which end point provides a particular data value - such as a change in which sensor provides the value, a change from a directly detected value to a virtually determined value or vice versa
  • collecting a value to avoid or allow utilization of one or more network zones for the data value and/or collecting a value to avoid or allow utilization of one or more features, flows, applications, etc.
  • the apparatus 2700 may be utilized, additionally or alternatively, to adjust a feature configuration, enable or disable a feature, to adjust trigger evaluation operations, and/or to adjust storage and/or transmission operations for at least a portion of the collected vehicle data 2722 in response to the location description value 3702.
  • example and non-limiting location description value(s) 3702 include one or more of a geographic location value (e.g., GPS location information, and/or categorical information such as “UNITED STATES”, “CANADA”, “CALIFORNIA”, “GERMANY”, “EU COUNTRY”, “RURAL HIGHWAY”, “POPULATION CENTER”, etc.), a jurisdiction value (e.g., a specific jurisdiction such as “FRANCE”, and/or a descriptive jurisdiction such as “EURO 6 EMISSIONS LOCATION”, “PRIVACY RULE 2 LOCATION”, etc.), a relative location value (e.g., a distance from a point, region, or boundary, etc.), and/or a defined geographic region value (e.g., “DELIVERY ROUTE 25”, within or outside a defined region, etc.).
  • a geographic location value e.g., GPS location information, and/or categorical information such as “UNITED STATES”, “CANADA”, “CALIFORNIA”, “GERMANY”, “
  • the example of Fig. 38 includes a vehicle data collection description 2714, having one or more vehicle data for collection 3516 values corresponding to one or more of the location description value(s) 3702.
  • Example vehicle data for collection 3516 values include one or more of: an end point or end point group 3504 to be utilized; data value(s) for collection 3506; a collected data formatting and/or processing description 3508; a collected data storage description 3510; a collected data transmission description 3512; and/or collected data priority value(s) 3514.
  • an example procedure 3900 for adjusting data collection in response to a location description value is schematically depicted.
  • the example procedure 3900 includes an operation 3902 to interpret a vehicle policy data value including a location description value, and an operation 3904 to generate a vehicle data collection description in response to the location description value.
  • the example procedure 3900 further includes an operation 3906 to collect vehicle data from end points of a vehicle in response to the vehicle data collection description.
  • an example operation 3904 includes adjusting collection of the vehicle data in response to the location description value - for example changing a baseline data collection operation based on a location of the vehicle.
  • an example operation 3904 includes adding or modifying metadata of the collected vehicle data in response to the location description value, for example adjusting a time stamp, tagging data, making a notation (e.g., processing operation or other adjustment to the data, based on adjustments made according to the location, and/or according to requirements related to the location to capture processing operations utilized).
  • a notation e.g., processing operation or other adjustment to the data, based on adjustments made according to the location, and/or according to requirements related to the location to capture processing operations utilized.
  • an example operation 3904 includes an operation to prevent collection of vehicle data (e.g., including just a portion of the vehicle data collected, or all of the vehicle data collected) in response to the location description value - where the operations to prevent collection of the vehicle data may include preventing any one or more operations in the collection cycle, such as requesting data from an end point (e.g., where the data is not ordinarily available, but the policy execution circuit 2708 retrieves it by requesting from a source end point), preventing the storage of the collected data (e.g., cache storage, buffering storage for external transmission, and/or storage of supporting information such as that utilized for trigger evaluations, historical data capture after an event, or the like), preventing related data and/or metadata collection, and/or preventing of external transmission of the data (and/or limiting transmission options, for example cellular data transmission).
  • vehicle data e.g., including just a portion of the vehicle data collected, or all of the vehicle data collected
  • the operations to prevent collection of the vehicle data may include preventing any one or more operations in
  • an example operation 3904 includes commencing collection of vehicle data in response to the location description value (and/or commencing any one or more operations of the collection cycle).
  • an example operation 3904 includes adjusting a priority value of at least a portion of the collected vehicle data in response to the location description value (e.g., a network utilization priority, data storage priority, and/or transmission priority).
  • a priority value e.g., a network utilization priority, data storage priority, and/or transmission priority.
  • an example apparatus 4500 is depicted to provide data collection operations in response to vehicle status data, and/or based upon a data type of the collected data. For example, operations of the apparatus 4500 include commencing, changing, and/or stopping data collection operations based on the data type of the vehicle status data.
  • operations of the apparatus 4500 allow for selected data collection, and/or adjustments of collected data, based on the data type of the vehicle status data, such as adjustments in response to a control data type (e.g., data utilized for mission execution of the vehicle and/or operating a mission related feature of the vehicle), a diagnostic data type (e.g., data utilized to diagnose operations of the vehicle, and/or in a longer term diagnostic learning operation for the vehicle and/or a group of vehicles), a performance data type (e.g., data utilized for improving performance of the vehicle, to adjust performance of the vehicle, to implement a performance rating for the vehicle, etc.), a monitoring data type (e.g., to monitor a driver, vehicle status, etc.), and/or an aggregated datatype (e.g., data that may be summarized, integrated with other data, summarized with other data, etc.).
  • a control data type e.g., data utilized for mission execution of the vehicle and/or operating a mission related feature of the vehicle
  • a diagnostic data type e.
  • Operations of the apparatus 4500 allow for adjustments to data collection responsive to how the data is to be utilized, the urgency of the data, the value of the data in view of degraded transmission performance (e.g., time delay before transmission, loss of some data resolution and/or time synching availability upon summarization, lossy compression, intermittent gaps, etc.) ⁇ Operations of the apparatus 4500 allow for protection of the collected data for high value loss events (e.g., protecting data that is both mission critical, and experiences a high loss of value with minor degradation in time, data resolution, and/or loss of continuous sequencing), while allowing degradation and/or loss of data that is low value and/or does not experience a high loss in value with some degradation.
  • high value loss events e.g., protecting data that is both mission critical, and experiences a high loss of value with minor degradation in time, data resolution, and/or loss of continuous sequencing
  • operations of the apparatus 4500 allow for the removal of data that has already experienced a high loss value - for example removing data that, due to degradation, is no longer worth resource utilization, in favor of other data that, despite degradation, retains significant value. It can be seen that the operations of apparatus 4500 protect system resources (e.g., intra-network communication resources, on-vehicle processing resources, on-vehicle memory resources, transmission resources, etc.) to maximize the value and utility of data collection operations.
  • system resources e.g., intra-network communication resources, on-vehicle processing resources, on-vehicle memory resources, transmission resources, etc.
  • apparatus 4500 protects higher value data (e.g., based on datatype and/or priority value(s) provided in the vehicle policy data value), but may also protect the overall value of data collected, for example keeping data that initially has a lower value, but due to degradation may retain a higher value than other data that initially had a higher value.
  • the example apparatus 4500 includes a policy acquisition circuit 2704 that interprets a vehicle policy data value 2710 including vehicle status data 4502 (e.g., any data available on the vehicle, and/or any data on the vehicle indicating a status such as an operating condition, diagnostic condition, operation of a feature, and/or data utilized by a service operation, diagnostic operation, and/or application to determine a status of the vehicle).
  • vehicle status data 4502 e.g., any data available on the vehicle, and/or any data on the vehicle indicating a status such as an operating condition, diagnostic condition, operation of a feature, and/or data utilized by a service operation, diagnostic operation, and/or application to determine a status of the vehicle.
  • any data value available from an end point on the vehicle may be, depending upon the context and the operations of the application, flow, feature, and/or external device utilizing the collected data, a value indicating a status of the vehicle and/or a status of an end point, feature, flow, and/or application of the vehicle.
  • the example apparatus 4500 further includes a policy processing circuit 2706 that generates parsed policy data in response to the vehicle policy data value 2710, where the parsed policy data includes a vehicle data collection description 2714.
  • the example apparatus 4500 further includes a policy execution circuit 2708 that collects vehicle data 2722 form end points 2716 on network zone(s) 2718, 2720 on the vehicle.
  • An example apparatus 4500 further includes a vehicle data transmission circuit 4504 that selectively transmits at least a portion of the collected vehicle data 2722, provided as transmitted collected data 4506 in the example, in response to a data type 4508 of the collected vehicle data 2722.
  • Example operations to selectively transmit the collected vehicle data 2722 include prioritizing transmission resources according to the vehicle data type(s) 4508, providing selected storage on-vehicle for collected vehicle data 2722, providing an opportunistic transmission of data (e.g., when detecting connection to a WiFi, coupled Ethernet service tool, or other low cost transmission element), deleting stored collected vehicle data 2722 that has not been transmitted (e.g., based on collected data storage needs, priority of competing collected data for the storage, and the remaining value of the stored data), and/or reducing a storage impact of the collected vehicle data 2722 (e.g., replacing a portion of the data with a summarized data segment, an aggregated data segment, a compressed data segment, etc.).
  • a storage impact of the collected vehicle data 2722 e.g., replacing a portion of the data with a summarized data segment, an aggregated data segment, a compressed data segment, etc.
  • the vehicle data type 4508 provides an indication of the value of the data based on resolution (e.g., loss of data resolution - such as in bit depth, precision, and/or time resolution such as sampling rate and/or synchronization data matching - may have a higher utility cost for certain data types such as control data, and a lower cost for certain data types such as monitoring data), preservation of sequential data segments (e.g., continuous data sequences without time gaps may be high value for certain data types, and not of significant value for other data types), time to transmission (e.g., some data may be highly valuable if transmitted almost immediately, but of little value if transmitted later, while other data may retain value regardless of the transmission time, or over an extended range of transmission times such as within a few hours, within a day, within a week, etc.), summarization effects (e.g., an average value over a period of time, during a selected event, etc., may be of high value for some data types, but of low value for other data types), and/or compression effects (
  • Example and non-limiting data types may include a control data type; a diagnostic data type; a performance data type; a monitoring data type; or an aggregated data type.
  • the example data types are non-limiting, and any data type may be utilized, for example including a data type associated with the data structure of the data (e.g., string, floating point value, Boolean value, single precision value, double precision value, integer, etc.), and/or a data type associated with the data request in the vehicle policy data value 2710 (e.g. - “MAINTENANCE”, “FUEL ECONOMY”, “FINANCE”, etc.) allowing for a scheduled behavior of collected data transmission according to any selected criteria.
  • a data type associated with the data structure of the data e.g., string, floating point value, Boolean value, single precision value, double precision value, integer, etc.
  • a data type associated with the data request in the vehicle policy data value 2710 e.g. - “MAINTENANCE”, “FUEL ECONOMY”,
  • the vehicle policy data value 2710 further includes a description of the data value (e.g., a quantitative description, qualitative description, ordering of data value, etc.), and/or a description of the loss of data value based on certain degradation events (e.g., time delay, intermittency gaps, compression losses, summarization losses, etc.).
  • a description of the data value e.g., a quantitative description, qualitative description, ordering of data value, etc.
  • certain degradation events e.g., time delay, intermittency gaps, compression losses, summarization losses, etc.
  • the vehicle policy data value 2710 further includes specific operations that may result in degradation of value for data types, which may define acceptable operations and/or a description of losses (e.g., send within 60 minutes of collection), and/or value descriptions associated with such operations (Example 1: send within 1 minute, and data retains a value of 100 units; send within 60 minutes, and data retains a value of 75 units; and send within 1 day and data retains a value of 35 units;
  • specific operations that may result in degradation of value for data types, which may define acceptable operations and/or a description of losses (e.g., send within 60 minutes of collection), and/or value descriptions associated with such operations (Example 1: send within 1 minute, and data retains a value of 100 units; send within 60 minutes, and data retains a value of 75 units; and send within 1 day and data retains a value of 35 units;
  • Example 2 native collected data sent retains a value of 100 units, compression 1 lossless retains the value of 100 units, compression 2 lossy with 8-bit quantization retains a value of 30 units, and compression 3 lossy with 24-bit quantization retains a value of 55 units;
  • Example 3 consecutive lossless sequences of at least 30 seconds are value 100, consecutive lossless sequences of at least 10 seconds are value 50, and sequences of less than 5 seconds are value 0).
  • transmission of collected data may be performed in a priority order for the stored collected vehicle data 2722 (e.g., always transmit highest priority data when available, with priority defined in the vehicle policy data value 2710 and/or according to the vehicle data type 4508, and/or with weighted scheduling based on priority), and/or scheduling of operations that may result in degradation of value may be performed in priority order (e.g., protecting higher priority collected vehicle data 2722 before lower priority data) and/or in lost value order (e.g., protecting collected vehicle data 2722 where operations that may result in degradation will incur a greater loss in the value of the collected vehicle data 2722).
  • priority order e.g., protecting higher priority collected vehicle data 2722 before lower priority data
  • lost value order e.g., protecting collected vehicle data 2722 where operations that may result in degradation will incur a greater loss in the value of the collected vehicle data 2722.
  • aggregated and/or weighted loss of value may be considered by the vehicle data transmission circuit 4504 - for example where operations (e.g., deletion, compression, summarization, etc.) on a single block of collected vehicle data 2722 may result in a high loss of value, but will protect an even greater loss of value (e.g., where a number of other blocks of collected vehicle data 2722 are thereby protected, even where individually they may each exhibit a smaller loss of value, but protected together preserve more value than is lost by the single block).
  • portions of a block of collected vehicle data 2722 may be protected - for example preserving a five minute continuous chunk of collected data, but deleting the rest.
  • value descriptions for collected vehicle data 2722 may be weighted according to the amount of data, the number of parameters in the data, and/or the data type (and/or data types) represented in the data - for example a 50 kb block of data may have less weighted value than a similar 100 kb block of data (e.g., having a similar priority value expressed in the vehicle policy data value 2710 and/or a similar data type or mix of data types).
  • the policy execution circuit 2708 determines the datatype of the collected vehicle data 2722 in response to one or more of: an end point providing an associated vehicle data (e.g., a source end point for the collected vehicle data 2722); an end point requesting the associated vehicle data; an entity requesting the associated vehicle data (e.g., an entity associated with an external device providing the vehicle policy data value 2710 or relevant portion thereol); an application associated with an end point providing the associated vehicle data (e.g., if the end point is part of a fueling control operation, the data type may be determined to be a control data type); an application associated with a request of the vehicle data; a flow associated with an end point providing the associated vehicle data; a flow associated with a request of the vehicle data; and/or an indicated data type provided in the vehicle policy data value 2710 for the collected vehicle data 2722.
  • an end point providing an associated vehicle data e.g., a source end point for the collected vehicle data 2722
  • an end point requesting the associated vehicle data e.g.,
  • an example vehicle status data 4502 includes one or more data types such as a control data type, a diagnostic data type, a performance data type, a monitoring data type, and/or an aggregated data type.
  • the example data types are non- limiting and illustrative.
  • the example of Fig. 46 includes a vehicle data collection description 2714 having associated operations of the data collection cycle corresponding to each data type.
  • vehicle data for collection 3516 associated with one or more of: an end point or end point group 3504 to be utilized; data value(s) for collection 3506; a collected data formatting and/or processing description 3508; a collected data storage description 3510; a collected data transmission description 3512; and/or collected data priority value(s) 3514.
  • an example procedure 4700 to schedule data collection in response to a data type of the collected data is schematically depicted.
  • the example procedure 4700 includes an operation 4702 to interpret a vehicle policy data value including vehicle status data, and an operation 4704 to generate a vehicle data collection description in response to the vehicle policy data value.
  • the example procedure 4700 further includes an operation 4706 to collect vehicle data from end points of the vehicle in response to the vehicle data collection description.
  • an example operation 4704 includes an operation to adjust the collection of the vehicle data in response to data type(s) of the collected vehicle data.
  • an example operation 4704 includes an operation to commence collection of vehicle data in response to data type(s) of the data to be collected. Referencing Fig.
  • an example operation 4704 includes an operation to prevent collection of vehicle data in response to data type(s) of the data to be collected - for example where transmission of the data is not possible and the data cannot be stored, and/or in response to an operating condition of the vehicle whereby data of a particular data type is not to be collected (e.g., tagging a data type that should not be collected during certain operating conditions, in a specific location, etc.).
  • an example operation 4704 includes an operation to add and/or modify metadata of collected vehicle data in response to a data type of the collected data - for example to add time stamp information, source identifying information, network address information, and/or to translate these, in response to a data type of the collected data.
  • an example operation 4704 includes an operation to adjust a priority value of collected vehicle data in response to data type(s) of the collected data.
  • the example procedure 5300 includes an operation 5302 to determine data type(s) of the collected vehicle data.
  • the operation 5302 may be determined in response to the vehicle policy data value 2710 - for example utilizing a defined data type in the policy, and/or determining the data type according to the end points, applications, flows, entities, etc. that are either providing or requesting the data.
  • the operation 5302 may be determined after the data collection, for example determining from the collected vehicle data 2722 the source(s) providing the elements of the collected vehicle data 2722.
  • the example procedure 5300 further includes an operation 5304 to configure the vehicle data collection description and/or data collection operations in response to the data types, where the data collection operations may relate to any aspect of the collection cycle (e.g., utilization of on-vehicle network transmission resources, data storage resources, data formatting and/or processing resources, and/or off-vehicle transmission resources).
  • an example operation 5302 includes determining data type(s) based on a providing end point for the collected data.
  • an example operation 5302 includes determining datatype(s) based on a requesting end point for the collected data.
  • an example operation 5302 includes determining data type(s) based on a requesting entity for the collected data.
  • an example operation 5302 includes determining datatype(s) based on an application associated with an end point providing the collected data.
  • an example operation 5302 includes determining datatype(s) based on a flow associated with an end point requesting the collected data.
  • an example operation 5302 includes determining data type(s) based on a flow associated with an end point providing the collected data.
  • an example operation 5302 includes determining data type(s) based on an application associated with an end point requesting the collected data.
  • an example operation 5302 includes determining datatype(s) based on a data type indicated in the policy.
  • a given block of the collected data may include data provided from a number of end points, and/or include multiple associated flows, applications, and/or other prioritizing and/or data typing information.
  • a highest priority and/or most important one of the associated end points, flows, applications, and/or indicated data type(s) may be utilized to determine data collection operations for the given block of the collected data.
  • a weighted priority and/or data type value may be utilized (e.g., if 60% of the data is of a high priority data type, then weight the priority of the block at 60% of the high priority data type), and/or a most common or descriptive priority and/or datatype value may be utilized (e.g., if 60% of the data is of a high priority data type, then treat the data block as the high priority data type).
  • a most common or descriptive priority and/or datatype value may be utilized (e.g., if 60% of the data is of a high priority data type, then treat the data block as the high priority data type).
  • Fig. 62 depicts an example collected data priority value 3514, including an on-vehicle data storage priority 6202, a transmission priority 6204, and/or an on-vehicle transmission priority 6206.
  • on-vehicle storage resources may include: memory allocations and/or stored values utilizing memory; resources utilized to delete, move, compress, and/or summarize stored data; and/or resources to determine memory allocation, to update memory allocation (e.g., based on collected data amounts relative to estimated data amounts to be collected), and/or to track expiration times and/or aging of stored data.
  • off-vehicle transmission resources may include: bandwidth utilization of external data transfer components (e.g., cellular data routes, Ethernet data routes, WiFi data routes, and/or other network data routes such as CAN communications); data capacity limitations (e.g., capped data amounts; data amounts associated with an entity, application, flow, etc.; and/or data amounts associated with an access point name (APN)); and/or power utilization associated with external data transfer (e.g., at any time, and/or during certain operating conditions such as when a prime mover of the vehicle is not providing power and battery power may be utilized for external data transfer).
  • bandwidth utilization of external data transfer components e.g., cellular data routes, Ethernet data routes, WiFi data routes, and/or other network data routes such as CAN communications
  • data capacity limitations e.g., capped data amounts; data amounts associated with an entity, application, flow, etc.; and/or data amounts associated with an access point name (APN)
  • power utilization associated with external data transfer e.g., at any time, and/or
  • on-vehicle transmission resources may include: bandwidth utilization of one or more network zones; allowed utilization of a network zone for a given end point, flow, application, etc.; latency management of communications on a network zone, including competition for low latency communications; and/or resource utilization of an inter-network device (e.g., a CEG, CES, and/or CND).
  • an inter-network device e.g., a CEG, CES, and/or CND
  • an example on-vehicle data storage priority 6202 includes one or more of: memory allocation priorities 6302, including for buffer capacity, cache capacity, short-term memory capacity, and/or long-term memory capacity; expired data treatment priority 6304, including for management operations of expired data, processing of expired data, and management of data lifetime tracking and comparisons to expiration times; and/or data expiration priorities 6306, including determining the order of expired data management, loss of value associated with expired data management, and the like.
  • memory allocation priorities 6302 including for buffer capacity, cache capacity, short-term memory capacity, and/or long-term memory capacity
  • expired data treatment priority 6304 including for management operations of expired data, processing of expired data, and management of data lifetime tracking and comparisons to expiration times
  • data expiration priorities 6306 including determining the order of expired data management, loss of value associated with expired data management, and the like.
  • an example transmission priority 6204 includes one or more of: transmission priority based on limited competing transmission resources 6402; transmission priority based on available transmission routes 6404 (e.g., cellular transmission may have a first priority set, and WiFi transmission may have a different priority set); transmission priority based on intermittent connectivity 6406 (e.g., high connectivity operating periods may have a first priority set, low connectivity periods may have a second priority set, and intermittent connectivity periods may have a third priority set); and/or transmission priority based on vehicle operating conditions 6408 (e.g., running at rated power, shutdown operations, startup operations, idling operations, etc. may each have a distinct priority set for transmission of collected data).
  • transmission priority based on limited competing transmission resources 6402 e.g., transmission priority based on available transmission routes 6404 (e.g., cellular transmission may have a first priority set, and WiFi transmission may have a different priority set); transmission priority based on intermittent connectivity 6406 (e.g., high connectivity operating periods may have a first priority set, low connectivity periods may have
  • an example on-vehicle transmission priority 6206 includes one or more of: an on-vehicle transmission priority (OVTP) based on limited network zone resources 6502 (e.g., bandwidth, utilization, low latency messaging slots, etc.); OVTP based on bandwidth 6504 (e.g., absolute or relative bandwidth allowed for the respective data, current bandwidth utilization and/or availability on the network zone, etc.); OVTP based on utilization of the network zone and/or converging devices 6506 passing parameters between network zones (e.g., capability of a CES, CEG, and/or CND to manage message transfer, and/or related resources such as message processing resources to prepare messages from a first network zone for utilization on the second network zone, buffering and/or caching memory to support intra-network message transfers, etc.); and/or OVTP based on latency parameters 6508 (e.g., where a network zone supports a limited number of low latency messages, where network zone traffic levels threaten the latency performance of high priority messages, etc.).
  • an example apparatus 6600 is depicted to provide data collection operations in response to vehicle status data, which are dynamically changeable, and/or which may be adjusted based on geography, jurisdiction, and/or operating conditions of the vehicle. For example, operations of the apparatus 6600 may adjust data collection operations in response to a requested change, detected events, evaluated trigger conditions, and/or detection of predetermined vehicle operating conditions and/or a change in vehicle operating conditions.
  • the example apparatus 6600 operates similarly to apparatus 4500, with certain differences described here for purposes of illustration.
  • the apparatus 6600 may be included in a system having a vehicle with one or more network zones as described throughout the present disclosure, and aspects of the apparatus 6600 may be included, in whole or part, with any systems, devices, controllers, and/or apparatuses as set forth throughout the present disclosure. Additionally or alternatively, aspects of any systems, devices, controllers, and/or apparatuses set forth herein may be included, in whole or part, with apparatus 6600.
  • the example apparatus 6600 includes a vehicle status data adjustment circuit 6602 that interprets a vehicle status data collection change value 6604.
  • An example apparatus 6600 includes the policy execution circuit 2708 adjusting collection operations of the collected vehicle data 2722 in response to the vehicle status data collection change value 6604, and/or the vehicle data transmission circuit 4504 adjusting transmission operations of the collected vehicle data 2722 in response to the vehicle status data collection change value 6604.
  • the vehicle status data adjustment circuit 6602 determines the vehicle status data collection change value 6604 in response to a vehicle operating condition 6606.
  • An example vehicle operating condition 6606 may be a categorical and/or discrete value, such as a state condition (e.g., shutdown, moving, startup, idle, high load operation, low load operation, etc.). Additionally or alternatively, an example vehicle operating condition 6606 may be a quantitative and/or continuous value, such as a power throughput level, torque value, vehicle speed, etc.
  • a state condition e.g., shutdown, moving, startup, idle, high load operation, low load operation, etc.
  • an example vehicle operating condition 6606 may be a quantitative and/or continuous value, such as a power throughput level, torque value, vehicle speed, etc.
  • the vehicle status data adjustment circuit 6602 determines the vehicle status data collection change value 6604 in response to determining an event occurrence 6608 - for example based on a trigger condition, fault value, diagnostic code, or the like.
  • the vehicle status data adjustment circuit determines the event occurrence 6608 in response to one or more of: a fault condition value (e.g., whether a fault condition is present in the vehicle, for example a fault related to data collection of the respective parameters, a fault related to an associated flow and/or application for the data collection parameters, and/or a fault condition defined in the policy 2710 to adjust data collection); determining a fault count value (e.g., an intermediate value utilized before a fault condition is set, such as an incrementing, decrementing, and/or warning parameter, which may be published to a network zone or not); determining a diagnostic parameter value (e.g., a diagnostic code, an intermediate value for a diagnostic operation, etc.); a fault confirmation value (e.g., a state value indicating whether a fault is active, latent, recently active, pending confirmation, etc.); a diagnostic confirmation value (e.g., a state value determining a diagnostic condition, an intermediate value tending to confirm a diagnostic determination and
  • the vehicle policy data value 2710 can be utilized to collect additional data related to a fault and/or diagnostic occurrence, for example to determine whether fault and/or diagnostic determinations are operating well, whether they can be improved or optimized, to provide information for fault tree analysis and/or diagnostic root cause analysis, and the like.
  • the capabilities of apparatus 6600, and/or other systems and devices herein, provide for a capability to collect additional data before a fault condition and/or diagnostic operation are confirmed - for example due to the ability of the policy execution circuit 2708 to reach any end point on any network zone of the vehicle, and to collect data - such as intermediate control data that is not ordinarily available on any network zone - to begin collecting more data, earlier in the process, where fault determination and/or diagnostic operations have not completed.
  • Previously known systems provide a light and/or other notification in response to a fault being set or a diagnostic operation confirming that a problem exists, but by the time the notification is provided, the operations of the fault determination and/or diagnostic operation are already completed, and at best a short period of historical data can be captured.
  • Operations of the apparatus 6600 allow for data collection configured based upon intermediate fault values - for example increasing the data collected (e.g., sampling rates, number of parameters, etc.) by collecting data when a preliminary indication that a fault may be applicable appears in the data, and/or further increasing the data collected if the fault or diagnostic condition appears more likely (e.g., increasing data collection rates and/or parameters as an intermediate counter value increases toward a fault threshold), while maintaining a high likelihood that data collected will be relevant to the intended use of the collected data.
  • intermediate fault values for example increasing the data collected (e.g., sampling rates, number of parameters, etc.) by collecting data when a preliminary indication that a fault may be applicable appears in the data, and/or further increasing the data collected if the fault or diagnostic condition appears more likely (e.g., increasing data collection rates and/or parameters as an intermediate counter value increases toward a fault threshold), while maintaining a high likelihood that data collected will be relevant to the intended use of the collected data.
  • apparatus 6600 the data that can be collected by apparatus 6600 is improved, as data collection is not limited to available data on a network zone, allowing for deeper analysis of fault and diagnostic operations, quicker convergence on improved service procedures and/or fault tree analysis, and the like. Further still, the capabilities of apparatus 6600 allow for a single policy to be utilized on vehicles having different configurations - including network zone layout, end point distribution on network zones, a different distribution of controllers and control operations across end points, and/or data having a different configuration (e.g., units, sampling rate, parameter names, bit depth and/or resolution, etc.).
  • a different configuration e.g., units, sampling rate, parameter names, bit depth and/or resolution, etc.
  • a given policy utilized to collect data can represent a significant investment to determine which data should be collected, the timing of the data collection relative to the event, and the like, and the ability to re-use a given policy across a number of vehicle configurations significantly reduces the cost of fault and diagnostic execution and improvement across the entire system of vehicles.
  • the utilization of apparatus 6600 and other embodiments throughout the present disclosure for fault and diagnostic operations is an illustrative example to demonstrate various benefits of aspects of the present disclosure.
  • An example vehicle status data 4502 further includes a trigger condition, where the vehicle status data adjustment circuit 6602 determines the event occurrence 6608 in response to the trigger condition.
  • the trigger condition may be any trigger condition as set forth throughout the present disclosure, including at least: an event detection condition; a vehicle status value; and/or a vehicle operating condition value.
  • An example vehicle status data adjustment circuit 6602 further interprets the vehicle status data collection change value 6604 in response to a location description value, for example a location description value included as a part of the vehicle policy data value 2710.
  • the location description value includes at least one description such as: a geographic location value; a jurisdiction value; a relative location value; or a defined geographic region value.
  • the policy execution circuit 2708 is responsive to the vehicle status data collection change value 6604 to prevent collection of at least a portion of the vehicle data, to commence collection of at least a portion of the vehicle data, to adjust a formatting of at least a portion of the vehicle data, and/or to adjust a priority associated with at least a portion of the vehicle data, in response to the location description value.
  • an example procedure 6700 to dynamically configure data collection for a vehicle is schematically depicted.
  • the example procedure 6700 includes an operation 6702 to interpret a vehicle policy data value including vehicle status data, an operation 6704 to generate a vehicle data collection description in response to the vehicle policy data value, and an operation 6706 to collect vehicle data from end points of the vehicle in response to the vehicle data collection description.
  • the example procedure 6700 includes an operation 6708 to transmit at least a portion of the collected vehicle data, and an operation 6710 to determine a vehicle status least a portion of the collected vehicle data, and an operation 6710 to determine a vehicle status data collection change value.
  • the example procedure 6700 includes an operation 6712 to adjust a collection and/or transmission operation in response to the vehicle status data collection change value.
  • an example procedure 6710 to determine a vehicle status data collection change value including an operation 6802 to interpret a vehicle operating condition, and an operation 6804 to determine the vehicle status data collection change value in response to the vehicle operating condition.
  • an example procedure 6710 includes an operation 6902 to determine an event occurrence, and an operation 6904 to determine the vehicle status data collection change in response to the event occurrence.
  • an example procedure 6710 includes an operation 7002 to determine a location description value, and an operation 7004 to determine the vehicle status data collection change value in response to the location description value.
  • example operations 6712 to adjust collection and/or transmission of collected data values in response to the vehicle status data collection change value are depicted.
  • an example operation 6712 includes adjusting collection of vehicle data (e.g., parameters collected, collection rates, amount of data to be captured, timing of data capture, etc.) in response to the vehicle status data collection change value (e.g., as a vehicle status data adjustment).
  • an example operation 6712 includes commencing collection of vehicle data in response to the vehicle status data adjustment.
  • an example operation 6712 includes preventing collection of vehicle data in response to the vehicle status data adjustment.
  • an example operation 6712 includes adding and/or modifying metadata of collected vehicle data in response to the vehicle status data adjustment.
  • an example operation 6712 includes adjusting a priority value of collected vehicle data in response to the vehicle status data adjustment.
  • an example operation 6712 includes adjusting transmission of collected vehicle data in response to the vehicle status data adjustment.
  • an example operation 6712 includes adjusting data storage of collected vehicle data in response to the vehicle status data adjustment.
  • an example operation 6712 includes adjusting formatting and/or processing of collected vehicle data in response to the vehicle status data adjustment.
  • an example procedure 7900 to dynamically configure data collection for a vehicle is schematically depicted.
  • the example procedure includes an operation 7902 to determine a vehicle status data collection change value in response to a trigger condition and/or an event occurrence, and operation 6712 to adjust a collection and/or transmission operation of the collected vehicle data in response to the vehicle status data collection change value.
  • example operations 7902 to determine an event occurrence and/or a trigger condition are schematically depicted. Referencing Fig.
  • an example operation 7902 includes determining an event occurrence in response to fault data, for example determining that an event has occurred to change data collection and/or transmission in response to a fault being set, and/or an intermediate fault value (e.g., a fault counter, threshold value for data tending to indicate a fault, etc.).
  • an example operation 7902 includes determining an event occurrence in response to diagnostic data, for example determining that an event has occurred to change data collection and/or transmission in response to a diagnostic operation output value, intermediate value, and/or diagnostic code value.
  • an example operation 7902 includes determining an event occurrence in response to available vehicle data, including one or more collected vehicle data parameters, or another vehicle data parameter available from an end point of the vehicle.
  • an example operation 7902 includes an operation to monitor trigger evaluation data, and determine the event occurrence based on a trigger condition (e.g., provided in a policy) and the trigger evaluation data.
  • a trigger condition e.g., provided in a policy
  • an example apparatus 8400 to implement data collection utilizing a policy hierarchy is schematically depicted.
  • the example apparatus 8400 is disclosed in the context of data collection, but may be utilized to configure automated operations, triggered data collection, and/or any other policy based operations as set forth in the present disclosure.
  • the example apparatus 8400 depicts example policy types to illustrate aspects of the present disclosure, but the policy types depicted are illustrative and non- limiting. Embodiments may include some or all of the policy types depicted, other policy types, and/or more than one policy of a given type.
  • the example apparatus 8400 operates similarly to apparatus 4500, with certain differences described here for purposes of illustration.
  • the apparatus 8400 may be included in a system having a vehicle with one or more network zones as described throughout the present disclosure, and aspects of the apparatus 8400 may be included, in whole or part, with any systems, devices, controllers, and/or apparatuses as set forth throughout the present disclosure. Additionally or alternatively, aspects of any systems, devices, controllers, and/or apparatuses set forth herein may be included, in whole or part, with apparatus 8400.
  • the example apparatus 8400 includes a policy acquisition circuit 2704 that interprets a vehicle policy data value 2710.
  • the example of Fig. 84 includes one or more of a downloaded policy 8402, a factory policy 8404, and/or a built-in policy 8406, where the vehicle policy data value 2710 is constructed from one or more of the policies 8402, 8404, 8406.
  • the vehicle policy data value 2710 may utilize a selected one of the policies 8402, 8404, 8406 as the vehicle policy data value 2710, and/or the vehicle policy data value 2710 may be constructed using more than one of the policies 8402, 8404, 8406.
  • the policies 8402, 8404, 8406 are utilized in a hierarchy by, for example, utilizing, in order and if present, the downloaded policy 8402 as the vehicle policy data value 2710, the factory policy 8404 (e.g., if a downloaded policy 8402 is not present), and/or the built-in policy 8406.
  • the example utilizing a built-in policy, a factory policy, and a downloaded policy is illustrative and non-limiting.
  • An example includes the built-in policy 8406 provided on a vehicle controller (e.g., the CND, and/or any other controller having policy management operations provided thereupon) at a time of initial manufacture of the vehicle and/or a supply of the respective controller to a manufacturer of the vehicle, a factory policy 8404 provided on the vehicle controller at a later stage of manufacturing (e.g., by a vehicle manufacturer, an original equipment manufacturer, body builder, assembler, an entity configuring a vehicle for a particular application, and/or a dealer), and the downloaded policy 8402 provided any time thereafter - for example by a dealer, after the vehicle is in operation, and/or as an update operation for the policy.
  • a vehicle controller e.g., the CND, and/or any other controller having policy management operations provided thereupon
  • a factory policy 8404 provided on the vehicle controller at a later stage of manufacturing (e.g., by a vehicle manufacturer, an original equipment manufacturer, body builder, assembler, an entity configuring a vehicle for
  • the built-in policy includes certain functionality, such as bootloading, initialization operations, or the like, that allow the collection of basic data, implementation of policy updates, or the like.
  • basic functionality provided by a built-in policy 8406 is retained after other policies are implemented, and/or basic functionality may be implemented or replaced by a subsequent policy.
  • the higher level policies e.g., downloaded policy 8402 relative to the factory policy 8404 and/or built-in policy 8406) supersede the lower policies.
  • compatible portions of lower policies are retained, and the treatment of lower policies may vary (e.g., one of the factory policy 8404 and/or built-in policy 8406 includes at least a portion that is retained if compatible with a higher policy, where the other one of the factory policy 8404 and/or built-in policy 8406 is ignored, deprecated, and/or deleted when a higher policy is received).
  • a lower policy that is ignored or deprecated is revived in response to the removal and/or expiration of a higher policy.
  • a highest policy, and/or any other policy may additionally or alternatively be received by any relevant operations, including provision by a tool having a direct connection (e.g., a physical port coupled to a network zone of the vehicle), through a LAN or WiFi connection, using cellular communications, and/or through any other operations.
  • the downloaded policy 8402 may be received utilizing a replacement controller installed on a vehicle (e.g., as a service operation to replace a controller of the vehicle, wherein the replacement controller includes the downloaded policy 8402).
  • the policy structure may have additional levels in a hierarchy, and/or more than one policy at a given level of the hierarchy.
  • the assembly of the vehicle policy data value 2710, or portions thereof, occurs on a vehicle controller - for example where one or more, or all, of the policies 8402, 8404, 8406 are received by the policy acquisition circuit 2704, and the hierarchy is applied to provide a final on-vehicle policy data value 2710.
  • the vehicle policy data value 2710 is assembled externally to the vehicle, and passed to the policy acquisition circuit 2704 after assembly.
  • a combination of these is present - for example a vehicle policy data value 2710 is assembled and passed to the policy acquisition circuit 2704, and another downloaded policy 8402 (and/or vehicle policy data value 2710) is provided to the policy acquisition circuit 2704, which may replace and/or be added to the existing policy utilized on the vehicle.
  • a vehicle policy data value 2710 is assembled and passed to the policy acquisition circuit 2704, and another downloaded policy 8402 (and/or vehicle policy data value 2710) is provided to the policy acquisition circuit 2704, which may replace and/or be added to the existing policy utilized on the vehicle.
  • FIG. 85 an example apparatus 8500 for utilizing multiple policy types to exercise vehicle data collection or other operations herein (e.g., trigger evaluation and consequent operations, control of authorization for data access, service access, and/or data collection, etc.) is schematically depicted.
  • the example apparatus 8500 operates similarly to apparatus 4500, with certain differences described here for purposes of illustration.
  • the apparatus 8500 may be included in a system having a vehicle with one or more network zones as described throughout the present disclosure, and aspects of the apparatus 8500 may be included, in whole or part, with any systems, devices, controllers, and/or apparatuses as set forth throughout the present disclosure. Additionally or alternatively, aspects of any systems, devices, controllers, and/or apparatuses set forth herein may be included, in whole or part, with apparatus 8500.
  • the example of Fig. 85 includes a vehicle policy data value 2710 provided including one or more of a persistent policy 8502, a discrete (or limited) policy 8504, and a streaming policy 8506.
  • the persistent policy 8502 sets forth data collection operations, or other operations, that exist on the vehicle on an ongoing basis, for example operating to collect data (and/or to check conditions for data collection) on an ongoing basis, for intermittent storage as collected vehicle data 2722, and transmission as transmitted collected data 4506 (e.g., according to priority values and/or other operations set forth herein).
  • the example discrete policy 8504 sets for data collection operations, or other operations, that exist on the vehicle for execution over a selected time period, a selected number of operations, or the like.
  • a discrete policy 8504 may be configured to collect a specific set of data a single time, and/or to perform certain operations a single time (e.g., to open a door, start the vehicle, confirm an owner identity, etc.). After the selected number of executions, and/or expiration of the valid time frame, the discrete policy 8504 may be ignored, deprecated, and/or deleted.
  • the example streaming policy 8506 sets forth data collection operations, or other operations, that exist on the vehicle either on an ongoing basis, for a selected time period, or the like, that provides transmits vehicle data 2722 immediately, or as soon as available, during operations pursuant to the streaming policy 8506.
  • either a persistent policy 8502 or a discrete policy 8504 having a high transmission priority value may operate effectively in the same manner, and in certain embodiments a streaming policy 8506 is implemented as another policy type having a high transmission priority value.
  • the description including the persistent policy 8502, discrete policy 8504, and/or streaming policy 8506 is illustrative to demonstrate operations of certain embodiments.
  • the policy acquisition circuit 2704 replaces a previous policy with an updated vehicle policy data value 2710, and/or replaces a previous policy with the updated vehicle policy data value 2710.
  • the vehicle policy data value 2710 includes a data field or other implementing information that sets forth whether the policy should replace a previous policy, and/or to be appended to and/or utilized in addition to the previous policy.
  • the data field or other implementing information is checked against an authorization of the policy provider (e.g., an entity providing the vehicle policy data value 2710 and/or one or more of the policies 8502, 8504, 8506) before implementing the updated policy.
  • treatment of the policy types is distinct - for example a discrete policy 8504 and/or streaming policy 8506 may be always appended, and/or the persistent policy 8502 may selectively replace, append, and/or be added in parallel to a previous policy.
  • the described operations are non-limiting examples.
  • the procedure 8600 includes an operation 8602 to interpret a vehicle policy data value, an operation 8604 to generate a vehicle data collection description, an operation 8608 to collect vehicle data from end point(s) of a vehicle in response to the vehicle data collection description, and an operation 8608 to transmit at least a portion of the collected vehicle data.
  • Operations of procedure 8600 may be performed in response to a hierarchy of policies (e.g., reference Fig. 84 and the related description) and/or in response to a number of policy types (e.g., reference Fig. 85 and the related description).
  • a hierarchy of policies e.g., reference Fig. 84 and the related description
  • a number of policy types e.g., reference Fig. 85 and the related description.
  • an example procedure 8700 for implementing policy execution on a vehicle is schematically depicted.
  • the procedure 8700 includes operation 8702 to determine policy type(s) provided to the vehicle, and operation 8704 to generate a vehicle data collection description based on the policy types.
  • the operations 8702, 8704 may be combined as an operation 8604 to generate a vehicle data collection description.
  • the example procedure 8700 further includes an operation 8706 to determine whether policy collection is active (e.g., if data collection pursuant to a policy is active, and/or monitoring for potential data collection pursuant to the policy is active), and operation 8708 to collect vehicle data in response to the vehicle data collection description if the operation 8706 determines YES.
  • the operations 8706, 8708 may be combined as an operation 8606 to collect data from end points of a vehicle in response to the vehicle data collection description.
  • the example procedure 8700 includes operation 8710 to determine if the inactive policy should be deleted - for example if a replaced policy, expired policy, resolved discrete policy, and/or a discrete and/or streaming policy having a time frame that has elapsed.
  • the procedure 8700 includes an operation 8608 to transmit at least a portion of the collected vehicle data, for example in response to collected data from operation 8708, and/or in response to data previously collected for the inactive policy that has not been transmitted yet.
  • the example procedure 8700 includes an operation 8712 to delete a policy and/or inactive portions of the policy, for example in response to operation 8710 determining YES.
  • the operations of procedure 8700 may be configured to retain an inactive policy until data collected pursuant to the inactive policy have been transmitted. Additionally or alternatively, the inactive policy may be deleted, and the data collected pursuant to the inactive policy may be transmitted at a later time.
  • an illustrative utilized policy hierarchy 8802 is schematically depicted.
  • a downloaded policy 8402 is utilized if present
  • a factory policy 8404 is utilized if present and if the downloaded policy 8402 is not present
  • a built-in policy 8406 is utilized if present, and if neither the downloaded policy 8402 or factory policy 8404 are present.
  • another illustrative utilized policy hierarchy 8802 is schematically depicted. In the example of Fig.
  • the built-in policy 8406 includes a compatible portion 8902 with the factory policy 8404 and the downloaded policy 8402
  • the factory policy 8404 includes a compatible portion 8904 with the downloaded policy 8402
  • the final utilized policy includes the downloaded policy 8402 combined with the appended compatible portions 8904, 8902 of the factory policy 8404 and the built-in policy 8406.
  • the example of Fig. 89 is illustrative, and for purposes of clarity the compatible portion 8902 of the built-in policy 8406 is depicted as compatible with both of the factory policy 8404 and the downloaded policy 8402.
  • a portion of the built-in policy 8406 may be compatible with only one of the factory policy 8404 or the downloaded policy 8402, where only the compatible portions with both of the factory policy 8404 and the downloaded policy 8402 appended in the final policy.
  • the example of Fig. 89 depicts appending the compatible portions of lower policies for clarity of the description.
  • the policy processing circuit 2706 may utilize compatible portions to construct the vehicle data collection description 2714, without compiling a final policy having appended portions.
  • the policy processing circuit 2706 may provide the vehicle data collection description 2714 to implement the downloaded policy 8402, and the compatible portions of the lower policies, without constructing the appended final policy.
  • an illustrative utilized policy hierarchy 8802 is schematically depicted, with a number of downloaded policies 8402, 90002, 9004 utilized in the construction of a final policy and/or the vehicle data collection description 2714. In the example, the lower policies may be ignored and/or utilized in compatible portions.
  • an example utilized policy hierarchy 8802 is schematically depicted, having a number of high level policies, such as one or more persistent policies 9102, one or more discrete policies 9104, and/or streaming policies 9106.
  • the utilized policy hierarchy 8802 may be a compiled version of the policies 9102, 9104, 9106, and/or a vehicle data collection description 2714 constructed utilizing the policies 9102, 9104, 9106.
  • the policies 9102, 9104, 9106 may be provided within a policy hierarchy, for example where all of the policies 9102, 9104, 9106 are treated as a downloaded policy 8402 and/or a highest level policy.
  • the policies 9102, 9104, 9106 may have a hierarchy therebetween, for example determined according to a priority value and/or authorization value associated with an entity, device, flow, application, or the like providing the policy, where higher ones of the policies 9102, 9104, 9106 supersede lower ones of the policies, and/or where compatible portions of the lower ones of the policies are implemented.
  • the utilized policy hierarchy 8802 may further include lower policies such as a factory policy 8404, a built-in policy 8406, where the lower policies 8404, 8406 may be ignored and/or utilized in compatible portions.
  • a discrete policy 9104 and/or streaming policy 9106 is provided that is incompatible with a portion of a lower policy 8404, 8406, where the incompatible portion is ignored during operations pursuant to the higher level policy 9104, 9106 and revived after the higher level policy 9104, 9106 is resolved (e.g., data collection operations are completed, the relevant implementation time expires, and/or the higher level policy 9104, 9106 is deleted 8712).
  • the example procedure 9200 includes an operation 9202 to interpret a vehicle policy data value, an operation 9204 to update a data collection policy in response to the vehicle policy data value (e.g., appending an update to the policy, providing the added policy as an additional policy to be implemented, and/or deleting a previous policy).
  • the example procedure 9200 further includes an operation 9206 to generate a vehicle data collection description in response to the updated data collection policy, an operation 9208 to collect vehicle data responsive to the vehicle data collection description, and an operation 9210 to transmit at least a portion of the collected vehicle data.
  • the example procedure 9300 includes an operation 9302 to determine whether a downloaded policy is present on the vehicle, and an operation 9306 to generate a vehicle data collection description in response to operation 9302 determining YES.
  • the example procedure 9300 includes an operation 9304 to determine whether a factory policy is present, and an operation 9308 to generate the vehicle data collection description in response to operation 9304 determining YES.
  • the example procedure 9300 includes an operation 9310 to generate the vehicle data collection description in response to a built-in policy, in response to operation 9304 determining NO.
  • the example operations of procedure 9300 utilize a highest level policy as the policy, but may be adjusted to implement compatible portions of one or more of the lower level policies.
  • an example procedure 9400 to implement a policy hierarchy is depicted.
  • an operation 9402 determines whether compatible portions of a factory policy are present in response to determination YES from operation 9302.
  • operation 9404 include adding compatible portions of the factory policy to the implemented policy, and operation 9406 to determine whether compatible portions of the built-in policy are present in response to any one of: operation 9404, operation 9402 determining NO, and/or operation 9304 determining YES.
  • the example procedure 9400 includes operation 9412 to generate the vehicle data collection description in response to the built-in policy, for example where neither the downloaded policy or the factory policy are present.
  • the example procedure 9400 includes operation 9410 to generate the vehicle data description in response to the implemented policy, excluding the built-in policy, in response to operation 9406 determining NO.
  • the example procedure 9400 includes operation 9408 to add compatible portions of the built-in policy to the implemented policy, and operation 9410 to generate the vehicle data description in response to the implemented policy, in response to operation 9406 determining YES.
  • an example apparatus 9500 for performing data collection operations utilizing a shared storage for collected data is schematically depicted.
  • the example apparatus 9500 operates similarly to apparatus 4500, with certain differences described here for purposes of illustration.
  • the apparatus 9500 may be included in a system having a vehicle with one or more network zones as described throughout the present disclosure, and aspects of the apparatus 9500 may be included, in whole or part, with any systems, devices, controllers, and/or apparatuses as set forth throughout the present disclosure. Additionally or alternatively, aspects of any systems, devices, controllers, and/or apparatuses set forth herein may be included, in whole or part, with apparatus 9500.
  • the example apparatus includes a parameter acquisition circuit 9502 that interprets a number of vehicle parameter values 9510 responsive to requested vehicle property (ies)
  • the example apparatus 9500 further includes a parameter storage circuit 9504 that selectively stores at least a portion of the vehicle parameter values 9510, where at least a first portion of the stored vehicle parameter values 9514 are stored on a storage end point 9508 that is distinct from a providing end point for the stored vehicle parameter values 9514. In certain embodiments, all of the stored vehicle parameter values 9514 are stored on a single end point.
  • the utilization of shared storage for collected data parameters can be used to consolidate capabilities in the system, providing for a few (or one) high capability storage resources in the system, reducing overall costs and complexity to manage storage of data collection parameters.
  • the shared storage may be a general storage capable of storing any type of data from any ECU and/or applications. Additionally or alternatively, processing capability can be consolidated into a few (or one) high capability processing resource, which may be provided on controllers having high memory capability as well.
  • the utilization of shared storage is supported by the ability of the parameter acquisition circuit 9502 to reach and move data from any end point on any network zone, while maintaining security, for example utilizing operations of a CEG, CES, CND, or the like.
  • data at rest in the system e.g., buffered data, cached data, stored vehicle parameter values, policy information and/or parsed policy data, and the like
  • the management of encrypted stored data is simplified with a reduced number of storage resources utilized in the system.
  • shared storage may be provided by a single controller having memory resources, which may include a controller having policy management components such as the policy acquisition circuit 2704 and the like. However, the shared storage may be distributed across several controllers, and/or may be included separately from a controller having policy management components. In certain embodiments, policy management components are distributed, in whole or part, across several controllers, and may be provided partially on a controller having shared storage resources, or independently from a controller having shared storage resources. Controllers having shared storage resources are coupled to the system as end points of a network zone of the vehicle, and in certain embodiments controllers having policy management components are themselves end points of a network zone of the vehicle.
  • Operations of the controller 2702 are capable to manage shared memory resources, including providing memory allocation provided for data collection operations, buffering and caching of parameter values, expiration of stored data, transmission of stored data, and/or reallocation of memory based on changes in a policy, observed data collection operations, and the like.
  • the allocation of memory resources may consider the amount of data to be collected to support policy collection operations, supporting data such as rolling buffer data (e.g., to capture historical data, perform trigger analysis, and the like), trigger evaluation data, conditionally stored data that may be sent upon request, the network zone location(s) of end points providing data and having shared storage resources (e.g., to determine on-vehicle network communication impacts in determining data generation and data storage locations), and transmission impacts for on-vehicle networks when the collected data is transmitted as transmitted collected data 4506.
  • data such as rolling buffer data (e.g., to capture historical data, perform trigger analysis, and the like), trigger evaluation data, conditionally stored data that may be sent upon request, the network zone location(s) of end points providing data and having shared storage resources (e.g., to determine on-vehicle network communication impacts in determining data generation and data storage locations), and transmission impacts for on-vehicle networks when the collected data is transmitted as transmitted collected data 4506.
  • a shared storage resource that requires fewer on-vehicle network resources to transmit may be selected to store the vehicle parameters that are likely to be transmitted, where a shared storage resource that requires more on-vehicle network resources to transmit (e.g., where the data is transferred from one network zone to another network zone before it can be transmitted) may be utilized for trigger evaluation data, intermediate data used for calculations and/or virtual parameter determinations, rolling buffer data where a large majority of the data is iteratively re-written, and only occasionally or never transmitted unless an event occurs, and/or any other type of data that is less likely to be transmitted, or that is a type of data that is never transmitted.
  • data having a lower priority value and/or having a low value loss indication in response to memory management operations may be stored on a shared memory resource having a relatively higher transmission cost, since such data is more likely to be reduced through memory management operations before transmission than other data having a higher priority and/or higher value loss due to memory management operations.
  • An example parameter storage circuit 9504 selectively stores the at least a portion of the plurality of vehicle parameter values 9514 on a single storage end point 9508.
  • An example storage management circuit 9506 determines a parameter transmission schedule 9516 for stored vehicle parameter values, and the parameter storage circuit 9504 selectively stores the at least a portion of the plurality of vehicle parameter values 9514 in response to the parameter transmission schedule 9516.
  • the parameter transmission schedule 9516 may include estimated values for data collection operations to service aspects of the policy (or policies), and may further include estimated transmission times, data residence times, or the like, to determine memory allocation values to support the data collection operations.
  • the transmission schedule 9516 is defined in the vehicle policy data value 2710, and/or determined in response to data in the vehicle policy data value 2710 - for example according to transmission time constraints, time delay cost descriptions, priority values, or the like. Accordingly, the parameter storage circuit 9504 can determine which data collection operations require memory support, the amount of memory to support each operation, and select locations for the storage end points 9508 (e.g., where more than one shared storage resource is available) that protect the value of the data, reduce transmission costs, and preserve on-vehicle network resources to support other functions of the vehicle.
  • An example apparatus 9500 includes the storage management circuit 9506 determining a parameter expiration schedule 9518 for stored vehicle parameter values 9514, for example as defined in the policy, determined according to a data type of the respective collected data, and/or determined according to a loss value for the data based on time and/or likely memory management operations that will be performed on the data based on expected transmission delays (including consideration for uncertainties in the transmission delays).
  • the example parameter storage circuit 9504 further selectively stores the at least a portion of the plurality of vehicle parameter values 9514 in response to the parameter expiration schedule 9518, for example adjusting allocated memory values, selected storage end points 9508, or the like.
  • Example operations of the parameter storage circuit 9504 to the parameter expiration schedule 9518 include operations such as: deleting at least a portion of the stored vehicle parameter values 9514 (e.g., after determining that the parameters have expired); summarizing at least a portion of the stored vehicle parameter values (e.g., storing a reduced form of the stored vehicle parameters 9514, such as a statistical description, average value, qualitative description, bucketed data description, etc.); compressing at least a portion of the stored vehicle parameter values; and/or adjusting a reserved memory amount 9520 associated with at least a portion of the stored vehicle parameter values 9514. Any other memory management operations as set forth throughout the present disclosure are also contemplated as operations of the parameter storage circuit 9504 to the parameter expiration schedule 9518.
  • An example parameter storage circuit 9504 determines the reserved memory amount 9520 (e.g., memory allocation values on the storage end points 9508) associated with at least a portion of the plurality of vehicle parameter values, and selectively stores the at least a portion of the plurality of vehicle parameter values 9514 in response to the reserved memory amount 9520.
  • the reserved memory amount 9520 e.g., memory allocation values on the storage end points 9508
  • certain storage amount determinations depend upon the formatting and/or processing that is applied to the data, and determining the storage amount may consider how and when the formatting and/or processing is performed. For example, down-sampling operations reduce the number of data values utilized to capture a specified stream of data (e.g., a 10 second segment of data), and in certain embodiments down sampling processing may be performed before the data is stored. In another example, up sampling operations increase the number of data values utilized to capture a specified stream of data, which may be performed after storage of the initial data to preserve memory storage for collected data.
  • down-sampling operations reduce the number of data values utilized to capture a specified stream of data (e.g., a 10 second segment of data), and in certain embodiments down sampling processing may be performed before the data is stored.
  • up sampling operations increase the number of data values utilized to capture a specified stream of data, which may be performed after storage of the initial data to preserve memory storage for collected data.
  • the up-sampling operations would be performed before the data is transmitted, and/or the up-sampling operations may be performed by an off- vehicle processing resource before the transmitted data is provided to an end user and/or placed in cloud storage.
  • certain types of processing such as frame removal or reduction, bit depth reduction, precision reduction (e.g., converting a double precision floating point value to a single precision floating point value), and/or certain lossless compression operations (e.g., storage of consistent values such as a parameter name value in a single location or a few locations, rather than with every data value) reduce storage resources and utilize few processing resources, and may be performed before storage of the data values.
  • certain types of processing such as frame addition or enhancement, bit depth increases, and/or precision increases, increase the stored data value size, allowing for a selection between processing as-needed (e.g., to minimize storage size), selectively processing (e.g., in batches when processing resources on the vehicle are in a relatively low utilization period - such as during shutdown operations, idle operations, steady state operations, or the like) which may preserve responsiveness when a transmission opportunity occurs but reduce the overall storage impact of the collected data, and/or transfer of processing to off-vehicle resources (e.g., processing operations performed by an off- vehicle resource before providing to an end user and/or placing in a cloud storage).
  • processing as-needed e.g., to minimize storage size
  • selectively processing e.g., in batches when processing resources on the vehicle are in a relatively low utilization period - such as during shutdown operations, idle operations, steady state operations, or the like
  • off-vehicle resources e.g., processing operations performed by an off- vehicle resource before providing to an end user and/
  • the storage management circuit 9506 is capable to determine the characteristics of the system, including on-vehicle network communication resources, storage resources, processing resources and availability based on vehicle operating conditions, availability of transmission resources (including estimated time gaps between transmission opportunities, amount of data transmitted during transmission opportunities, etc.), availability of off-vehicle processing resources for formatting and/or processing data values, and the like, to determine values of the reserved memory amounts 9520, parameter expiration schedule 9518, parameter transmission schedule 9516, and the selection of processing, formatting, and/or memory management operations to reduce costs, reduce resource utilization, avoid impacts to the mission (and/or mission critical) function of controllers and/or network zones of the vehicle, and improve system capability (e.g., improved memory resource management results in the ability to service a policy having a greater data collection capability for a
  • any one or more aspects set forth may be defined, at least partially, in the policy - for example and without limitation: parameter expiration times, memory management operations to be performed and the related data age values for such operations, transmission delay values that may be acceptable for data collection associated with the policy, the availability of external processing capability and/or formatting or processing operations that are allowed to be shifted off-vehicle.
  • Example operations to determine the reserved memory amount 9520 include operations such as: determining an amount of data to be collected to support the at least a portion of the plurality of vehicle parameter values (e.g., based on sampling rates, up sampling and/or down-sampling operations, formatting operations, number of data values, estimated residence time of the data values, etc.); determining an amount of data to be collected to support a trigger evaluation associated with the at least a portion of the plurality of vehicle parameter values (e.g., associated data utilized to determine trigger evaluations, and/or rolling buffers or other historical data that might be captured based on a trigger event); or determining a transmission latency value associated with the at least a portion of the plurality of vehicle parameter values (e.g., transmission delays may be imposed due to the storage location of the data values, and/or processing operations to be performed on stored data before transmission, such that the parameter storage circuit 9504 adjusts the reserved memory amount 9520 to ensure acceptable servicing of the policy).
  • An example parameter storage circuit 9504 further determines the reserved memory amount 9520 in response to a priority value associated with the at least a portion of the vehicle parameter values.
  • high priority values associated with collected data values may indicate a higher memory allocation - for example to ensure those values are available for transmission.
  • high priority values associated with collected data values may indicate a lower memory allocation - for example due to a high time degradation of the data value (e.g., collected data that has zero value after five minutes does not require storage beyond the five minutes) and/or due to a high likelihood that that data will be transmitted before it takes up significant memory space.
  • the parameter storage circuit 9504 determines the reserved memory amount 9520 based on the priority value and other considerations as set forth herein, and/or may further update the reserved memory amount 9520 in response to feedback - for example reducing allocations for data collection units that under-utilize allocated memory, and increasing allocations for data collection units that over- utilize allocated memory, consistently experience memory management operations, and/or adjusting based on historical transmission opportunity values, vehicle operating condition values, and the like.
  • Example priority values may be provided in the policy, and include any priority values set forth herein, including at least an on-vehicle data storage priority, a transmission priority, and/or an associated priority such as a priority for an end point (e.g., providing, requesting, and/or storing the data values), a priority for a flow (providing and/or requesting the data values), a priority for an application (e.g., providing and/or requesting the data values), priority for an entity (e.g., requesting the data values), and/or a priority associated with a data type of the data values.
  • a priority for an end point e.g., providing, requesting, and/or storing the data values
  • a priority for a flow providing and/or requesting the data values
  • a priority for an application e.g., providing and/or requesting the data values
  • priority for an entity e.g., requesting the data values
  • a priority associated with a data type of the data values e.g
  • an example procedure 9600 for selectively storing collected data parameters on a vehicle is schematically depicted.
  • the example procedure 9600 includes an operation 9602 to interpret a vehicle policy data value including requested vehicle properties, and an operation 9604 to acquire vehicle parameter value(s) responsive to the requested vehicle properties.
  • the example procedure 9600 further includes an operation 9606 to selectively store at least a portion of the vehicle parameter value(s), where at least a portion of the stored values are stored on a separate end point from a providing end point.
  • an example operation 9606 includes an operation 9702 to determine a parameter transmission schedule for stored parameters, and an operation 9704 to selectively store at least a portion of the vehicle parameter values in response to the transmission parameter schedule.
  • an example operation 9606 includes an operation 9802 to determine a parameter expiration schedule for stored parameters, and an operation 9804 to selectively store at least a portion of the vehicle parameter values in response to the parameter expiration schedule.
  • an example operation 9606 includes an operation 9902 to determine a reserved memory amount for stored parameters, and an operation 9904 to selectively store at least a portion of the vehicle parameter values in response to the reserved memory amount.
  • example operations 9804 to selectively store at least a portion of the vehicle parameter values in response to the parameter expiration schedule are schematically depicted.
  • an operation 9804 includes deleting at least a portion of the stored vehicle parameter values.
  • an operation 9804 includes summarizing at least a portion of the stored vehicle parameter values.
  • an operation 9804 includes adjusting a reserved memory amount associated with the stored vehicle parameters.
  • an operation 9804 includes compressing at least a portion of the stored vehicle parameters.
  • an operation 9902 includes determining an amount of data to be collected to support the vehicle parameter values.
  • an operation 9902 includes determining an amount of data to be collected to support a trigger evaluation associated with the vehicle parameter values.
  • an operation 9902 includes determining a transmission latency value associated with the vehicle parameter values.
  • an operation 9902 includes determining a priority value associated with the vehicle parameter values.
  • FIG. 108 an example apparatus 10800 for performing data collection operations implementing a data collection policy is schematically depicted.
  • the example apparatus 10800 operates similarly to apparatus 4500, with certain differences described here for purposes of illustration.
  • the apparatus 10800 may be included in a system having a vehicle with one or more network zones as described throughout the present disclosure, and aspects of the apparatus 10800 may be included, in whole or part, with any systems, devices, controllers, and/or apparatuses as set forth throughout the present disclosure. Additionally or alternatively, aspects of any systems, devices, controllers, and/or apparatuses set forth herein may be included, in whole or part, with apparatus 10800.
  • the example apparatus 10800 includes a policy acquisition circuit 2704 that interprets a data collection policy 10804 including at least one requested vehicle property, and a policy processing circuit 2706 that determines a property request value 10806 in response to the at least one requested vehicle property, for example translating a terminology utilized in the data collection policy 10804 to determine vehicle parameter values available that are responsive to data collection requests in the data collection policy 10804.
  • the example apparatus 10800 includes parameter acquisition circuit 9502 that interprets at least one vehicle parameter value 10808 in response to the property request value 10806, for example collecting data from end points 2716 on one or more network zones 2718, 2720 of the vehicle.
  • the example apparatus 10800 further includes a parameter provisioning circuit 10802 that selectively transmits the at least one vehicle parameter value 10808 in response to the data collection policy 10804, for example providing transmitted collected data 10810.
  • the example apparatus 10800 determines data on the vehicle that is responsive to the requested data, including translating parameter names, determining the configuration of the vehicle, such as end point distribution, network zone configuration, and the like, to allow the data collection policy 10804 to request a standardized and/or interface selected parameter description, without a requesting device providing the data collection policy 10804 requiring knowledge about the vehicle or vehicle configuration.
  • An example data collection policy 10804 includes a policy type, where the parameter acquisition circuit 9502 further interprets the vehicle parameter values 10808 in response to the policy type.
  • the policy type may be any type of policy as set forth herein, for example a persistent policy, discrete and/or limited policy type, and/or a streaming policy type.
  • the policy type additionally or alternatively is a policy type within a policy hierarchy, for example a built-in policy type, factory policy type, and/or downloaded policy type.
  • the parameter acquisition circuit 9502 persistently evaluates the data collection policy 10804 in response to the policy type being a persistent policy type - for example persistently collecting data, and/or persistently evaluating data collection criteria to determine whether data should be collected.
  • the parameter acquisition circuit 9502 discontinues evaluating the data collection cycle of the data collection in response to fulfilling a data collection cycle of the data collection policy - for example where the policy type is an on demand policy (e.g., discontinuing after the defined data collection is serviced), where the policy type is a streaming policy (e.g., discontinuing after the defined data collection is provided), and/or where the policy type is a discrete or limited policy (e.g., discontinuing after a determined number of data collection events, expiration of a time period, etc.).
  • the policy type is an on demand policy (e.g., discontinuing after the defined data collection is serviced)
  • the policy type is a streaming policy (e.g., discontinuing after the defined data collection is provided)
  • the policy type is a discrete or limited policy (e.g., discontinuing after a determined number of data collection events, expiration of a time period, etc.).
  • the policy acquisition circuit 2704 deletes the data collection policy 10804 in response to the parameter acquisition circuit 9502 discontinuing the evaluating the data collection policy 10804 - for example deleting the associated policy once the evaluation operations are discontinued, and/or deleting the associated policy after the related collected data is transmitted.
  • An example policy acquisition circuit 2704 implements a downloaded policy if present.
  • An example policy acquisition circuit 2704 ignores a factory policy and a built-in policy, if the downloaded policy is present.
  • An example policy acquisition circuit 2704 implements a compatible portion of the factory policy if present.
  • An example policy acquisition circuit 2704 implement the factory policy if present and a downloaded policy is not present.
  • An example policy acquisition circuit 2704 ignores the built-in policy, for example if a factory policy and/or downloaded policy is present.
  • An example policy acquisition circuit 2704 implements a compatible portion of the built-in policy if present.
  • an example data collection policy 10804 includes one or more of the following: a vehicle property 10902 (e.g., a description of a requested collection parameter, as viewed from the external device, user interface, and/or recited in a API (e.g., reference Fig.
  • a data collection cycle 10904 e.g., a timing, number of times, expiration window, etc., setting forth the requested data collection cycle of the policy
  • a transmission description value 10906 e.g., transmission criteria such as time values, data chunk sizes, expiration times, associated APNs, and/or transmission routes, etc.
  • a data configuration value 10908 e.g., units, formatting, bit depth, sampling rates, and/or synchronization criteria among data values
  • a triggered data description 10910 e.g., parameters defining a trigger condition to be evaluated, data to be collected in response to the trigger occurrence, and/or operations to be performed in response to the trigger occurrence such as actuator commands, feature adjustments, etc.
  • a policy priority value 10912 e.g., priority associated with the policy generally, and/or associated with individual elements of the policy such as vehicle properties, transmission, etc.
  • a policy life cycle description 10914 e.g., a number of times to be executed
  • the example data collection policy 10804 may be provided in any manner.
  • the data collection policy 10804 is provided as a data structure readable by the policy acquisition circuit 2704, for example as an HTML file, XML file, a delimited file, a binary file, and/or any data structure parseable by the data acquisition circuit 2704.
  • the data collection policy 10804 is prepared by an external system, such as a cloud based system, service tool, manufacturing tool, or the like - for example as set forth in Figs. 1-16, 114, 119, 121, and the related descriptions).
  • an example transmission description value 10906 includes one or more of the following: a transmission priority value 11002 (e.g., transmission priority values associated with the collected data), a data storage description 11004 (e.g., data storage priority, reserved memory amount, data aging and/or expiration parameters, etc.), a network zone utilization description 11006 (e.g., a priority for network zone utilization for the policy, and/or allowed bandwidth and/or utilization values for a network zone, and/or for a data collection operation of the policy), and/or an APN 11008 (e.g., associated collected data elements each with one or more APNs).
  • a transmission priority value 11002 e.g., transmission priority values associated with the collected data
  • a data storage description 11004 e.g., data storage priority, reserved memory amount, data aging and/or expiration parameters, etc.
  • a network zone utilization description 11006 e.g., a priority for network zone utilization for the policy, and/or allowed bandwidth and/or utilization values for a network zone,
  • an example policy priority value 10912 includes one or more of: a data collection priority value 11102 (e.g., providing data collection priority descriptions for data collection elements of the policy); a data storage priority value 11104 (e.g., providing data storage priority information for data collection elements of the policy); and/or a transmission priority value 11106.
  • a data collection priority value 11102 e.g., providing data collection priority descriptions for data collection elements of the policy
  • a data storage priority value 11104 e.g., providing data storage priority information for data collection elements of the policy
  • a transmission priority value 11106 e.g., the organization of elements of the policy is a non-limiting illustration - for example transmission priority values may be provided in a transmission description value 10906 and/or in a policy priority value 10912. Additionally or alternatively, elements may be applied to the whole policy, and/or to individual data collection aspects of the policy. Referencing Fig.
  • an example policy life cycle description 10914 includes one or more of the following: a policy start time 11202, a policy end time 11204, a triggered data description 11206, an amount of data to be captured 11208, a number of data collection events 11210, and/or a number of triggered event operations 11212.
  • an example procedure 11300 to collect data pursuant to a policy is schematically depicted.
  • the example procedure 11300 includes an operation 11302 to interpret a data collection policy including a requested vehicle property, an operation 11304 to determine a property request value in response to the requested vehicle property, an operation 11306 to interpret vehicle parameter(s) responsive to the requested vehicle property, and an operation 11308 to selectively transmit the vehicle parameter(s) responsive to the data collection policy.
  • FIG. 114 an example cloud system 11400 for retrieving selected data from a vehicle, and/or dividing stored collected data and access to the data.
  • the example of Fig. 114 is described as a cloud-based system 11400 for clarity of the description to illustrate aspects of the present disclosure.
  • operations of the system 11400 may be performed, additionally or alternatively, on any system configuration external to the vehicle.
  • operations may be performed in whole or part by a service tool, a manufacturing tool, a computing device at least selectively communicatively coupled to the vehicle, or other configurations as set forth herein.
  • An example system includes an external device, whether a cloud-based system or otherwise, coupled to the vehicle using a cellular data connection, a WiFi connection, a physical port connection to a network zone of the vehicle, a Bluetooth connection, and/or any other connection as understood in the art.
  • Operations of intra-vehicle network zone connection devices such as a CES, CEG, and/or CND, allow for a connection to any network zone of the vehicle to be utilized to receive, configure, and/or update policies to be implemented on the vehicle, and to transmit collected data.
  • aspects of the system 11400 may be implemented in the cloud, with other aspects implemented on another external device.
  • the example system 11400 includes a request interface 11402 configured to interpret a plurality of response action values 11404 from an external device 11424.
  • the response action values 11404 include, without limitation, one or more of: data values for collection (e.g., requested data to be collected from the vehicle); trigger conditions for conditional actions (e.g., data values to be observed for characteristics indicating the trigger event, for example determined by threshold values, processed responses such as a rate of change of a value, a trigger based on a number of values, state values such as “ON”, “OFF”, “ACTIVE”, and/or mode values such as indications of an operating mode, control operation state, etc.); time frames for data collection (e.g., calendar time; operating time relative to the vehicle; a time based amount of data to be collected - e.g., three minutes of data; a relative time to an event detection or trigger condition, such as beginning five minutes after the event, data from the three minutes preceding the event, etc.); priority information to be attributed to any of
  • the response action values 11404 may be provided by a user selection of preconfigured values - for example a user may select “vehicle speed” for inclusion as response action value 11404.
  • aspects of the response action values 11404 that the user is not authorized to request may be hidden from the user - for example by not providing such values to the user interface operated on the external device 11424.
  • aspects of the response action values 11404 that the user is not authorized to request may be annotated - for example with a greyed out text or the like - letting the user know that such values are generally available, but not with the present permissions of the user.
  • aspects of the response action values 11404 are presented to the user, and enforcement of the authorization is performed by the policy creator circuit 11406, for example by excluding the values from a final data collection policy 11408, and/or by excluding the entire set of response action values 11404 from the final data collection policy 11408.
  • response action values 11404 indicate defining operations for data collection, trigger evaluation, and/or automatic operations of the vehicle, while vehicle data requests 11422 indicate requests to access responsive vehicle data 11418 collected in response to the response action values 11404.
  • vehicle data requests 11422 indicate requests to access responsive vehicle data 11418 collected in response to the response action values 11404.
  • the terminology utilized herein is illustrative and non-limiting.
  • Operations to generate the data collection policy 11408 with excluded values may include a notification to the user that the requested response action values 11404 were not authorized.
  • a notification to the user that the requested response action values 11404 are not authorized in response to a submission attempt by the user - for example allowing the user to identify which aspects of the response action values 11404 are preventing submission, and allowing the user to adjust the response action values 11404.
  • a combination of these operations are utilized on the interface - for example hiding some not authorized parameters completely from the user (e.g., highly sensitive parameters that are only available to certain users), and displaying some not authorized parameters to the user.
  • some parameters may be available in response to a further approval - for example an administrative or supervising user of an entity may have authorization to approve certain parameters as response action values 11404, where another user from the entity requesting the certain parameters may receive a notification to request authorization, and/or the administrative or supervising user may receive a notification that one or more of the certain parameters have been requested.
  • some parameters may be available based on a subscription, a particular version of the user interface (e.g., a standard versus premium version of a web portal, local application, mobile application, or the like), where the interface may prompt the user to obtain the authorizing features (e.g., subscription, or updated interface version), and/or a notification associated with the parameters may indicate the features needed to access the parameters.
  • certain parameters may be available based on access characteristics - for example an unsecured access to the interface and/or a partial login operation to the interface (e.g., entering a password, but not a second step of a two-step authentication, etc.) - where the request interface 11402 may selectively hide parameters unavailable based on the access characteristics, and/or show the parameters as inactive on the interface.
  • access characteristics for example an unsecured access to the interface and/or a partial login operation to the interface (e.g., entering a password, but not a second step of a two-step authentication, etc.)
  • the request interface 11402 may selectively hide parameters unavailable based on the access characteristics, and/or show the parameters as inactive on the interface.
  • the request interface 11402 is configured according to the external device, an associated entity, and/or a type of user and user goal associated with these.
  • the request interface 11402 for interaction with an owner of the vehicle and/or a third party application developer may be simplified, allowing for selection of data collection parameters using selections from menus, utilizing templates, and/or with more limited capability.
  • the request interface 11402 for interaction with a sophisticated developer may include convenient interfaces, allow for direct submission of completed policy data structures (e.g., an HTML file, XML file, delimited file, binary file, or the like), or a combination of these (e.g., building an initial data structure based on menu interactions and selections, and allowing access to the source file generated thereby for direct editing and submission).
  • a user device 11424 to provide the response action values 11404 and to provide vehicle data requests 11422 may be different devices, and/or may access separate interfaces 11402.
  • a first user providing the response action values 11404 and a second user providing the vehicle data requests 11422 may be separate users, users associated with different entities, and/or may be entirely unrelated.
  • a third party application developer may provide response action values 11404, where the vehicle data requests 11422 may be provided by a vehicle owner.
  • a number of separate users may have access to the responsive vehicle data 11418.
  • the system 11400 is depicted with a first cloud boundary to the external device 11424, and a second cloud boundary to the vehicle 11426, with the cloud system positioned therebetween, including the request interface 11402, the policy creator circuit 11406, the raw data manager circuit 11416, and the cloud interface circuit 11412.
  • one or more aspects of the cloud system, or all aspects of the cloud system may be positioned apart from a cloud system, for example with aspects positioned on the vehicle 11426, another external device, or combinations of these.
  • aspects of the cloud system 11400 may be provided as an internet-based aspect, a web portal, a mobile application, or the like.
  • An example request interface 11402 includes more than one option to interface with the cloud system, for example with a first interface operated as a web portal, another interface operated as a mobile application, another interface operated on a tool (e.g., a service tool, manufacturing tool, or the like), and/or another interface such as on an external device 11424 operating a local application on the device.
  • a first interface operated as a web portal another interface operated as a mobile application
  • another interface operated on a tool e.g., a service tool, manufacturing tool, or the like
  • another interface such as on an external device 11424 operating a local application on the device.
  • capabilities available for interacting with the cloud system may be varied according to the interface utilized for the interaction (e.g., a service tool having distinct capabilities relative to a mobile application), an entity associated with a user exercising the interface (e.g., a third party application provider, manufacturer, dealer, vehicle owner, etc.), and/or a type of interaction with the cloud system (e.g., a web portal access having distinct capabilities to a manufacturing tool coupled directly to a network zone of the vehicle).
  • interactions with the cloud system may utilize verification and/or authorization, for example exercising a login interface, encrypted communications between the cloud system and external devices, between the cloud system and the vehicle, and between components of the cloud system.
  • the cloud system components may be separate devices - including physically separate devices and/or logically separated devices.
  • the request interface 11402 may be embodied on a separate device (or group of devices) than the raw data manager circuit 11416.
  • a portion of the request interface 11402 may be at least partially included on an external device and/or on the vehicle.
  • the example system 11400 includes a policy creator circuit 11406 that determines a data collection policy 11408 in response to the response action values 11404, the data collection policy 11408 including a vehicle data identifier 11410.
  • the policy creator circuit 11406 compiles more than one response action values 11404 from more than one user into a data collection policy 11408, for example creating a single compiled data structure representing the policy, and/or providing multiple separate data structures representing the policy.
  • the policy creator circuit 11406 checks authorization for portions of the policy according to the entity, user, application, flow, or the like providing the respective portion.
  • the policy creator circuit 11406 checks for capability of the policy, for example determining whether data storage resources, processing resources, parameter availability, and/or transmission resources of the vehicle are capable to service data collection or other operations responsive to the policy.
  • a policy manager on the vehicle further performs an authorization and/or capability check of the policy provided to the vehicle, for example providing a confirmation to the cloud interface circuit 11412 if the policy is accepted, and providing a notification to the cloud interface circuit 11412 if the policy is declined.
  • An example cloud interface circuit 11412 - for example configured to access the vehicle - is configured to receive identified vehicle data 11414 collected in response to the data collection policy 11408.
  • the vehicle data identifier 11410 may be specifically identifiable information about the vehicle - for example a vehicle identification number (VIN), serial number, media access control (MAC) address from a specified controller of the vehicle, or the like, and/or identifiable information ensuring that the identified vehicle data 11414 can be matched to the vehicle and/or a vehicle data request 11422.
  • VIN vehicle identification number
  • MAC media access control
  • An example vehicle data identifier 11410 includes a session identifier (e.g., identifying a data collection “session”, and/or a data collection instance, tied to the block of collected data provided in response to the data collection policy 11408) - for example a unique identifier included with the data collection policy 11408, and attached to the identified vehicle data 11414, allowing identification of the responsive vehicle data 11418 separate from other information such as personal information about the vehicle owner, identification of the specific vehicle related to the data, etc.
  • a session identifier e.g., identifying a data collection “session”, and/or a data collection instance, tied to the block of collected data provided in response to the data collection policy 11408
  • a unique identifier included with the data collection policy 11408 e.g., a unique identifier included with the data collection policy 11408, and attached to the identified vehicle data 11414, allowing identification of the responsive vehicle data 11418 separate from other information such as personal information about the vehicle owner, identification of the specific vehicle
  • the vehicle data identifier 11410 utilized for a particular data collection policy 11408 may depend upon the type of policy (e.g., a persistent policy may utilize a first type of identifier, and a discrete and/or streaming policy may utilize a second type of identifier), and/or according to the importance for the particular system to keep identifying information separate from the responsive vehicle data 11418.
  • An example raw data manager circuit 11416 stores at least a portion of the received identified vehicle data 11414, the at least a portion of the identified vehicle data including responsive vehicle data 11418 and identification data 11420.
  • the identification data 11420 may be the same as the vehicle data identifier 11410, or a different identifier.
  • the responsive vehicle data 11418 may be encrypted separately from the identification data 11420, allowing for the raw data manager circuit 11416 to provide the correct responsive vehicle data 11418 by comparing the related identification data 11420, without the raw data manager circuit 11416 having access to the responsive vehicle data 11418.
  • Example identification data 11420 includes metadata specific to a particular set of response action value(s) 11404.
  • An example request interface 11402 interprets a vehicle data request 11422, and retrieves at least a portion of the responsive vehicle data 11418 from the raw data manager circuit 11416 in response to the vehicle data request 11422.
  • the example request interface 11402 provides the retrieved data to the external device 11424.
  • An example system 11400 includes the responsive vehicle data 11418 encrypted utilizing a first encryption key set, and the identification data 11420 encrypted utilizing a second encryption key set. Accordingly, the raw data manager circuit 11416 can be configured to identify responsive data to vehicle data requests 11422, without having access to the responsive vehicle data 11418. In certain embodiments, the raw data manager circuit 11416 may identify responsive data utilizing a hash check or other operation. In certain embodiments, an encryption key to decrypt the responsive vehicle data 11418 is not present on the cloud system 11400, and/or unavailable to selected portions of the cloud system 11400 (e.g., unavailable to the raw data manager circuit 11416).
  • FIG. 115 an example cloud system 11500 for retrieving selected data from a vehicle, and/or dividing stored collected data and access to the data is schematically depicted.
  • the example of Fig. 115 is described as a cloud-based system 11500 for clarity of the description to illustrate aspects of the present disclosure. However, operations of the system 11500 may be performed, additionally or alternatively, on any system configuration external to the vehicle.
  • the example system 11500 includes a collected vehicle data storage circuit 11502 that stores collected data 11504 from a vehicle, and an external data collection interface 11506 that selectively provides vehicle data collection request(s) 11508 from an external device to the vehicle, for example by processing the vehicle data collection request(s) 11508 into a policy data structure provided to the vehicle.
  • the example external data collection interface 11506 further provides at least a portion of the stored collected data 11504 from the collected vehicle data storage circuit 11502 in response to a vehicle data request 11510 from an external device.
  • the example system includes separation of at least a portion of the stored collected data 11504 from an encryption key for the at least a portion of the stored collected data 11504.
  • Example arrangements to separate the encryption key from the at least a portion of the stored collected data 11504 include, without limitation to any other aspect of the present disclosure: separate encryption of an identifying portion of the data from a payload portion of the data; identification and/or verification of the payload portion of the data utilizing a hash check; and/or identification and/or verification of the payload portion with a separate identifier for the payload portion.
  • An example external data collection interface 11506 selectively provides the vehicle data collection request(s) 11508 to the vehicle by providing the requests 11508 to the collected vehicle data storage circuit 11502, and/or to a policy creator circuit 11406 (e.g., reference Fig. 114 and the related description).
  • an example procedure 11600 for data collection operations from a vehicle is schematically depicted.
  • the example procedure 11600 includes an operation 11602 to interpret response action values from an external device, and an operation 11604 to determine a data collection policy in response to the action values, the data collection policy including a vehicle data identifier.
  • the example procedure 11600 includes an operation 11606 to receive identified vehicle data in response to the data collection policy, an operation 11608 to store received identified data from the vehicle that is responsive to the data collection policy and related identifying data, and an operation 11610 to interpret a vehicle data request, and to retrieve at least a portion of the responsive data.
  • an example procedure 11700 for separating responsive data to a vehicle data collection operation from access to the responsive data is schematically depicted.
  • the example procedure 11700 includes an operation 11702 to encrypt responsive data using a first encryption key, and an operation 11704 to encrypt identification data using a second encryption key.
  • identification data may be unencrypted.
  • the example procedure 11700 further includes an operation 11706 to store the responsive data on a separate memory from the first encryption key, and an operation 11708 to retrieve requested data utilizing the second encryption key (and/or utilizing the identification data).
  • an example procedure 11800 for separating responsive data to a vehicle data collection operation from access to the responsive data is schematically depicted.
  • the example procedure 11800 includes an operation 11802 to encrypt responsive data for storage on a first memory, an operation 11804 to interpret a vehicle data request directed to at least a portion of the encrypted responsive data, and an operation 11808 to access requested portions of the encrypted responsive data utilizing an unencrypted identifier and/or a separately encrypted identifier.
  • FIG. 119 an example system 11900 for retrieving selected data from a vehicle, and/or dividing stored collected data and access to the data is schematically depicted.
  • the example system 11900 includes a raw data manager circuit 11416 that stores responsive encrypted data 11418, collected in response to a data collection vehicle description 11408 (and/or a policy), utilizing vehicle data 11902 provided by the vehicle operating a data collection policy on the vehicle.
  • the example system 11900 includes an external data collection interface 11506 that provides at least a portion of the responsive encrypted data 11418 to an external device in response to a vehicle data request 11510.
  • a raw data manager circuit 11416 that stores responsive encrypted data 11418, collected in response to a data collection vehicle description 11408 (and/or a policy), utilizing vehicle data 11902 provided by the vehicle operating a data collection policy on the vehicle.
  • the example system 11900 includes an external data collection interface 11506 that provides at least a portion of the responsive encrypted data 11418 to an external device in response to
  • an encryption key 11512 for the responsive encrypted data 11418 is kept separate from the raw data manager circuit 11416, for example utilizing separate identifying data 11420 to determine portions of the responsive encrypted data 11418 without decrypting the responsive encrypted data 11418.
  • either or both of the external data collection interface 11506 or the external device 11424 have access to the responsive data encryption key 11512, thereby allowing the external device 11424 to access the received data.
  • the break between the responsive data encryption key 11512 and the raw data manager circuit 11416 is explicitly depicted for purposes of illustration, but the responsive data encryption key 11512 may be stored on a separate device from the raw data manager circuit 11416, whether a separate physical device or a separate logical device.
  • Example identifying data 11420 include one or more of the following: a collected vehicle data metadata 12002, a data collection session identifier 12004, an identifier configured without personally identifiable information (PII) present, and/or identifying data correlated with a consent 12008 (e.g., where the request interface 11402, and/or a policy manager on the vehicle, provide a consent notification to an external device, where the consent notification includes consent for information presented in the identifying data 11420).
  • PII personally identifiable information
  • FIG. 121 an example cloud system for preparing data collection policies, and collecting responsive data from a vehicle, is schematically depicted.
  • the example of Fig. 121 is described as a cloud-based system 12100 for clarity of the description to illustrate aspects of the present disclosure. However, operations of the system 12100 may be performed, additionally or alternatively, on any system configuration external to the vehicle.
  • the example system 12100 includes a request interface 11402 configured to interpret a vehicle data collection request 12110 for at least one identified vehicle, and a policy creator circuit 11406 that determines a data collection policy 11408 in response to the vehicle data collection request(s) 12110.
  • An example cloud interface provides the data collection policy 11408 to a vehicle, and a raw data manager circuit that stores at least a portion of responsive vehicle data received from the vehicle (e.g., reference Fig. 114).
  • An example request interface 11402 is further configured to expose an application programming interface (API) (e.g., data collection API 12102) to an external device 12104, 12106, 12108.
  • API application programming interface
  • the API may include access to any selected operations, for example allowing a web portal, mobile application, tool, local application, or the like, to operate an interface to select available data values for collection, to configured a data structure including any aspects of a policy as set forth herein, and/or to request responsive data 14118 after collection operations.
  • the example request interface 11402 further interprets a vehicle data request 12112, and provides retrieved data from the responsive vehicle data 11418 to an external device in response to a vehicle data request 12112.
  • the data collection requests 12110 and/or the vehicle data requests 12112 may be received based on interactions with a user interface provided to the external device(s), and/or in response to an exercise of the API 12102 by the user, an application operated by the user, or the like.
  • the example policy creator circuit 11406 determines the data collection policy 11408 in response to the data collection requests 12110, and/or further in response to policy collection authorization value(s) 12120 and/or policy collection capability value(s) 12118.
  • Example operations of the policy creator circuit 11406 to determine the policy capability value 12118 include determining the policy capability value 12118 in response to one or more of: a data storage size determined to support the vehicle data collection request; a transmission amount 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.
  • Example operations of the policy creator circuit include determining a policy capability value 12118 in response to the vehicle data collection request 12110 and at least one additional vehicle data collection request 12110, and to selectively enable, in response to the policy capability value 12118, at least one of: determining the data collection policy 11408, or including at least one of the vehicle data collection request 12110 or the at least one additional vehicle data collection request 12110.
  • the policy creator circuit 11406 further determines the policy capability value 12118 in response to at least one parameter such as: a data storage size determined to support each of the vehicle data collection request 12110 and the at least one additional vehicle data collection request 12110; a transmission amount value determined to support each of the vehicle data collection request 12110 and the at least one additional vehicle data collection request 12110; a data availability value associated with each of the vehicle data collection request 12110 and the at least one additional vehicle data collection request 12110; a data configuration value associated with each of the vehicle data collection request 12110 and the at least one additional vehicle data collection request 12110; or a priority determination between the vehicle data collection request 12110 and the at least one additional vehicle data collection request 12110 for any one or more of the foregoing.
  • at least one parameter such as: a data storage size determined to support each of the vehicle data collection request 12110 and the at least one additional vehicle data collection request 12110; a transmission amount value determined to support each of the vehicle data collection request 12110 and the at least one additional vehicle data collection request 12110; a data availability value
  • An example policy creator circuit 11406 determines a policy authorization value 12120 in response to the vehicle data collection request 12110, and to perform at least one operation, in response to the policy authorization value, such as: selectively enabling the determining the data collection policy 11408; or determining the data collection policy 11408 to support at least a portion of the vehicle data collection request 12110.
  • the request interface 11402 is configured to provide at least one use case value 12116 to a user interface, each use case value 12116 including a vehicle data collection template 12114, and determining the vehicle data collection request 12110 in response to responses from the user interface to the provided at least one use case value 12116.
  • the request interface 11402 is further configured to determine the at least one use case value in response to at least one of: an entity type associated with the user interface; a permissions value associated with the user interface; and previous data collection policies determined for users having a shared characteristic determined for the user interface.
  • an example policy creator circuit 11406 is schematically depicted.
  • the example policy creator circuit 11406 may be utilized in any system herein, and/or may perform operations herein, related to determining, interpreting, and/or creating a policy and/or data collection operations.
  • the example policy creator circuit 11406 determines a policy collection capability value 12118 in response to received data collection requests 12110.
  • the policy creator circuit 11406 determines the policy collection capability values 12118 in response to capability considerations 12202 such as: data storage support to service the policy, data transmission support to service the policy, data availability to support the policy (e.g., are the requested data values available), data formatting, processing, and/or configuration support for the policy (e.g., can the parameters be provided in the requested units, bit depth, sampling rates, response time, etc., including whether processing support resources are available to perform formatting and/or configuration operations for collected data), resource permissions associated with the request (e.g., does an entity, flow, and/or application associated with the data collection request 12110 have sufficient permissions to utilize supporting resources, and/or sufficient permissions to consume supporting resources in a quantity needed to support the data collection request 12110), and/or priority comparisons between requests (e.g., lower priority data collection requests 12110 may be excluded if the overall policy including all requests exceeds a capability value).
  • capability considerations 12202 such as: data storage support to service the policy, data transmission support to service the policy, data availability to
  • an example request interface 11402 providing use case and/or template selections to external device(s) is schematically depicted.
  • the example request interface 11402 may be utilized in any system herein, and/or may perform operations herein, related to determining, interpreting, and/or creating a policy and/or data collection operations, and/or related to receiving and processing data collection requests.
  • the example request interface 11402 determines a data collection template 12114 and/or a data collection use case 12116 for providing to an external device 12104, 12106, 12108 on an interface, where the use case 12116 and/or template 12114 is available for selection as a data collection request, and/or for modification to rapidly configure a data collection request.
  • the example request interface 11402 determines the data collection templates 12114 and/or data collection use cases 12116 in response to selection considerations 12302 such as: an entity type associated with a request (e.g., providing useful use cases and/or templates according to the entity type - such as a manufacturer, service organization, application developer, dealer, vehicle operator, vehicle owner, etc.); a permissions value associated with an interfacing external device (e.g., where users having a similar permissions profile may be more likely to be seeking similar data, and/or users having a similar permissions profile can efficiently utilize the same templates and/or use cases due to overlap in available parameters); previous data collection policies and/or requests from the same user (and/or same entity, same external device, same access location, etc.); and/or previous data collection policies and/or requests from other users having a shared characteristic with the user (e.g., sharing an expressed goal, an entity type, a permissions value, and/or a categorical selection, such as by a user, where the categorical selection may relate to subject
  • an example procedure 12400 for operating a request interface to determine data collection requests and/or collected data access requests is schematically depicted.
  • the example procedure 12400 includes an operation 12402 to expose a data collection API to an external device, an operation 12404 to interpret a vehicle data collection request in response to an exercise of the API, and an operation 12406 to determine a data collection policy in response to the vehicle data collection request.
  • the example procedure 12400 includes an operation 12408 to provide the data collection policy to a vehicle, an operation 12410 to receive responsive vehicle data collected in response to the data collection policy, and an operation 12412 to store at least a portion of the responsive data 12412.
  • the example procedure 124000 includes an operation 12414 to interpret a vehicle data request in response to an exercise of the API, an operation 12416 to retrieve at least a portion of the stored data in response to the vehicle data request, and an operation 12418 to provide the retrieved data to an external device.
  • FIG. 125-130 example embodiments of the present disclosure are schematically depicted to operate a container based implementation of one or more control aspects of a vehicle.
  • the apparatuses, systems, circuits, and/or operations set forth in relation to Figs. 125-130 and the related descriptions may be utilized in any embodiments of the present disclosure, may be utilized in whole or part with embodiments of Figs. 17-25, and/or aspects of embodiments depicted in Figs. 17-25 may be utilized in whole or part with embodiments of Figs. 125-130.
  • container based implementation of one or more control aspects of a vehicle leverage numerous aspects of embodiments of the present disclosure - for example, and without limitation: allowing for control operations and/or features to be installed, updated, enabled, disabled, and/or configured utilizing a policy implementation infrastructure described herein; allowing distribution of control operations across controllers of the vehicle, enabled from aspects such as the ability of embodiments herein to retrieve and/or provide data values to any end point on any network zone of any type, and to determine, manage, and respond to network utilization of network zones of the vehicle; performing authorization, verification, and capability determination operations utilizing the policy implementation infrastructure described herein; and allowing for external data transmission control and management, including resource management, that supports the increased burden and/or complexity introduced by implementing a container based implementation of one or more control aspects of the vehicle.
  • a container based implementation of one or more control aspects of the vehicle encompasses all or a selected portion of available controllers on the vehicle, of selected control operations on the vehicle, and/or end points of selected network zones.
  • an example apparatus 12500 includes a container acquisition circuit 12502 that interprets container application value(s) 12508, each including an application operable on an end point of a vehicle.
  • the container application value(s) 12508 may include an image, e.g., a binary image, data structure having values that combine with an executable backbone stored on a controller of the vehicle, and/or another type of image, where the container application value 12508, alone or in combination with instructions on a controller of the vehicle, includes computer readable instructions which, when executed by a processor on a controller of the vehicle, cause the processor to execute operations of a feature embodied in the container application value 12508 - for example a prime mover control, operator interface control, control operations for a component of the vehicle, etc.
  • the example apparatus 12500 includes a container security circuit 12504 that interprets an authorization value 12510 associated with each of the container application values 12508.
  • the container application value 12508 may be rejected (e.g., not downloaded), and/or the container application value 12508 may be installed but disabled (e.g., not executed), for example to reduce a download time at a later time where the authorization value 12510 can later be corrected without having to re-download the respective container application value 12508.
  • the example apparatus 12500 includes a container orchestration circuit 12506 that interprets a container policy 12512, and determines operation parameters 12516 for each of the plurality of container application values 12508 in response to the container policy 12512 and the authorization value 12510 associated with each of the plurality of container application values 12510.
  • the container policy 12512 includes one or more of: an authorization description defining an authorization value 12510 required to perform certain operations on the vehicle (e.g., based on an output value of an application, accessed data for the application, an operation type of the application, etc.); a data dependency description of the container application values 12508 (e.g., which container applications depend on data from each other); an execution order of one or more of the container application values 12508 (e.g., utilized to enforce selected order dependencies for applications); priority values for one or more of the container application values 12508; and/or latency descriptions for one or more of the container application values 12508 (e.g., acceptable time lags for data utilized by an application, and/or time lags between execution events of related applications).
  • an authorization description defining an authorization value 12510 required to perform certain operations on the vehicle (e.g., based on an output value of an application, accessed data for the application, an operation type of the application, etc.); a data dependency description of the container application values 12508 (
  • the example container orchestration circuit 12506 is further structured to distribute the plurality of container application values 12508 across a number of end points of the vehicle (e.g., determining which container application value is provided on which controller of the vehicle).
  • the example container orchestration circuit 12506 is further structured to distribute the plurality of container application values 12508 to balance workloads of the controllers including the number of end points, for example to balance utilization of processing resources and/or data storage resources of the controllers.
  • the example container orchestration circuit 12506 is further structured to distribute the plurality of container application values 12508 to balance network communication loads of a plurality of network zones of the vehicle, for example distributing container application values 12508 based on parameter values passed between applications, and the layout of controllers on various network zones, to balance utilization of network zones, and/or to limit utilization of network zones within capability limits and/or within predetermined utilization limits.
  • the example container orchestration circuit 12506 is further structured to distribute the plurality of container application values 12508 responsive to network communication loads of the network zones of the vehicle.
  • An example container security circuit 12504 is further structured to determine the authorization value 12510 in response to an authorization associated with an entity providing each of the plurality of container application values, for example determining that the providing entity has authorization to access data values and/or provide actuation commands utilized by the application corresponding to the container application value 12508.
  • An example container security circuit 12504 is further structured to determine the authorization value 12510 in response to an authorization requirement associated with operations of each of the plurality of container application values 12508.
  • An example container security circuit 12504 is further structured to determine the authorization requirement in response to an input data value of each of the plurality of container application values 12508.
  • An example container security circuit 12504 is further structured to determine the authorization requirement in response to an output data value of each of the plurality of container application values 12508.
  • An example container security circuit 12504 is further structured to determine the authorization requirement in response to an actuator command value of each of the plurality of container application values 12508.
  • An example container security circuit 12504 is further structured to determine the authorization requirement in response to a memory support value of each of the plurality of container application values 12508.
  • Example memory support values include one or more of an installation memory support value and/or an operating memory support value.
  • An example container security circuit 12504 is further structured to determine the authorization requirement in response to a processing support value of each of the plurality of container application values.
  • An example container acquisition circuit 12502 is further structured to interpret an additional container application value (e.g., utilized to update an application and/or add a new application to a vehicle), and wherein the container orchestration circuit 12506 is further structured to update the operation parameters 12516 for the plurality of container application values 12508 and the additional container application value 12508 in response to an added container application value 12508.
  • An example container orchestration circuit 12506 is further structured to distribute the added container application value 12508 to a selected end point of the vehicle in response to a capability of the selected end point to perform the added container application value 12508.
  • An example container orchestration circuit 12506 is further structured to change a distribution of the plurality of container application values 12508 across a number of end points of the vehicle in response to the added container application value 12508 - for example to re-balance and/or provide capability to execute installed container application values 12508 in view of the added container application value 12508.
  • An example container acquisition circuit 12502 is further structured to interpret an enable value for at least one of the plurality of container application values 12508, for example provided in an update to the container policy 12512, an updated image of the container application value 12508, and/or provided as a part of a policy as set forth elsewhere throughout the present disclosure, where the container orchestration circuit 12506 is further structured to determine the operation parameters 12516 in response to the enable value.
  • An example container orchestration circuit 12506 is further structured to interpret a vehicle operating condition, and to determine the operation parameters 12516 in response to the vehicle operating condition - for example delaying a reconfiguration of the operation parameters 12516 until a selected vehicle operating condition is present (e.g., stationary, shutdown, idle, etc.), and/or providing for selected operations of applications based on a vehicle operating condition, for example disabling features that are not utilized in certain operating conditions, enabling features utilized in certain operating conditions, and/or changing feature execution rate and/or execution order in response to the operating conditions.
  • An example container orchestration circuit 12506 is further structured to interpret a vehicle configuration value (e.g., indicating a power rating, trim level, performance rating, model identifier, etc.), and to determine the operation parameters in response to the vehicle configuration value.
  • an example container operating parameter 12516 is schematically depicted.
  • the container operating parameter 12516 may be stored as a local container registry (e.g., reference Fig. 17 and the related description).
  • the example container operating parameter 12516 includes a container location 12602 (e.g., a location where a container application value 12508 is installed), a container execution order 12604 (e.g., a listing of container application execution orders, which may in certain embodiments be specific to container application values 12508 provided on a given controller), and/or a container data instruction 12606 (e.g., providing a description of data values, including formatting and/or processing for the data values, that are utilized by and/or provided by one or more, or all, container application values 12508).
  • a container location 12602 e.g., a location where a container application value 12508 is installed
  • a container execution order 12604 e.g., a listing of container application execution orders, which may in certain embodiments be specific to container application values 12508 provided on a given controller
  • a container data instruction 12606 e.g., providing a description of data values, including formatting and/or processing for the data values, that are utilized
  • the authorization value 12510 includes one or more of: permissions associated with a container provider 12702; permissions associated with input data for a container 12704; permissions associated with an output data for a container 12706; permissions associated with actuator command(s) accessed by a container 12708; permissions associated with memory support for a container 12710; and/or permissions associated with processing support for a container 12712.
  • FIG. 128 an example vehicle resource information 12514 value is schematically depicted.
  • the container orchestration circuit 12506 determines capability and/or load balancing of container operations, to determine the container operating parameters 12516 including the distribution of container application values 12508 across end points of the vehicle.
  • the example vehicle resource information 12514 includes one or more aspects such as: an end point processing capability description 12802; an end point memory capability description 12804; an end point I/O description 12806 (e.g., including which sensors and/or actuators are operationally coupled to a given end point, and/or configuration of the sensors and/or actuators such as voltage ranges, electrical characteristics, A/D processing operations, etc.); an end point network zone location 12808; a network zone capability description 12810 (e.g., including bandwidth, latency, synchronization description, types of messages available, network protocols, etc.); a convergence device capability description 12812 (e.g., data throughput and/or processing capability of a CEG, CES, and/or CND); a redundancy support consideration 12814 (e.g., a description of applications that may have a redundant capacity, for example a substitute container application that can perform all or a portion of operations for another container application in response to a communication loss, end point loss, off-nominal operation,
  • FIG. 129 an example procedure 12900 for providing a containerized implementation of one or more control operations on a vehicle is schematically depicted.
  • the example procedure 12900 includes an operation 12902 to interpret container application values, an operation 12904 to interpret authorization values associated with each of the container application values, an operation 12906 to interpret a container policy, and an operation 12908 to determine operation parameters for each of the container application values in response to the container policy and the authorization values.
  • an example procedure 13000 to provide a containerized implementation of one or more control operations on a vehicle is schematically depicted.
  • the example procedure 13000 includes an operation 13002 to distribute container application values (e.g., install container applications) across a number of end points of the vehicle.
  • FIG. 131-134 example embodiments of the present disclosure are schematically depicted to provide automated vehicle operations based on detected data values, response of data values, combined data values and/or responses, and/or trigger evaluations as set forth throughout the present disclosure.
  • the apparatuses, systems, circuits, and/or operations set forth in relation to Figs. 131-134 and the related descriptions may be utilized in any embodiments of the present disclosure, may be utilized in whole or part with embodiments of Figs. 1-16, and/or aspects of embodiments depicted in Figs. 1-16 may be utilized in whole or part with embodiments of Figs. 131-134.
  • the utilization of automated response operations of a vehicle leverage numerous aspects of embodiments of the present disclosure - for example, and without limitation: allowing for rapid implementation of features utilizing little or no application development resources for the features; allowing for installation and utilization of features having a light footprint in terms of verification, installation, and distribution of features to a number of vehicles; allowing for creative third parties and/or vehicle owner/operators to provide high value and/or convenience enhancements for interactions with the vehicle; and/or allowing for installation of feature (e.g. as a containerized application) at a first time, and enabling of the feature at a later time (e.g., to provide verification time, provide for distributed roll-out risk, etc.).
  • feature e.g. as a containerized application
  • aspects of the present disclosure enable high capability automated vehicle operations, including aspects such as: the ability of embodiments herein to retrieve and/or provide data values to any end point on any network zone of any type; to control access to features, end points, applications, flows, and/or actuators that are protective of vehicle security and mission integrity; allowing for access to any data on the vehicle and/or any actuator on the vehicle without requiring in-depth knowledge of the vehicle configuration; and/or utilization of an external device facing interface and API to provide a selected user experience and enable easy access to available capabilities of the vehicle.
  • the example apparatus 13100 includes an automated operation circuit 13102 structured to interpret an automated operation value 13110 including an automated operation description for a vehicle 13112.
  • the example apparatus 13100 further includes an automation manager circuit 13104 structured to determine a trigger description value 13114 in response to the automated operation value 13110, the trigger description value 13114 including a trigger condition value 13116 (e.g., data values, operating conditions, state values, and/or mode values defining detected values utilized to determine whether the trigger event has occurred), and a trigger response value 13118 (e.g., operations to be performed in response to a trigger event occurrence 13120, including operation of an actuator, collection of data, providing notifications or alerts, etc.).
  • the example apparatus 13100 further includes a trigger evaluation circuit 13106 structured to determine a trigger event occurrence 13120 in response to the trigger condition value 13116 and at least one vehicle data value 13122.
  • the example apparatus 13100 includes a task and/or trigger execution circuit 13108 structured to execute a trigger response 13124 in response to the trigger event occurrence 13120. Embodiments of the disclosure may execute one or more tasks without a trigger.
  • Example and non-limiting trigger responses 13124 include operations such as: performing a data collection operation 13402 (e.g., reference Fig. 134); providing an actuator command value 13404; and/or enabling operation of a pre-configured feature on a controller of the vehicle 13406.
  • An example trigger response 13124 includes providing a high priority response 13408 for at least a portion of the trigger response 13124, for example to allow for a rapid user experience for at least a portion of the trigger response 13124, for example providing immediate feedback to the user that an operation has commenced, providing for a rapid notification or external communication, and/or providing a high priority actuator command (e.g., unlocking a door) as a part of the trigger response 13124.
  • An example automated operation value 13110 includes a selection from a number of pre-configured automated operation values 13110, for example to provide pre-configured operations available on an interface to allow for rapid configuration of automated operations, and/or to ensure that certain operations are always performed together or in a determined arrangement (e.g., confirming aspects before allowing an engine start, such as enforcing a zero vehicle speed, closed doors, etc.).
  • An example automation manager circuit 13104 is further structured to determine an authorization value 13126 associated with the automated operation value 13110, and to selectively determine the trigger description value 13114 in response to the authorization value 13110 (e.g.,, declining to implement the automated operation value 13110 if the authorization is insufficient, providing a notification that the automated operation value 13110 is not to be implemented, etc.).
  • An example automation manager circuit 13104 is further structured to determine the trigger description value 13114 as a persistent value (e.g., similar to implementation of a persistent policy), and/or as a limited execution value (e.g., similar to implementation of a limited and/or discrete policy).
  • An example automation manager circuit 13104 is further structured to maintain a receiver of the vehicle in a selected power mode during selected operating conditions of the vehicle - for example allowing for exchange of external data to support automated operations of the vehicle, and/or to enhance a response time of the vehicle, while managing power consumption.
  • An example automation manager circuit 13104 is further structured to maintain at least one controller of the vehicle in a selected power mode during selected operating conditions of the vehicle, for example to monitor data values supporting an automated operation and/or to monitor a trigger condition value 13116, and/or to reduce a response time of the vehicle to an automated operation, for example keeping a selected controller in a power mode where a startup time is reduced and/or eliminated, while managing power consumption.
  • An example automation manager circuit 13104 is further structured to maintain the at least one controller of the vehicle in the selected power mode in response to a content of the trigger description value 13114 (e.g., keeping controllers associated with a monitored value and/or actuator in a selected power mode).
  • an example procedure 13200 to implement an automated operation of a vehicle is schematically depicted.
  • the example procedure 13200 includes an operation 13202 to interpret an automated operation value, an operation 13204 to determine a trigger description value in response to the automated operation value, an operation 13206 to determine a trigger event occurrence in response to a trigger condition value and a vehicle data value, and an operation 13208 to execute a trigger response in response to the trigger event occurrence.
  • one or more trigger/event responses may be included in a recipe which may be created via an external tool, e.g., a cloud application, and deployed to one or more vehicles.
  • the example procedure 13300 in addition to procedure 13200, further includes an operation 13302 to maintain a controller and/or a receiver (e.g., a WiFi and/or cellular data receiver) in a selected power mode.
  • a controller and/or a receiver e.g., a WiFi and/or cellular data receiver
  • the example apparatus 13500 includes a policy acquisition circuit 13502 that interprets a vehicle policy data value 13508 including at least one requested vehicle property 13510, a parameter acquisition circuit 13504 structured to interpret a plurality of vehicle parameter values 13512, responsive to the at least one requested vehicle property 13508, from a number of providing end points, each of the number of providing end points on at least one network zone of a vehicle.
  • An example vehicle policy data value 13508 further includes an authorization value 13522, which may be utilized to determine whether transmission is authorized, and/or to determine if certain transmission resource utilizations are authorized.
  • the example apparatus 13500 further includes a vehicle data transmission circuit 13506 that selectively transmits at least a portion of collected vehicle data 13520, for example provided by end points responsive to the vehicle parameter values 13512, and provided as transmitted vehicle data 13518.
  • the vehicle parameter values 13512 are retrieved from a network zone of the vehicle, and/or requested from an end point where a given vehicle parameter value 13512 is not already available on a network zone.
  • An example vehicle data transmission circuit 13506 further selectively transmits the at least a portion of the collected vehicle data 13520 by selecting a transmission interval 13516 for the at least a portion of the collected vehicle data 13520.
  • An example vehicle data transmission circuit 13506 is further structured to select the transmission interval 13516 in response to at least one of: an interval provided in the vehicle policy data value 13508; an interval responsive to a priority of the at least a portion of the collected vehicle data 13520; an interval responsive to an availability description for transmitting resources (e.g., based on current vehicle operating conditions, availability of external data communication, current bandwidth for a network zone supporting external communications, and/or a transceiver providing external communications, etc.) for the at least a portion of the collected vehicle data 13520; an interval responsive to a historical transmission availability for the vehicle; and/or an operating condition of the vehicle.
  • resources e.g., based on current vehicle operating conditions, availability of external data communication, current bandwidth for a network zone supporting external communications, and/or a transcei
  • An example vehicle data transmission circuit 13506 is further structured to selectively transmit the at least a portion of the collected vehicle data 13520 by selecting a bandwidth utilization 13524 for the at least a portion of the collected vehicle data 13520 (e.g., a permitted bandwidth utilization for the element of the collected vehicle data 13520).
  • An example vehicle data transmission circuit 13506 is further structured to select the bandwidth utilization 13524 in response to at least one of: a bandwidth utilization provided in the vehicle policy data value; a bandwidth utilization responsive to a priority of the at least a portion of the collected vehicle data 13520; a bandwidth utilization responsive to an availability description for transmitting resources for the at least a portion of the collected vehicle data 13520; an interval responsive to a historical transmission availability for the vehicle; or an operating condition of the vehicle.
  • An example vehicle data transmission circuit 13506 is further structured to selectively transmit the at least a portion of the collected vehicle data by selecting a transmission interval 13516 in response to a data type 13514 of the at least a portion of the collected vehicle data 13520.
  • the vehicle data transmission circuit 13506 is further structured to selectively transmit the at least a portion of the collected vehicle data 13520 in response to a vehicle operational impact 13536 of transmission operations (e.g., based on utilization of network zones and/or external data transfer resources according to various operating conditions of the vehicle, such as an operating state, power throughput, engine speed, etc.).
  • the vehicle data transmission circuit is further structured to selectively transmit the at least a portion of the collected vehicle data in response to a power utilization impact of transmission operations.
  • the vehicle data transmission circuit 13506 is further structured to selectively transmit the at least a portion of the collected vehicle data 13520 in response to a data transmission capacity value 13532.
  • the data transmission capacity value 13532 includes at least one data transmission capacity value such as: a data transmission capacity 13532 associated with a time interval (e.g., a transmission rate, and/or an amount of data over a predetermined time period); a data transmission capacity 13532 associated with an entity related to the at least a portion of the collected vehicle data; a data transmission capacity 13532 associated with an access point name; a data transmission capacity 13532 associated with a flow related to the at least a portion of the collected vehicle data; a data transmission capacity 13532 associated with an application of the vehicle related to the at least a portion of the collected vehicle data; or a data transmission capacity 13532 associated with a vehicle function related to the at least a portion of the collected vehicle data.
  • An example vehicle data transmission circuit 13506 is further structured to selectively transmit the at least a portion of the collected vehicle data 13520 in response to a currently available transmission type 13526, for example a cellular data transmission, WiFi transmission, physically connected device transmission, or the like.
  • the vehicle data transmission circuit 13506 is further structured to selectively transmit the at least a portion of the collected vehicle data by selecting a data transmission chunk size 13538 for the at least a portion of the collected vehicle data.
  • the data transmission chunk size 13538 includes at least one of an individual message size (e.g., a packet size value) or a single transmission flow size (e.g., a data amount to be transmitted over the course of a single transmission attempt period).
  • An example vehicle data transmission circuit 13506 is further structured to select the transmission chunk size 13538 in response to at least one of: a transmission chunk size provided in the vehicle policy data value; a transmission chunk size to a priority of the at least a portion of the collected vehicle data (e.g., increasing a chunk size to pass high priority data faster, and/or reducing a chunk size to improve a success rate of transmitting high priority data); a transmission chunk size responsive to an availability description for transmitting resources for the at least a portion of the collected vehicle data (e.g., configuring chunk size based on a capability of available transmission resources); a transmission chunk size responsive to a historical transmission availability for the vehicle; or an operating condition of the vehicle.
  • a transmission chunk size provided in the vehicle policy data value e.g., increasing a chunk size to pass high priority data faster, and/or reducing a chunk size to improve a success rate of transmitting high priority data
  • An example vehicle transmission circuit 13506 is further structured to adjust the selectively transmitting the at least a portion of the collected vehicle data in response to a success parameter 13534 for transmitting operations (e.g., allowing for adjustment and/or variation in transmission parameters to continuously improve transmissions, and/or adapt transmission parameters to conditions).
  • the vehicle transmission circuit is further structured to adjust the selectively transmitting the at least a portion of the collected vehicle data in response to a quality of service parameter 13528 for transmitting operations (e.g., adapting transmission selections to improve a quality of service, to enforce a quality of service requirement, etc.).
  • an example procedure 13600 to manage transmission operations of a vehicle is schematically depicted.
  • the example procedure 13600 includes an operation 13602 to interpret a vehicle policy data value, an operation 13604 to interpret vehicle parameter values responsive to the vehicle properties of the vehicle policy data value, and an operation 13606 to selectively transmit at least a portion of the collected vehicle data.
  • example operations 13606 to selectively transmit at least a portion of the collected vehicle data are schematically depicted.
  • an operation 13606 includes selectively transmitting collected data in response to a selected transmission interval.
  • an operation 13606 includes selectively transmitting collected data in response to a selected bandwidth utilization.
  • an operation 13606 includes selectively transmitting collected data in response to a data type of the collected data.
  • an operation 13606 includes selectively transmitting collected data in response to a vehicle operational impact of transmission operations.
  • an operation 13606 includes selectively transmitting collected data in response to a power utilization impact of transmission operations.
  • an operation 13606 includes selectively transmitting collected data in response to a data transmission capacity value.
  • an operation 13606 includes selectively transmitting collected data in response to a currently available transmission type.
  • an operation 13606 includes selectively transmitting collected data in response to a selected data transmission chunk size.
  • an example operation 13606 includes selectively transmitting collected data in response to a success parameter for transmitting operations.
  • an example operation 13606 includes selectively transmitting collected data in response to a quality of service value for transmitting operations.
  • the example apparatus 14700 includes a remote access execution circuit 14702 structured to interpret a remote access request value 14710 from a requesting device (e.g., an external device coupled to a cloud system, and/or otherwise in communication with the vehicle), the remote access request value 14710 including at least one requested vehicle property 14712.
  • the example apparatus 14700 includes a property translation circuit 14704 structured to determine a property request value 14714 in response to the at least one requested vehicle property 14712, and a parameter acquisition circuit 14706 structured to interpret a plurality of vehicle parameter values 14716 in response to the property request value 14714.
  • the example apparatus 14700 includes a parameter conditioning circuit 14708 structured to generate, in response to the property request value 14714, vehicle property data 14718 from the plurality of vehicle parameter values 14716, the vehicle property data 14718 corresponding to at least one the requested vehicle property 14712, where the remote access execution circuit 14702 is further structured to transmit the vehicle property data 14718 to the requesting device - for example as transmitted vehicle property data 14720.
  • a parameter conditioning circuit 14708 structured to generate, in response to the property request value 14714, vehicle property data 14718 from the plurality of vehicle parameter values 14716, the vehicle property data 14718 corresponding to at least one the requested vehicle property 14712, where the remote access execution circuit 14702 is further structured to transmit the vehicle property data 14718 to the requesting device - for example as transmitted vehicle property data 14720.
  • the requested vehicle property 14712 describes a parameter of interest to a user of the requesting device, which may be selected from an interface - for example a service interface (e.g., where technical assistance is provided by a remote service personnel), and/or an owner or operator of the vehicle (e.g., where the owner/operator remotely accesses the vehicle to determine data of interest and/or perform a remote operation).
  • the property request value 14714 may be provided as a value to be requested, for example from an end point of a network zone of the vehicle, and the vehicle parameter value 14716 is the responsive value provided by the end point.
  • the vehicle property data 14718 includes the vehicle parameter value 14716, configured according to the external value as requested in the requested vehicle property 14712, for example a value determined from one or more vehicle parameter values 14716, and/or a vehicle parameter value 14716 which has formatting, selected units, sampling rates, bit depth, etc. configured to the requested vehicle property 14712.
  • An example apparatus 14700 includes a converged network device (CND) structured 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 14716 are generated by each of the first network endpoint and the second network endpoint.
  • CND converged network device
  • the apparatus further includes wherein the remote access request value 14710 further includes a vehicle function value 14722 - for example an actuator operation, a feature to be enabled, exercised, and/or configured, and/or a sequence of operations (e.g., starting an engine, operating the vehicle through a sequence of operations, testing a number of actuators, etc.).
  • An example property translation circuit 14704 determines an actuator command value 14726 in response to the vehicle function value 14722; and a remote operation circuit 14724 provides the actuator command value 14726 to an endpoint of a network zone of a vehicle.
  • An example apparatus 14700 further includes a converged network device (CND) structured to regulate communications between a first network zone having a first network endpoint and a second network zone having a second network endpoint and including the network zone of the vehicle; wherein the first network endpoint provides at least a portion of the plurality of vehicle parameter values; and wherein the second network endpoint includes an actuator responsive to the actuator command value 14726.
  • CND converged network device
  • An example property translation circuit 14704 is further structured to determine the actuator command value 14726 by performing at least one operation such as: determining the actuator command value 14726 as a sequence of actuator commands corresponding to a diagnostic test operation; determining the actuator command value 14726 as a sequence of actuator commands corresponding to a remote control operation; and/or determining the actuator command value 14726 as at least one actuator command responsive to the vehicle function value 14722.
  • An example apparatus 14700 includes an additional number of endpoints distributed across at least the first network zone and the second network zone, wherein the additional plurality of endpoints each provide at least a portion of the plurality of vehicle parameter values 14716.
  • An example apparatus 14700 further includes an additional number of endpoints distributed across at least the first network zone and the second network zone, wherein the additional plurality of endpoints each include a corresponding actuator, each responsive to at least a portion of the actuator command value 14726.
  • An example remote access request value 14710 includes a policy.
  • the policy includes at least one value such as: an authorization value of the requesting device; a data collection description including the at least one requested vehicle property; a trigger description value including a trigger condition and a trigger response value, and where the parameter acquisition circuit 14706 is further structured to generate at least a portion of the vehicle property data 14718 from the plurality of vehicle parameter values 14716 further in response to the trigger description value and/or a policy priority value.
  • FIG. 148 an example system including an apparatus 14700 is schematically depicted.
  • the example system may include any apparatus as set forth herein, and is not limited to inclusion of the apparatus 14700. Additionally or alternatively, the apparatus 14700 and/or portions thereof may be provided on the vehicle 14806, and/or on the external device 14804.
  • the example of Fig. 148 illustrates the apparatus 14700 provided as a cloud system, but a connection between the external device 14804 and the vehicle 14806 may be provided in any manner, including connection through a WiFi, LAN, and/or any other connection configuration described throughout the present disclosure.
  • the external device 14804 may couple directly to the vehicle 14806, with operations of the apparatus 14700 performed in a cloud system, and/or on the vehicle 14806 and/or the external device 14804.
  • the example of Fig. 148 includes a CND 14802 configured to allow data value and/or actuator access between network zones 14808, 14810 of the vehicle 14806.
  • the system of Fig. 148 allows for remote assistance and/or remote control operations of the vehicle 14806, including access to data values, operation of actuators, and/or operation of more complex operational features, regardless of the configuration of end points on the vehicle 14806, and without requiring knowledge of the vehicle configuration by the user of the external device 14804, and/or a user configuring operations of the apparatus 14700.
  • FIG. 149 an example procedure 14900 for performing remote operations for a vehicle, including remote assistance operations, is schematically depicted.
  • the example procedure 14900 includes an operation 14902 to interpret a remote access request value, including at least one requested vehicle property, an operation 14904 to determine a property request value in response to the requested vehicle property, an operation 14906 to interpret vehicle parameter value(s) in response to the requested vehicle property, an operation 14908 to generate vehicle property data, responsive to the property request value, from the vehicle parameter values, and an operation 14910 to transmit the vehicle property data to the requesting device.
  • FIG. 150 an example procedure 15000 for performing operations for a vehicle, including remote assistance operations, is schematically depicted.
  • the example procedure 15000 includes an operation 15002 to interpret a remote access request value, including a vehicle function value, an operation 15004 to determine an actuator command value in response to the vehicle function value, and an operation 15006 to provide an actuator command value to an end point of a network zone of the vehicle.
  • the apparatus 15100 may be a standalone controller or form part of one or more of any of the controllers described herein. As such, in embodiments, the apparatus 15100 may be disposed onboard a vehicle. In embodiments, as explained in greater detail herein, part of, or all of the apparatus 15100 may be disposed offboard a vehicle.
  • the apparatus 15100 includes a parameter acquisition circuit 15110 structured to interpret a vehicle parameter value 15112.
  • the apparatus 15100 further includes a property translation circuit 15114 structured to interpret a property request value 15116 that defines, at least in part, a requested vehicle property.
  • the apparatus 15100 further includes a parameter conditioning circuit 15118 structured to generate, in response to the property request value 15116, vehicle property data 15120 from the vehicle parameter value 15112.
  • vehicle property data 15120 may correspond to the requested vehicle property, e.g., the vehicle property defined, at least in part, by the property request value 15116.
  • FIG. 151 An embodiment of the apparatus 15100 is depicted in Fig. 151 as interpreting/receiving a single vehicle parameter value 15112. It is to be understood, however, that embodiments of the apparatus 15100 may interpret/receive a plurality of vehicle parameter values 15112.
  • the apparatus 15100 may continuously collect vehicle parameter values 15112 over a period of time, e.g., for a day, week, month, year, the operating life of a vehicle, etc., and/or under certain conditions, e.g., while the vehicle is occupied and/or unoccupied, being driven and/or stationary, during periods when a parameter value is within a predetermined range, above or below a predetermined threshold, and/or in response to a characteristic of the parameter (e.g., having a rate of change greater than a predetermined value and/or within a predetermined range, having a selected value, switching between selected values, etc.).
  • a characteristic of the parameter e.g., having a rate of change greater than a predetermined value and/or within a predetermined range, having a selected value, switching between selected values, etc.
  • the example parameter and collection values are described as relating to a particular parameter for illustration, but collected parameters and/or collection criteria may utilize a number of parameters, an operating condition of the vehicle, or the like. Parameters for collection and/or to determine collection criteria may be quantitative (e.g., a numerical value) and/or qualitative (e.g., a category, Boolean value, state value, etc.).
  • the vehicle parameter values 15112 may be generated by one or more vehicle sensors, vehicle controllers, and/or vehicle actuators (e.g., a feedback value, position value, fault value, etc.) as described herein.
  • Non-limiting examples of vehicle parameter values include vehicle speed values, prime mover speed values, prime mover torque values, user actuated vehicle feature values, vehicle location values, network utilization values for a network zone of the vehicle, raw network messages from a network zone of the vehicle, network addresses for endpoints on a network zone of the vehicle, memory storage description of a controller of the vehicle, values from endpoints on a controller area network (CAN), values from endpoints from a local interconnect network (LIN), intermediate control values, an actuator state or feedback value, and/or the like.
  • vehicle parameter values include vehicle speed values, prime mover speed values, prime mover torque values, user actuated vehicle feature values, vehicle location values, network utilization values for a network zone of the vehicle, raw network messages from a network zone of the vehicle, network addresses for endpoints on a network zone of the vehicle, memory storage description of a controller of the vehicle, values from endpoints on a controller area network (CAN), values from endpoints from a local interconnect network (LIN), intermediate control values, an actuator state or
  • the vehicle parameter value may be any value available on a network zone of a vehicle, on an end point of the vehicle, in a memory of a controller of the vehicle, and/or available to be provided by an end point of the vehicle, for example in response to a request or command to the end point to provide the parameter.
  • the embodiment of the apparatus 15100 in Fig. 151 is also depicted as interpreting/receiving a single property request value 15116. It is to be understood, however, that embodiments of the apparatus 15100 may interpret/receive a plurality of property request values 15116. For example, the apparatus 15100 may continuously collect property request values 15116 over a period of time, e.g., for a day, week, month, year, the operating life of a vehicle, etc., and/or under certain conditions, e.g., while the vehicle is occupied and/or unoccupied, being driven and/or stationary, etc.
  • the property request values 15116 may be generated offboard a vehicle by one or more computing devices, as described herein, and transmitted to the vehicle via one or more network connections, as also described herein.
  • vehicle properties include component temperature values, sensor raw values, component speed values, actuator feedback values, drivetrain component speed values, drive shaft speed values, drive shaft torque values, selected gear values, battery state of health values, battery state of charge values, battery throughput values, and/or the like.
  • the parameter acquisition circuit 15110 may include and/or communicate with one or more electrical communication ports that have access to network devices, controllers and/or sensors, disposed onboard a vehicle, that generate and/or have access to devices, e.g., vehicle sensors, that generate vehicle parameter values 15112.
  • An example parameter acquisition circuit 15110 may be capable to communicate with any network zone of the vehicle, any end point of the vehicle, and may take data from any network zone and/or end point, a memory of a controller, and/or may command any end point to provide a value - for example a value that is available on the end point but not normally published to a network zone.
  • the property translation circuit 15114 may include and/or communication with one or more electrical communication ports that have access to network devices and/or controllers that have access to the property request values 15116.
  • An example property translation circuit 15114 determines available property request values 15116 that are responsive to the vehicle parameter values 15112 - for example allowing an external device and/or other user to request vehicle data using a general term for the data (e.g., “vehicle speed”), while configuring the property request value 15116 to get the selected data from the vehicle without requiring knowledge of the data location, vehicle configuration, parameter and/or control operation version, etc.
  • an interface to the external device to allow request of the vehicle parameter values 15112 for collection can be configured for operations of the requesting user interface, without having to update and/or have knowledge of information about the vehicle, the vehicle network zone configuration, and/or the location or details of control operations and/or data availability on the vehicle.
  • the interface to the external device will operate properly for a range of vehicles (e.g., multiple models, model years, trims, configurations, etc.), and continue to operate properly when a specific vehicle experiences a change (e.g., movement of an end point, upgrading a control operation, addition or removal of an end point, changing control operation locations, addition of a feature or control operation, etc.).
  • the property conditioning circuit 15118 may communicate with the parameter acquisition circuit 15110 and/or the property translation circuit 15114.
  • Generation of the vehicle property data 15120 may include conditioning, formatting, interpolation and/or other adjusting and/or manipulation of the vehicle parameter values 15112.
  • the vehicle parameter values 15210 directly correspond to the requested vehicle property
  • the vehicle property data 15214 conveys substantially the same information as the vehicle parameter value 15210 - for example utilizing the same unit type (e.g., length, mass, time, etc.), having a difference only in the time domain (e.g., a sampling rate difference), and/or where vehicle parameter value 15210 and/or vehicle property data 15214 include sufficient information to be correlated except for potentially changes in formatting, processing, and the like.
  • the property conditioning circuit 15118 may adjust the format and/or units of the vehicle parameter value 15210 when generating the vehicle property data 15214.
  • Formatting of the vehicle parameter value 15210 may include adjusting the network protocol of the vehicle parameter value 15210 for transmission off the vehicle, e.g., the vehicle parameter value 15210 may be received in CAN format with its underlying data repackaged by the property conditioning circuit 15118 into a TCP/IP packet. While the foregoing example describes a CAN to TCP/IP conversion, embodiments of the apparatus 15200 may perform conversion between other types of networks described herein.
  • formatting of the vehicle parameter value 15210 includes any one or more of: up-sampling parameter values; down-sampling parameter values; changing a bit depth of a parameter value (e.g., a number of fixed point bits assigned to the value, and/or a precision level of a floating point parameter value); changing a sampling rate of the parameter value (e.g., how often a sensor, controller, or other end point provides an updated value); changing a processing of the parameter value (e.g., filtering, de-bouncing, reserved ranges that indicate information such as faults, diagnostic values, state values, etc.); changing a name of the parameter value; and/or adding, removing, and/or modifying metadata of the parameter value (e.g., a time stamp, source end point, packet information, associated application and/or flow, etc.).
  • a bit depth of a parameter value e.g., a number of fixed point bits assigned to the value, and/or a precision level of a floating point parameter value
  • Fig. 153 Shown in Fig. 153 is another embodiment of the apparatus 15300 wherein the property conditioning circuit 15310 may generate vehicle property data 15312 from two or more vehicle parameter values 15314 and 15316.
  • the property conditioning circuit 15310 may generate/derive a virtual vehicle property value 15318 (also shown in Fig. 154) from the two or more vehicle parameter values 15314 and 15316, wherein the vehicle property data 15312 includes the virtual vehicle property value 15318.
  • a property request value 15320 may request a property, e.g., an estimated vehicle operating cost value, while the vehicle may not have any sensors that directly generate the requested property.
  • a virtual vehicle property value 15318 may be provided even where a directly generated property would be available - for example to reduce network traffic (e.g., while the value is available, the value can also be determined from other values already being collected); as a backup value (e.g., utilizing the virtual vehicle property value 15318 in response to a sensor associated with a directly generated property being in a fault condition); to reduce other processing (e.g., the directly available value requiring additional formatting operations, where the use of the virtual vehicle property value 15318 requires fewer formatting operations); in response to priority and/or authorization considerations (e.g., where a requesting flow, entity, application, etc.
  • the property conditioning circuit 15310 may derive the requested property as a virtual vehicle property value 15318 from the two or more vehicle parameter values 15314 and 15316, e.g., a fuel efficiency sensor or determined value, oil change detection sensor or determined value, etc.
  • Non- limiting examples of virtual vehicle properties include: vehicle speed values; motive power efficiency values; event occurrence values; a listing of previous vehicle locations; estimated temperature values; estimated pressure values; effective temperature values; effective pressure values; heat transfer rate values; remaining life values for components; time to maintenance values for a component; diagnostic counter values; a listing of one or more user activated features; an average vehicle runtime value; an estimated vehicle operating cost value; a state value of any end point, sensor, actuator, control operation, and/or the vehicle; and/or the like.
  • generation/derivation of the virtual vehicle property value 15318 from the from the two or more vehicle parameter values 15314 and 15316 may include interpolation, operation of a model, utilization of one or more lookup tables, operation of a state diagram, etc.
  • a value that is directly available to the property conditioning circuit 15310 may be a virtual parameter value determined from a number of other parameters in the system, but treated as a directly available value by the property conditioning circuit 15310 because it is available for direct request as a parameter.
  • a virtual vehicle property value 15318 as used herein includes a value that the property conditioning circuit 15310 determines from one or more additional directly available values, and/or a parameter provided directly by another controller where the property conditioning circuit 15310 can adjust, control, confirm, verify, and/or otherwise have visibility to the determination of the directly provided parameter value.
  • FIG. 154 Illustrated in Fig. 154 is another embodiment of the apparatus 15400 for collecting and/or managing vehicle data in accordance with this disclosure.
  • the apparatus 15400 include a parameter acquisition circuit 15110, a property translation circuit 15114 and a property conditioning circuit 15118, as described herein.
  • the apparatus 15400 may further include a requestor verification circuit 15410 structured to determine an entity authorization value 15412, and a vehicle property provisioning circuit 15414 structured to transmit the vehicle property data 15120 in response to the entity authorization value 15412. Determination of the entity authorization value 15412 may be responsive and based at least in part on the property request value 15116.
  • the property request value 15116 may contain an indicator of a requesting entity, e.g., the entity that generated the property request value 15116, and the requestor verification circuit 15410 may check the requesting entity against an approved access list. If the approved access list indicates the requesting entity is authorized to access the requested property, then the entity authorization value may be structured to indicate the same so that the vehicle property provisioning circuit 15414 transmits the vehicle property data 15120 to the requesting entity, or to an entity and/or location indicated by the property request value 15116 as being approved by the requesting entity to receive the vehicle property data 15120.
  • the apparatus 15120 may receive a property request value 15116 from a vehicle manufacturer that calls for vehicle property data 15120 to be transmitted to an approved third-party vendor.
  • the apparatus 15400 may check, via the requestor verification circuit 15410, the vehicle manufacturer and/or the third-party vendor against an approved access list and then transmit vehicle property data 15120 to the third-party vendor if the vehicle manufacturer and/or the third-party vendor are on the approved access list.
  • the requestor verification circuit 15410 may check, via the requestor verification circuit 15410, the vehicle manufacturer and/or the third-party vendor against an approved access list and then transmit vehicle property data 15120 to the third-party vendor if the vehicle manufacturer and/or the third-party vendor are on the approved access list.
  • embodiments of the disclosure may use other forms of authentication and/or verification to control access to the vehicle property data 15120, e.g., encryption keys, digital certificates, etc.
  • the apparatus 15400 may include a subscription circuit 15416 structured to add a requesting entity, e.g., the entity that generated the property request value 15116, to a subscriber data list 15418, wherein the property provisioning circuit 15414 is structured to transmit the vehicle property data 15120 to the requesting entity in response to the subscriber data list 15418. Addition of the requesting entity to the subscriber data list 15418 may be responsive to the property request value 15116. For example, an interpreted property request value 15416 may trigger the subscription circuit 15416 to add the requesting entity to the subscriber data list 15418. The vehicle property provisioning circuit 15414 may then transmit, periodically or continuously, the vehicle property data 15120 to the requesting entity (or to an entity and/or location approved by the requesting entity) as long as the requesting entity remains on the subscriber data list 15418.
  • a subscription circuit 15416 structured to add a requesting entity, e.g., the entity that generated the property request value 15116, to a subscriber data list
  • the apparatus 15400 may include a CND 15420, as described herein, that regulates 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 15421 may be generated by at least one of the first and/or the second vehicle sensor.
  • a first vehicle parameter value 15421 may be generated by the first vehicle sensor (in the first network zone) and a second vehicle parameter value 15422 may be generated by the second vehicle sensor (in the second network zone).
  • the first network zone and the second network zone may be of distinct types, as described herein.
  • Fig. 155 an embodiment of a method 15500 for collecting and/or managing vehicle data in accordance with this disclosure is shown.
  • the method 15500 may be performed by the apparatuses 15100 and/or 15400 and/or by the controller and/or processors of any other device described herein. Accordingly, with reference to Figs. 151 and 155, the method 15500 includes interpreting 15510 a vehicle parameter value 15112, interpreting 15512 a property request value 15116, and generating 15514 vehicle property data 15120.
  • the method 15500 may further include determining 15610, in response to and based at least in part on the property request value 15116, an entity authorization value 15412 and transmitting 15612 the vehicle property data 15120 in response to the entity authorization value 15412.
  • the method 15500 may further include adding 15614 a requesting entity to a subscriber data list 15418 in response to the property request value 15116.
  • transmitting 15612 of the vehicle property data 15120 may be in response to the subscriber data list 15418.
  • the method 15500 may include regulating 15710 communications between a first network zone having a first vehicle sensor and a second network zone having a second vehicle sensor.
  • the method 15500 may further include generating 15712 the vehicle parameter value(s) and/or 15421 and/or 15422 by at least one of the first and the second vehicle sensors.
  • interpreting 15510 the vehicle parameter value may include interpreting 15714 a plurality of vehicle parameter values 15421 and 15422.
  • generating 15514 the vehicle property data is based, at least in part on, the plurality of vehicle parameter values 15421 and 15422.
  • a first vehicle parameter value 15421 may be from the first vehicle sensor (in the first network zone) and a second vehicle parameter 15422 may be from the second vehicle sensor (in the second network zone).
  • embodiments of the disclosure may provide for a requesting entity to be agnostic with respect to the manner in which different vehicles acquire/collect data, and/or the configuration (e.g., network zones, end points, control operation locations, etc.) of the vehicle.
  • embodiments of the disclosure may provide for a requesting entity to use the same type of property request value to request the same vehicle property from different vehicles, and/or from the same vehicle having different configurations, regardless of any underlying distinctions between how the vehicles collect and configure their own vehicle parameters.
  • a first vehicle of a first make, model and year may have an oil temperature sensor disposed on a CAN.
  • a requesting entity may be able to retrieve the oil temperature from the first vehicle via a first property request value that requests “oil temperature”.
  • the first property request value may then be interpreted by an apparatus, e.g., 15100 or 15400, which then generates first vehicle property data providing the oil temperature of the first vehicle to the requesting entity.
  • a newer version of the model of the first vehicle e.g., a second vehicle of the same make and model but of a newer year, may have an oil temperature sensor disposed on an Ethernet, and/or the oil temperature sensor may be of a completely different type and/or have a differently formatted output, as compared to the oil temperature of the first vehicle.
  • Embodiments of the disclosure provide for the requesting entity to send a second property request, that is substantially the same as the first property request, requesting “oil temperature” to the second vehicle.
  • the second property request may then be interpreted by an apparatus, e.g., 15100 or 15400, which then generates second vehicle property data, that may be substantially the same as the first vehicle property data, which provides the oil temperature of the second vehicle to the requesting entity.
  • the method 15800 includes interpreting 15810 a first property request value and generating 15812 first vehicle property data from a first plurality of vehicle parameter values.
  • the method 15800 further includes interpreting 15814 a second property request value corresponding to the requested vehicle property and generating 15816 second vehicle property data from a second plurality of vehicle parameter values.
  • the first vehicle data and the second vehicle data both corresponding to the requested vehicle property.
  • generating the vehicle property data 15514 may include generating 15716 a virtual vehicle property 15618.
  • the method 15800 may further include generating 15910 the first plurality of vehicle parameter values via a first vehicle sensor and a second vehicle sensor, the first vehicle sensor disposed on a first network of the first vehicle and the second vehicle sensor disposed on a second network of the first vehicle, the first network of a distinct type from the second network.
  • the method 15800 may further include generating 15912 the second plurality of vehicle parameter values via a third vehicle sensor and a fourth vehicle sensor, the third vehicle sensor disposed on a third network of the second vehicle and the fourth vehicle sensor disposed on a fourth network of the second vehicle, the third network of a distinct type from the fourth network.
  • Fig. 160 an embodiment of an apparatus 16000 for data collection policy intake and execution, in accordance with an embodiment of the disclosure, is shown.
  • embodiments of the apparatus 16000 may provide for the intake, parsing, and/or execution of vehicle policies that control collection and/or transmission of vehicle data.
  • policies may provide for the collection of specific types of vehicle data and/or specific time periods and/or conditions triggering collection of vehicle data.
  • a policy may be used to start and stop data collection based on a particular region, e.g., city, state/province, country, etc., and the applicable data privacy laws within such regions.
  • embodiments of the apparatus 16000 may trigger the collection and/or transmission of one or more types of vehicle data when sensors and/or controllers, onboard and/or offboard the vehicle, determine that the vehicle is in a region where collection of such types of vehicle data is permissible under applicable privacy laws. Similarly, embodiments of the apparatus 16000 may trigger the ceasing of collection and/or transmission of one or more types of vehicle data when sensors and/or controllers, onboard and/or offboard the vehicle, determine that the vehicle is in a region where collection of such types of vehicle data is prohibited under applicable privacy laws.
  • embodiments of the apparatus 16000 may determine whether and/or when certain data is passively collected or actively collected. Passive data collection indicates, in certain embodiments, that a parameter for collection is available without operations of the apparatus 16000, for example where a parameter is ordinarily provided to a network zone by an end point, and observable on the network zone without a specific request or other action.
  • Active data collection indicates, in certain embodiments, that a parameter for collection is not available, only intermittently available, and/or available but not in a fully usable manner for collection - for example the parameter is provided at an insufficient data rate, not provided continuously, and/or provided with insufficient resolution or other aspects, where the apparatus 16000 provides a request or instruction to the end point providing the actively collected data. It will be understood that a data parameter may be collected actively at a first time and/or during certain operating conditions, and collected passively at a second time and/or under other operating conditions.
  • operations of the apparatus 16000 to collect a data parameter may be considered active for certain purposes (e.g., providing an instruction to an end point to provide the parameter and/or configure the parameter), but passive for other purposes (e.g., during periods when the end point is already configured to provide the parameter sufficient to meet the instructions, even if the instructions were absent).
  • embodiments of the apparatus 16000 may provide for the delegation of the collection of vehicle data to various controllers disposed onboard and/or offboard a vehicle.
  • the apparatus 16000 may serve as a collection point for vehicle data gathered by the delegate controllers.
  • the apparatus 16000 includes a policy acquisition circuit 16010 structured to interpret a vehicle policy data value 16012 having at least a portion of a vehicle policy.
  • the vehicle policy data value 16012 may be a text file having coded instructions therein, e.g., an XML file or other markup based format.
  • the vehicle policy data value 16012 may be a data file having coded instructions therein, e.g., machine code, assembly, high level code, e.g., C, C#, Ada, and/or other suitable programing code.
  • the policy data value may be a data structure, e.g., an instantiated class object having various fields and/or properties that store data effecting portions of a vehicle policy.
  • the apparatus 16000 further includes a policy processing circuit 16014 structured to generate, in response to and based at least in part on the vehicle policy data value 16012, parsed policy data 16016 that includes one or more vehicle sub-policies of the vehicle policy.
  • the apparatus 16000 further includes a policy execution circuit 16018 structured to collect vehicle data 16020 from one or more vehicle sensors, as described herein, in response to the parsed policy data 16016.
  • the policy execution circuit 16018 may electronically communicate with one or more sensors, actuators, and/or controllers in the vehicle.
  • the policy execution circuit 16018 may also electronically communicate with and/or control the other circuits of the apparatus 16000, as described herein.
  • the policy execution circuit 16018 may interpret portions of the parsed policy data 16016 and generate command values for controlling operation of actuators.
  • a portion of the parsed policy data 16016 may correspond to a sub-policy concerning a fuel timing rate of an engine of the vehicle, wherein the policy execution circuit 16018 may generate and transmit a command value that updates the fuel timing to a controller responsible for controlling the fuel timing of the engine.
  • the policy execution circuit 16018 may interpret a portion of the parsed policy data 16016 corresponding to a sub-policy concerning what types of vehicle data are to be collected, the duration the vehicle data is to be collected, and whether the vehicle data is to be stored onboard the vehicle and/or transmitted offboard the vehicle.
  • a sub-policy may dictate that location data of a vehicle is to be collected whenever the engine of the vehicle is being operated, and that the collected vehicle data is to be stored in a memory device onboard the vehicle as it is collected.
  • the sub-policy may further dictate that the collected vehicle data is to be transmitted at pre-determined intervals, e.g., once a day, week, month, etc., to a database offboard the vehicle.
  • the policy execution circuit 16018 may direct circuits of the apparatus 16000, and/or of other controllers onboard the vehicle, to collect location data and store it within the onboard memory device. The policy execution circuit 16018 may then direct circuits of the apparatus 16000, and/or of other controllers onboard the vehicle, to transmit the collected location data at the pre determined intervals to the offboard database. While the foregoing example concerned location data, other types of vehicle data are contemplated.

Abstract

L'invention concerne un appareil de gestion de collecte de données de véhicule comprenant un circuit de commande d'accès à distance, un circuit de traduction de propriétés, un circuit d'acquisition de paramètres, un circuit de commande à distance et un circuit de conditionnement de paramètres. Le circuit de commande d'accès à distance interprète une valeur de demande d'accès à distance comprenant une propriété de véhicule et/ou une valeur de fonction de véhicule demandée. Le circuit de traduction de propriétés détermine: une valeur de demande de propriété adaptée à la propriété de véhicule demandée; et/ou une valeur de commande d'actionneur adaptée à la valeur de fonction de véhicule. Le circuit d'acquisition de paramètres interprète des valeurs de paramètres de véhicule adaptées à la valeur de demande de propriété. Le circuit de commande à distance fournit la valeur de commande d'actionneur à un point d'extrémité de zone de réseau de véhicule. Le circuit de conditionnement de paramètres génère, en réponse à la valeur de demande propriété, des données de propriétés de véhicule à partir des valeurs de paramètres de véhicule. Les données de propriété du véhicule correspondent à la propriété demandée de véhicule. Le circuit de commande d'accès à distance transmet les données de propriété de véhicule au dispositif demandeur.
EP21764127.3A 2020-03-06 2021-03-08 Système, procédé et appareil pour la gestion de collecte de données de véhicule Pending EP4097923A4 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US202062986444P 2020-03-06 2020-03-06
US202063024383P 2020-05-13 2020-05-13
US17/027,167 US11411823B2 (en) 2019-09-20 2020-09-21 System, method, and apparatus to support mixed network communications on a vehicle
US17/027,187 US11228496B2 (en) 2019-09-20 2020-09-21 System, method, and apparatus to extra vehicle communications control
US202063123531P 2020-12-10 2020-12-10
PCT/US2021/021421 WO2021178979A1 (fr) 2020-03-06 2021-03-08 Système, procédé et appareil pour la gestion de collecte de données de véhicule

Publications (2)

Publication Number Publication Date
EP4097923A1 true EP4097923A1 (fr) 2022-12-07
EP4097923A4 EP4097923A4 (fr) 2024-04-10

Family

ID=77612836

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21764127.3A Pending EP4097923A4 (fr) 2020-03-06 2021-03-08 Système, procédé et appareil pour la gestion de collecte de données de véhicule

Country Status (5)

Country Link
EP (1) EP4097923A4 (fr)
JP (1) JP2023516760A (fr)
KR (1) KR20220152268A (fr)
CN (1) CN115443637A (fr)
WO (1) WO2021178979A1 (fr)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11763410B1 (en) * 2018-02-25 2023-09-19 Matthew Roy Mobile payment system for traffic prioritization in self-driving vehicles
US11538287B2 (en) 2019-09-20 2022-12-27 Sonatus, Inc. System, method, and apparatus for managing vehicle data collection
JP2022548324A (ja) 2019-09-20 2022-11-17 ソナタス インコーポレイテッド 車両外通信制御のためのシステム、方法、及び装置
US11772583B2 (en) 2020-03-06 2023-10-03 Sonatus, Inc. System, method, and apparatus for managing vehicle automation
US20230010673A1 (en) * 2021-07-07 2023-01-12 Jpmorgan Chase Bank, N.A. Method and system for jobsite monitoring
US11425196B1 (en) * 2021-11-18 2022-08-23 International Business Machines Corporation Prioritizing data replication packets in cloud environment
WO2023122156A1 (fr) * 2021-12-21 2023-06-29 Continental Automotive Systems, Inc. Système et procédé de conduite d'un véhicule dans de multiples régions de véhicule-à-tout (v2x)
CN115168053A (zh) * 2022-08-02 2022-10-11 北京天融信网络安全技术有限公司 进程管理方法、装置、电子设备及存储介质
CN117938825A (zh) * 2022-10-14 2024-04-26 广州汽车集团股份有限公司 远程控制方法、域控制器以及车辆
CN116567063B (zh) * 2023-07-10 2023-09-15 北京集度科技有限公司 车载控制器、服务发现方法及计算机程序产品
CN117170818B (zh) * 2023-09-25 2024-04-12 中关村科学城城市大脑股份有限公司 容器处理方法、装置、电子设备和计算机可读介质
CN117294347B (zh) * 2023-11-24 2024-01-30 成都本原星通科技有限公司 一种卫星信号接收处理方法

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001026330A2 (fr) * 1999-10-06 2001-04-12 Sensoria Corporation Reseaux de radiosenseurs integres hybrides en inter-reseau, et procede correspondant
US7844687B1 (en) * 1999-10-06 2010-11-30 Gelvin David C Method for internetworked hybrid wireless integrated network sensors (WINS)
US7401233B2 (en) * 2003-06-24 2008-07-15 International Business Machines Corporation Method, system, and apparatus for dynamic data-driven privacy policy protection and data sharing
US7584029B2 (en) * 2003-12-31 2009-09-01 Teradyne, Inc. Telematics-based vehicle data acquisition architecture
US7660652B2 (en) * 2006-02-02 2010-02-09 Signature Control Systems, Inc. Method, system and device for monitoring vehicle usage
US7917253B2 (en) * 2006-11-22 2011-03-29 General Motors Llc Method for making vehicle-related data available to an authorized third party
AU2007333025B2 (en) * 2006-12-13 2012-03-08 Crown Equipment Corporation Fleet management system
US7826944B2 (en) * 2006-12-14 2010-11-02 General Motors Llc Configurable vehicle bus storage cache mechanism
US20110196571A1 (en) * 2010-02-09 2011-08-11 At&T Mobility Ii Llc System And Method For The Collection And Monitoring Of Vehicle Data
US8390474B2 (en) * 2010-04-27 2013-03-05 General Motors Llc Method for collecting data and system for accomplishing the same
KR101470206B1 (ko) * 2013-08-29 2014-12-05 주식회사 현대케피코 이동 단말기 기반의 범용 통합 차량 제어 시스템
US9256467B1 (en) * 2014-11-11 2016-02-09 Amazon Technologies, Inc. System for managing and scheduling containers
KR101628566B1 (ko) * 2014-12-09 2016-06-08 현대자동차주식회사 차량 데이터 수집 시스템 및 방법
JP6032265B2 (ja) * 2014-12-10 2016-11-24 トヨタ自動車株式会社 車両データのリモート収集システム
JP2016119547A (ja) * 2014-12-19 2016-06-30 トヨタ自動車株式会社 車両データのリモート収集システム
JP6020611B2 (ja) * 2015-01-20 2016-11-02 トヨタ自動車株式会社 車両データのリモート収集システム
US9870656B2 (en) * 2015-12-08 2018-01-16 Smartcar, Inc. System and method for processing vehicle requests
CN107819736B (zh) * 2016-09-13 2021-12-31 现代自动车株式会社 基于车辆网络中的汽车安全完整性等级的通信方法及设备
US10210672B2 (en) * 2017-04-07 2019-02-19 Toyota Research Institute, Inc. Systems and methods for remotely controlling data collection by a vehicle
KR102320043B1 (ko) * 2017-09-13 2021-11-01 현대자동차주식회사 차량용 제어 장치의 진단 방법 및 장치
KR102041846B1 (ko) * 2017-11-14 2019-12-10 (주)세코인터페이스 Obd-ⅱ를 활용한 차량 can 데이터 자동 수집 단말기와 수집 방법
US10589717B2 (en) * 2017-12-13 2020-03-17 General Motors Llc Vehicle remote start functionality
JP7103788B2 (ja) * 2017-12-28 2022-07-20 トヨタ自動車株式会社 車載システム、ゲートウェイ、プログラム、情報処理方法、情報処理システム、及び車両

Also Published As

Publication number Publication date
WO2021178979A8 (fr) 2021-10-07
EP4097923A4 (fr) 2024-04-10
CN115443637A (zh) 2022-12-06
KR20220152268A (ko) 2022-11-15
WO2021178979A1 (fr) 2021-09-10
JP2023516760A (ja) 2023-04-20

Similar Documents

Publication Publication Date Title
US11721137B2 (en) System, method, and apparatus for managing vehicle data collection
EP4097923A1 (fr) Système, procédé et appareil pour la gestion de collecte de données de véhicule
US11929878B2 (en) System, method, and apparatus for extra vehicle communications control
US10939262B2 (en) System and method for bringing programmability and connectivity into isolated vehicles
US20220297635A1 (en) System, method, and apparatus for managing vehicle data collection
US20230158975A1 (en) System, method, and apparatus for managing vehicle automation
EP4315284A1 (fr) Système, procédé et appareil de gestion de la collecte de données de véhicule
US11772583B2 (en) System, method, and apparatus for managing vehicle automation
US20230161583A1 (en) System, method, and apparatus for managing vehicle automation
US20230154246A1 (en) System, method, and apparatus for managing vehicle automation
US20230154244A1 (en) System, method, and apparatus for managing vehicle automation
US20240163174A1 (en) System, method, and apparatus for extra vehicle communications control
US20240163173A1 (en) System, method, and apparatus for extra vehicle communications control

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220901

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230511

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: H04L0012240000

Ipc: H04W0004380000

A4 Supplementary search report drawn up and despatched

Effective date: 20240311

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/28 20060101ALI20240304BHEP

Ipc: H04L 47/41 20220101ALI20240304BHEP

Ipc: H04L 47/2416 20220101ALI20240304BHEP

Ipc: H04L 47/20 20220101ALI20240304BHEP

Ipc: H04W 4/44 20180101ALI20240304BHEP

Ipc: H04W 4/38 20180101AFI20240304BHEP