Systems, methods, and apparatus for performing vehicle diagnostics and configuration operations.

Abstract

The device may include a policy manager configured to interpret policies, including an automated escalation protocol for vehicle monitoring operations. The device may include a data collection manager configured to interpret vehicle data in response to vehicle monitoring operations. The device may include a monitoring manager configured to detect vehicle events in response to vehicle data and to execute an automated escalation protocol in response to determining that a vehicle event is active.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims priority to U.S. Provisional Patent Application No. 63 / 468,754, filed on May 24, 2023, entitled "SYSTEM, METHOD AND APPARATUS FOR PERFORMING VEHICLE DIAGNOSTIC AND CONFIGURATION OPERATIONS" (SONA - 0017 - P01).

[0002] The above application is hereby incorporated by reference in its entirety for all purposes.

Background Art

[0003] Vehicles and mobile applications increasingly rely on computer devices distributed around the vehicle to perform electronic control functions. With the growth of features, capabilities, and control operations on the vehicle, it has become difficult to ensure the correct operation and update of all computer devices, sensors, and actuators, and the identification of the causes of potential problems has become complex. Further, vehicles may have different configurations such as endpoints, network addresses, and component models even between slightly different vehicles, such as two vehicles of different model years, or within a closely related group of vehicles due to, for example, component upfits or updates during manufacturing, changes (e.g., lack of available identical parts, continuous improvement of the manufacturing process, response to problems found in in - use vehicles, etc.). As a result, the specific configuration of each vehicle is complex. Additionally, customer and commercial expectations for improved vehicle operation, downtime performance, and feature capabilities are continuously increasing, resulting in a situation where performance improvement is expected while it becomes more complex to meet those expectations.

Prior Art Documents

Patent Documents

[0004] [Patent Document 1] U.S. Patent Application Publication No. 17 / 027,167 [Patent Document 2] U.S. Patent Application Publication No. 17 / 027,187 [Patent Document 3] U.S. Patent Application Publication No. 17 / 195,589 [Patent Document 4] U.S. Patent Application Publication No. 17 / 833,614 [Patent Document 5] U.S. Patent No. 11,411,823 [Patent Document 6] U.S. Patent Application Publication No. 2022 / 046292 [Overview of the project]

[0005] The embodiments described herein offer many improvements over known systems.

[0006] The embodiments provide a convenient and highly capable implementation for monitoring vehicle-related issues, such as failures, malfunctions, and / or suboptimal operation that degrades performance, without causing actual failures or malfunctions. Furthermore, the embodiments herein enable responsible users (e.g., in some cases manufacturers, OEMs, service personnel, bodybuilders, aftermarket providers, fleet owners, and / or owners or operators) to monitor vehicles, perform test operations, perform advanced diagnostics, and / or maintenance operations (collectively, MTDM operations) without requiring software updates and associated thorough testing, certification, downtime, or other issues associated with updating vehicle software. This is achieved with both high accessibility to any aspect of the vehicle within each user's authority or authorization, and a convenient implementation, such as providing typically one or a few data files. The embodiments also provide a convenient interface for performing these operations without requiring the user to have programming skills or detailed knowledge related to the specific configuration of individual vehicles. Furthermore, embodiments of this specification provide a convenient rollout of MTDM operations to a fleet of vehicles, supporting a wide range of upfits, improvements, recalls, or other similar operations that can be intelligently rolled out to the fleet with minimal user input. Moreover, embodiments of this specification provide MTDM creation, implementation, and rollout to benefit from learning across different vehicles, enabling early identification of problems in specific MTDM operations before significant rework costs are incurred, allowing for faster implementation of continuous improvements to converge to best practice configurations, and enhancing the overall value of the MTDM system for the entire fleet of vehicles involved.

[0007] These examples of benefits are non-limiting, and a given embodiment may lack one or more, or all, of the benefits described, and / or may include further benefits not shown in this summary.

[0008] A detailed description of this disclosure and some embodiments thereof described below can be understood by referring to the following figures. [Brief explanation of the drawing]

[0009] [Figure 1] This is a diagram showing an example of an MTDM system. [Figure 2] This figure shows another example of an MTDM system. [Figure 3] This is a schematic diagram of the vehicle controller for the MTDM system. [Figure 4] This is a schematic diagram of the cloud controller for the MTDM system. [Figure 5] This is a schematic diagram of the MTDM workflow. [Figure 6] This is a schematic diagram of an MTDM implementation example. [Figure 7] This is a schematic diagram of an MTDM implementation example. [Figure 8] This is a schematic diagram illustrating an example of how the automated escalation protocol works. [Figure 9] This is a schematic diagram of the automated MTDM builder. [Figure 10] This is a schematic diagram of example recipe elements. [Figure 11] This is a schematic diagram illustrating the implementation procedure for the automated escalation protocol. [Figure 12] This is a schematic diagram of the implementation procedure for the MTDM interface. [Figure 13] This is a schematic diagram of the implementation procedure for the MTDM interface. [Figure 14] This is a schematic diagram of the implementation procedure for the MTDM interface. [Figure 15] This is a schematic diagram of the implementation procedure for the MTDM interface. [Figure 16] This is a schematic diagram of the rollout operation. [Figure 17] This is a schematic diagram of the rollout operation. [Figure 18] This is a schematic diagram of the rollout operation. [Figure 19] It is a schematic diagram of the roll-out operation. [Figure 20] It is a schematic diagram of the roll-out operation. [Figure 21] It is a schematic diagram of the roll-out operation. [Figure 22] It is a schematic diagram of the roll-out operation.

Embodiments for Carrying Out the Invention

[0010] Not limited to any aspect of this disclosure, several tools that can be used to tactically implement some of the operations described herein in combination with this disclosure, and explanations that can enhance understanding of some of the terms used herein (e.g., policy, endpoint, external device, network protocol, network type, etc.) are provided in U.S. Patent Application Publication No. 17 / 027,167, “SYSTEM, METHOD, AND APPARATUS TO SUPPORT MIXED NETWORK COMMUNICATIONS ON A VEHICLE” (SONA-0006-U01), filed September 21, 2020, and “SYSTEM, METHOD, AND APPARATUS TO EXTRA VEHICLE COMMUNICATIONS” filed September 21, 2020. These can be found in one or more of the following U.S. patents or patent applications: U.S. Patent Application Publication No. 17 / 027,187, entitled "SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION" (SONA-0010-U01), filed on 8 March 2021, entitled "SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION" (SONA-0012-U01), filed on 6 June 2022, each of which is incorporated herein by reference in its entirety for all purposes.

[0011] The monitoring operations used herein should be understood in a broad sense without being limited to any other aspect of this disclosure. Monitoring operations include operations that determine data values ​​and / or system states from a vehicle, and that determine the occurrence of specific events on the vehicle, such as specific operating conditions and / or transitions between operating conditions. Monitoring may relate to any values, states, conditions, or transitions observable from the vehicle, including aspects that are only intermittently observable (e.g., the data being monitored is available under specific operating conditions that are not always present or not always theoretically present) and / or theoretically observable (e.g., the data being monitored is available under specific operating conditions that the vehicle may not experience during the monitoring period, but may experience if the relevant operating conditions occur). A monitoring operation can be an initiator of an MTDM operation (e.g., a monitor to detect a specific event used to initiate further MTDM operations), the final MTDM operation of a particular sequence (e.g., several monitoring operations continue over a selected period and / or continuously after diagnostics, testing and / or maintenance), and / or can be used in any part of an MTDM operation (e.g., testing that utilizes monitoring operations during testing or between testing phases).

[0012] The test operations used herein should be understood in a broad sense without being limited to any other aspect of this disclosure. A test operation generally involves an operation to determine whether a particular event, value, or state exists on a vehicle in a manner that is readily apparent but not conclusive based on other conditions of the vehicle. For example, a temperature sensor that directly detects temperature exceeding a certain temperature may not be a test operation because the value is readily apparent by looking at one or two parameters on the vehicle. As another example, a transient response usually does not have a single available response data value, and determining the transient response and how it relates to an expected or conformance value usually involves observing many parameters, the operation of a model or correlation, or comparison with empirically determined values. Therefore, determining the transient response of a vehicle component during a particular operation may be a test operation. In some embodiments, the test can be passive, including requesting or retrieving data that is not normally available (typically, adding data parameters for observation may depend on the amount of such data, the data acquisition rate, and / or the amount of such data stored to support the test operation, but not interfering with vehicle operation) (for example, this test can be performed by observing data during normal vehicle operation without interfering with these operations, rather than directly adjusting vehicle control parameters). In some embodiments, the test can be active, including adjusting parameters that disable normal vehicle operation to some extent, and / or completely disabling vehicle control, including ensuring that the vehicle is in a safe operating state for the test to be performed). In some embodiments, a passive test can be performed by monitoring the vehicle to determine when the test conditions occur and observing normal vehicle operation under these conditions. For example, the test may involve observing the transient powertrain response during a shift between second and third gear when the vehicle's engine is at 1800-2200 RPM.Such tests can be performed quickly using active tests, but the vehicle's operating conditions may not always match those of an active test. In this example, the test can be performed passively, for example, by monitoring the vehicle's operating conditions until the test conditions occur. Passive tests collect data as they occur (and / or immediately afterward) and may not be as fast as active tests, but they do not interfere with the vehicle's operation. In some embodiments, the test operation can maintain a rolling buffer of data, such as the last 30 seconds of engine speed and gear selection, and capture recent historical data when the test conditions occur. In some embodiments, additional information related to the test can also be held in the rolling buffer to support the test. Examples of test data may include initiating data (e.g., data defining the trigger conditions for the test to become possible and / or reliable), actual test data (e.g., parameters observed to determine the test results, such as whether transient behavior is within the correct operating range), and / or test contraindications (e.g., if the gear shifts back from third gear before the test is completed, and / or if the engine speed falls outside the 1800-2200 RPM range). In some embodiments, the test can be performed passively over a period of time and then progressed to an active test after a specified period or when the vehicle meets the conditions for active testing.

[0013] The diagnostic operations used herein should be understood in a broad sense without being limited to any other aspect of this disclosure. Diagnostic operations include any operation to determine the correct operating state of components, systems, applications, sensors, actuators, etc., on a vehicle. In some embodiments, diagnostics may be integrated into the vehicle system in a more formal way than tests, such as reporting formal state parameters, setting fault codes, setting diagnostic codes, etc., but this is not required. In some embodiments, diagnostics may be performed periodically, continuously, after specific events (e.g., 50,000 miles since the last diagnostic operation, once a day, once per trip, etc.), and / or as desired (e.g., a service person may perform a specific diagnostic as part of a fault tree analysis, etc., due to specific observed conditions or operating behavior of the vehicle). In some embodiments, there may be significant overlap between several operations that can be characterized as tests or diagnostics, and actually labeling such operations as “tests” or “diagnoses” is not a limitation of this disclosure. Diagnostic operations can also be performed passively or actively, as described in the preceding description of tests.

[0014] The maintenance operations used herein should be understood in a broad sense without being limited to any other aspect of this disclosure. Typically, maintenance operations include operations that modify several aspects of the vehicle, such as trimming (for example, parameters available for adjustment within a particular user's permitted range, typically changing non-basic control features of the vehicle, such as default performance rules (e.g., "economy" or "sport") or maximum cruise speed within an acceptable range), calibration (for example, parameters available for adjustment that can change basic control parameters such as PID controller gains or maximum vehicle output, but are also enforced within a user's permitted range), enabling or disabling vehicle features, or reconfiguring vehicle aspects (for example, endpoint network addresses, selection of specific control algorithms (e.g., torque governor vs. speed governor for primary vehicle drive force control), changes to connections and / or permissions for endpoints, applications, or flows on the vehicle, resetting parameters on the vehicle (e.g., system time, battery health status, vehicle mileage indicator, adaptive controller value reset, etc.)). Maintenance operations include adjustments performed during MTDM operations and that persist after the completion of MTDM operations (and / or after the completion of the initial stages of MTDM operations). In some embodiments, maintenance operations do not change the vehicle's configuration. For example, a maintenance operation to switch the vehicle to "Power Governor B" may not switch the governor if the governor is already set to B, but the status check in this example still functions as a maintenance operation.

[0015] In this specification, operations that support monitoring, testing, diagnosis, and / or maintenance are collectively referred to as MTDM operations. It should be understood that some operations may be characterized as one or more of monitoring, testing, diagnosis, or maintenance, depending on the context and purpose of the operation, the state of the vehicle, the location of the vehicle (e.g., on the road, at a repair shop, during vehicle manufacturing, or during upfitting of a vehicle at a bodybuilder or OEM), the relevant user terminology and / or philosophy (e.g., one manufacturer may consider a particular operation a test operation, while another may define the same operation as a diagnosis), and the maturity of the vehicle and related vehicles (e.g., a particular test may be used over a period of time and then reclassified as a diagnosis after that period, or after it has been determined that the test has diagnostic value). In this specification, an operation referred to as an MTDM operation (or similarly, an MTDM system or a component referred to in similar terms) includes (and / or supports) at least one operation that can be characterized as a monitoring, testing, diagnostic, or maintenance operation, but does not have to include all of these, and may also include operations that can be characterized within multiple MTDM categories depending on the context and / or purpose of such operations. The specific terminology used is not limited.

[0016] Aspects of this disclosure provide systems and / or procedures that support the performance of flexible and highly configurable monitoring, testing, diagnostics, and / or maintenance operations on mobile applications such as vehicles. Embodiments of this specification are applicable to any vehicle having at least one network zone used for various endpoints (e.g., vehicle controllers, sensors, actuators, and / or other components coupled to a network on the vehicle). In the example of Figure 1, System Example 100 includes a vehicle 108 having a single network zone 103 (e.g., an Ethernet network, CAN, or any other type of network) having a plurality of endpoints 104 that are communicably coupled over the network, and a vehicle-side controller (controller V) 102 that performs various operations for performing the operations described herein, including controlling vehicle communications, including communications between endpoints on the network, communications between endpoints and external devices (e.g., a cloud controller (controller C)), and / or communications with other external devices such as tools communicably coupled to the vehicle, an internet website or web-based tool, an operator interface as part of the vehicle, or a mobile application.

[0017] In the example in Figure 2, System Example 200 includes a vehicle 108 having multiple network zones 103, 202, where the second network zone 202 can be a different type of network than the first network zone (e.g., Ethernet, CAN, LIN, etc.), a different hardware layer than the first network zone (e.g., a first Ethernet network and a second Ethernet network), a different logical network from the first network zone (e.g., a virtual network 202 operating on the same hardware layer as the first network zone 103), and / or a combination thereof. The network zone configuration of the vehicle is non-limiting; for example, all relevant endpoints 104, 204 on the vehicle 108 can reside on a single network zone or on a mixed network zone containing network zones of different types, protocols, or communication parameters. Embodiments herein support the creation, rollout, and implementation of MTDM operations regardless of the location of endpoints on the network zones. Embodiments of this specification allow users to focus on what actions they want to perform on controllers 102, 106 (e.g., data rate, resolution, units, how to package data into network messages, where to retrieve data that a particular endpoint does not possess) without needing to know the network location of the endpoint or the communication parameters of the endpoint.

[0018] While controllers 102 and 106 are shown as a single device in the diagram for clarity, controllers 102 and 106 can also be distributed devices, and / or embodiments of controllers 102 and 106 can be fully or partially embodied as part of any computer device, sensor, actuator or logic circuit, etc., on the vehicle, in the cloud, and / or communicating with these controllers at least selectively or intermittently. In some embodiments, controllers 102 and 106 and / or embodiments thereof can be embodied in different forms at different points in time, for different operations, and / or under different operating conditions. For example, a controller manager can be fully or partially deployed on the user device during certain operations, for example, an MTDM interface manager can be at least partially deployed on the user device during user operations such as creating, modifying, and / or rolling out an MTDM workflow, to improve system responsiveness for the user, or to reduce resource utilization such as memory resources and / or communication resources.

[0019] Controller example V102 can manage communication between endpoints on vehicle 108, including endpoints on different networks that utilize different network protocols, different data types (e.g., data formats, units represented within the data, etc.), and / or different sampling rates (e.g., using upsampling or downsampling of data to match algorithmic expectations for endpoints, applications, flows, etc. that utilize the data, or to filter out some dynamic responses within the data for any reason). Furthermore, controller example V102 can enforce permissions for endpoints 104, 204 to communicate data, expose available data, request data, reference data, or register for available data. In addition, controller example V102 can enforce external communication plans provided as part of policies that manage, for example, which endpoints 104, 204 can communicate with external devices, utilize network resources, utilize memory and / or buffering resources, or request or provide data to external devices. In some embodiments, the external communication plan may include restrictions on data usage, restrictions on external communication devices (e.g., available transceivers, hardware ports such as OBD ports, Bluetooth communication, WiFi communication, etc.), and routing of communication between endpoints and external devices (e.g., routing through various networks, endpoints, or transceivers, etc.). In some embodiments, the controller V102 may further determine priorities among endpoints, applications, flows, or individual communications in response to operating conditions such as the availability and / or status of external communication resources or the availability of memory storage.In some embodiments, the controller V102 may further determine operational responses to off-nominal conditions, such as changing data routing in response to endpoint loss or failure conditions, and / or changing the responsible controller / endpoint on the vehicle. Without limiting to any other aspect of this disclosure, the controller V102 may utilize any of the circuits, controllers, managers, models, computer devices, and / or other embodiments shown in the following references to perform the modes of operation described herein. The supported operational examples for each of the following disclosures are non-limiting examples. These references are related to: Systems, methods and apparatus for supporting mixed network communications on vehicles (U.S. Patent Application Publication No. 17 / 027,167, now issued as U.S. Patent No. 11,411,823, filed September 21, 2020) (SONA-0006-U01) (related to vehicle network communication management); Systems, methods and apparatus for controlling external vehicle communications (U.S. Patent Application Publication No. 17 / 027,187, now issued as U.S. Patent No. 11,228,496, filed September 21, 2020) (SONA-0007-U01) (communication management with external devices); and vehicle data This includes systems, methods and apparatus for managing data collection (U.S. Patent Application Publication No. 17 / 195,589, now issued as U.S. Patent No. 11,538,287, filed March 8, 2021) (SONA-0010-U01) (providing data collection operations), systems, methods and apparatus for managing vehicle data collection (U.S. Patent Application Publication No. 17 / 833,614, filed June 6, 2022) (SONA-0012-U01) (providing automated vehicle operations, data collection, and / or remote control), and / or Universal Intrusion Detection and Prevention for Vehicle Networks (PCT / U.S. Patent Application Publication No. 2022 / 046292, filed November 11, 2022) (SONA-0013-WO) (security support for externally connected vehicles). Each of the aforementioned patents and / or applications is incorporated herein by reference in its entirety for all purposes.

[0020] Embodiments herein provide one or more of the following: improved detection of defects or abnormal conditions occurring in a vehicle; improved fidelity in detecting and identifying the source of abnormal conditions; enabling secure knowledge sharing throughout the vehicle and / or enabling determined knowledge of a first vehicle to separately benefit other vehicles that share a similar configuration with the first vehicle; enabling users who are experts in vehicle diagnostics, reliability, service, and / or maintenance to configure and deploy monitoring, testing, diagnostic, and / or maintenance flows to vehicles without requiring advanced knowledge of vehicle configurations, network topology, endpoints, and / or data value locations and / or names; and / or reducing recall costs where appropriate (by easy deployment to vehicles, the ability to provide the same update to multiple vehicles with multiple different configurations, and the ease of verifying that the update has been correctly applied).

[0021] In some embodiments, the operations described herein support rapid vehicle configuration, including enabling or disabling features on the vehicle, changing calibrations on the vehicle, installing new features on the vehicle (e.g., new features for testing, diagnostics, additional capabilities, new features for future problem detection, new features for detected or potential problem mitigation, etc.) through flexible data structures such as policy changes, without requiring vehicle shutdown and / or software updates, and coordinating inter- and / or intra-network communication management on the vehicle, adjusting the vehicle's memory storage parameters, and / or coordinating external communication with the vehicle's endpoints.

[0022] In some embodiments, the operations described herein may be performed at any point in the vehicle lifecycle, for example, during manufacturing, final adjustments to the vehicle after manufacturing, application by the OEM, application by the bodybuilder, application by the dealer, application by the service personnel, application by the fleet manager, application by the operator, vehicle upgrade, change of vehicle ownership, and / or during changes in the application of the vehicle (for example, when the vehicle is changed to a new fleet, or when there is a change in operation to a new load cycle).

[0023] In some embodiments, the operations described herein support better overall vehicle performance, reduced operating costs, and / or reduced risks, addressing many of the challenges arising in vehicle operation, including vehicle manufacturing, service, support, or operational management. Vehicles are manufactured with an increasing number of advanced sensors, diverse network configurations, an increasing number of controllers or other endpoints on the vehicle's (one or more) network, configuration variations of individual components (e.g., selected sensors, actuators, controllers, etc.) and / or basic vehicle configurations (e.g., network topology, network operation such as protocols, network speed capability, network security management, etc.), changes over time, including between models, between model years, and / or within a given model year, increasing customization options for vehicle groups (e.g., specific fleets), vehicle types (e.g., high-performance options for models), and / or individual users (e.g., users may want to change the vehicle's HVAC behavior), and / or proliferation of powertrain configurations for a given model (e.g., ICE, hybrid, and / or EV versions of the model). The proliferation of such components, features, and / or configurations significantly increases the complexity of performing monitoring, testing, diagnostic, and / or maintenance (MTDM) operations, determining the physical and / or data implementation of a vehicle, deciding on repairs or updates that function throughout the vehicle, rolling out repairs, tests, diagnostics, or configuration updates to the relevant vehicles, and / or verifying that applied repairs, tests, diagnostics, and / or configuration updates have been correctly applied and / or that the targeted issues have been corrected.

[0024] Known systems that perform MTDM operations for vehicles have many shortcomings. For example, currently, the proliferation of vehicle components and / or configurations requires specific knowledge of the vehicle's configuration, endpoint locations / addresses and / or naming conventions, which endpoints provide (and / or can provide) what data types, formats and / or other operational information about the data provided (e.g., data format, network communication / packet information, units used, data sampling rate, data latency, etc.), which endpoints provide (and / or can provide) operational capabilities (e.g., actuators that respond to commands), and / or an understanding of the format and / or other operational information about the operational capabilities provided. In another example, a high rate of change in vehicle capabilities and / or configuration increases the cost of delays in diagnostic, corrective and / or configuration update operations, as a given vehicle spends a significant portion of its lifecycle in a state of low capability for diagnostic, test and / or configuration operations due to delays in verifying correct operation and / or correcting incorrect operation. Consequently, one or more suboptimal aspects are introduced, such as delays in capability (e.g., delays in installing or implementing new capabilities, reducing the commercial value and / or usefulness of the vehicle), increased risks (e.g., installing inadequately tested capabilities), increased mitigation costs (e.g., reduced ability to provide corrective actions and / or delays in implementing corrective actions), and / or a combination thereof.In another example, a known system that provides a specific type of capability, such as recalibrating basic operations (e.g., a new sensor table), adding or removing features to a vehicle, changing the vehicle's network communication control, and / or a combination thereof (e.g., the installation of updated sensors may involve some of these operations), may require coordination among multiple experts (e.g., an expert on the vehicle network in that particular vehicle, a service expert who understands operational problems and how to detect them), and / or require software updates on the vehicle (e.g., forcing a vehicle shutdown and / or preventing certain types of operations during installation, increasing operational costs, and / or introducing the risk of the vehicle stopping if the installation fails).

[0025] Figure 3 schematically shows an example controller V102 that supports MTDM operation for a vehicle and / or a group of vehicles. Although controller V102 is shown as a single device as an endpoint on the vehicle, controller V can be distributed across multiple devices or included as part or partly as another endpoint on the vehicle. A group of vehicles can be related in any way, for example, by being a vehicle with a specific application, flow, endpoint, sensor, actuator, or feature, and / or by being part of a specific fleet, a vehicle sold by a specific dealer, a vehicle provided by a specific manufacturer, or a vehicle enrolled in a specific system, or by having a shared relationship. Controller example V102 includes a policy manager 302 that interprets new or updated policies (and / or initial policies, such as those at the time of vehicle manufacture) which may include multiple aspects such as permission descriptions (for example, for accessing data, endpoints, flows, applications, features, external communications, etc.), data collection descriptions, trigger evaluation descriptions (for example, trigger conditions may be based on any data available on the vehicle and / or may include timers, conditions before the trigger evaluation is performed, multiple parallel and / or serial trigger evaluations, etc.), or actions to be performed based on the trigger evaluation (for example, data collection operations, actuator commands, setpoint commands, alternative calibration sets, etc.). In some embodiments, policies may be provided as cloud communications 320 (for example, when the policy is communicated from the cloud to the vehicle) and / or as tool communications 322 (for example, when the policy is provided by a manufacturer, OEM, dealer, bodybuilder, service representative, etc., who uses a tool to communicate with the vehicle). The use of policy manager 302 and / or policies to provide command communication between controller V102 and controller C106 is a non-exclusive implementation example.

[0026] Controller example V102 further includes a data collection manager 308 that can respond to current (single or multiple) policies, controlling various aspects of data collection, such as endpoint identification, managing data publication and / or subscription, determining data format, units, sampling rates, etc., deciding on the disposal of collected data (e.g., storage, communication, data lifecycle management, redundancy management, prioritization, etc.), and / or providing authorization information for use by other managers of Controller 102. Controller V102 further includes an intra-network manager 304 that controls endpoint communication on a given network, including, for example, which endpoints are permitted to provide or request data, endpoint network usage, or the configuration of packets used between networks. Controller V102 further includes an inter-network manager 310 that may include edge gateways or other components to facilitate communication between networks of different types and / or different protocols, enabling communication to flow seamlessly between network zones, potentially according to relevant authorizations (e.g., related to potential communications, according to relevant endpoints, flows, applications, features, etc.). In some embodiments, the inter-network manager 310 configures communication for the receiving endpoint, including, for example, the expected sampling rate, data resolution, provision of communication in units of data, and packaging of network packets in the expected form. The controller V102 further includes an external communication manager 306 that enables, for example, the endpoint to communicate with an external device (including, for example, controller C106), receive and provide operator communication 324, configure routing of communication between the endpoint and the external device, perform authorization, and / or perform intrusion detection or other security operations for the vehicle.

[0027] Controller example V102 further includes a monitoring manager 312 that performs vehicle monitoring operations. Monitoring operations can be applied to any aspect of the vehicle, including, for example, the correct operation of sensors or actuators, the correct operation of flows (e.g., related sets of functions on the vehicle as logical subsystems that perform specific operations on the vehicle), the correct operation of applications or features (e.g., vehicle features for HVAC control, vehicle speed control, ADAS operation support, etc.), and / or confirmation that there are (or are not) any faults, bugs, or other aspects related to observations on the vehicle, on an offset vehicle, or related to components installed on the vehicle. Monitoring operations may include observing any data value on the vehicle, comparing data values ​​in a sophisticated manner to detect underlying conditions, and / or using determined indices (e.g., comparing data values ​​to thresholds, determining an index or other value from multiple data values, performing statistical analysis on data values, etc.). In some embodiments, the monitored data values ​​may relate to network functions (e.g., network traffic monitoring), vehicle functions (e.g., monitoring of vehicle operating parameters), or any other aspect of the vehicle where relevant data is available somewhere on the vehicle's endpoints. The monitoring operation may be performed in response to any type of trigger evaluation, such as data values ​​to be observed before the start of the monitoring operation, data values ​​to be observed to indicate the end of the monitoring operation, data values ​​to be observed at any stage of the MTDM operation, data values ​​to be observed to determine the transition between stages of the MTDM operation, and / or data values ​​to be continuously observed after the completion of other MTDM operations. The monitoring operation may include storing data values, whether by utilizing long-term storage and / or by using a rolling buffer or other technique that enables the ingestion of recent data after the trigger condition is met.The monitoring operation can repeat, for example, monitoring a specific operation, utilizing its features, for a predetermined number of times and / or over a set period (e.g., each time event X occurs during September). The use of data values ​​for monitoring and / or trigger evaluation related to monitoring may include performing any type of mathematical, statistical, and / or logical operation on the data values, including processing the values ​​to determine time derivatives, comparing them to a range or threshold, determining the mean, and determining inflection points. In some embodiments, any authorized user can configure, adjust, and / or transmit monitoring operations to the vehicle by a tool that communicates with the vehicle (e.g., a service tool, manufacturing tool, engineering tool, OEM tool, dealer tool, etc.) and / or through an interface with controller C106, for example, by logging into a web portal, using a dedicated application (e.g., stored on or accessible by the user's local computer device), and / or using a mobile application that works in conjunction with controller C106 to set and / or execute monitoring operations. In some embodiments, the monitoring interface provides a dropdown menu or other interface element so that the user can see the data they can access and use that data when defining monitoring and / or trigger evaluation behavior. An example of a monitoring interface can be implemented by an MTDM interface manager 904 (see Figure 9 and related description) which is at least partially located on and / or on an automated MTDM builder 902 that can communicate with controller C106.In some embodiments, the structuring, listing, or identification of data provided to the user is done in a user-accessible format, allowing the user to select "oil temperature" without knowing which sensors are being used, or which endpoints the sensor is associated with (for example, if the sensor is an endpoint and / or can be associated with a controller that functions as an endpoint for the sensor), convert to units of preference, and configure the data format and / or sampling rate (and / or provide the user with options for these).

[0028] In some embodiments, monitoring operations or trigger evaluations, etc., can be stored in modules or other discrete elements so that the user can reuse all or part of the monitoring operations in any of the later types of vehicle functional elements (e.g., any MTDM operation according to various embodiments of this disclosure). In some embodiments, monitoring operations, trigger evaluations, and / or parts thereof can be stored in a library (e.g., datastore 916 in the example of Figure 9) so that the user can access them for reuse and / or sharing with other users. In some embodiments, the relevant instructions for monitoring operations are provided to the vehicle for implementation as a policy, for example, so that the operations can be performed without software updates to the vehicle, but any other implementation is also assumed herein. In some embodiments, monitoring operations can be provided as recipes (see, for example, Figures 6-7 and related descriptions) and / or can be implemented at least partially in response to maps or models provided by the vehicle automation platform 608. In some embodiments, relevant commands for monitoring operations can be given to an entire group of selectable vehicles according to criteria provided to the user (e.g., vehicle ID, model, model year, owner information, fleet constituent, etc.), and adjustments for each specific vehicle can be made automatically (e.g., different components or endpoints across the vehicle group provide data values ​​for monitoring operations, and policies for each vehicle are configured for that vehicle and / or interpreted by each vehicle's policy manager, allowing the operator to ignore and / or be unaware of the differences), and can be restricted according to user permissions (which may differ for different vehicles in the group), and can be provided as policy updates and / or as further policies served by (one or more) vehicles.

[0029] Controller example V102 further includes a test manager 316 that performs test operations on the vehicle. In some embodiments, the difference between test operations and monitoring operations depends on the action being performed. For example, in some embodiments, actively controlling the vehicle's behavior (e.g., adjusting setpoints, articulating actuators) can be understood as a test operation, while in other embodiments, mere data collection and / or further processing of data can be understood as a monitoring operation. In some embodiments, the distinction between operations that are monitoring operations and those that are test operations can be determined according to conventions such as the user, user-related entities, rules, or industry standards. The specific terminology used in a given set of operations as monitoring operations or test operations is not limiting. A test operation may include any of the functional aspects described herein, including at least data collection, data processing, formatting, upsampling / downsampling and / or compression, data storage and / or communication including data lifecycle management and / or prioritization, adjustment of any control values ​​on the vehicle (e.g., limits, setpoints, specified ranges, calibration values), initiation, termination and / or progression (e.g., from stage 1 to stage 2) of a test operation using trigger evaluation, and / or modification of network control parameters (e.g., authorization for endpoints, communication between networks, resource utilization restrictions). Similarly, a monitoring operation may include one or more of these operations. In some embodiments, a test operation may be performed on a user interface in a similar manner to a monitoring interface. In some embodiments, even for a particular user with a specific set of permissions related to the MTDM operations herein, the available data and / or operations that can be commanded from the test interface to enforce specific rules for, for example, test operations and / or monitoring operations may differ from the available data and / or operations that can be commanded from the monitoring interface.

[0030] Controller example V102 further includes a diagnostic manager 314 that performs diagnostic operations on the vehicle. In some embodiments, the difference between test and monitoring operations and diagnostic operations depends on the action being performed. In some embodiments, the distinction between operations that are test or monitoring operations and operations that are diagnostic operations can be determined according to conventions such as the user, user-related entities, rules, and industry standards. In some embodiments, the diagnostic operation outputs a status value, index value, or other value indicating whether a vehicle aspect (e.g., sensors, actuators, endpoints, flows, applications, features, etc.) is in a fault condition, abnormal condition, or suspicious condition, etc. In some embodiments, the diagnostic operation is performed in interaction with the vehicle's official diagnostic system (e.g., OBD, fault code reporting, etc.). In some embodiments, diagnostic operations are performed that interact with the vehicle's informal diagnostic system (e.g., silent fault codes, engineering parameters, etc.) to determine component status values ​​for analysis by a service representative and / or to determine whether any type of condition exists on the vehicle, for example, to support troubleshooting operations, fault tree analysis, risk analysis, determination of whether a recall is indicated, and / or to plan a recall response, and / or for any other purpose desired by the user. In some embodiments, diagnostic operations can be performed on the user interface in a similar manner to the monitoring interface. In some embodiments, even for a particular user with a certain set of permissions related to the MTDM operations herein, the available data and / or operations that can be commanded from the diagnostic interface to enforce certain rules for, for example, test operations, diagnostic operations, and / or monitoring operations may differ from the available data and / or operations that can be commanded from the monitoring interface.

[0031] Controller example V102 further includes a maintenance manager 318 that performs vehicle maintenance operations. In some embodiments, the difference between test / monitoring / diagnostic operations and maintenance operations depends on the action being performed. In some embodiments, maintenance operations include operations related to changing components on the vehicle, upgrading components on the vehicle, adjusting operations in response to wear (e.g., temperature sensor response profiles that change over time), resetting values ​​in response to service and / or maintenance events, and notifying the vehicle controller that a component has been changed or upgraded. In some embodiments, maintenance operations involve operations intended to be long-term or permanent changes to the operation of the vehicle, such as changing calibration values ​​on the vehicle, enabling or disabling vehicle features, installing new features on the vehicle (e.g., features provided by trigger evaluation and automatic operations that can be achieved without software updates, and / or features implemented by software updates), removing features from the vehicle, changing setpoints and / or operating values ​​on the vehicle (e.g., maximum speed or maximum power) (which may also be provided as calibration changes or by any other operation), and / or changing the operation of the vehicle (e.g., network configuration, network management operations, etc.). In some embodiments, maintenance operations may include calibration changes, tuning changes, or component reconfigurations. In some embodiments, maintenance operations may be performed on a user interface in a manner similar to that of a monitoring interface. In some embodiments, even for a particular user with a specific set of permissions related to MTDM operations as defined herein, the available data and / or operations that can be commanded from the maintenance interface to enforce specific rules for, for example, test, diagnostic, monitoring, and / or maintenance operations may differ from the available data and / or operations that can be commanded from the monitoring interface.

[0032] Exemplary and non-limiting monitoring operations include one or more modes such as vehicle-wide monitoring (e.g., any parameter on a vehicle), event-driven monitoring, vehicle and / or fleet (and / or any other group of vehicles) level monitoring, monitoring for expected and / or unexpected events or anomalies, and / or determining outliers in monitoring (e.g., distinguishing events that do not exceed thresholds for automatic determination but are determined due to a statistical description of data corresponding to similar data on a vehicle, on an offset vehicle, and / or within a group of vehicles), and / or both reactive and / or predictive monitoring.

[0033] Exemplary and non-exclusive test operations include one or more of the following: integration with an external test management system (e.g., an OEM or manufacturer's test management system that performs tests and / or provides data used in the external test management system); execution of functional tests (e.g., whether the feedback performance of an operating mode meets performance criteria such as power response during transitions); execution of feature tests (e.g., monitoring the operation of a feature to ensure that it operates at the intended time and provides the intended response, testing conflicting versions of a feature, and / or testing whether feature changes are working as intended); and / or operation as a programmable traffic generator / simulator (e.g., reducing the cost of testing by simulating specific parameters on a vehicle to test other features on the vehicle, and / or separating other aspects of the vehicle from testing the feature of interest).

[0034] Exemplary and non-exclusive diagnostic operations include one or more of the following: providing virtual and / or cloud-based official diagnostic support (e.g., OBD); utilizing single-step and / or multi-step diagnostic operations; providing and / or coordinating diagnostic operations from various locations (e.g., in-vehicle, near the vehicle, remotely, web-based, etc.); and / or providing on-demand and / or self-directed diagnostics (e.g., potential diagnostics installed on the vehicle that operate based on any type of trigger assessment) (e.g., a service operator commands the execution of the diagnostics).

[0035] Exemplary and non-limiting maintenance operations include one or more actions such as reconfiguring the vehicle's configuration (e.g., changing components or endpoints and / or their locations), adjusting the vehicle's configuration (e.g., adjusting operating parameters to obtain desired behavior such as controller gain values, setpoints, error detection, or response sequences), and / or calibrating any component, endpoint, flow, application, or feature of the vehicle.

[0036] Figure 4 schematically shows an example controller C106, which is a support controller in the cloud, on a tool, or on another external device that communicates at least intermittently with a vehicle (and / or controller V102). Example controller C106 can perform one or more operations as shown with respect to controller C106 throughout this disclosure, including, for example, providing a user interface to one or more users for MTDM operations. In some embodiments, controller C106 is configured to perform one or more operations as shown with respect to controller V102 (for example, when the vehicle controller offloads certain operations to the cloud controller) and / or can embody the automated MTDM builder 902, data analysis components 602, 702, vehicle data platform 606, vehicle automation platform 608, and / or vehicle update platform 706 in whole or in part (see, for example, Figure 7 and related descriptions). Example controller C106 communicates with cloud-side users using user communication 424. Controller example C106 can provide long-term data storage, configure data access, implement a web portal and / or mobile application for interaction, check various user permissions, and / or provide policies or policy updates to vehicles (e.g., using a policy manager 402, providing vehicle communications 420 to provide policies, collecting data, etc.). In some embodiments, controller C106 includes a vehicle group manager 426 that enables a user to provide MTDM operations to a group of vehicles, perform rollout operations of MTDM operations to selected groups of vehicles, select vehicles, collect data from the groups of vehicles, and / or perform analysis on the data from vehicles in the group (e.g., from monitoring operations) to determine potential abnormal operations, determine abnormal value results, etc.

[0037] Figure 5 shows a schematic flowchart example 500 illustrating the operation of an automated workflow according to embodiments of this specification. In the example of Figure 5, the operations above the line (in this example, the "cloud" 502) are performed by one or more devices that collectively embody the controller C106, and the operations below the line (in this example, the "vehicle" 504) are performed by one or more devices that collectively embody the controller V102. Controller example C106 performs one or more of the following: reporting operations 506 (e.g., making the results from the MTDM operations of this specification accessible to the user, including highlighting abnormal data, outlier data, request data, etc.) and analysis operations 508 (e.g., applying a specified analysis to data to determine whether there are any failures, malfunctions, or other conditions in the vehicle, checking the vehicle configuration, checking calibrations or other settings on the vehicle, building, improving and / or implementing vehicle version models, recipes and / or maps, etc.), and the analysis operations may include performing a specified analysis and / or user-specified analysis on data from (one or more) vehicles. Controller example C106 performs configuration operations 510 that provide policies, calibration changes, or feature enablement changes in response to detected conditions, user-requested changes, etc., as shown, for example, throughout this disclosure. Controller example V102 performs MTDM operations as shown throughout this disclosure and includes an automation work element 520 that performs, for example, changes provided by the configuration operations of controller C106, completion of vehicle configuration changes, and / or features or other operations that are added or removed. In some embodiments, the automation work element 520 provides direct communication, control, and / or updates of endpoints, applications, flows, or controllers on the vehicle in order to perform some of the MTDM operations. The operation split between controller C106 and controller V102 in Figure 5 is a non-limiting example, and some operations may be switched entirely or partially from the illustrated controller split, and / or some operations may be performed by both controller C106 and controller V102.In some embodiments, the division of work elements between controller C106 and controller V102 may depend on operating conditions, for example, the ongoing vehicle operation, the method of user access to the system (e.g., mobile applications, tools communicatively coupled to the vehicle, and / or web portal access), and / or available connections between the vehicle and the cloud or tools. In addition to or instead of this, it will be understood that the cloud side 502 may also be implemented entirely or partially by tools such as service tools, engineering tools, manufacturing tools, OEM tools, bodybuilder tools, and / or dealer tools that communicate with the vehicle by any available communication coupling (e.g., direct physical connections such as WiFi, Bluetooth, OBD ports or dedicated ports, via cellular connections, and / or via WANs such as the Internet).

[0038] In some embodiments, any individual work element (see, for example, Figure 5) and / or the entire MTDM workflow can be automated, either entirely or partially. In some embodiments, a user can perform MTDM operations using a single device, such as a mobile device, without using other equipment (e.g., cables, communication connections, access to OBD ports, access to keys for software updates on the vehicle). Workflow 500 schematically represents the vehicle-side MTDM operations as a monitoring work element 512, a test work element 514, a diagnostic work element 516, and / or a maintenance element 518.

[0039] One embodiment includes one or more automated test sequences, represented as a workflow to controller C106 via a user interface, which are deployed and executed on selected vehicles. In some embodiments, test sequences can be stored as vehicle recipes, for example, for analysis and / or reuse of automated test sequences and / or parts thereof, and these vehicle recipes can be used to label and identify data. Examples of automated test sequences include one or more actions such as triggering tests in response to vehicle operating conditions, triggering tests from remote messages from a user, triggering tests from the results of other tests, diagnostics, monitoring and / or maintenance operations, providing result data from tests to the cloud, adjusting test sequences in response to data (and / or analysis thereof) sent to the cloud, executing a test suite incorporating multiple tests, deploying (one or more) tests to vehicles, and / or tracking test results (e.g., events of tests performed and / or related data).

[0040] One embodiment includes one or more automated diagnostic sequences, which are shown as a workflow to controller C106 via a user interface, and which are deployed and executed on selected vehicles. In some embodiments, the diagnostic sequences can be provided as policy updates and / or further policies. Examples of automated diagnostic sequences include one or more actions such as operating a diagnostic tree containing nodes (e.g., operating it as a state machine, or transitioning between nodes in the tree in different ways), operating a diagnosis in response to vehicle conditions, operating a diagnosis in response to previous diagnostic results, traversing the diagnostic tree to determine root causes such as faults, unexpected events, or abnormal events, providing result data from the diagnosis to the cloud, analyzing the diagnostic results and / or related data, and / or adjusting the diagnostic sequence in response to the diagnostic results.

[0041] Examples of embodiments include providing a software-defined component. For example, monitoring any component of a vehicle (e.g., a sensor, actuator, endpoint, flow, application, controller, feature, etc.) according to one or more trigger policies (and / or any MTDM operation as shown herein), providing the collected data to the cloud, analyzing the collected data to determine a new configuration, and implementing the new configuration on the relevant (one or more) vehicles to update the component's operation. In some embodiments, a new feature may be created as a codeless feature at the initial stage and implemented as a coded feature at a later stage (e.g., to reduce the number of software updates and manage the size of policies or other implementation data structures for features). In some embodiments, but not limited to, MTDM operations including the provision of a software-defined component may be repeated throughout the vehicle's lifecycle to continuously improve the vehicle's operation, configure the vehicle to suit a specific operator and / or conditions, manage regulatory compliance, and provide the vehicle with the benefits of continuous improvement decisions made throughout its lifespan.

[0042] One embodiment includes creating an automated diagnostic sequence and executing the automated diagnostic sequence on selected vehicles. This embodiment includes, for example, (the MTDM interface manager 904) using the diagnostic user interface of controller C106 to create the automated diagnostic sequence and storing the automated diagnostic sequence as a recipe that can be reused and / or shared with other users. This embodiment includes building a diagnostic tree, such as a state machine and / or algorithm with progressive staging, from the recipe and / or other data structures that take up the automated diagnostic sequence. This embodiment includes executing the automated diagnostic sequence on selected (one or more) vehicles and providing and executing the diagnostics to the vehicles, for example, as an executable workflow and / or policy. In some embodiments, the automated diagnostic sequence can interact with and / or include test operations, monitoring operations and / or maintenance operations (for example, allowing the system to immediately correct a problem if one is detected, even if cloud communication is not available at that time).

[0043] Figures 6 and 7 show an example embodiment illustrating MTDM operations performed using a cloud server (e.g., above the “cloud” line) and a vehicle controller (e.g., below the “vehicle” line). This example embodiment includes an AI model that provides continuous operational improvements to diagnose or detect problems, mitigate problems, and / or resolve problems or reconfigure the vehicle to address problems. In the example of Figure 6, the data analysis component 602 utilizes an AI motor control model 604 implemented by a vehicle automation manager 612, which builds models for motors on the vehicle (e.g., electric motors with heavy workloads, such as providing power, operating fans, and providing accessory power for steering, etc.) and provides recipes and / or maps for controlling the motors on the vehicle. The AI ​​motor control model 604 provides continuous analysis of motor control, including taking into account, for example, motor aging or degradation, specific duty cycles in the motors on the vehicle, etc., and periodically updates the motor models, recipes and / or maps to perform control in response to the model. The controller V102 in the example of Figure 6 includes a vehicle data controller 610 that manages data collection from endpoint 614 in response to the policies and / or MTDM operations described herein. The controller V102 in the example in Figure 6 includes a vehicle automation manager 612 that manages the vehicle's automated responses in response to the policies and / or MTDM operations described herein, for example, by issuing commands to, updating, and / or monitoring the vehicle's endpoint 614.

[0044] In the example in Figure 7, the data analysis component 702 includes an AI motor control model 704, and all or part of the AI ​​model resides on the vehicle controller (as a local AI model 708) to enable faster, more specific responses and improvements for that vehicle. The example in Figure 7 includes a vehicle-side AI model component 708 that runs the model, providing a greater capability on the vehicle to improve motor operation if, for example, the controller V102 has sufficient computing resources to run the model, or has access to such computing resources. In some embodiments, the model provided to the vehicle is simplified compared to the cloud version of the model, and can utilize, for example, lower resolution, modeling step time, or parameter input. In addition to or instead of this, in some embodiments, recipes and / or maps for motor control can also be provided from, for example, the vehicle automation platform 608 to the vehicle automation manager 612. The example in Figure 7 includes an optional shared data store 710 and a vehicle update manager 712 that manages vehicle updates, including updates provided as, for example, automated maintenance operations.

[0045] Examples in Figures 6 and 7 illustrate how high-performance AI models can be developed for any component, actuator, sensor, motor, application, flow, or feature of a vehicle, enabling the application of the benefits of high-performance AI models within the vehicle for rapid and / or real-time implementation while maintaining the vehicle's computing resources, which are generally more limited than those available outside the vehicle. The data analysis component 602 can extract any information useful to the model (e.g., motor duty cycle, operating conditions, temperature, voltage, current values, operating speed, phase determination, etc.), including parameters used to determine an appropriate update cycle (e.g., odometer values, operating time, fault status, WiFi APN status, etc., which can be used as trigger conditions for updating the model and / or to check the model for potential updates that are considered useful), and provide the model, recipe, and / or map to the vehicle. The example in Figure 7 enables the direct use of a model or simplified model on the vehicle that can improve the response time to changes in the operating state of a motor (or other component) and / or to expected motor behavior (e.g., changes in duty cycle, environment, etc.). In the examples in Figures 6 and 7, motor control is used as a framework for illustrative purposes, but all aspects of a vehicle can benefit from similar operations, and it is assumed herein that all aspects of a vehicle will benefit from similar use of the data analysis component 602 and / or the AI ​​model component. In some embodiments, example components include ultrasonic sensors used to support ADAS operations, for example, near-range object detection (e.g., to support automated navigation such as parking, and / or to support the operator, such as providing the operator with images of the surrounding environment). The examples provided are not limiting.

[0046] Automakers and suppliers lack a reliable way to monitor the performance of vehicle components after sale in the real world, yet they are constantly seeking ways to improve the performance of various complex features, applications, or flows, such as Advanced Driver Assistance Systems (ADAS). One example of an area for improvement is sensor tuning, which enhances the performance of various sensors and actuators that enable ADAS features such as automatic parking or obstacle detection. This type of detection heavily depends on the sensitivity of the sensors and how their outputs are interpreted to detect curbs and other obstacles.

[0047] Current sensor tuning methods often rely on limited data sources and frequently require cumbersome FOTA (e.g., over-the-air software installation) campaigns to iteratively improve on-vehicle ADAS performance in a timely and efficient manner. An example of an implementation is a software-defined component that collects and transmits data from multiple data sources, including signals, camera data, sensor data, and logs, to the cloud. The data can then be correlated in the cloud using advanced algorithms and machine learning techniques to enable rapid and accurate identification of areas where sensor performance can be improved.

[0048] Subsequently, the output in the form of performance mappings for lightweight, optimized sensors and actuators can be immediately deployed to the vehicle, enabling real-time updates to improve ADAS performance. Embodiments of this specification that support MTDM operation enable automotive manufacturers and suppliers to efficiently keep their components up-to-date after manufacturing and optimize them for all conceivable scenarios, including those not anticipated or understood at the time of manufacturing. Operation includes dynamically and accurately collecting data of interest from multiple sources such as signals, camera data, sensor data, and logs; conveniently executing scheduled diagnostic routines or sensor calibration campaigns from the cloud; and quickly deploying new component performance mappings to target ECUs, enabling such embodiments to efficiently keep components up-to-date without costly FOTA campaigns.

[0049] Referring again to Figure 3, the example system includes a controller V102 having a policy manager 302 that interprets policies (e.g., as cloud communications 320 and / or tool communications 322) that include an automated escalation protocol for vehicle monitoring operations, a data collection manager 308 that interprets vehicle data in response to vehicle monitoring operations, and a monitoring manager 312 that detects vehicle events in response to vehicle data (e.g., determining that a vehicle event has occurred in response to trigger evaluations (one or multiple) provided within the policy) and executes the automated escalation protocol in response to determining that a vehicle event is active. The example automated escalation protocol provides progress for MTDM operations, such as progress of monitoring, testing, diagnostic and / or maintenance operations in response to trigger evaluations provided within the policy, transitions between operations, or controlled iterative operations.

[0050] Referring to Figure 8, exemplary and non-limiting actions that can be performed as escalation protocol action 802 include: performing passive tests 804, performing active tests 806, collecting additional data 808 (e.g., collecting a first dataset until a vehicle event is detected and a second dataset in response to the detected event, for purposes such as gaining a better understanding of the cause of the event, improving future vehicle response during the event, determining whether related conditions also exist due to the event, or collecting data to support diagnostics, testing, continuous improvement actions, etc.), developing, deploying and / or performing fault tree analysis (or part thereof) 810, providing notifications 812 (e.g., to any user defined in the policy, such as a service representative, controller C administrator, manufacturer, vehicle owner, or operator), and updating communications to users 81 4 (for example, updating the user on the status of MTDM operation, the progress of MTDM operation, important decisions made during MTDM operation, etc.), performing automatic adjustments 816 (for example, enabling a quick vehicle response to detected conditions in order to mitigate the consequences of an event), performing automatic diagnostics 820 (for example, performing diagnostics prepared to be performed in response to a condition after a condition has been detected), performing automatic maintenance 822 (for example, changing vehicle configuration, calibration, trim, etc. in response to a detected event and / or further data collection, testing, or diagnostics performed in response to the detected event), and / or performing reliability improvement actions 826 (for example, collecting further relevant data that tends to identify or exclude conditions that are thought to cause an event, in order to determine whether the relevant conditions also exist in the vehicle). Escalation protocol action example 802 includes, for example, performing an automatic rollback 824 to return the vehicle to the condition before automatic adjustment 816 in response to determining that the automatic adjustment was ineffective, determining that the underlying conditions potentially indicated by the detected events do not actually exist on the vehicle, determining that the automatic adjustment 816 has caused another problem on the vehicle, and / or removing a temporary fix on the vehicle that was avoided by a more permanent fix.Escalation protocol action example 802 includes a fully capable workflow 818 that supports an escalation operation involving multiple operations ordered according to various trigger evaluations, branch operations, loop operations and / or recursive operations, and / or enables multiple MTDM operations to further develop information through further data collection operations.

[0051] The system example includes a data collection manager 308 that performs at least a portion of the automated vehicle data collection operations of the automated escalation protocol. The system example includes a diagnostic manager 314 that performs at least a portion of the automated diagnostic operations of the automated escalation protocol. The system example includes a test manager 316 that performs at least a portion of the automated test operations of the automated escalation protocol. The system example includes a maintenance manager 318 that performs at least a portion of the automated maintenance operations of the automated escalation protocol. The system example includes an external communications manager 306 that performs at least a portion of the notification operations to (one or multiple) users that form part of the automated escalation protocol. In some embodiments, cloud-side managers 402, 408, 412, 414, 416, and 418 can support managers 302, 308, 312, 314, 316, and 318 for purposes such as storing data, performing specific processing and / or analytical operations, and providing communications to users using communication avenues that may not be generally available to vehicles.

[0052] Examples of exemplary and non-exclusive notifications that can be used as part of an automated escalation protocol include one or more of the following: instructions for detected vehicle events, values ​​determined during at least one of an automated diagnostic operation or automated test operation, actions performed while the automated escalation protocol is being implemented, or the status of the automated escalation protocol implementation. Examples of exemplary and non-exclusive notifications include one or more of the following: detected vehicle events, test parameters for an automated test operation, test results for an automated test operation, or the status of an automated test operation. Examples of exemplary and non-exclusive notifications include one or more of the following: detected vehicle events, diagnostic parameters for an automated diagnostic operation, diagnostic results for an automated diagnostic operation, or the status of an automated diagnostic operation. Examples of exemplary and non-exclusive notifications include one or more of the following: notification that an automated test operation has been performed or is pending, a summary of key results from an automated test operation, the next steps planned in accordance with the automated escalation protocol, or the progress of the automated escalation protocol.

[0053] An exemplary and non-exclusive automated vehicle data collection operation is the operation of collecting selected vehicle data related to a detected vehicle event. Examples of exemplary and non-exclusive selected vehicle data include data related to the detected vehicle event, confirmation data used to verify the detected vehicle event and / or related conditions, and / or related vehicle condition data (for example, condition X may be an indicator that condition Y also exists, and related vehicle condition data is data that checks and / or confirms the existence of condition Y). Examples of exemplary and non-exclusive automated test operations include confirmation tests (for example, verifying that an event is real and / or related conditions actually exist) and / or related vehicle condition tests. Examples of exemplary and non-exclusive automated test operations include, for example, performing a test operation at a later point in time on past data stored in a rolling buffer of related data, and performing a post-test on recently collected data stored in the rolling buffer (and / or including further ongoing data collected during the test operation) when, for example, the trigger conditions for the automated test are met. Exemplary and non-limiting automated maintenance operations include one or more of the following: vehicle adjustment operations, vehicle calibration operations, vehicle reconfiguration operations, and / or feature activation operations. In some embodiments, automated maintenance operations are performed in response to confidence values ​​related to detected vehicle events and / or confidence values ​​related to the detection of basic vehicle conditions relating to the detected vehicle events (determined, for example, as a result of further testing and / or diagnostic operations). In some embodiments, automated maintenance operations are performed in response to influence values ​​related to detected vehicle events (and / or basic vehicle conditions), and maintenance operations are applied more strongly or more quickly, for example, if the influence of the conditions on the vehicle's ability to perform the vehicle's mission functions is significant.In some embodiments, automatic maintenance operations are performed in response to influence values ​​related to the automatic maintenance operation, and maintenance operations that could significantly affect the vehicle's ability to perform the vehicle's transmission functions, for example, can be delayed or postponed until the vehicle is no longer affected by these operations and / or compared to the influence values ​​of the baseline conditions (for example, maintenance operations that pose a high risk of affecting the vehicle's transmission can be postponed until the influence values ​​of the baseline conditions outweigh the potential impact of the maintenance operation, and if the maintenance action limits the vehicle's maximum output, the maintenance operation can be postponed until the baseline conditions reduce transmission performance and / or pose a risk of damaging the vehicle).

[0054] In some embodiments, the operation of the escalation protocol is performed in accordance with permissions defined in the policy. Permissions may define the data that can be collected, resource usage restrictions, actuators that can be controlled, vehicle operating condition restrictions (e.g., specific operations limited to low power or idle operation), time restrictions, network usage restrictions (e.g., restricting operation when the vehicle network is relatively busy supporting the vehicle's transmission operation), data that can be exposed or otherwise provided by the escalation operation, parameter restrictions (e.g., the escalation operation can only set the cruise control speed within a specific range). Permissions may relate to authorizations granted to users, devices, flows, applications, or user-related entities that provide, request, and / or enable implementations of the escalation protocol. In some embodiments, example authorizations and implementations relate to any of the MTDM actions shown throughout this disclosure.

[0055] The automated maintenance operation is executed in response to the status of vehicles within a selected group of vehicles, for example, enabling the operation to proceed on a vehicle and allowing the system to postpone maintenance on subsequent vehicles in the group until the impact on the initial vehicle in the group is determined and / or confirmed. In some embodiments, the maintenance operation for a group of vehicles can be limited to a small group of vehicles and rolled out to the entire group after waiting for the impact to be analyzed and / or for any problems caused by the maintenance operation to be checked. In some embodiments, for example when the group of vehicles is very large, the maintenance operation can be configured to manage the risks of implementation by utilizing multiple rollout stages, such as one vehicle, then 10 vehicles, then 100 vehicles, before the maintenance operation is performed on the entire group, or by utilizing learning from the initial vehicle. The automated maintenance operation is executed in response to the issue scope value of a detected vehicle event. The problem scope value provides a lever for determining how many vehicles will be affected, allowing for a single approach to addressing issues specific to a particular vehicle (e.g., performing maintenance only when indicated), while addressing issues affecting a large fleet can be handled differently (e.g., a staged rollout, and / or including more data collection, diagnostics, and / or testing to ensure the issue is fully understood before beginning a rollout to further vehicles). Automated maintenance operation examples are performed in response to the maintenance classification of the automated maintenance operation, and the implementation is adjusted based on, for example, the type of maintenance (e.g., which systems are affected, whether a rollback is available, whether the transmission may be affected, etc.) and / or how many other vehicles have similar maintenance classifications and therefore how many vehicles are likely to be affected by similar problems and / or maintenance operations.

[0056] The Maintenance Manager example performs a rollback action in response to a vehicle response value indicating that a detected vehicle event was not resolved by an automated maintenance action. The Automated Escalation Protocol example includes alternative actions to be used in response to a detected vehicle event not being resolved by an automated maintenance action. Exemplary and non-limiting alternative actions include one or more of the following: alternative test actions, alternative diagnostic actions, further monitoring actions, and / or further maintenance actions. The Maintenance Manager example adjusts or selects alternative actions (e.g., from a set of actions that may relate to various potential outcomes of monitoring, testing, and / or diagnostic actions) in response to a vehicle response value (e.g., indicating whether the detected event and / or underlying condition was resolved by a maintenance action).

[0057] The monitoring manager example determines MTDM outcome results in response to the automated escalation protocol (e.g., whether the problem has been resolved and / or whether the maintenance action has provided the vehicle with an acceptable configuration), and the external communication manager provides the MTDM outcome results to the second vehicle (e.g., enabling the implementation on the second vehicle to benefit from the observation of the MTDM action on the first vehicle). The external communication manager example interprets the MTDM outcome results from the second vehicle and adjusts the automated escalation protocol for the first vehicle in response to the MTDM outcome results from the second vehicle.

[0058] Referring to Figure 9, the example system includes an automated MTDM builder 902 which includes an MTDM interface manager 904 that communicates with user equipment (e.g., as platform communication 914) through the MTDM interface to facilitate the construction of MTDM workflows (e.g., any of the monitoring, testing, diagnostic and / or maintenance operations, automated escalation protocols, and / or complete workflows schematically shown in the illustrations and related descriptions of Figures 6-7) by implementing the MTDM interface. The automated MTDM builder 902 further includes an MTDM assistance manager 906 that exposes an MTDM workflow library (e.g., stored in data store 916 and / or stored in communication with the automated MTDM builder 902) to the MTDM interface, and an MTDM implementation manager 908 that prepares at least one of policies, recipes, maps, and / or models in response to user interaction with the MTDM interface. The example MTDM workflow library includes one or more embodiments such as escalation scheme objects, trigger logic objects, or notification logic objects. In addition to or instead of the above, the MTDM workflow library example also includes one or more aspects such as monitoring workflow elements, test workflow elements, diagnostic workflow elements, maintenance workflow elements, and / or automated escalation protocols. The MTDM workflow library example includes one or more parts of any of the aspects described above, allowing the user to leverage some of these aspects that have been previously created, for example, by the user or another user, and / or provided as templates for specific MTDM actions.MTDM support manager example 906 inserts objects from the MTDM workflow library into an MTDM workflow in response to user selection actions (e.g., the user selecting an object from a list, performing a drag-and-drop action, or selecting an object using the API interface to the automated MTDM builder 902). MTDM support manager example 906 also creates new objects within the MTDM workflow library in response to user object creation actions (e.g., allowing the user to press a button or other executable object to capture the current workflow and / or its selection as a new library object in the MTDM workflow library). An MTDM workflow example includes one or more of the following: an MTDM workflow cycle, branching actions, looping actions, a trigger scheme, a rollback scheme, or an escalation scheme.

[0059] MTDM Implementation Manager Example 908 provides at least one of policy 910 or recipe 912 to vehicles in response to a user rollout action (for example, a user rollout action may include a "Submit" button or similar interface object for implementing the rollout, and / or may include requesting the rollout action using an API, confirmation interface, etc.). MTDM Implementation Manager Example 908 provides at least one of policy or recipe to a selected group of vehicles in response to a user rollout action (for example, a user may define a selected group of vehicles in a standardized way, such as by model number, year, associated software version or hardware components, vehicles having specific detected events and / or basic conditions, vehicles owned by a specific entity, vehicles belonging to a specific fleet, etc.). MTDM Implementation Manager Example 908 provides at least one of policy or recipe to the selected group of vehicles using a rollout schedule, which includes the order and / or timing of providing at least one of policy or recipe to individual vehicles in the selected group of vehicles. For example, the user can define the rollout schedule, or / or the rollout schedule can be automatically determined in response to the impact of relevant detected events and / or basic conditions, or the impact of MTDM operations performed by the rollout. The MTDM implementation manager example 908 customizes at least one of the policies or recipes for at least one individual vehicle in the selected vehicle group in response to the characteristics of at least one individual vehicle in the selected vehicle group. For example, the selected vehicle group may have variations in endpoint locations, hardware components and / or their versions, or software components and / or their versions, and the MTDM implementation manager 908 adjusts the policies and / or recipes to take into account these differences, which may not be related to the basic mode of MTDM operation, thereby relieving the user of the burden of considering these issues for individual vehicles in the group.Exemplary and non-limiting characteristics that may indicate customization include one or more of the following: endpoint name, endpoint location (e.g., network address, network zone location, network zone type, etc.), endpoint configuration (e.g., data sampling rate, network protocol, network packet configuration, data unit, data resolution, data byte size, etc.), and / or network configuration in at least one individual vehicle (e.g., selected zone architecture, number and type of zones, connectivity between zones, etc.).

[0060] Figure 10 shows actuator commands 1004, data acquisition operations 1006, conditional operations 1008 (e.g., operations to be performed based on trigger conditions and evaluations), branch operations 1010 (e.g., one or more modes to be performed in parallel and / or independently of each other), loop operations 1012 (e.g., operations to be continuously repeated a set number of times until another condition is met), rolling data buffer maintenance 1014 (e.g., enabling post-ingestion of data generated before the occurrence of a trigger event), and selected data exposure 1016 (e.g., new data generated by MTDM operations, new data generated by MTDM operations, and / or previously available data). The following are illustrative and non-limiting recipe elements 1002, including data that was previously unpublished but may now be of interest, subscription to selected data 1018 (e.g., searching for data that was previously available but not received by a particular endpoint, application, flow, feature, etc.), data processing operations 1020 (e.g., performing specific data processing such as statistical analysis, compression, filtering, smoothing, outlier or noise removal), sending notifications 1022, and / or manipulating models 1024 (e.g., models provided by the user through the MTDM interface, models provided by the cloud data analytics component, etc.).

[0061] Referring again to Figures 6 and 7, System Examples 600 and 700 include a vehicle data platform 606 that provides a vehicle with a policy containing MTDM workflow elements (e.g., monitoring elements, test elements, diagnostic elements, maintenance elements, and / or automated escalation protocol elements), and a vehicle automation platform 608 that provides a vehicle with a recipe containing actions for automated vehicle responses. Vehicle data platform example 606 is further configured to receive collected data from the vehicle in response to the execution of at least one of the MTDM workflow elements or automated vehicle responses by the vehicle's controller 102. An MTDM workflow example includes arrangements of elements such as monitoring operations and maintenance operations, monitoring operations and test operations and maintenance operations, and / or monitoring operations and diagnostic operations and maintenance operations. Examples of MTDM workflow examples include arrangements of elements such as monitoring operations and maintenance operations and further monitoring operations, monitoring operations and test operations and further monitoring operations and further test operations, monitoring operations and diagnostic operations and further monitoring operations and test operations, or monitoring operations and diagnostic operations and further monitoring operations and further diagnostic operations. The deployment examples for MTDM workflows are non-limiting, and as shown throughout this disclosure, any number of workflow elements can be arranged in any order, according to any transition criteria between elements, according to specified actions for detecting and / or confirming vehicle events and / or basic conditions. Vehicle automation platform example 608 provides a vehicle with a map containing a control model for at least one aspect of the vehicle. Exemplary and non-limiting aspects of a vehicle for a control model include one or more of the vehicle's motors, vehicle components, vehicle powertrain, vehicle endpoints, vehicle flow, or vehicle applications.Without limiting to any other aspect of this disclosure, the maps provided to a vehicle by the vehicle automation platform 608 include one or more of the following: tuning parameters for the vehicle's control algorithm (e.g., gain, setpoint, error value), control method selection for the vehicle's control algorithm (e.g., which version of the control algorithm should be used, enabled, or disabled), and / or model parameters. Exemplary and non-limiting model parameters include one or more of the following: virtual sensors of the vehicle, feedforward components of the vehicle's control algorithm, and / or response models of the vehicle's characteristics. Example vehicle automation platform 608 provides a recipe and / or performance map to the vehicle in response to a model of the vehicle's characteristics (e.g., a cloud model). In some embodiments, the vehicle automation platform 608 includes a vehicle model which may be a functional equivalent of the cloud model or a scaled-down version of the cloud model. An example cloud model includes an artificial intelligence model implemented by a data analysis component.

[0062] Several procedures are described below. These example procedures are illustrative, and the actions described may be rearranged in whole or in part, actions may be omitted, repeated, and / or combined between procedures. One or more, or all, aspects of the procedures described may be performed by any of the systems, managers, controllers, platforms, or other devices shown throughout this disclosure.

[0063] Figure 11 schematically shows an example procedure 1100 for executing an automated escalation protocol. Example procedure 1100 includes an action 1102 for interpreting a policy that includes an automated escalation protocol for a vehicle, an action 1104 for interpreting vehicle data in response to a vehicle monitoring action, and an action 1106 for detecting a vehicle event in response to the vehicle data and executing the automated escalation protocol in response to determining that the vehicle event is active.

[0064] Figure 12 schematically shows an example procedure 1200 for implementing the MTDM interface. Example procedure 1200 includes operation 1202 for implementing the MTDM interface, operation 1204 for communicating with user devices through the MTDM interface to facilitate the construction of MTDM workflows, operation 1206 for exposing the MTDM workflow library to the MTDM interface, and operation 1208 for preparing policies and / or recipes in response to user interaction with the MTDM interface.

[0065] Figure 13 schematically shows example procedure 1300 for implementing the MTDM interface. Example procedure 1300 further includes, in addition to procedure 1200, an operation 1302 for inserting an object from the library into the MTDM interface in response to a user selection operation, and / or for storing a new object in the library in response to a user object creation operation. Figure 14 schematically shows example procedure 1400 for implementing the MTDM interface. Example procedure 1400 further includes, in addition to procedure 1200, an operation 1402 for providing a policy / receipt to a vehicle in response to a user rollout operation. Figure 15 schematically shows example procedure 1500 for implementing the MTDM interface. Example procedure 1500 further includes, in addition to procedure 1200, an operation 1502 for providing a policy / receipt to a selected group of vehicles in response to a user rollout operation.

[0066] Figure 16 schematically shows example procedure 1702 for a rollout operation, which includes providing a policy / recipe to a selected group of vehicles using a rollout schedule. Figure 17 schematically shows example procedure 1802 for a rollout operation, which includes customizing a policy / recipe for one or more vehicles in a selected group in response to the characteristics of one or more vehicles.

[0067] Figure 18 schematically shows example procedure 1900 for a rollout operation. Example procedure 1900 includes operation 1902, which provides the vehicle with a policy containing one or more MTDM workflow elements. Example procedure 1900 further includes operation 1904, which provides the vehicle with a recipe containing actions for automated vehicle responses, and operation 1906, which receives collected data from the vehicle in response to the execution of the MTDM workflow elements and / or automated vehicle responses.

[0068] Figure 19 schematically shows example procedure 2000 for a rollout operation. Example procedure 2000 includes, in addition to procedure 1900, operation 2002, which provides the vehicle with a map containing a control model for the vehicle's configuration. Figure 20 schematically shows example procedure 2100 for a rollout operation. Example procedure 2100 includes, in addition to procedure 1900, operation 2102, which provides the vehicle with a map containing tuning parameters, control method selection, and / or model parameters. Figure 21 schematically shows example procedure 2200 for a rollout operation. Example procedure 2200 includes, in addition to procedure 1900, operation 2202, which provides the vehicle with a map and / or performance model in response to a model of the vehicle's configuration. Figure 22 schematically shows example procedure 2300 for a rollout operation. Example procedure 2300 includes, in addition to procedure 1900, operation 2302, which provides the vehicle with a vehicle model in response to a cloud model of the vehicle's configuration.

[0069] The methods and systems described herein can be partially or entirely deployed through a machine having a computer, computer device, processor, circuit and / or server, which includes computer-readable instructions, program code, instructions, and / or hardware configured to functionally perform one or more operations of the methods and systems described herein. The terms computer, computer device, processor, circuit and / or server ("computer device") used herein should be understood in a broad sense.

[0070] Examples of computer devices include any type of computer that can access instructions stored communicably on a non-temporary computer-readable medium or the like, and so the computer performs the operations of the computer device when the instructions are executed. In some embodiments, such instructions themselves constitute the computer device. In addition to or instead of this, the computer device may be an independent hardware device, one or more computing resources distributed across hardware devices, and / or embodiments such as logic circuits, embedded circuits, sensors, actuators, input and / or output devices, networks and / or communication resources, any type of memory resource, any type of processing resource, and / or hardware devices configured to functionally perform one or more operations of the systems and methods herein in response to determined conditions.

[0071] Network and / or communication resources include, but are not limited to, local area networks, wide area networks, wireless, the Internet, or any other known communication resources and protocols. Exemplary and non-exclusive hardware and / or computer devices include, but are not limited to, general-purpose computers, servers, embedded computers, mobile devices, virtual machines, and / or emulated computer devices. A computer device can be a distributed resource included as a set of interoperable resources for performing the functions of the described computer device, such that distributed resources work together to perform the operation of the computer device. In some embodiments, each computer device may reside on independent hardware, and / or one or more hardware devices may include a set of computer devices, for example, as independently executable instructions stored on the devices and / or as logically divided sets of executable instructions, some of which include a portion of one of the first computer devices, and some of which include a portion of other portions of these computer devices.

[0072] Computer devices can be servers, clients, network infrastructure, mobile computing platforms, fixed computing platforms, or part of other computing platforms. A processor can be any type of computation or processing device capable of executing program instructions, code, and binary instructions, etc. A processor can be a signal processor, a digital processor, an embedded processor, a microprocessor, or a variant of a coprocessor (such as a math coprocessor, a graphics coprocessor, and a communications coprocessor) or similar devices that can directly or indirectly facilitate the execution of stored program code or program instructions, or may include such devices. A processor can also enable the execution of multiple programs, threads, and code. Threads can be executed concurrently to enhance processor performance and facilitate the simultaneous operation of applications. As an implementation, the methods, program code, and program instructions described herein can be implemented in one or more threads. Threads can trigger other threads to which associated priorities may be assigned, and the processor can execute these threads based on priority or any other order based on instructions provided within the program code. A processor may include memory for storing methods, code, instructions, and programs as described herein and elsewhere. The processor may access, through an interface, a storage medium capable of storing methods, programs, code, program instructions, or other types of instructions that a computer device or processing unit can execute. Examples of processor-related storage media for storing such methods, programs, code, program instructions, or other types of instructions include, but are not limited to, one or more of the following: CD-ROMs, DVDs, memory, hard disks, flash drives, RAM, ROM, and caches.

[0073] The processor may include one or more cores that can enhance the speed and performance of the multiprocessor. In embodiments, the process may be a dual-core processor, a quad-core processor, other chip-level multiprocessors, and similar combinations of two or more independent cores (referred to as chips).

[0074] The methods and systems described herein can be deployed in part or in whole through a server, client, firewall, gateway, hub, router, or other machine that executes computer-readable instructions on such computer and / or networking hardware. Computer-readable instructions may be associated with a server, which may include file servers, print servers, domain servers, internet servers, intranet servers, and other variants such as secondary servers, host servers, and distributed servers. A server may include one or more of the following: memory, processors, temporary and / or non-temporary computer-readable media, storage media, (physical and virtual) ports, communication devices, and interfaces that allow access to other servers, clients, machines, and devices via wired or wireless media. Methods, programs, or code as described herein and elsewhere may also be executed by a server. Furthermore, other equipment necessary for executing the methods described herein may be considered part of the infrastructure associated with the server.

[0075] The server may provide interfaces to other devices, including, but is not limited to, clients, other servers, printers, database servers, print servers, file servers, communication servers, and distributed servers. This coupling and / or connection may also facilitate remote program execution across networks. Some or all of the networking of these devices may, without departing from the scope of this disclosure, facilitate parallel processing of program code, instructions, and / or programs at one or more locations. Furthermore, all devices connected to the server via an interface may include at least one storage medium capable of storing methods, program code, instructions, and / or programs. Program instructions to be executed on different devices may be provided by a central repository. In this implementation, a remote repository may function as a storage medium for methods, program code, instructions, and / or programs.

[0076] Methods, program code, instructions, and / or programs may relate to clients, which may include file clients, print clients, domain clients, internet clients, intranet clients, and other variants such as secondary clients, host clients, and distributed clients. A client may include one or more of the following: memory, processors, temporary and / or non-temporary computer-readable media, storage media, (physical and virtual) ports, communication devices, and interfaces that allow access to other clients, servers, machines, and devices via wired or wireless media. Methods, program code, instructions, and / or programs as described herein and elsewhere may also be executed by a client. Other devices necessary for executing the methods described in this application may be considered part of the infrastructure related to the client.

[0077] The client may provide interfaces to other devices, including, but is not limited to, servers, other clients, printers, database servers, print servers, file servers, communication servers, and distributed servers. This coupling and / or connection may also facilitate the remote execution of methods, program code, instructions, and / or programs across a network. Some or all of the networking of these devices may, without departing from the scope of this disclosure, facilitate the parallel processing of methods, program code, instructions, and / or programs at one or more locations. Furthermore, all devices connected to the client via the interface may include at least one storage medium capable of storing methods, program code, instructions, and / or programs. Program instructions to be executed on different devices may be provided by a central repository. In this implementation, a remote repository may function as a storage medium for methods, program code, instructions, and / or programs.

[0078] The methods and systems described herein can be deployed partially or entirely through a network infrastructure. The network infrastructure may include elements such as computer devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices, and other active and passive devices, modules, and / or components, as are well known in the art. Computer devices and / or non-computer devices associated with the network infrastructure may include storage media such as flash memory, buffers, stacks, RAM, and ROM, separate from other components. Methods, program code, instructions, and / or programs as described herein and elsewhere may be executed by one or more of these network infrastructure elements.

[0079] Methods, program code, instructions, and / or programs as described herein and elsewhere can be implemented on a cellular network having multiple cells. The cellular network may be either a frequency division multiple access (FDMA) network or a code division multiple access (CDMA) network. The cellular network may include mobile devices, cell sites, base stations, repeaters, antennas, and towers, etc.

[0080] Methods, program code, instructions, and / or programs as described herein and elsewhere may be implemented on or via a mobile device. A mobile device may include navigation devices, cellular telephones, mobile phones, personal digital assistants, laptops, palmtops, netbooks, pagers, e-book readers, and music players. These devices may include, separately from other components, storage media such as flash memory, buffers, RAM, ROM, and one or more computer devices. Computer devices associated with a mobile device may execute stored methods, program code, instructions, and / or programs. Alternatively, a mobile device may be configured to execute instructions in cooperation with other devices. A mobile device may communicate with a base station configured to execute methods, program code, instructions, and / or programs in conjunction with a server. A mobile device may communicate over a peer-to-peer network, a mesh network, or other communication network. Methods, program code, instructions, and / or programs may be stored in storage media associated with a server and executed by computer devices embedded in the server. A base station may include computer devices and storage media. A storage device may store methods, program code, instructions, and / or programs executed by computer devices associated with the base station.

[0081] Methods, program code, instructions, and / or programs may be stored in and / or accessed on temporary and / or non-temporary machine-readable media, which may include computer components, devices and recording media that hold digital data used for calculations over some time intervals, mass storage typically for more persistent storage such as semiconductor storage known as random access memory (RAM), optical disks, hard disks, tapes, drums, cards and other types of magnetic storage, processor registers, cache memory, volatile memory, non-volatile memory, optical storage such as CDs and DVDs, flash memory (e.g., USB sticks or keys), floppy disks, magnetic tape, paper tape, punch cards, standalone RAM disks, Zip drives, removable mass storage and offline media, dynamic memory, static memory, read / write storage, variable storage, read-only, random access, sequential access, location-addressable, file-addressable, content-addressable, network-attached storage, storage area networks, barcodes, magnetic ink and other computer memory.

[0082] Some operations described herein involve interpreting, receiving, and / or determining one or more values, parameters, inputs, data, or other information ("received data"). Operations that receive data include, but are not limited to, receiving data via user input, receiving data via any type of network, reading data values ​​from memory locations communicating with the receiving device, using default values ​​as received data values, estimating, calculating, or deriving data values ​​based on other information available to the receiving device, and / or updating any of these in response to subsequently received data values. In some embodiments, a data value may be received by a first operation and then updated by a second operation as part of receiving data values ​​thereafter. For example, a first receiving operation may be performed when communication is stopped, intermittent, or interrupted, and an updated receiving operation may be performed when communication is restored.

[0083] To illustrate aspects of this disclosure, we provide specific logical groupings of operations in this specification, such as methods or procedures of this disclosure. The operations described herein are described and / or depicted in general terms, and operations can be combined, divided, rearranged, added, or deleted in accordance with the disclosures herein. While the context of an operation description may require a sequence of one or more operations, and / or may explicitly disclose a sequence of one or more operations, the sequence of operations should be understood in a broad sense where any equivalent grouping of operations that yields equivalent operational results is specifically assumed herein. For example, if a value is used in an operation step, depending on the context (e.g., if it is important for an operation to time delay data to achieve a particular effect), the determination of the value may be required before that operation step, or it may not be required before that operation step (e.g., if it seems sufficient to use a value from an execution cycle of a previous operation for these purposes). Accordingly, in some embodiments of this specification, the sequence of operations and groupings of operations described herein are explicitly assumed, and in some embodiments of this specification, rearrangement, subdivision, and / or different groupings of operations are explicitly assumed.

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

[0085] The methods and / or processes and their steps described above can be implemented in hardware, program code, instructions, and / or programs, or in any combination of hardware and methods, program code, instructions, and / or programs suitable for a particular application. The hardware may include a dedicated computer device or a specific computer device, a specific aspect or component in a specific computer device, and / or an arrangement of hardware components and / or logic circuits to perform one or more operations of the methods and / or system. These processes can be implemented in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors, or other programmable devices, together with internal and / or external memory. In addition to or separately from these, these processes can also be embodied in application-specific integrated circuits, programmable gate arrays, programmable array logic, or any other device or combination of devices that can be configured to process electronic signals. Furthermore, it will be understood that one or more of these processes can also be implemented as computer executable code that can be executed on a machine-readable medium.

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

[0087] Accordingly, in one embodiment, each of the methods and combinations of methods described above can be embodied in computer-executable code that performs the steps of the method when executed on one or more computer devices. In another embodiment, these methods can be embodied in a system that performs its steps and distributed across multiple devices, or all functions can be integrated into a dedicated standalone device or other hardware. In yet another embodiment, the means for performing the steps related to the processes described above may include either the hardware and / or computer-readable instructions described above. All such substitutions and combinations are intended to be within the scope of this disclosure.

[0088] While this disclosure has been made in relation to several embodiments illustrated and described in detail, various modifications and improvements to this disclosure will be readily apparent to those skilled in the art. Accordingly, the purpose and scope of this disclosure should not be limited by the examples described above, but should be understood in the broadest sense permitted by law. [Explanation of Symbols]

[0089] 102 Controller V 302 Policy Manager 304 Network Manager 306 External Communications Manager 308 Data Acquisition Manager 310 Network Manager 312 Monitoring Manager 314 Diagnostic Manager 316 Test Manager 318 Maintenance Manager 320 Cloud Communication 322 Tool Communication 324 Operator Communication

Claims

1. A policy manager configured to interpret policies, including an automated escalation protocol for vehicle monitoring operations, A data acquisition manager configured to interpret vehicle data in response to the aforementioned vehicle monitoring operation, A monitoring manager configured to detect vehicle events in response to the vehicle data and to execute the automated escalation protocol in response to determining that the vehicle event is active, A system equipped with these features.

2. The aforementioned automated escalation protocol includes automated vehicle data collection operations, The system according to claim 1.

3. The system further comprises a data collection manager that performs at least a portion of the aforementioned automated vehicle data collection operations. The system according to claim 2.

4. The aforementioned automated escalation protocol includes automated diagnostic operations, The system according to claim 1.

5. The system further comprises a diagnostic manager that performs at least a portion of the aforementioned automated diagnostic operations. The system according to claim 4.

6. The aforementioned automated escalation protocol includes automated test operations, The system according to claim 1.

7. The system further comprises a test manager that performs at least a portion of the aforementioned automated test operations. The system according to claim 6.

8. The aforementioned automated test operation includes passive testing. The system according to claim 6.

9. The aforementioned automated test operation includes a post-test that utilizes stored vehicle data. The system according to claim 8.

10. The aforementioned automated test operation includes active testing. The system according to claim 6.

11. The aforementioned automated escalation protocol includes automated maintenance operations, The system according to claim 1.

12. The system further comprises a maintenance manager that performs at least a portion of the aforementioned automated maintenance operations. The system according to claim 11.

13. The aforementioned automated escalation protocol includes, The system according to claim 1.

14. The aforementioned notice is, Instructions for the detected vehicle events, A value determined during at least one of the automated diagnostic operation or automated test operation, Actions performed during the execution of the aforementioned automated escalation protocol, or The status of the execution of the aforementioned automated escalation protocol, The system according to claim 13, comprising at least one of the following.

15. The aforementioned automated vehicle data collection operation includes the operation of collecting selected vehicle data related to the detected vehicle event, The system according to claim 2.

16. The selected vehicle data includes verification data. The system according to claim 15.

17. The selected vehicle data includes related vehicle condition data. The system according to claim 15.

18. The aforementioned automated test operation is performed in accordance with the permissions set forth in the policy. The system according to claim 6.

19. The aforementioned automated test operation is performed in accordance with the vehicle operating conditions defined in the policy. The system according to claim 18.

20. The aforementioned automated test operation includes a verification test. The system according to claim 6.

21. The aforementioned automated test operation includes relevant vehicle condition tests, The system according to claim 6.

22. The aforementioned automated escalation protocol includes notification to the selected user, The notification includes at least one of the detected vehicle event, the test parameters of the automated test operation, the test results of the automated test operation, or the status of the automated test operation. The system according to claim 6, further comprising the following:

23. The aforementioned automated escalation protocol includes notification to the selected user, The notification includes at least one of the following: a notification that the automated test operation has been performed or is pending; a summary of the main results from the automated test operation; the next steps planned in accordance with the automated escalation protocol; or the progress of the automated escalation protocol. The system according to claim 6, further comprising the following:

24. The aforementioned automated diagnostic operation is performed in accordance with the permissions set forth in the policy. The system according to claim 4.

25. The aforementioned automated diagnostic operation is performed in accordance with the vehicle operating conditions defined in the policy. The system according to claim 24.

26. The aforementioned automated escalation protocol includes notification to the selected user, The notification includes at least one of the detected vehicle event, the diagnostic parameters of the automatic diagnostic operation, the diagnostic result of the automatic diagnostic operation, or the status of the automatic diagnostic operation. The system according to claim 24, further comprising the following:

27. The aforementioned automated escalation protocol includes notification to the selected user, The notification includes at least one of the following: a notification that the automated diagnostic operation has been performed or is pending; a summary of the main results from the automated diagnostic operation; the next steps planned in accordance with the automated escalation protocol; or the progress of the automated escalation protocol. The system according to claim 24, further comprising the following:

28. The aforementioned automatic maintenance operation includes a vehicle tuning operation. The system according to claim 11.

29. The aforementioned automatic maintenance operation includes a vehicle calibration operation. The system according to claim 11.

30. The aforementioned automatic maintenance operation includes a vehicle reconfiguration operation. The system according to claim 11.

31. The aforementioned automatic maintenance operation includes a feature activation operation. The system according to claim 11.

32. The aforementioned automatic maintenance operation is performed in response to the confidence value associated with the detected vehicle event. The system according to claim 11.

33. The aforementioned automatic maintenance operation is performed in response to the influence value related to the detected vehicle event. The system according to claim 11.

34. The aforementioned automatic maintenance operation is performed in response to the influence values ​​related to the automatic maintenance operation. The system according to claim 11.

35. The maintenance manager is further configured to perform the automated maintenance operation in response to the status of the vehicle within the selected group of vehicles. The system according to claim 12.

36. The maintenance manager is further configured to determine the problem range value of the detected vehicle event and to perform the automatic maintenance operation in response to the problem range value. The system according to claim 12.

37. The maintenance manager is further configured to determine a maintenance classification for the automated maintenance operation and to execute the automated maintenance operation in response to the maintenance classification. The system according to claim 12.

38. The monitoring manager is further configured to determine the vehicle response value to the automatic maintenance operation, The maintenance manager is further configured to perform a rollback operation in response to the vehicle response value indicating that the detected vehicle event was not resolved by the automatic maintenance operation. The system according to claim 11, further comprising the following:

39. The automated escalation protocol includes alternative actions used in response to the detected vehicle event not being resolved by the automated maintenance operation. The system according to claim 38.

40. The alternative action includes at least one of the following: an alternative test action, an alternative diagnostic action, an additional monitoring action, or an additional maintenance action. The system according to claim 39.

41. The maintenance manager is further configured to either adjust the alternative action or select the alternative action in response to the vehicle response value. The system according to claim 39.

42. The monitoring manager is further configured to determine the MTDM performance result in response to the automated escalation protocol. The system further comprises an external communication manager configured to provide the MTDM performance results to a second vehicle. The system according to claim 1.

43. The system further comprises an external communications manager configured to interpret MTDM performance results from a second vehicle and to adjust the automatic escalation protocol in response to the MTDM performance results from the second vehicle. The system according to claim 1.

44. A system equipped with an automatic MTDM builder, wherein the automatic MTDM builder is An MTDM interface manager is configured to implement an MTDM interface and communicate with user devices via the MTDM interface to facilitate the construction of an MTDM workflow. An MTDM support manager configured to expose the MTDM workflow library to the aforementioned MTDM interface, An MTDM implementation manager configured to prepare at least one of a policy or a recipe in response to user interaction with the MTDM interface, A system that includes this.

45. The MTDM workflow library includes at least one of the following: an escalation scheme object, a trigger logic object, or a notification logic object. The system according to claim 44.

46. The MTDM support manager is configured to insert objects from the MTDM workflow library into the MTDM workflow in response to a user selection action. The system according to claim 45.

47. The MTDM support manager is configured to store new objects in the MTDM workflow library in response to user object creation operations. The system according to claim 45.

48. The aforementioned MTDM workflow is: MTDM workflow cycle, Branching operation, Loop operation, Trigger scheme, Rollback scheme, or Escalation scheme, The system according to claim 44, comprising at least one of the following.

49. The MTDM implementation manager is further configured to provide the vehicle with at least one of the policy or the recipe in response to a user rollout operation. The system according to claim 44.

50. The MTDM implementation manager is further configured to provide the selected group of vehicles with at least one of the policy or the recipe in response to a user rollout operation. The system according to claim 44.

51. The MTDM implementation manager is further configured to provide the at least one of the policy or the recipe to the selected vehicle group using a rollout schedule, the rollout schedule includes at least one of the order or timing of providing the at least one of the policy or the recipe to the individual vehicles of the selected vehicle group. The system according to claim 50.

52. The MTDM implementation manager is further configured to customize the policy or at least one of the recipes for the at least one individual vehicle in response to the characteristics of at least one individual vehicle of the selected group of vehicles. The system according to claim 51.

53. The aforementioned characteristics include at least one of the endpoint name, endpoint location, endpoint configuration, or network configuration of the at least one individual vehicle. The system according to claim 52.

54. A system for executing MTDM workflows, A vehicle data platform configured to provide policies to vehicles that include MTDM workflow elements, A vehicle automation platform configured to provide the vehicle with a recipe that includes actions for automated vehicle response, A system comprising, wherein the vehicle data platform is further configured to receive collected data from the vehicle in response to the execution of at least one of the MTDM workflow elements or the automated vehicle response by the vehicle's controller.

55. The MTDM workflow elements and the recipe are, Monitoring operations and maintenance operations, Monitoring operation, test operation, and maintenance operation, or, Monitoring operations, diagnostic operations, and maintenance operations. The system according to claim 54, which together embodies at least a portion of an MTDM workflow that includes at least one of the above.

56. The MTDM workflow elements and the recipe are, Monitoring operations, maintenance operations, and further monitoring operations, Monitoring operation and test operation and further monitoring operation and further test operation, Monitoring operation, diagnostic operation, further monitoring operation, and test operation, or, Monitoring operations and diagnostic operations and further monitoring operations and further diagnostic operations, The system according to claim 54, which together embodies at least a portion of an MTDM workflow that includes at least one of the above.

57. The vehicle automation platform is further configured to provide a map to the vehicle, the map including a control model for at least one embodiment of the vehicle. The system according to claim 54.

58. The at least one embodiment is, The motor of the aforementioned vehicle, Components of the aforementioned vehicle, The powertrain of the aforementioned vehicle, The endpoint of the aforementioned vehicle, The flow of the aforementioned vehicle, or Applications of the aforementioned vehicle, The system according to claim 57, comprising at least one of the following.

59. The vehicle automation platform is further configured to provide a map to the vehicle, and the map is, Tuning parameters of the vehicle's control algorithm, Selection of a control method for the vehicle's control algorithm, or Model parameters for at least one of the following: a virtual sensor of the vehicle, a feedforward component of the vehicle's control algorithm, or a response model of the vehicle's behavior. The system according to claim 54, comprising at least one of the following.

60. The vehicle automation platform further comprises a model of the vehicle configuration, and is further configured to provide the vehicle with at least one of the recipe or performance map in response to the model of the vehicle configuration. The system according to claim 54.

61. The vehicle automation platform further comprises a cloud model of the vehicle configuration, and is further configured to provide the vehicle model of the vehicle configuration to the vehicle in response to the cloud model of the vehicle configuration. The system according to claim 54.

62. The vehicle model includes a functional equivalent of the cloud model, The system according to claim 61.

63. The aforementioned vehicle model includes a scaled-down version of the aforementioned cloud model, The system according to claim 61.

64. The aforementioned cloud model includes an artificial intelligence model implemented by a data analysis component. The system according to claim 61.

65. Interpreting policies, including automated escalation protocols for vehicle monitoring operations, Interpreting vehicle data in response to the aforementioned vehicle monitoring operation, The system detects a vehicle event in response to the vehicle data, and executes the automated escalation protocol in response to determining that the vehicle event is active. A method that includes this.

66. Executing the aforementioned automated escalation protocol includes performing automated vehicle data collection operations. The method according to claim 65.

67. Executing the aforementioned automated escalation protocol includes performing automated diagnostic operations. The method according to claim 65.

68. Executing the aforementioned automated escalation protocol includes performing automated test operations. The method according to claim 65.

69. Performing the aforementioned automated test operation includes performing passive tests. The method according to claim 68.

70. Performing the aforementioned passive test includes performing a post-test using the stored vehicle data. The method according to claim 69.

71. Performing the aforementioned automated test operation includes performing an active test. The method according to claim 68.

72. Executing the aforementioned automated escalation protocol includes performing automated maintenance operations. The method according to claim 65.

73. Executing the aforementioned automated escalation protocol includes providing notifications to selected users. The method according to claim 65.

74. Providing the aforementioned notification includes providing instructions for the detected vehicle event, The method according to claim 73.

75. Providing the aforementioned notification includes providing a value determined during at least one of the automated diagnostic operation or the automated test operation. The method according to claim 73.

76. Providing the aforementioned notification includes providing notification of the action to be taken to execute the automated escalation protocol. The method according to claim 73.

77. Providing the aforementioned notification includes providing the status of the execution of the aforementioned automated escalation protocol. The method according to claim 73.

78. Executing the aforementioned automated vehicle data collection operation includes collecting selected vehicle data related to the detected vehicle event, The method according to claim 66.

79. Collecting the selected vehicle data includes collecting confirmation data for the detected vehicle events. The method according to claim 78.

80. Collecting the selected vehicle data includes collecting data for vehicle conditions related to the detected vehicle events. The method according to claim 78.

81. This further includes performing the automated test operation in accordance with the permissions set forth in the aforementioned policy, The method according to claim 68.

82. This further includes performing the automated test operation in accordance with the vehicle operating conditions defined in the aforementioned policy, The method according to claim 81.

83. Performing the aforementioned automated test operation further includes providing notifications to selected users. The method according to claim 68.

84. The notification includes at least one of the detected vehicle event, the test parameters of the automated test operation, the test results of the automated test operation, or the status of the automated test operation. The method according to claim 83.

85. The notification includes at least one of the following: a notification that the automated test operation has been performed or is pending; a summary of the main results from the automated test operation; the next steps planned in accordance with the automated escalation protocol; or the progress of the automated escalation protocol. The method according to claim 83.

86. This further includes performing the automated diagnostic operation in accordance with the permissions set forth in the aforementioned policy, The method according to claim 67.

87. This further includes performing the automatic diagnostic operation in accordance with the vehicle operating conditions defined in the aforementioned policy, The method according to claim 67.

88. Performing the aforementioned automated diagnostic operation includes providing a notification to the selected user. The method according to claim 67.

89. The notification includes at least one of the detected vehicle event, the diagnostic parameters of the automatic diagnostic operation, the diagnostic result of the automatic diagnostic operation, or the status of the automatic diagnostic operation. The method according to claim 88.

90. The notification includes at least one of the following: a notification that the automated diagnostic operation has been performed or is pending; a summary of the main results from the automated diagnostic operation; the next steps planned in accordance with the automated escalation protocol; or the progress of the automated escalation protocol. The method according to claim 88.

91. Performing the aforementioned automatic maintenance operation includes performing a vehicle tuning operation. The method according to claim 72.

92. Performing the aforementioned automatic maintenance operation includes performing a vehicle calibration operation. The method according to claim 72.

93. Performing the aforementioned automatic maintenance operation includes performing a vehicle reconfiguration operation. The method according to claim 72.

94. Performing the aforementioned automated maintenance operation includes performing a feature activation operation. The method according to claim 72.

95. The automatic maintenance operation is further performed in response to a confidence value related to the detected vehicle event. The method according to claim 72.

96. The automatic maintenance operation is further performed in response to the influence value related to the detected vehicle event. The method according to claim 72.

97. The further includes performing the automatic maintenance operation in response to an influence value related to the automatic maintenance operation, The method according to claim 72.

98. The automatic maintenance operation is further performed in response to the status of the vehicle within the selected group of vehicles. The method according to claim 97.

99. The process further includes determining the problem range value for the detected vehicle event and performing the automatic maintenance operation in response to the problem range value. The method according to claim 97.

100. The process further includes determining a maintenance classification for the automated maintenance operation and performing the automated maintenance operation in response to the maintenance classification. The method according to claim 97.

101. The process further includes determining a vehicle response value to the automatic maintenance operation, and performing a rollback operation in response to the vehicle response value indicating that the detected vehicle event was not resolved by the automatic maintenance operation. The method according to claim 96.

102. Executing the automated escalation protocol further includes performing an alternative action in response to the vehicle response value indicating that the detected vehicle event was not resolved by the automated maintenance operation. The method according to claim 101.

103. Performing the aforementioned alternative action includes performing an alternative test action. The method according to claim 102.

104. Performing the aforementioned alternative action includes performing an alternative diagnostic action. The method according to claim 102.

105. Performing the aforementioned alternative action includes performing further monitoring actions, The method according to claim 102.

106. Performing the aforementioned alternative action includes performing further maintenance actions. The method according to claim 102.

107. Further includes adjusting the alternative action in response to the vehicle response value, The method according to claim 102.

108. The further includes selecting the alternative action from a group of potential actions in response to the vehicle response value, The method according to claim 102.

109. The MTDM performance results are determined in response to the aforementioned automated escalation protocol, To provide the aforementioned MTDM performance results to a second vehicle, The method according to claim 65, further comprising:

110. Interpreting the MTDM results from the second vehicle, Adjusting the automated escalation protocol in response to the MTDM performance results from the second vehicle, The method according to claim 65, further comprising:

111. Implementing the MTDM interface, To facilitate the construction of the MTDM workflow, communication with the user device is performed via the MTDM interface, To expose the MTDM workflow library to the aforementioned MTDM interface, In response to user interaction with the aforementioned MTDM interface, prepare at least one of a policy or a recipe. A method that includes this.

112. Further includes inserting an object from the MTDM workflow library into the MTDM workflow in response to a user selection action, The method according to claim 111.

113. This further includes storing a new object in the MTDM workflow library in response to a user object creation operation. The method according to claim 111.

114. Further comprising providing the vehicle with at least one of the policy or the recipe in response to a user rollout operation, The method according to claim 111.

115. Further comprising providing the selected group of vehicles with at least one of the policy or the recipe in response to a user rollout operation, The method according to claim 111.

116. The rollout schedule further includes providing the at least one of the policy or the recipe to the selected group of vehicles, wherein the rollout schedule includes at least one of the order or timing of providing the at least one of the policy or the recipe to the individual vehicles of the selected group of vehicles. The method according to claim 115.

117. Further comprising customizing the policy or the recipe for the at least one individual vehicle in response to the characteristics of the at least one individual vehicle of the selected group of vehicles, The method according to claim 116.

118. A method for executing an MTDM workflow, Provide the vehicle with a policy that includes at least one MTDM workflow element, To provide the vehicle with a recipe that includes actions for automated vehicle response, Receiving data from the vehicle in response to the execution of at least one of the MTDM workflow elements or the automated vehicle response by the vehicle's controller, A method that includes this.

119. The further includes providing a map to the vehicle, the map including a control model for at least one embodiment of the vehicle. The method according to claim 118.

120. The further includes providing a map to the vehicle, the map being, Tuning parameters of the vehicle's control algorithm, Selection of a control method for the vehicle's control algorithm, or Model parameters for at least one of the following: a virtual sensor of the vehicle, a feedforward component of the vehicle's control algorithm, or a response model of the vehicle's behavior. The method according to claim 118, comprising at least one of the following.

121. The further includes providing the vehicle with at least one of the recipes or performance maps in response to a model of the vehicle's configuration. The method according to claim 118.

122. The further includes providing a vehicle model of the vehicle configuration in response to a cloud model of the vehicle configuration. The method according to claim 118.

123. The vehicle model includes a functional equivalent of the cloud model, The method according to claim 122.

124. The aforementioned vehicle model includes a scaled-down version of the aforementioned cloud model, The method according to claim 122.

125. The aforementioned cloud model includes an artificial intelligence model implemented by a data analysis component. The method according to claim 122.

Images