This disclosure relates generally to the control of automotive vehicle drivetrain, powertrain, suspension components and accessories. More particularly the disclosure relates to effecting such control using portable personal electronic telecommunication devices, such as smartphones and tablet computers.
Although rarely found in passenger cars, some sport utility vehicles and light trucks can be purchased with variety of different powertrain, drivetrain and suspension options that make those vehicles better suited for rugged off-road use. Original equipment manufacturers of these off-road capable vehicles must necessarily make certain equipment choices to meet fuel economy and pricing requirements. Thus an off-road driving enthusiast may simply not be able to purchase an original equipment vehicle that has the precise complement of components he or she desires.
That is where the aftermarket comes in. Owners of original equipment vehicles can replace stock powertrain, drivetrain and suspension components with more off-road capable components. Many of these can be electrically switched between different modes: one suitable for around-town driving and another suitable for off-road use.
One problem with installing aftermarket components is that the vehicle dashboard is not so easily customized. If special switches are needed to control the aftermarket components, these typically need to be bolted on under the dashboard or otherwise installed in a manner that defaces the look of the original vehicle interior, there by damaging resale value.
The disclosed system takes a fresh approach to the problem of how to retrofit an automotive vehicle with aftermarket powertrain, drivetrain and suspension components. Through the deployment of a protocol converter circuit board, the disclosed system allows these aftermarket powertrain, drivetrain and suspension components, as well as associated accessories such as electric winches, light bars, vehicle lift devices and the like, to be controlled using a portable personal electronic telecommunication device, such as a smartphone or tablet computer.
The disclosed system goes further, however, by providing a system that will programmatically provide the user with a selectable range of different driving experience packages, all at the touch of a button. The disclosed system leverages both vehicle mounted sensors and native sensors within the portable personal electronic telecommunication device to provide a degree of control that has not heretofore been practical. The disclosed system thus opens up many driving experience possibilities that were not heretofore available through aftermarket retrofit.
For example, in one embodiment the disclosed system is able to utilize GPS and/or accelerometer sensors within the portable device to implement a lockout mechanism that inhibits certain off-road features from being used or engaged above a certain speed limit. In another embodiment, the GPS sensor data from the portable device is used as a form of geofencing, whereby a preprogrammed driving experience is automatically deployed, or recommended for deployment, when the vehicle is in a particular geographic location. Weather data obtained from sensors and data connections provided by the portable device can also be used to automatically deploy, or recommend for deployment, the driving experience setting that is appropriate for the sensed weather conditions. Tilt sensors and/or inertial sensors provided by the portable device can also be used to automatically deploy, or recommend for deployment, a driving experience to ensure best vehicle performance when the system detects the vehicle is ascending or descending at steep angles or traveling on non-level terrain.
Therefore, according to one aspect the disclosure describes a circuit for adapting at least one of the powertrain, drivetrain and vehicle suspension components of an automotive vehicle to be controlled by a portable personal electronic telecommunication device having memory and a processor. The circuit includes a protocol converter circuit coupled to receive electric power from an electrical power system of the automotive vehicle, the protocol converter circuit having at least one port by which to electrically couple to at least one actuator that supplies control to a powertrain, drivetrain or vehicle suspension component of the automotive vehicle. The protocol converter circuit further provides a communication channel by which communication is established with a portable personal electronic telecommunication device. An executable program, stored in the memory circuit of the portable personal electronic telecommunication device and operable by the processor of the portable personal electronic telecommunication device, supplies control signals via the protocol converter circuit to said at least one actuator.
According to another aspect, the executable program, stored in the memory circuit of the portable personal electronic telecommunication device and operable by the processor of the portable personal electronic telecommunication device, supplies control signals via the protocol converter circuit to plural different actuators in harmony or in concert to programmatically provide different drive and handling performance of the vehicle.
In yet another aspect, the protocol converter circuit provides a communication channel by which communication is established with a portable personal electronic telecommunication device; and the executable program processes signals from at least one inertial or guidance sensor and supplies control signals via the protocol converter circuit the at least one actuator based on said signals from the at least one inertial sensor or guidance sensor.
In still another aspect, the executable program processes signals from at least one inertial or guidance sensor and supplies control signals via the protocol converter circuit to at least one actuator based on said signals from the inertial or guidance sensor and further based on said vehicle powered sensor.
In a further aspect, the executable program processes signals from at least one inertial or guidance sensor and from a vehicle powered sensor: (a) to generate a first location datum, (b) to supply predefined control signals via the protocol converter circuit to the at least one actuator and (c) to store in said memory a record that associates said predefined control signals with the first location datum. The executable program is then operable by the processor to read from said memory the stored record that associates the predefined control signals with the first location datum and to use that stored record to supply additional control signals via the protocol converter circuit the at least one actuator.
Referring to
Each of these described components is coupled to the electronic control system, allowing each component to be operated, individually or in tandem, by a portable personal electronic telecommunication device, programmed to utilize the executable program stored in the memory circuit of the device as will be described.
The electronic control circuit 40 is preferably deployed on a circuit board that can be mounted within the vehicle at a suitable location where access to one or more wiring harnesses is made available. Power for the electronic control circuit 40 is obtained from the vehicle power system 44, which provides a supply of DC electric power. The typical vehicle power system 44 includes a 12 volt battery and associated electronic equipment such as an alternator and voltage regulator that supplies electrical energy to charge the battery and to provide electrical power to components within the vehicle when the internal combustion engine is running. In a conventional vehicle power system, the alternator produces a nominal voltage of about 13.5 to 14.5 volts, which provides sufficient potential to charge the 12 volt battery. Electronic circuits coupled to such power system are typically designed to operate at a nominal 12 volts. In an all-electric vehicle the vehicle power system employs a larger, rechargeable battery system, and these systems may operate at a higher voltage, such as 42 volts, for example. When using such higher voltage power systems, voltage convertor circuits can be used to support circuits designed for 12 volt use.
The vehicle power system also includes an ignition circuit 46 that supplies a signal, such as a 12 volt DC signal, when switched on by the vehicle operator. Thus the illustrated vehicle power system 44 and optionally the ignition circuit 46 can be capable of providing electrical power to the electronic control circuit 40. The difference being that the vehicle power system 44 provides power at all times, whereas the ignition circuit 46 provides power only when the ignition circuit is switched on by the vehicle operator (by manipulating a key-operated or wireless key fob-operated ignition switch, for example).
The electronic control circuit 40 includes a processor circuit 48 that includes a main voltage regulator 50, used to condition the power supplied to the processor circuit 48 so that a steady nominal 12 volt DC power is available to power the microprocessor 52, the Bluetooth radio 54 and the vehicle bus transceiver 56. Microprocessor 52 is programmed to decode sensor signals and to supply control signals that are delivered over the vehicle bus. These signals include, for example, control signals that control actuators within the vehicle, including actuators used in connection with the vehicle powertrain, drivetrain and active suspension components. Although different vehicle bus architectures are possible, exemplary is the CAN bus architecture.
In the processor circuit 48 the Bluetooth radio circuit 54 provides communication between microprocessor 52 and the portable device 42. It is through this wireless communication that control functions associated with the vehicle actuators are off loaded to the microprocessor (not shown) within the portable device 42. Thus the user can control actuators that switch on and off and regulate various off-road performance-affecting (i.e., vehicle powertrain and/or drivetrain) components. The portable device 42 can also programmatically provide different drive and handling performance of the vehicle automatically, based on driver preferences or based on measured conditions or vehicle location using sensors (not shown) within the portable device. Such sensors within the portable device include, for example, GPS receivers, accelerometers, tilt sensors, temperature and barometric sensors, inertial sensors and the like. Programmatic control via the portable device may also be based on data signals provided from external data sources, such as cloud-based Internet sources, accessed using cellular telephone connectivity of the portable device.
The processor circuit 48 is in turn coupled via suitable vehicle bus or wiring harness connections 58 to a control module circuit 60 which may be implemented using electromechanical or solid state relays to control attached actuators, such as the illustrated locking devices 62 and auxiliary devices 64. The locking devices would be used, for example, to control physical operation of powertrain, drivetrain or active suspension subsystems within the vehicle. Examples of auxiliary devices 64 would include the winch 30, lift mechanism 32 and light bar 34 (
As illustrated, the control module circuit 60 has its own bus connection 66 to the on-board diagnostic connection. Through this connection the states of devices attached to the control module circuit can be interrogated and made available to the on-board diagnostic system.
In effect, the processor circuit 48 and control module circuit 60 collectively act as a protocol convertor 106 that furnishes least one port by which to electrically couple to at least one actuator that supplies control to a powertrain component, drivetrain component, vehicle suspension component or vehicle accessory. In so doing, the protocol convertor 106 provides a communication channel by which communication is established with a portable personal electronic telecommunication device.
As illustrated in
In other instances where a subsystem, powertrain component, drivetrain component, suspension component or vehicle accessory does not communicate over the vehicle bus, a separate wirelessly-enabled relay circuit 82 is provided. In the exemplary embodiment of
The electronic control circuit 40 communicates with the portable device 42 via WiFi signals that are transmitted and received between the WiFi radio within the portable device (not shown) and the WiFi radio or radios within the control circuit 40, such as WiFi radio 70.
Comparable to the embodiment of
In a third embodiment, the functionality of protocol convertor 106 may be implemented as gateway circuit 84 shown in
The gateway circuit further includes a microprocessor 86 that is programmed to pass communication signals among the various devices coupled to the gateway circuit 84. A further explanation of the programming of microprocessor 86 is discussed in connection with
The gateway circuit 84 is equipped with a vehicle bus communication transceiver circuit 88 (an example vehicle bus being the CAN bus). This transceiver circuit allows the microprocessor 86 to communicate with vehicle devices that are addressable via the vehicle bus. In this regard, the various actuators and sensors that make up the vehicular powertrain, drivetrain and suspension systems may be equipped with the ability to communicate over and thus are controlled by signals sent over the vehicle bus.
While it is expected that many vehicle devices will be bus-enabled, the gateway circuit 84 includes a block of discrete input circuitry 89 that allows the microprocessor 86 to communicate with (receive data signals from) a set of physical control switches or with the portable device 42 by wire interface cable when WiFi connectivity is not available. In this regard the wire interface cable to the portable device 42 can attach to the port normally used by the portable device for charging the battery of the portable device and for syncing the portable device with other computers.
In some instances, the gateway circuit 84 may pass to the microprocessor 86 sensor signals received from other systems within the vehicle, such as those supplied via the vehicle bus. In this way the microprocessor can be supplied with data indicating the current vehicle speed, for example. However, the gateway circuit 84 may also include its own sensors that can supply data to the microprocessor independent of what may be available elsewhere on the vehicle. To illustrate this concept, the gateway circuit 84 includes an accelerometer module 90, which is an electronic circuit that measures tilt and motion in both linear directions and rotational directions, depending on the configuration. Such data are used by the control logic to assist in determining the state of the vehicle, which may in turn be used to control various vehicular device control algorithms. For example, because the gateway control circuit 84 is fixedly secured to the vehicle in a known orientation, the accelerometer module 90 can provide an indication of the yaw, pitch and roll movement of the vehicle.
While modern vehicles typically include many devices that communicate over the vehicle bus, the gateway circuit 84 can also accommodate devices that are not bus-enabled. This functionality is provided by a bank of field effect transistor (FET) control line circuits 91 that each provide the capability of switching a nominal control voltage (e.g. 12 volt dc) on and off. The FET control line circuits 91 are controlled by microprocessor 86 and can be used to switch a variety of different devices on and off, and to control other voltage-controlled aspects of those devices. Examples of such devices include accessory modules, electric powered winches, light bars (for improved nighttime illumination) and the like.
Once these initial housekeeping matters are attended to, the microprocessor proceeds to handle communication traffic. Messages are sent over the vehicle bus in packets that are each encoded with a packet ID. To enhance reliability, messages sent over the vehicle bus are encoded with an error detection pattern, such as a cyclic redundancy check (CRC) code. The microprocessor, at step 96, checks each new packet as it is received to test whether the CRC code associated with the packet is correct for that packet. If the CRC check fails, the packet is discarded, at step 97 and control can loop back to step 96. If the packet passes the CRC check in step 96, it is copied by the microprocessor to the receive buffer, at step 98, whereupon the packet is then read from the buffer, at step 99 and tested, at step 107, to determine if the packet ID is valid. If the packet ID is invalid at step 107, control can proceed to step 97. If the packet ID is valid in step 107, control can pass the (valid) packets for parsing at step 108. Such parsing separates the commands received from the received packet according to which device the command corresponds. At step 109, the microprocessor transmits commands to the connected devices using the same packet protocol.
By way of illustration,
While slide switches are one presently preferred user interface control, other options are possible.
It will be appreciated that the embodiments of
Executable Program Run by Processor of Mobile Device
The portable device 42 has at least one internal processor 100 with attached processor-readable memory 102, as diagrammatically illustrated in
As previously discussed, the portable device 42 communicates wirelessly with the protocol converter circuit 106 to effect wireless control over the many disparate vehicular subsystems that contribute to the overall driving performance and handling of the vehicle. These subsystems include those illustrated in
The executable program run by processor 100 may be configured as shown in
In this architecture the model 108 encapsulates the state data corresponding to the switch settings entered by the user and corresponding to other settings that are automatically set by operation of the program itself. The model is communicates with the controller 112, by providing notifications to the controller 112 of state changes arising from logic processing under the model's control and by receiving updates from the controller regarding changes requested by user interaction or based on other sensor data processed by the controller.
The controller 112 handles communication with the protocol converter 106 and thus sends and receives data that are sent via the wireless link to the protocol converter. The controller 112 is also responsible for managing the lifecycle of software objects instantiated during operation of the executable program.
The view 110 is responsible for providing the user with a visualization of the state of the model. The view 110 is thus responsible for generating the display screen shown in
With reference to
Once network connection is established, the executable program causes the processor 100 to connect to the TCP/IP socket designated by the program. This TCP/IP socket thus serves as the port through which the processor will communicate with devices coupled to the protocol converter 106. If a socket connection cannot be established, at 201, the program loops back to step 206, allowing the processor 100 to recheck and reconnect to the WiFi network. Once the socket is connected, the program checks the incoming message stream for system messages at step 212. If system messages are not received, the program loops back to step 210 to again test whether a TCP/IP socket has been properly connected. Assuming system messages are being received at step 214, the program enters a Status OK state at 218. If desired a Status OK flag can be set at this point, whereupon the program branches back to step 212 to continue to check for system messages. If at any point system messages are not received, the program loops back to step 210 as discussed above.
Thus it can be seen that the executable program implements a nested series of steps that test and establish a network connection, test and establish a TCP/IP socket connection and then test and receive system messages sent over the network via the assigned socket connection.
With reference to
Assuming the Status OK state is true, the program begins by harvesting any human-machine interface (HMI) input such as a button press entered via the screen of the portable device (as illustrated in
For example, a more complex operation might involve using the current vehicle GPS location, obtained from the GPS receiver on board the portable device and then consulting a separate table that stores a set of one or more simple commands that have been associated with a stored GPS location. In this way, the current GPS location can be used to assemble a plurality of different simple (e.g. button press) commands that are then concurrently issued to effect a change in the settings of plural vehicle devices in harmony with one another.
Once the outgoing system message has been compiled, the program, at step 230, calculates a CRC code based on the compiled message and appends this code to the message. In this way the message can be checked for integrity by the protocol converter or by another processor or controller within the vehicle to ensure that the message was not garbled in transit.
Because the system messages are being sent wirelessly, a security mechanism is employed to prevent inadvertent or intentional interference by other third party devices that happen to be communicating on the same wireless channel. Clearly, the vehicle owner would not want his or her vehicle to be controlled by someone else who happens to be running the same application software on a portable device. Thus the program, at step 232, encodes the system message with using an encryption process, such as the Advanced Encryption Standard (AES) algorithm. The encrypted message is then sent via the socket at step 234.
With reference to
This application claims the benefit of U.S. Provisional Application No. 62/073,404, filed on Oct. 31, 2014. The entire disclosure of the above application is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
62073404 | Oct 2014 | US |