Patent Application
20230251648
The present disclosure relates generally to motor vehicles. More specifically, aspects of this disclosure relate to intelligent control systems provisioning flexible asset notification and management for in-vehicle electronic devices of motor vehicles.
Current production motor vehicles, such as the modern-day automobile, may be equipped with a resident network of electronic control units, connection buses, and communications devices that enable the vehicle to interface with permanent and portable electronic devices (collectively “assets”). Examples of such assets include, but are not limited to, personal assets (e.g., laptop computers, smartphones, tablet computers, smart watches, etc.) and vehicle assets (e.g., navigation units, audio components, flatscreen monitors, etc.). Some in-vehicle assets may be securely mounted to a motor vehicle in order to prevent unauthorized removal of the asset from the vehicle (e.g., when parked). Power lock and security systems may also be employed to prevent unsanctioned ingress to the vehicle and unauthorized removal of in-vehicle assets. Modern center-stack telematics units allow occupants to pair assets with the vehicle and, if desired, register device-specific information of a paired asset with the vehicle for asset monitoring and control.
Presented herein are intelligent vehicle systems with attendant control logic for flexible notification and management of in-vehicle assets, methods for manufacturing and methods for operating such systems, and motor vehicles equipped with such systems. By way of example, there are disclosed flexible asset notification management systems for actively inventorying and monitoring in-vehicle assets. For instance, a wireless interface allows a vehicle occupant to selectively pair an asset, establish a device profile for the asset, and stipulate a set of conditional requirements for managing the asset, such as temperature limits, theft prevention controls, vehicle lock settings, notification triggers, etc. When an asset approaches or enters a vehicle, for example, a short-range communication device of the asset automatically connects to a wireless interface device within the vehicle cabin. The vehicle responsively retrieves device-specific data and settings for the paired asset; if none is available, the asset user is prompted to enter such device information. The vehicle actively monitors the asset so long as the short-range device remains in proximity to and connected with the vehicle's wireless interface. If one of the predefined conditional criteria is met during asset monitoring, the vehicle automatically notifies the user (e.g., telematics unit or digital instrument cluster displays a user prompt) and takes protective action (e.g., locks the vehicle, changes the cabin temperature, contacts a remote vehicle service, etc.).
Aspects of this disclosure are directed to intelligent control systems, system control logic, and closed-loop feedback control techniques for flexible notification and management of in-vehicle assets. In an example, a method is presented for operating a motor vehicle, including hybrid-electric vehicles (HEV), full-electric vehicles (FEV), and internal combustion engine (ICE) variants. This representative method includes, in any order and in any combination with any of the above and below disclosed options and features: detecting, e.g., via a resident or remote vehicle controller in cooperation with a resident communications interface (RCI) device inside the vehicle, an electronic asset within a compartment of the motor vehicle; retrieving, e.g., via the controller from a resident or remote memory device responsive to detecting the asset, device data specific to the detected asset, the device data containing device-specific identification information and conditional criteria designed to protect the asset while inside the vehicle compartment; detecting, e.g., via the controller in cooperation with a powertrain control module (PCM), a vehicle starter system, or a gear shift device (PRNDL), the motor vehicle is stopped; determining, e.g., via the vehicle controller responsive to detecting that the vehicle is stopped, if one or more conditional criteria in the set of conditional criteria has been met; and transmitting, e.g., via the vehicle controller to one or more resident vehicle subsystems of the motor vehicle, one or more command signals to execute one or more automated control operations responsive to determining a conditional criterion has been met.
Additional aspects of this disclosure are directed to intelligent motor vehicles equipped with flexible asset notification and management systems. As used herein, the terms “vehicle” and “motor vehicle” may be used interchangeably and synonymously to include any relevant vehicle platform, such as passenger vehicles (ICE, REV, FEV, fuel cell, fully and partially autonomous, etc.), commercial vehicles, industrial vehicles, tracked vehicles, off-road and all-terrain vehicles (ATV), motorcycles, farm equipment, watercraft, aircraft, etc. In an example, a motor vehicle includes a vehicle body with a passenger compartment, multiple drive wheels rotatably mounted to the vehicle body (e.g., via corner modules coupled to a unibody or body-on-frame chassis), and other standard original equipment. A prime mover, such as an electric traction motor (e.g., for HEV and FEV powertrains) and/or an internal combustion engine assembly (e.g., for HEV or ICE powertrains), selectively drives one or more of the road wheels to propel the vehicle. The vehicle is also equipped with a resident communications interface device, such as a BLUETOOTH®, RFID, or dedicated short-range communications (DSRC) transceiver, that is mounted to the vehicle body and operable to communicate with electronic assets.
Continuing with the discussion of the preceding example, the vehicle employs a vehicle controller, such as a microprocessor, control module, control unit, or network of processors/controllers/modules, for detecting and monitoring in-vehicle assets. The controller is programmed to use the RCI device to detect an electronic asset entering or located within one of the vehicle's compartments. Upon detecting the electronic asset, the controller accesses a memory device to retrieve device data that is specific to the detected asset. This device data contains a set of conditional criteria that is designed to protect the asset while in the vehicle compartment. The controller then detects when the motor vehicle is stopping/stopped; upon detecting that the vehicle is stopped, the controller responsively determines if any one or more of the criteria in the set of conditional criteria has been met. If so, the controller automatically commands one or more vehicle subsystems resident to the motor vehicle to execute at least one automated control operation to protect the asset.
Aspects of this disclosure are also directed to computer-readable media (CRM) for sensing and governing in-vehicle assets. In an example, non-transitory CRM stores instructions executable by one or more processors of a vehicle controller, such as an electronic control unit (ECU) of a center-stack telematics unit. These instructions, when executed by the processor(s), cause the vehicle controller to perform operations, including: detecting an electronic asset within a vehicle compartment using an RCI device; retrieving, from a memory device responsive to detecting the electronic asset, device data specific to the electronic asset, the device data including a set of conditional criteria predetermined to protect the asset while in the vehicle compartment; detecting the motor vehicle is stopped; determining, responsive to detecting the motor vehicle is stopped, if a conditional criterion in the set of conditional criteria has been met; and transmitting, to a resident vehicle subsystem of the motor vehicle, a command signal to execute an automated control operation responsive to determining the conditional criterion has been met.
For any of the disclosed vehicles, systems, and methods, the electronic asset is equipped with a short-range communications (SRC) device. In this instance, detecting an asset within a vehicle compartment may include the vehicle's RCI device wirelessly pairing with the asset's SRC device. As yet a further option, asset-specific device data may be retrieved by: determining device data for a detected asset does not currently exist in the memory device; prompting a user of the motor vehicle to enter the device data; and storing the entered device data, associated with a unique identifier of the electronic asset, in the memory device. Furthermore, the conditional criteria may include one or more notification criteria, such as a notification type setting (e.g., text, call, push, telematics prompt, etc.) and/or a notification transmission time setting (e.g., immediate notification, X-minute delay, snooze period, etc.). In the same vein, the conditional criteria may include one or more temperature criteria, such as a temperature threshold setting (e.g., maximum and/or minimum cabin temperature) and/or a temperature notification setting (e.g., immediate notification, X-minute delay, snooze period, etc.). The conditional criteria may also include one or more lock system criteria, such as a lock status setting (e.g., vehicle unattended, unlocked and stopped) and/or a lock notification setting (e.g., immediate notification, X-minute delay, snooze period, etc.).
For any of the disclosed vehicles, systems, and methods, the resident vehicle subsystem may include an electronic display device that is mounted inside the vehicle's passenger compartment. In this instance, the command signal causes the display device to display a notification to vehicle occupants indicating that a conditional criterion of the asset has been met. After displaying the notification, the vehicle controller may receive a snooze input from a user (e.g., via a resident HMI) to snooze the notification. After receiving the snooze input, the controller responsively determines if a memory-stored or user-selected notification timer has expired; if so, the in-vehicle display device responsively displays another (second) notification that indicates the conditional criterion has been met. Any of the herein described notifications may be provisioned by a permanent in-vehicle device or sent directly to a user, e.g., via a laptop computer, smartphone, smart watch, etc.
For any of the disclosed vehicles, systems, and methods, the resident vehicle subsystem may include a power lock system that is operable to lock and thereby secure closed the passenger compartment. In this instance, the command signal causes the power lock system to enter a lock mode and, thus, lock the passenger compartment responsive to a conditional criterion being met. Before entering the lock mode, the vehicle controller may transmit a visual/audible prompt to a user of the motor vehicle to approve locking of the vehicle. After receiving the user's approval to lock the motor vehicle, the vehicle controller responsively commands to power lock system to enter the lock mode.
For any of the disclosed vehicles, systems, and methods, the resident vehicle subsystem may include a telecommunications and informatics (telematics) unit that is mounted inside the vehicle's passenger compartment. In this instance, the command signal causes the telematics unit to transmit an intervention service request to a third-party vehicle service (e.g., ONSTAR®) that is remote from the motor vehicle. For example, after detecting an asset within the vehicle compartment, the controller utilizes the RCI device to detect removal of the asset from the vehicle compartment. If the asset is removed while the vehicle is stopped and the compartment is locked, the controller may conclude that the removal was illicit and therefore command the telematics unit to transmit a service request to the remote vehicle service provider to intervene (e.g., contact the authorities, activate a vehicle alarm, contact the vehicle owner, etc.
For any of the disclosed vehicles, systems, and methods, the resident vehicle subsystem may include an in-vehicle heating, ventilation and air-conditioning (HVAC) system that is operable to regulate a cabin temperature of the passenger compartment. In this instance, the command signal activates the HVAC system to heat or cool the passenger compartment to a predefined cabin temperature that is retrieved from the conditional criteria specific to the detected asset. Prior to HVAC activation, the vehicle controller may transmit a visual/audible prompt to a user of the motor vehicle to approve activation of the HVAC system. Upon receiving user approval for HVAC activation, the controller commands the HVAC system to sufficiently heat/cool the passenger compartment, e.g., to raise/lower the cabin temperature to within a user-defined operating temperature range. Optional conditional criteria may include a designation as perishable, a designation as valuable, a device charge status, a designation to not leave during day/night, etc.
The above Summary is not intended to represent every embodiment or every aspect of the present disclosure. Rather, the foregoing summary merely provides an exemplification of some of the novel concepts and features set forth herein. The above features and advantages, and other features and attendant advantages of this disclosure, will be readily apparent from the following detailed description of illustrated examples and representative modes for carrying out the present disclosure when taken in connection with the accompanying drawings and the appended claims. Moreover, this disclosure expressly includes any and all combinations and subcombinations of the elements and features presented above and below.
The present disclosure is amenable to various modifications and alternative forms, and some representative embodiments are shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the novel aspects of this disclosure are not limited to the particular forms illustrated in the above-enumerated drawings. Rather, the disclosure is to cover all modifications, equivalents, combinations, subcombinations, permutations, groupings, and alternatives falling within the scope of this disclosure as encompassed, for example, by the appended claims.
This disclosure is susceptible of embodiment in many different forms. Representative embodiments of the disclosure are shown in the drawings and will herein be described in detail with the understanding that these embodiments are provided as an exemplification of the disclosed principles, not limitations of the broad aspects of the disclosure. To that extent, elements and limitations that are described, for example, in the Abstract, Introduction, Summary, Description of the Drawings, and Detailed Description sections, but not explicitly set forth in the claims, should not be incorporated into the claims, singly or collectively, by implication, inference or otherwise.
For purposes of the present detailed description, unless specifically disclaimed: the singular includes the plural and vice versa; the words “and” and “or” shall be both conjunctive and disjunctive; the words “any” and “all” shall both mean “any and all”; and the words “including,” “containing,” “comprising,” “having,” and the like, shall each mean “including without limitation.” Moreover, words of approximation, such as “about,” “almost,” “substantially,” “generally,” “approximately,” and the like, may each be used herein in the sense of “at, near, or nearly at,” or “within 0-5% of,” or “within acceptable manufacturing tolerances,” or any logical combination thereof, for example. Lastly, directional adjectives and adverbs, such as fore, aft, inboard, outboard, starboard, port, vertical, horizontal, upward, downward, front, back, left, right, etc., may be with respect to a motor vehicle, such as a forward driving direction of a motor vehicle when the vehicle is operatively oriented on a horizontal driving surface.
Referring now to the drawings, wherein like reference numbers refer to like features throughout the several views, there is shown in
The representative vehicle 10 of
Communicatively coupled to the telematics unit 14 is a network connection interface 34, suitable examples of which include twisted pair/fiber optic Ethernet switches, parallel/serial communications buses, local area network (LAN) interfaces, controller area network (CAN) interfaces, and the like. Other appropriate communication interfaces may include those that conform with ISO, SAE, and/or IEEE standards and specifications. The network connection interface 34 enables the vehicle hardware 16 to send and receive signals with one another and with various systems and subsystems both onboard the vehicle body 12 and off-board the vehicle body 12. This allows the vehicle 10 to perform assorted vehicle functions, such as modulating powertrain output, governing operation of the vehicle's transmission, activating the friction and regenerative brake systems, controlling vehicle steering, regulating charge and discharge of the vehicle's battery pack(s), and other automated functions. For instance, telematics unit 14 receives and transmits signals and data to/from a Powertrain Control Module (PCM) 52, an Advanced Driver Assistance System (ADAS) module 54, an Electronic Battery Control Module (EBCM) 56, a Steering Control Module (SCM) 58, a Brake System Control Module (BSCM) 60, and assorted other vehicle ECUs, such as a transmission control module (TCM), engine control module (ECM), Sensor System Interface Module (SSIM), etc.
With continuing reference to
Long-range vehicle communication capabilities with remote, off-board devices may be provided via one or more or all of a cellular chipset/component, a navigation and location chipset/component (e.g., global positioning system (GPS) transceiver), or a wireless modem, all of which are collectively represented at 44. Close-range wireless connectivity may be provided via a short-range wireless communications device 46 (e.g., a BLUETOOTH® unit, RFID tag/reader, or near field communications (NFC) transceiver), a dedicated short-range communications (DSRC) component 48, and/or a dual antenna 50. It should be understood that the vehicle 10 may be implemented without one or more of the above-listed components or, optionally, may include additional components and functionality as desired for a particular end use. The communications devices described above may provision data exchanges as part of a periodic broadcast in a vehicle-to-vehicle (V2V) communication system or a vehicle-to-everything (V2X) communication system, e.g., Vehicle-to-Infrastructure (V2I), Vehicle-to-Pedestrian (V2P), Vehicle-to-Device (V2D), etc.
CPU 36 receives sensor data from one or more sensing devices that use, for example, photo detection, radar, laser, ultrasonic, optical, infrared, or other suitable technology, including short range communications technologies (e.g., DSRC) or Ultra-Wide Band (UWB) radio technologies, e.g., for executing an automated vehicle operation or a vehicle navigation service. In accord with the illustrated example, the automobile 10 may be equipped with one or more digital cameras 62, one or more range sensors 64, one or more vehicle speed sensors 66, one or more vehicle dynamics sensors 68, and any requisite filtering, classification, fusion, and analysis hardware and software for processing raw sensor data. The type, placement, number, and interoperability of the distributed array of in-vehicle sensors may be adapted, singly or collectively, to a given vehicle platform for achieving a desired level of autonomous vehicle operation.
To propel the motor vehicle 10, an electrified powertrain is operable to generate and deliver tractive torque to one or more of the vehicle's drive wheels 26. The powertrain is generally represented in
The battery pack 70 may be configured such that module management, cell sensing, and module-to-module or module-to-host communication functionality is integrated directly into each battery module 72 and performed wirelessly via a wireless-enabled cell monitoring unit (CMU) 76. The CMU 76 may be a microcontroller-based, printed circuit board (PCB)-mounted sensor array. Each CMU 76 may have a GPS transceiver and RF capabilities and may be packaged on or in a battery module housing. The battery module cells 74, CMU 76, housing, coolant lines, busbars, etc., collectively define the cell module assembly.
With continuing reference to
With reference next to the flow chart of
Methods 100 and 200 begin at START terminal block 101 of
After protocol initialization, method 100 of
Upon detection of an SRC device of an asset (block 103=YES), method 100 advances to RECOGNITION decision block 105 to determine if the asset is recognized by the host vehicle. For instance, a previously paired asset may have “bonded” with the host vehicle such that the two devices have already shared with each other their addresses, names, and profiles; this data is stored in memory for future retrieval and use. Any such bonded devices may automatically establish a connection whenever they are within sufficient proximity for short-range data exchanges.
If the vehicle recognizes the detected asset, e.g., as a prior-paired and bonded device (block 105=YES), the host vehicle may retrieve the asset's memory-stored profile. At the same time, the method 100 may execute SETTINGS CHANGE decision block 107 to determine whether the previously stored device-specific information should be maintained or replaced, in whole or in part. To effect this feature, the telematics unit 14 may display a prompt to a vehicle occupant with a request to select whether or not—YES or NO—they would like to replace any of the available device information contained in the asset's profile. If not (block 107=NO), method 100 may optionally execute RECORDED ASSET data output block 129 and display or otherwise notify the user of their selection(s) and related asset data.
When the vehicle does not recognize the detected asset (block 105=NO) or the user wishes to change a stored device setting of a recognized asset (block 107=YES), method 100 executes NAME decision block 109 to determine if a new name should be added for the asset. For instance, telematics unit 14 may display a prompt to a vehicle occupant with a request to select whether or not—YES or NO—they would like to enter a device name for the detected asset. If so (block 109=YES), the user enters a desired device name via an available HMI input device and the vehicle stores the new device name in its respective profile for the paired device at NAME STORAGE data block 111.
If a new device name is saved (block 111) or one is not desired (block 109=NO) for the detected asset, method 100 advances to CONDITIONAL SETTINGS decision block 113 to determine if a new conditional criterion should be added or an existing conditional criterion should be changed for the asset. In accord with disclosed concepts, the memory-stored asset profile contains device-related data and device-specific data for the detected asset. That is, in addition to standard device-related information (e.g., make, model, series, type, operating system, etc.), there is information within the asset profile that is unique to the detected asset being monitored. As noted above, device-specific data may include an assigned device name, MAC address, UDID code, serial number, etc. This device-specific data also contains a set of conditional criteria that is designed to protect the asset while inside the vehicle, as will be explained in extensive detail hereinbelow. Upon determining that no new conditional criteria will added and/or no existing conditional criteria will be changed (block 113=NO), method 100 executes data output block 129.
When a user wishes to add a new conditional criterion or modify an existing conditional criterion (block 113=YES), the user is prompted to enter the new/updated criteria setting(s).
After a user changes the temperature criteria for the detected in-vehicle asset (block 115=YES), or as part of an independent inquiry, the user may be prompted to add/modify/select a temperature notification setting at TEMP NOTIFICATION decision block 117. If not (block 117=NO), method 100 may transition from decision block 117 to decision block 121. User-selectable notification criteria may include a variety of different settings, such as a notification type (e.g., text, call, push, telematics prompt, haptic prompt, audible prompt, etc.) or a transmission time for the notification (e.g., immediate notification, X-minute delay, snooze period, etc.). If the user decides to add a max/min temp criterion or a notification timing criterion (block 115=YES &/OR block 117=YES), method 100 executes a TEMP SETTINGS data storage block 119 and stores the user-selected in the paired device's profile. It should be appreciated that greater, fewer, or alternative conditional criteria settings may be added by a driver, an occupant, or any other authorized party. Some examples of discretionary operational criteria may include a designation of an asset as perishable (e.g., groceries), a designation of an asset as valuable (e.g., wallet or laptop), a device charge status setting (e.g., minimum charge to trigger notification), a designation to not leave during day/night (e.g., a child or pet), etc.
Prior to, contemporaneous with, or after changing an asset's temperature settings at blocks 115, 117 and 119, method 100 may execute UNATTENDED VEHICLE decision block 121 to ascertain whether or not the user would like to add/modify/select vehicle dynamics criteria and/or a key-on/key-off criteria for the detected in-vehicle asset. If not (block 121=NO), method 100 may proceed directly to block 129. On the contrary, the user may choose to modify a vehicle dynamics/key-on/key-off criteria (block 121=YES); at that time, the user may select or modify threshold criteria that will trigger a warning that the vehicle is unattended and the asset may be at risk of theft or damage. For instance, the user may choose to trigger an automated vehicle notification/response upon determining that the vehicle is stopped and keyed off while the asset is in the passenger cabin. As yet a further option, the user may choose to trigger an automated vehicle notification/response upon determining that the vehicle is stopped and keyed-on while the asset is unexpectedly no longer in the passenger cabin.
After a user changes the unattended vehicle criteria for the detected in-vehicle asset (block 121=YES), or as part of an independent inquiry, the user may be prompted to add/modify/select a lock system setting at LOCK NOTIFICATION decision block 123 or an unattended notification setting at UNATTENDED NOTIFICATION decision block 125. If the user chooses to not change either settings (block 123=NO &/OR block 125=NO), method 100 may transition to data block 127 or data output block 129. These notification settings may take on any of the various options for notification settings described herein, such as choosing to send an immediate notification, send a notification after an X-minute delay, set a snooze period after which a supplemental reminder will be sent. At LOCK NOTIFICATION decision block 123, the user may select to send a notification if the vehicle doors are locked (or unlocked) while the asset is in (or illicitly removed from) the host vehicle. Upon completion of some or all of the operations illustrated in
With reference next to
Upon determining that a conditional criterion has been met (block 203=YES), an automated electronic notification may be transmitted to a user at NOTIFICATION data output block 205 as part of, or in lieu of, an autonomous vehicle response. The notification may take on a variety of forms, including an audible notice (e.g., via speakers 30), a visual notice (e.g., via display 18), a push, text, call, or email (e.g., sent to a user's personal computing device), or any other suitable form of reporting. After sending the user a notification, method 200 determines if the user has chosen to delay an automated vehicle response at SNOOZE decision bock 207. If a user-selected request to delay vehicle response has been received (block 207=YES), method 200 retrieves a memory-stored time delay at SNOOZE TIME data input block 209. This time delay may be a user-defined or a system-default number of minutes between user-selected snoozing and a follow-up reminder. At SNOOZE LAPSE decision block 211, method 200 determines if the predefined snooze time has expired. If the snooze time has not yet expired (block 211=NO), method 200 may run in a continuous loop until the snooze timer expires. Upon expiration of the snooze time (block 211=YES), method 200 may transmit another notification to the user or, alternatively, may proceed to block 207 or directly to block 209.
If the user chooses to not snooze the notification (block 207=NO) or after expiration of the snooze timer (block 211=YES), one or more controller-governed responses may be automatically carried out in direct response to an in-vehicle asset criterion being met. By way of example, and not limitation, REMOTE SERVICES decision block 213 determines if an exigent situation exists that may warrant involvement by a remotely located third-party vehicle service (e.g., cloud computing host service 24 of
Upon determining that an exigent situation does not exist (block 213=NO), method 200 will assess at UNLOCKED ASSET decision block 217 if the met conditional criteria (block 203) indicate that the detected asset, which is designated as an asset that should not be left in an unlocked vehicle, has in fact been left in an unlocked vehicle. If not (block 217=NO), method 200 advances to decision block 225. Responsive to a determination that the asset has been left in an unlocked vehicle (block 217=YES), e.g., while the vehicle is stationary and unattended, method 200 may optionally transmit a notification to the user with an offer to lock the vehicle, as indicated at LOCK NOTIFICATION data output block 219. LOCK APPROVAL decision block 221 thereafter determines if the user has accepted locking of the vehicle. If approval to lock is not received from the user (block 221=NO), method 200 advances to decision block 225 without locking the vehicle. On the contrary, when the user inputs approval to lock the compartment that contains the asset or, if desired, to lock the entire vehicle (block 221=YES), a designated vehicle controller commands the vehicle's power lock system to lock the compartment/vehicle, as indicated at VEHICLE LOCK data output block 223.
After locking the vehicle at block 223, or as part of an independent inquiry, method 200 executes TEMP SENSITIVE decision block 225 to determine whether or not the met conditional criteria (block 203) indicate that the detected asset is a temperature-sensitive device that has been left in a potentially detrimental environment. If not (block 225=NO), method 200 may proceed to TERMINATION decision block 233 to determine if the notification has ended or, alternatively, may proceed directly to END terminal block 235. If the notification has not ended (block 233=NO), method 200 may loop back to block 207; if it has (block 233=YES), method 200 may advance to terminal block 235 and end.
Returning to the discussion of TEMP SENSITIVE decision block 225, the memory-stored predefined conditional criteria for a subject asset may fix a desired operating temperature range, e.g., of between about 0° C. and about 35° C. (˜32-95° F.); however, the detected asset may be stowed inside a trunk compartment with a measured temperature of 42° C. Upon determining that a detected asset is temperature-sensitive and is located within a vehicle compartment with a measured (real-time) temperature that is outside the asset's desired temperature range (block 225=YES), method 200 may optionally transmit a notification to the user with an offer to heat/cool the vehicle, as indicated at HVAC NOTIFICATION data output block 227. HVAC APPROVAL decision block 229 thereafter determines if the user has accepted heating/cooling of the vehicle. If HVAC approval is not received from the user (block 229=NO), method 200 advances to decision block 233 without heating/cooling the vehicle. On the contrary, when the user inputs approval for active thermal management of the vehicle compartment that contains the asset or, if desired, the entire vehicle (block 229=YES), a designated vehicle controller commands the vehicle's HVAC system to selectively modify the compartment/vehicle temperature, as indicated at HVAC ACTIVATION data output block 231.
Aspects of this disclosure may be implemented, in some embodiments, through a computer-executable program of instructions, such as program modules, generally referred to as software applications or application programs executed by any of a controller or the controller variations described herein. Software may include, in non-limiting examples, routines, programs, objects, components, and data structures that perform particular tasks or implement particular data types. The software may form an interface to allow a computer to react according to a source of input. The software may also cooperate with other code segments to initiate a variety of tasks in response to data received in conjunction with the source of the received data. The software may be stored on any of a variety of memory media, such as CD-ROM, magnetic disk, and semiconductor memory (e.g., various types of RAM or ROM).
Moreover, aspects of the present disclosure may be practiced with a variety of computer-system and computer-network configurations, including multiprocessor systems, microprocessor-based or programmable-consumer electronics, minicomputers, mainframe computers, and the like. In addition, aspects of the present disclosure may be practiced in distributed-computing environments where tasks are performed by resident and remote-processing devices that are linked through a communications network. In a distributed-computing environment, program modules may be located in both local and remote computer-storage media including memory storage devices. Aspects of the present disclosure may therefore be implemented in connection with various hardware, software, or a combination thereof, in a computer system or other processing system.
Any of the methods described herein may include machine readable instructions for execution by: (a) a processor, (b) a controller, and/or (c) any other suitable processing device. Any algorithm, software, control logic, protocol or method disclosed herein may be embodied as software stored on a tangible medium such as, for example, a flash memory, a solid-state drive (SSD) memory, a hard-disk drive (HDD) memory, a CD-ROM, a digital versatile disk (DVD), or other memory devices. The entire algorithm, control logic, protocol, or method, and/or parts thereof, may alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in an available manner (e.g., implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.). Further, although specific algorithms may be described with reference to flowcharts and/or workflow diagrams depicted herein, many other methods for implementing the example machine-readable instructions may alternatively be used.
Aspects of the present disclosure have been described in detail with reference to the illustrated embodiments; those skilled in the art will recognize, however, that many modifications may be made thereto without departing from the scope of the present disclosure. The present disclosure is not limited to the precise construction and compositions disclosed herein; any and all modifications, changes, and variations apparent from the foregoing descriptions are within the scope of the disclosure as defined by the appended claims. Moreover, the present concepts expressly include any and all combinations and subcombinations of the preceding elements and features.
