Patent ID: 12237971

DETAILED DESCRIPTION OF THE DRAWINGS

I. Foreword

For the purposes of promoting an understanding of the principles of the present disclosure, reference is made below to the embodiments illustrated in the drawings, which are described below. The embodiments disclosed below are not intended to be exhaustive or to limit the present disclosure to the precise form disclosed in the following detailed description. Rather, the embodiments are chosen and described so that others skilled in the art may utilize their teachings. Therefore, no limitation of the scope of the present disclosure is thereby intended.

In some instances throughout this disclosure and in the claims, numeric modifiers such as first, second, third, and fourth are used in reference to various components, data such as various identifiers, and/or other elements. Such use is not intended to denote or dictate a specific or required order of the elements. Rather, this numeric terminology is used to assist the reader in identifying the element that is being referenced and in distinguishing that element from other elements, and should not be narrowly interpreted as insisting upon a specific order of elements.

Moreover, before proceeding with the detailed description, it is noted that the entities, arrangements, and the like that are depicted in—and described in connection with—the various drawings are presented by way of example and not by way of limitation. As such, any and all statements or other indications as to what a particular drawing “depicts,” what a particular element or entity in a particular drawing “is” or “has,” and any and all similar statements—that could in isolation and out of context be read as absolute and therefore limiting—can only properly be read as being constructively (unless actually) preceded by a clause such as “In at least one embodiment, . . . .” And it is for reasons akin to brevity and clarity of presentation that this implied leading clause is not repeated ad nauseum in this detailed description.

Furthermore, in the present disclosure, it may be the case that various elements of one or more of the described embodiments are referred to as “modules” that carry out (i.e., perform, execute, and the like) various functions described herein. If and when the term “module” is used herein, each described module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices, and/or one or more of any other type or types of devices and/or components deemed suitable by those of skill in the relevant art in a given context and/or for a given implementation.

Each described module also includes instructions executable by said hardware for carrying out the one or more functions described herein as being carried out by the particular module, where those instructions could take the form of hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and/or the like, stored in any non-transitory computer-readable medium (CRM) deemed suitable by those of skill in the relevant art in a given context and/or for a given implementation. A non-transitory CRM, or memory, may include random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (e.g., EPROM, EEPROM, or Flash memory), or any other tangible medium capable of storing information. Moreover, it is explicitly contemplated that a module could be centralized in a single component or be distributed across multiple components as deemed suitable by those of skill in the relevant art.

II. Overview

An example scenario is described here in accordance with the present systems and methods. This example scenario is meant by way of example and illustration and not at all by way of limitation. In the example scenario, a shipping company maintains a fleet that includes thousands of trucks, each of which have installed thereon an onboard system that includes a TCM. In this example scenario, that TCM is manufactured, maintained, and supported by a technology company that is separate and distinct from the shipping company. From time to time, the shipping company may request certain changes to the functionality of the TCM, where such changes necessitate updating the TCM with respect to its firmware, its software, and/or one or more of its configuration settings. In such an instance, the technology company may “push” an OTAP update to every vehicle in the fleet or perhaps some defined subset thereof.

In the context of a given vehicle, the technology company may push this OTAP update by sending a notification message via a wireless data connection to a wireless-communication module with which the vehicle has been equipped. The vehicle's onboard system may responsively request a download of the entire update from the network-side infrastructure that is utilized by the technology company. In other cases, the technology company may simply push the entire update in whole or in pieces until it has been successfully downloaded by the vehicle (i.e., by one or more components of the onboard system of the vehicle).

Once that download is successfully completed, the onboard system may notify the driver in some way that an update is ready to be installed. In some embodiments, the onboard system notifies the driver unconditionally (e.g., while the driver is driving the vehicle 70 miles per hour (mph) along a U.S. Interstate). In other embodiments, the onboard system does not notify the driver of the ready-for-installation update until one or more preconditions are satisfied. One example of such precondition is that the ignition switch of the vehicle is in an ON position (as opposed to an OFF position or a CRANKED position, as is known in the art). Another example of such a precondition is that the prime mover (e.g., the internal-combustion engine) of the vehicle is in a NOT-RUNNING state (as opposed to a RUNNING state, as is known in the art). And certainly one or more additional preconditions (e.g., time of day, location, and/or the like) could be listed here in addition to or instead of those two examples.

Moreover, in some embodiments in which the vehicle notifies the driver unconditionally that an update is ready to be installed, the onboard system (e.g., the TCM) nevertheless insists on a set of one or more preconditions being satisfied before the onboard system will actually install the update, regardless of whether the driver attempts to make that installation begin. Such would naturally be a safety consideration among other reasons.

Whether or not satisfaction of one or more preconditions is required, the vehicle in certain embodiments will only initiate installation of the available update in response to receiving a confirmation input via the operator interface of the vehicle, perhaps in recognition of the desirability of not triggering a TCM-reprogramming event without a driver's consent. In some embodiments, this confirmation input can be received as a sequence of shift-selector-position inputs. In other embodiments, this confirmation input can be received as a user input on a touchscreen if such has been installed in the vehicle. Confirmation inputs could also be entered via a mobile device that is in communication with the vehicle via, as examples, a Universal Serial Bus (USB) connection, a Bluetooth connection, and/or the like. And certainly other examples of ways in which a confirmation input could be received via the operator interface of the vehicle could be listed here, as these are merely some representative examples.

Upon receiving the confirmation input, the vehicle (e.g., the onboard system (e.g., the TCM)) may then responsively install the available update and, once completed, present the operator (i.e., the driver) of the vehicle with a confirmation indication that the installation has been completed successfully. Of course upon encountering any problems, errors, interruptions, and/or the like, a suitable alert could be presented to the operator to convey that status. In the balance of this detailed description, examples of architecture and then operation are described with reference to the figures.

Among the advantages of the present systems and methods is that at least some embodiments enable operator approval and therefore triggering of OTA with existing transmission inputs. Another advantage is that at least some embodiments enable such OTA reprogramming to occur without reliance on what is known in the art as a head unit (including, e.g., an infotainment and/or stereo system), a heads-up display, and/or the like. That is, with respect to at least some embodiments, additional hardware is not required to implement the present systems and methods in the context of existing vehicles, providing savings of cost and time among other aspects. The present systems and methods may well prove particularly advantageous in the context of vehicle onboard systems that do not have what is known in the art as a wake-on controller area network (CAN) or a twin-memory architecture.

Additionally among the advantages of the present systems and methods is that embodiments are compatible with multiple product lines, simple to use, and suitable for both high-end and cost-effective vehicle installations. Moreover, another advantage is that, in a scenario like the example scenario described above, an OTAP update to a TCM would be installed if and only if approval was present from the shipping company, the technology company, and the driver. The shipping company may indicate their approval by requesting a feature change and/or sending an update to the technology company and requesting that it be pushed to the fleet. The technology company may indicate their approval by pushing the update, and the driver may indicate his or her approval by entering a confirmation input via the operator interface of the vehicle as described herein.

Also among the advantages of the present systems and methods are reducing visits to the service channel, eliminating a need for vehicle hardware to be physically connected (e.g., at a repair location) to receive updates, allowing for new features to be added and existing features to be enabled and/or configured, reducing the time needed to receive warranty improvements, and mitigation of potential cybersecurity vulnerabilities. And certainly there are other advantages of various embodiments of the present methods and systems that could be listed here.

III. Example Architecture

a. Example TCM

FIG.1is a simplified functional block diagram of an example TCM102that includes a communication interface104, a processor106, and a CRM108that itself contains firmware110, software112, and configuration settings114. It should be understood that the depicted architecture of the TCM102is presented by way of example, and that other architectures could be used as deemed suitable by those of skill in the relevant art. In addition to the functions disclosed herein, the TCM102generally functions as known in the relevant art to control, manage, diagnose, and/or monitor the operation of an associated transmission.

In at least one embodiment, the communication interface104includes a wired-communication interface for communicating with one or more other devices, components, and/or the like of a given vehicle according to a wired-communication protocol such as society of automotive engineers (SAE) J1939, USB, and/or any other wired-communication protocol deemed suitable by those of skill in the relevant art.

In at least one embodiment, instead of or more likely in addition to the wired-communication interface, the communication interface104further includes a wireless-communication interface that includes the corresponding hardware, firmware, and the like for communicating wirelessly with one or more other entities using one or more wireless-communication protocols such as Bluetooth, LTE, WiMAX, CDMA, and/or the like. In some embodiments, the communication interface104of the TCM102communicates in a wired fashion with one or more other entities that themselves then communicate wirelessly across an air interface with a network-side infrastructure, as is described more fully below in connection with at leastFIG.5.

The processor106may take the form of or include one or more processors of any suitable type, such as but not limited to microprocessors, microcontrollers, microchips, ASICs, FPGAs, and/or the like. In some installations, the processor106includes one processor that is deemed the central processing unit (CPU) of the TCM102and one or more additional processors respectively dedicated to one or more specific tasks, such as signal processing and/or the like. And certainly other example configurations of the processor106could be listed here.

The CRM108may take the form of or include one or more non-transitory CRMs of any type deemed suitable by those of skill in the relevant art, where a non-limiting list of examples includes any suitable non-transitory CRM such as, as examples, memory devices, RAMs, ROMs, EPROMs, EEPROMs, Flash memory, and/or any other non-transitory CRM capable of storing information. Moreover, the CRM108could be centralized in a single component or be distributed across multiple components as deemed suitable by those of skill in the relevant art. It is further noted that while all three of the firmware110, the software112, and the configuration settings114are depicted inFIG.1, one or more of these types of data may not be present in certain embodiments, and certain embodiments may further have one or more types of data stored in the CRM108other than those depicted inFIG.1. That being said, the balance of this written description by way of example treats all three depicted elements—i.e., the firmware110, the software112, and the configuration settings114—as being present in the described embodiments.

In at least one embodiment, the firmware110contains instructions executable by the processor106for interacting with various hardware elements and for providing an environment in which one or more applications can be executed, the software112contains the instructions that make up those one or more applications.

In at least one embodiment, the configuration settings114includes values that may be referred to herein and in the art as parameters, operating values, configuration settings, and the like. The term configuration settings in this disclosure is covers all such types of data.

b. Example Vehicle with Operator Interface

FIG.2is a simplified functional block diagram of an example vehicle202that includes an example operator interface228as well as the example TCM102. In the embodiment that is depicted inFIG.2, the vehicle202also includes a prime mover204having a prime-mover output shaft206and a speed sensor214; a transmission208having a transmission input shaft210and a transmission output shaft212; a data link220communicatively connecting the TCM102and the transmission208; an engine control module (ECM)218communicatively connected to the prime mover204via a data link222and communicatively connected to the TCM102via a data link224; a data link226communicatively connecting the TCM102and the operator interface228; and an onboard system216on which the TCM102illustratively resides. It is contemplated that the data links220,222,224, and226could all be the same physical data link (e.g., a system bus) or separate data links, and that their separate depiction is by way of example and to illustrate communicative connectivity among various elements, and is not meant in any way to limit this disclosure to a particular set of separate data links. Such is the case with all sets of data and any other communication links described herein. Furthermore, the operator interface228is depicted as including an ignition switch230, a shift selector232, an alert interface234, and a display236. It should be understood that the depicted architecture of the vehicle202is presented by way of example, and that other architectures could be used as deemed suitable by those of skill in the relevant art.

The vehicle202could be a truck, car, bus, van, or any other type of vehicle that would generally have the components—and function generally as—discussed herein.

The prime mover204could be an engine such as an internal-combustion engine, a rechargeable electric motor, or any other type of prime mover suitable to bring about translational motion of the vehicle202. In at least one embodiment, the prime mover204has at least two operating states: (i) a RUNNING state in which the prime mover204, if suitably engaged by a clutch or the like (if present) causes at least a threshold amount of rotational movement of the prime-mover output shaft206to bring about translational movement of the vehicle202and (ii) a NOT-RUNNING state, in which the prime mover204is producing less than that threshold amount of rotational movement (e.g. producing zero or effectively zero rotational movement) of the prime-mover output shaft206. Furthermore, the speed sensor214is configured to measure the rate of rotational movement of the prime-mover output shaft and to provide digital data representative of that measurement to a requesting entity such as the ECM218or the TCM102, among other possibilities. It is further noted that the speed sensor214could instead—or additional sensor(s) could—be arranged on the transmission input shaft210and/or the transmission output shaft212, among other possible sensor-deployment options.

The transmission208could be an automatic transmission, perhaps a multi-speed automatic transmission capable of establishing a plurality of forward speed ratios between the rotational speed of the transmission input shaft210and the transmission output shaft212. In general, then, the transmission208functions to transmit the rotational motion of the prime-mover output shaft206to the transmission output shaft212via mechanical communication involving at least the transmission input shaft210, which could be coupled with or physically integral with the prime-mover output shaft206. That aforementioned mechanical communication could also include components such as a torque converter, a flywheel, and/or the like, as is known to those of skill in the relevant art. The transmission output shaft212is then in turn coupled to one or more axles or the like that are in turn coupled to tires to bring about the aforementioned translational motion of the vehicle202.

Some examples of multi-speed automatic transmissions are automatic transmissions and automated manual transmissions. Some examples of automated manual transmissions are sliding mesh transmissions and constant mesh transmissions. The transmission208may continuously provide power from the transmission input shaft210to the transmission output shaft212during shifting, or it may instead be the case that power transfer from the transmission input shaft210to the transmission output shaft212is interrupted during shifting. And certainly other types of transmissions could be listed here.

The onboard system216on which the TCM102illustratively resides could take the form of or include a motherboard or other type of printed circuit board (PCB), a computing-and-communication device generally, and/or any other type of computing hardware, system, or the like of which the TCM102is a functional component. It is noted that, in at least one embodiment, the TCM102makes up the entirety of the onboard system216, while in at least one other embodiment, the TCM102is but one component of the onboard system216.

The ECM218is, as described above, communicatively connected with the TCM102via the data link224and is also communicatively connected with the prime mover204via the data link222. The ECM may also be communicatively connected to one or more additional components of the vehicle202, as these two instances are provided by way of example. In operation, the ECM218in at least one embodiment functions to control and manage the overall operation of the prime mover204. Prime mover204may include a speed-reducing device (not depicted) that reduces the speed of the prime mover204. Example speed-reducing devices include an engine brake and an exhaust brake, though one or more other speed-reducing devices could be used instead or in addition. The ECM218may be communicatively connected with the speed-reducing device to control the speed of the prime mover204.

The ECM218is, in at least one embodiment, also operative to exchange instructions and data with the TCM102in a conventional manner. In one embodiment, for example, the TCM102and the ECM218are operable to exchange information via the data link224in the form of one or more messages in accordance with the aforementioned J1939 communications protocol, although this disclosure contemplates other embodiments in which the TCM102and the ECM218are operable to exchange information via the data link224in accordance with one or more other conventional communication protocols.

The data links220-226may each be any suitable communication bus or other communicative data connection deemed suitable by those of skill in the art for a particular context or for a given implementation.

The operator interface228in at least one embodiment includes all of the input devices and output devices (and perhaps one or more combined input/output devices) that an operator of the vehicle202can use to input commands or other information and/or receive output indications, values, signals, alerts, and the like. This would include aspects of the vehicle such as the steering wheel, the accelerator and brake pedals, any dashboard lights, speakers, and/or the like. In at least one embodiment, and as depicted inFIG.2, the operator interface228includes the ignition switch230, the shift selector232, the alert interface234, and the display236, each of which is discussed more fully below.

The ignition switch230may take the form of any conventional ignition switch that may be arranged to receive a key or perhaps be a keyless ignition option such as a push button. In at least one embodiment, the ignition switch230has at least two positions. The first such position is an OFF position in which neither the electrical system (e.g., the TCM102) nor the prime mover204is in an operating state—in other words, the vehicle202is quiet and off. The second such position is an ON position in which at least the electrical system of the vehicle202is powered up and operating, and in which the prime mover204could be either in its RUNNING state or in its NOT-RUNNING state. In many embodiments, the ignition switch further has a third position: a CRANKED position which an operator would use to transition the prime mover204from its NOT-RUNNING state to its RUNNING state. Typically, upon physical release by the operator of the ignition switch230when in the CRANKED position, the ignition switch230would come to rest in the aforementioned ON position.

The shift selector232is as a general matter a component of the operator interface that is operable in its primary purpose to allow the operator of the vehicle202to put the transmission208in one of a number of possible states, such as a PARK state, a REVERSE state, a NEUTRAL state, and one or more DRIVE states. As is conventionally known in the art, the vehicle is (i) fixed by the transmission208in a non-moving condition when the transmission208is in the PARK state, (ii) operable for reverse motion in the REVERSE state (of which there could be more than one), (iii) not being impelled but free to roll when the transmission208is in the NEUTRAL state, and (iv) operable for forward motion according to a given forward-gear ratio when the transmission208is in the DRIVE state (or in one of the plurality of DRIVE states in embodiments in which there is more than one such state).

Turning toFIG.3, shown there is a depiction of a first example shift selector232A that can be used in connection with at least one embodiment. In the depicted embodiment, the shift selector232A includes a REVERSE button302, a NEUTRAL button304, a DRIVE button306, a MODE button308, an UP-ARROW button310, a DOWN-ARROW button312, and a display region314. It is contemplated that the shift selector232A could be arranged in a housing on a dashboard of the vehicle202and have actual physical buttons, but could instead be represented as a touchscreen display having soft buttons, among other options that could be listed here. The display region314may be arranged to provide visual feedback to the operator of the vehicle202of the status of one or both of the vehicle202and the TCM102. Examples of technology that could be implemented in connection with the display region314include an LED display, an LCD display, a plurality of indicator lights, and/or other suitable visual indicators. In one example, the display region314provides a visual indication of a vehicle direction of the vehicle202, a currently selected gear-shift position, and, if applicable, one or more fault codes. And certainly other values could be displayed as well or instead of the examples listed.

In at least one embodiment, the TCM102is responsive to operator selection of the REVERSE button302to configure the transmission208to operate in a reverse gear, responsive to operator selection of the NEUTRAL button304to configure the transmission208to operate in a neutral state wherein neither a forward or a reverse gear is engaged, responsive to operator selection of the DRIVE button306to configure the transmission208to operate in a forward gear. Furthermore, once operating in a forward gear, the TCM102may be responsive to the UP-ARROW button310and the DOWN-ARROW button312to change which forward gear the transmission208is operating in, presuming that prevailing conditions and associated logic do not prevent such a forward-gear shift. Moreover, the TCM102may be responsive to user selection of the MODE button308to configure the transmission208to select certain operating modes; for example, the transmission208may have a secondary output shaft that is used for a power take-off (“PTO”) operation, and the operator may activate the secondary output shaft using the MODE button308. The MODE button308may also be used for other operations, such as clearing fault codes, among numerous other examples that could be listed here. It is also noted that multiple reverse gears may be available in certain implementations, and that the TCM102may be responsive to the UP-ARROW button310and the DOWN-ARROW button312to change in which reverse gear the transmission208is operating. It is further noted that not all shift selectors have a digital display: some are simply labeled next to the shifter, some on the dashboard, some on another display, and other implementations are contemplated as well. Many other arrangements are possible as well, including shift selectors having any number (including more than 5) forward positions, any number of reverse positions, some not having a park position, and the like.

Turning toFIG.4, shown there is a depiction of a second example shift selector232B that can be used in connection with at least one embodiment. As shown, the shift selector232B includes a MODE button402, a display region404, and a shifter406. The MODE button may operate substantially as described above with respect to the MODE button308ofFIG.3, and the display region404may operate substantially as described above with respect to the display region314ofFIG.3. Moreover, as depicted, the shifter406can be positioned by an operator of the vehicle202in any one of the following positions:a PARK position421that is shown in association with a PARK indicator (P)411and that places the transmission208in the PARK state;a REVERSE position422that is shown in association with a REVERSE indicator (R)412and that places the transmission208in the REVERSE state;a NEUTRAL position423that is shown in association with a NEUTRAL indicator (N)413and that places the transmission208in the NEUTRAL state;a fifth DRIVE position424that is shown in association with a fifth DRIVE indicator (D5)414and that places the transmission208in a fifth DRIVE state;a fourth DRIVE position425that is shown in association with a fourth DRIVE indicator (D4)415and that places the transmission208in a fourth DRIVE state;a third DRIVE position426that is shown in association with a third DRIVE indicator (D3)416and that places the transmission208in a third DRIVE state;a second DRIVE position427that is shown in association with a second DRIVE indicator (D2)417and that places the transmission208in a second DRIVE state; anda first DRIVE position428that is shown in association with a first DRIVE indicator (D1)418and that places the transmission208in a first DRIVE state.

As will be understood by those of skill in the art, the first through fifth DRIVE states correspond respectively with five different forward-gear ratios. In general, then, the shifter406is manually actuatable to the plurality of different positions421-428. In at least one embodiment, the shifter406being placed in a given position among the plurality of different positions421-428corresponds to a different input signal that is provided from the operator interface228to the TCM102via the data link226.

Returning now toFIG.2and to the operator interface228in particular, the alert interface234may include any number of indicator lights, message screens, speakers, and/or one or more output-device types of any sort deemed suitable by those of skill in the art to convey any sort of alert information to an operator of the vehicle202. In at least one embodiment, the alert interface234includes a check-transmission light. Furthermore, the display236could be a one-way device (e.g., LCD) that only conveys information to the operator of the vehicle202, or could instead be a touchscreen display that is operable to both present information, prompts, confirmations, warnings, apps, and the like and to also accept touchscreen inputs, as is known generally in the art of touchscreen electronics.

IV. Example Operation

a. Example Communication Scenario

Turning now toFIG.5, depicted therein is an example communication scenario500that includes the vehicle202, and that also includes what is referred to herein as a network-side infrastructure502. As depicted, the vehicle202and the network-side infrastructure502communicate with one another via a wireless data link504, which in at least one embodiment is a secure (e.g., encrypted) wireless data link to avoid, minimize, or at least reduce risks associated with cybersecurity attacks. In various different embodiments, some or all of the messages sent across the wireless data link504are encrypted and/or signed. Thus, all of the following options are contemplated: neither the link nor the messages could be secure, just the link itself could be secure, each message could carry its own security, or both the link itself could be secured and the messages could carry their own security.

The network-side infrastructure502includes a wireless-communication module512that is communicatively connected with (i) the wireless data link504and (ii) via a data link520with an update-management module (UMM)522. The data link520could be wired and/or wireless, consistent with the above description of various other data links such as the data links220-226ofFIG.2. In some instances, the network-side infrastructure502may represent what those in the art and in society in general refer to as “the cloud,” i.e., a set of one or more computing devices that are located on a network and are accessible from multiple attachment points such as wireless data links and the like. In some cases, the communication between the network-side infrastructure502and the vehicle202over the wireless data link504is referred to as “telematics,” and an associated provider of such services is often known as a telematics service provider (TSP), and may be known by one or more other names as well.

Each of the wireless-communication module506and the wireless-communication module512include hardware (e.g., chipsets, antennas, and the like) as well as firmware, software, and/or other configuration data needed to communicate according to one or more wireless-communication protocols such as LTE, one or more of the other wireless-communication protocols mentioned herein, and/or one or more other wireless-communication protocols (e.g., 5G) deemed suitable by those of skill in the art for a given implementation. In some instances, the wireless-communication module512of the network-side infrastructure502may be equipped and configured to serve multiple, perhaps many, client devices such as the wireless-communication module506of the vehicle202.

In at least one embodiment, the UMM522is equipped, programmed, and configured to accept an update516and a push-approval input518, and also to push an OTAP update via the data link520, the wireless-communication module512, and the wireless data link504to the wireless-communication module506of the vehicle202. The update516could be received from within the same entity (e.g., a technology company) that also operates the network-side infrastructure502, or could instead be received from an external entity such as a shipping company that is a client or customer of the technology company. And certainly numerous other arrangements could be listed here as well. The push-approval input518is an input that authorizes the pushing of a given update from the UMM to the vehicle202. In instances in which the update516comes from an external organization, the presence of the push-approval input518in the process helps ensure that both the external organization (e.g., the aforementioned shipping company) and the organization that operates the network-side infrastructure502(e.g., the aforementioned technology company) provide authorization that a given update be pushed. That required pair of authorizations, along with the receipt by the TCM102of a valid confirmation (i.e., initiate-update) instruction via the operator interface228provides in at least some embodiments a triple-approval process before a given OTAP update is ultimately installed.

On the client side, it can be seen in the embodiment that is depicted inFIG.5that the vehicle202is shown as including the aforementioned wireless-communication module506, which is connected via a data link514to a download management module (DMM)508, which in turn is connected via a data link510to the TCM102. And as is also depicted inFIG.2, the TCM102and the operator interface228are shown as being in communicative contact via the data link226. As above, the data links510,514, and520could take any form deemed suitable by those of skill in the relevant art for a given implementation. It should be understood as well that the other components of the vehicle202that are depicted inFIG.2but not depicted inFIG.5(e.g., the ECM218) are still present in various embodiments and are simply not depicted inFIG.5for clarity of presentation of the aspects of the present disclosure on whichFIG.5is more focused.

In at least one embodiment, the DMM508is arranged to receive update-available indications from the UMM522via the above-described communication path, and to pass such alerts on to the TCM102. The DMM508may also be arranged to respond to such notifications from the network side by requesting that the UMM522transfer the entire actual update to the DMM508, which may only then notify the TCM102that an update is available. Such design choices are within the skill of those in the relevant art. In at least one embodiment, the DMM508takes the form of a hardware device that is configured to be mounted onboard a TSP device (which may be or at least include the wireless-communication interface506) of the vehicle202. In other embodiments, the DMM508takes the form of executable code residing in a device that may be intermediate between the wireless-communication interface506and the TCM102, or perhaps within the memory of the TCM102itself. And certainly other implementation options will occur to those of skill in the art and could be listed here. The DMM508may also be configured to relay messages (e.g., update-installation-success and update-installation-failure messages) from the TCM102to the UMM522.

b. First Example Method

FIG.6depicts a first example method600that may be carried out by a TCM such as the TCM102. The carrying out of the method600by a TCM is provided by way of example, in that the method600could be carried out by another device that is suitably equipped, programmed, and configured to carry out the associated functions.

At602, the TCM102determines whether an OTAP update is available. If not, then at604the TCM102returns on path606to step602. If so, then the TCM102proceeds at608to responsively present at610an update-ready indication via the operator interface228.

At step614, after presenting the update-ready indication at610, the TCM follows path612to614, where the TCM102determines whether a valid initiate-update instruction has been received via the operator interface228. If not, the TCM102returns at616on the path606to step602. But if so, the TCM102proceeds at618to620, where the TCM102determines whether each precondition in a set of one or more additional preconditions (i.e., in addition to the precondition evaluated at614) is satisfied. If not, the TCM102returns at622on path606to step602. But if so, the TCM102proceeds at624to step626, where the TCM102initiates installation of the particular OTAP update.

Thus, one way to look at steps614and620(and their associated conditional processing) collectively is that the TCM102is determining whether each precondition in a set of one or more preconditions is satisfied, where that set includes a first precondition that a valid initiate-update instruction has been received via the operator interface228. In other words, the set of one or more preconditions can be thought of as made up of that first precondition and the set of one or more additional preconditions (of which there might be none, one, or more than one, as described more fully below).

Turning now toFIG.7, depicted therein is an example submethod700that may be carried out in connection with a part of the method600. In particular, the submethod700pertains to reference numerals618,620,622, and624ofFIG.6. And as can be seen by inspection ofFIG.6, the bulk of the submethod700pertains to the decision box620ofFIG.6, at which the TCM, as described above, determines whether each precondition in a set of one or more additional preconditions (i.e., in addition to the precondition evaluated at614) is satisfied. The reader will recall that the precondition that is evaluated at614is whether a valid initiate-update instruction has been received via the operator interface228.

The submethod700begins at618, where the TCM102proceeds at702to evaluate at704whether a generically named “precondition2” is satisfied. This “precondition2” could just as well be labeled “additional precondition1” in the parlance of this disclosure. If precondition2is not satisfied, the TCM proceeds at706to return NO, corresponding to the similarly labeled arrow622ofFIG.6. If precondition2is satisfied, however, the TCM102proceeds at708to710, where the TCM102determines whether the ignition switch230is in its ON position.

If it is determined by the TCM102at710that the ignition switch230is not in its ON position, the TCM102proceeds at712to return NO at622as described above. But if it is determined by the TCM102at710that the ignition switch230is in its ON position, the TCM102proceeds at714to the decision box716, where the TCM determines whether the prime mover204is in its RUNNING state; if not, the TCM102proceeds at718to return NO at622; if so, the TCM102proceeds at720to decision box722.

At decision box722, the TCM102evaluates whether a generically named precondition N−1 is satisfied: if not, the TCM102proceeds at724to return NO at622; if so, the TCM102proceeds at726to decision box728. Similarly, at decision box728, the TCM102evaluates whether a generically named precondition N is satisfied: if not, the TCM102proceeds at730to return NO at622; if so, the TCM102proceeds at732to return YES to the method600at624, corresponding to the similarly labeled arrow624inFIG.6.

In some embodiments, N is zero, in which case the submethod700is unnecessary. In various other embodiments, the ignition-switch precondition, the prime-mover-state precondition, and/or one or more other preconditions deemed suitable by those of skill in the art for a given implementation could be used. Some possible examples include vehicle location, time of day, urgency of the update relative to a task (e.g., delivery) for which the vehicle202is currently in use, and/or the like. Another example of a precondition that could be enforced is that a calibration-configurable original-equipment-manufacturer (OEM) option as to whether OTAP updates are allowed is set in the affirmative. This may be particularly applicable in emergency and military-vehicle contexts, though such an option could be implemented in connection with any vehicle. Another example precondition that could be enforced is that a parking brake is set; the status of the parking brake could be monitored via CAN messaging as described herein. Moreover, it is explicitly contemplated that any one or more preconditions mentioned herein could be implemented in connection with any given embodiment.

Returning toFIG.6, the OTAP update could pertain to one, two, or all three of firmware, software, and configuration settings of the TCM102. Updating a subset of operating parameters could be referred to as “parameter trimming,” and could help eliminate a need to go to a service channel for minor updates, facilitate new feature enablement and configuration, shift-schedule modification, and the like. Such an operation may be referred to as a Level 1 operation in this context.

Performing a full-calibration update (i.e., all or substantially all configuration settings) may be referred to as a Level 2 operation in this context, and may help to facilitate changing what are known as vocational models, improving shift quality, improving any calibration issues generally, and perhaps providing some limited mitigation for any cybersecurity vulnerabilities.

Moreover, updating or even fully replacing the software and/or firmware of the TCM102in an update may be referred to as a Level 3 operation in this context. Such an operation could be helpful in facilitating functions such as installing new software features, improving existing software installations, perhaps more fully (as compared with the above-described Level 2 operation) mitigating any cybersecurity vulnerabilities, and improving alignment (i.e., compatibility and efficient operation) between hardware and software.

In this framework, it would generally be the case that higher-level operations (e.g., a Level 3 operation as compared with a Level 1 operation) would generally be associated with increased scope, increased value, increased risk, and increased cost. Such are considerations for those of skill in the relevant art.

In at least one embodiment, determining at602whether an OTAP update is available involves determining that the OTAP update has been received from a network-side entity such as the network-side infrastructure502via a wireless data connection such as the wireless data connection504. Such an operation may involve receiving an indication from the DMM508that it has received a downloaded update. And other possibilities exist as well.

The update-ready indication of610could involve one or more of a visible indication, an audible indication, and a tactile indication, perhaps presented via the alert interface234, perhaps by flashing the check-transmission light. Such would essentially be a one-way signal from the TCM102to an operator in a limited-interface environment.

Further to the discussion of embodiments involving limited operator-interface capabilities, the processing at614as to whether a valid initiate-update instruction has been received by the TCM102via the operator interface228could involve receiving a given sequence of shift-selector-position inputs; comparing the received sequence of shift-selector-position inputs to a prestored sequence of shift-selector-position inputs; determining that the first precondition is satisfied if the given sequence of shift-selector-position inputs matches the prestored sequence of shift-selector-position inputs; and determining that the first precondition is not satisfied if the given sequence of shift-selector-position inputs does not match the prestored sequence of shift-selector-position inputs.

Such shift-selector inputs could be enterable by positioning the shift selector232in a given position for less than a threshold amount of time and then proceeding to the next shift-selector input in the sequence. In an embodiment, a valid initiate-update instruction is made up of a sequence of inputs that a driver would be quite unlikely to randomly enter. One suggestion is the sequence N-D-N-D-N-R-N-R-N-D-N-D-N. And again, if the shift selector232is left in a given position for too long, the pattern would have to be restarted (i.e., it would be determined that a valid initiate-update instruction had not been received). But if the shift selector232is steadily moved between positions in the correct (i.e., matching) pattern, it is determined that a valid initiate-update instruction has been received. In an embodiment, the TCM102provides an indication to the operator (via either a display, by flashing the check-transmission light, and/or some other option) after an update has successfully completed installation. In some embodiments, the absence of that indicator indicates failure; in other embodiments, a separate, different indicator is used to indicate installation failure.

Moreover, in some embodiments, the TCM102permits the driver to modify what is considered a valid initiate-update instruction via suitable sequences of inputs. That is, the initiate-update instruction is customizable in some embodiments. In some cases, what is considered a valid initiate-update instruction is modifiable via the operator interface228. In some cases, what is considered a valid initiate-update instruction is modifiable via a wireless message from the network side. In some cases, neither is an option. In some cases, both options are implemented.

In embodiments that feature a touchscreen, the TCM may simply send a CAN message to the touchscreen to inform the user that an update is ready. The touchscreen interface may then guide the operator through various steps such as putting the vehicle in the PARK state, and so forth. The user may then be prompted on the touchscreen to confirm that the installation should proceed, which it then does if such a confirmation input is received. Notifications of installation success or failure can then be presented to the user via the touchscreen. Moreover, in connection with any embodiments, alerts (e.g., e-mails, texts, and/or the like) could be sent to one or more computers, mobile devices, and the like to alert various different personnel of the status of a given update. Current configuration settings, installation version, and so forth could also be communicated in those alerts and/or in separate messages.

c. Second Example Method

FIG.8depicts a second example method800that may be carried out by a TCM such as the TCM102or by another suitable device, similar to the method600. Due to similarities between some aspects of the methods600and800, the method800is not described in as great of detail. One difference between the two methods is that, unlike the processing that occurs in connection with the method600, the processing that occurs in connection with the method800involves determining that all preconditions in a set of one or more preconditions are met before even notifying the driver via the operator interface228that an update is available. In these embodiments, that set of one or more preconditions includes a precondition that the update has been successfully downloaded to the vehicle202, and may include zero, one, or more than one further preconditions.

At802, the TCM102determines that each precondition in a set of one or more preconditions is satisfied, where that set of one or more preconditions includes a first precondition that an OTAP update has been successfully downloaded to the TCM. At804, the TCM102responsively presents an update-ready indication via the operator interface228. At806, after presenting the update-ready indication, the TCM102receives an input via the operator interface228. At808, the TCM102responsively determines whether that received input is a valid initiate-update instruction. At810, if the TCM102determines at808that the received input is a valid initiate-update instruction, the TCM102then responsively initiates installation of the OTAP update. At812, if the TCM102determines at808that the received input is not a valid initiate-update instruction, the TCM102then responsively does not initiate installation of the OTAP update.

An embodiment takes the form of an onboard system of a vehicle, where the onboard system includes a TCM having a communication interface; a processor; and a non-transitory CRM containing instructions executable by the processor for causing the TCM to carry out the method800.

d. Third Example Method

FIG.9depicts a third example method900that may be carried out by a TCM such as the TCM102or by another suitable device, similar to the method600. Due to similarities between some aspects of the methods600,800, and900, the method900is not described in as great of detail. In general, the method900is focused on a context in which there is a limited operator interface228such that input via the shift selector232is involved, and in which exactly three preconditions must be satisfied to trigger installation of the OTAP update. These three preconditions are that the ignition switch230is in its ON position, the prime mover204is in its NOT-RUNNING state, and a correct sequence of shift-selector inputs is received via the shift selector232of the operator interface228.

At902, the TCM determines that an OTAP-update-available indication is being or has been presented via the operator interface228, where the OTAP-update-available indication indicates that an OTAP update is available for installation.

The TCM102proceeds at904to monitor the ignition switch230and at908proceeds to910to determine whether the ignition switch230is in its ON position. If not, the TCM102proceeds at912to path938back to906. If so, the TCM proceeds at914to monitor the prime mover204at916and proceeds at918to920to determine whether the prime mover204is in its RUNNING state. If so, the TCM102proceeds at922to the path938back to906. If not, the TCM102proceeds at924to926to monitor the shift selector232and at928to determine at930whether a predefined sequence of shift-selector inputs is received from the shift selector232, and responsively initiating installation of the OTAP update.

If the TCM102determines at930that the predefined sequence of shift-selector inputs has not been received from the shift selector232, the TCM102then proceeds at932to path938back to906. If, however, the TCM102determines at930that the predefined sequence of shift-selector inputs has been received from the shift selector232, the TCM102proceeds at934to936, where the TCM102initiates installation of the OTAP update, and then proceeds on the path938back to906. In some embodiments, an additional decision box is present and relates to detecting whether installation of the update has been canceled and/or failed for some other reason; if that is determined to be the case, a return path from that decision box may bring processing back to902. And certainly other variations could be listed here as well.

An embodiment takes the form of an onboard system that includes a communication interface; a processor; and a non-transitory CRM containing instructions executable by the processor for causing the onboard system to carry out the method900.

V. Incorporation By Reference

Each of the below-listed U.S. patent documents is hereby incorporated herein by reference in its respective entirety. It is further noted that similar though differently numbered and perhaps slightly differently named components (e.g., transmissions, shifters and shift selectors, and the like) are described in the present disclosure and also in one or more of the incorporated documents. It is explicitly contemplated that, other than any conflicts that one of skill in the art would realize would be unworkable, the various permutations (e.g., a transmission operating according to a planetary gear set) that are disclosed with respect to these similar elements could be implemented in connection with the present systems and methods.U.S. Pat. No. 7,499,784, entitled “Method of Selecting a Transmission Shift Schedule,” issued Mar. 3, 2009 from U.S. patent application Ser. No. 11/733,164, filed Apr. 9, 2007;U.S. Pat. No. 8,000,864, entitled “System and Method for Changing Values Stored in Memory that Relate to the Operation of an Automatic Transmission,” issued Aug. 16, 2011 from U.S. patent application Ser. No. 12/035,946, filed Feb. 22, 2008;U.S. Pat. No. 8,170,758, entitled “System and Method for Changing Values Stored in Memory that Relate to the Operation of an Automatic Transmission,” issued May 1, 2012 from U.S. patent application Ser. No. 13/190,644, filed Jul. 26, 2011;U.S. Pat. No. 8,332,108, entitled “System for Determining a Vehicle Mass-Based Breakpoint for Selecting Between Two Different Transmission Shift Schedules,” issued Dec. 11, 2012 from U.S. patent application Ser. No. 12/455,369, filed Jun. 1, 2009;U.S. Pat. No. 8,935,068, entitled “System and Method for Optimizing Downshifting of a Transmission During Vehicle Deceleration,” issued Jan. 13, 2005 from U.S. patent application Ser. No. 13/920,168, filed Jun. 18, 2013;U.S. Pat. No. 9,365,201, entitled “Device, System, and Method for Controlling Transmission Torque to Provide Hill Ascent and/or Descent Assistance Using Road Grade,” issued Jun. 14, 2016 from U.S. patent application Ser. No. 13/835,331, filed Mar. 15, 2013;U.S. Pat. No. 9,512,905, entitled “Multi-Speed Transmission,” issued Dec. 6, 2016 from U.S. patent application Ser. No. 14/918,804, filed Oct. 21, 2015;U.S. Pat. No. 9,518,638, entitled “Multi-Speed Transmission” and issued Dec. 13, 2016 from U.S. patent application Ser. No. 14/919,864, filed Oct. 22, 2015;U.S. Pat. No. 9,541,168, entitled “Multi-Speed Transmission,” issued Jan. 10, 2017 from U.S. patent application Ser. No. 14/919,878, filed Oct. 22, 2015;U.S. Pat. No. 9,625,007, entitled “Multi-Speed Transmission,” issued Apr. 18, 2017 from U.S. patent application Ser. No. 14/457,592, filed Aug. 12, 2014;U.S. Pat. No. 9,631,707; entitled “Multi-Speed Transmission,” issued Apr. 25, 2017 from U.S. patent application Ser. No. 14/919,827, filed Oct. 22, 2015;U.S. Pat. No. 9,726,256, entitled “Multi-Speed Transmission,” issued Aug. 8, 2017 from U.S. patent application Ser. No. 14/919,851, filed Oct. 22, 2015;U.S. Patent Application Publication No. 2015/0292615, entitled “System and Method for Automatic Neutral and Automatic Return-to-Range for use with an Automatic Transmission,” published Oct. 15, 2015 from U.S. patent application Ser. No. 14/251,283, filed Apr. 11, 2014;U.S. Patent Application Publication No. 2016/0025213, entitled “Method of Setting Transmission Shift Points in Real-Time Based Upon an Engine Performance Curve,” published Jan. 28, 2016 from U.S. patent application Ser. No. 14/875,753, filed Oct. 6, 2015;U.S. Patent Application Publication No. 2016/0040754, entitled “Multi-Speed Transmission,” published Feb. 11, 2016 from U.S. patent application Ser. No. 14/453,660, filed Aug. 7, 2014;U.S. Patent Application Publication No. 2016/0138680, entitled “Multi-Speed Transmission,” published May 19, 2016 from U.S. patent application Ser. No. 15/003,089, filed Jan. 21, 2016;U.S. Patent Application Publication No. 2016/0138681, entitled “Multi-Speed Transmission,” published May 19, 2016 from U.S. patent application Ser. No. 15/003,112, filed Jan. 21, 2016;U.S. Patent Application Publication No. 2016/0138682, entitled “Multi-Speed Transmission,” published May 19, 2016 from U.S. patent application Ser. No. 15/003,149, filed Jan. 21, 2016; andU.S. Patent Application Publication No. 2018/0031119, entitled “Manual Shifting Control System and Method for Multi-Speed Automatic Transmission,” published Feb. 1, 2018 from U.S. patent application Ser. No. 15/220,803, filed Jul. 27, 2016.