WO1997028988A1

WO1997028988A1 - Data communications computer

Info

Publication number: WO1997028988A1
Application number: PCT/US1997/002241
Authority: WO
Inventors: Charles Scott Carmody
Original assignee: Charles Scott Carmody
Priority date: 1996-02-12
Filing date: 1997-02-12
Publication date: 1997-08-14
Also published as: AU2050897A

Abstract

An apparatus including a controller interposed between vehicle electronics and multiple ports having data, power, and wireless communications connections, the ports being intended for accommodating various types of vehicle aftermarket products. Programs within a memory associated with the controller dictate which ports will communicate with selected other ports and/or the vehicle electronics; whether data transmitted between different ports and/or the vehicle electronics is to be translated to different formats, transformed to data representing other physical quantities, or otherwise manipulated; and whether signal conditioners between the controller and the ports and/or vehicle electronics are to be actuated to provide buffering, level conversion, analog-to-digital or digital-to-analog conversion, etc. The apparatus thus provides for the rapid and easy installation or removal of vehicle aftermarket products by plugging/unplugging them from their ports and installing/removing appropriate programs.

Description

DATA COMMUNICATIONS COMPUTER

FIELD OF THE INVENTION

The present invention relates generally to apparata for providing data transmission between vehicles and different data-utilizing devices. The present invention relates more specifically to a Data Communications Computer (DCC) which may be installed in vehicles or other products which generate or otherwise utilize data in electronic form to allow communication between and control of the vehicle and the data-utilizing products.

DESCRIPTION OF PROBLEM

In today's car and truck markets, vehicle options and aftermarket products such as wireless communication devices, security systems, maintenance systems, geographic tracking systems, and remote control systems are becoming increasingly popular.

However, new vehicles often have complex digital operating systems, making it risky and dangerous for installers of optional or aftermarket products to tap into the vehicle electronics. One approach to this problem is to integrate multiple aftermarket products into a single system which is designed for easy installation in a vehicle in its entirety. Because multiple aftermarket products are integrated into a single system, there is a lesser likelihood that the vehicle owner will later need or want to add other aftermarket products. Examples of several integrated systems follows.

U.S. Patent 5,081,667 to Drori et al. describes a system integrating vehicle security and a variety of different cellular telephones into a vehicle's electronics system. The system utilizes a controller which is installed between the cellular telephone, the vehicle electronics, and the vehicle security. The controller includes firmware for allowing the vehicle owner to call the vehicle using the telephone, discern its security status, and activate security features such as activation/deactivation of the ignition, the door locks, etc. In order to allow different types of cellular telephones to communicate with the vehicle security, the controller also includes a library of firmware translation protocols for different proprietary cellular telephone schemes. The system may be configured for communication with different telephone schemes by the user's input of a code on the telephone keypad corresponding to the desired telephone scheme, thereby enabling the appropriate translation protocol.

The RESCU (Remote Emergency Satellite Cellular Unit) system (Ford Motors, Detroit, MI, USA) allows a cellular telephone to link to a Global Positioning System (GPS) module so that pressing emergency roadside service buttons or emergency medical assistance buttons delivers a message to a clearinghouse including the type of alarm, the vehicle identification number, location of the vehicle, last recorded speed and direction of the vehicle, a time stamp, and the vehicle cellular telephone number. The clearinghouse can then contact roadside service providers in the area of the vehicle and request that assistance be dispatched to the vehicle location.

ONSTAR, a system currently installed in CADILLAC vehicles, provides features similar to those of RESCU. The ONSTAR system also contacts a clearinghouse when the vehicle security is triggered. It is then possible to track and recover a stolen vehicle via GPS. The vehicle owner may also call the clearinghouse for remote control of vehicle security features such as remote unlocking of the vehicle doors, or to get directions to a desired location, which the clearinghouse provides by correlating the GPS- specified vehicle location to the clearinghouse's geographic/map database.

AutoLink (Prince, Holland, MI, USA), CERES (RoadTrac, Roswell, GA, USA), and the Mobile Security Network by ADT Security Systems (Parsippany, NY, USA) and Rockwell Electronics (Troy, MI, USA) are systems offering features similar to those of

RESCU and ONSTAR. The Mobile Security Network system is unique in that it is available as an aftermarket stand-alone unit which may be mounted on a sun visor or the like. The AutoLink system is of interest because it allows transmission of data from a vehicle's diagnostics system to the clearinghouse for relay to roadside assistance service providers so that vehicle status is known before assistance units are dispatched.

The POSSE system (Audiovox Corporation, Hauppage, NY, USA) allows a vehicle owner to call a clearinghouse which can remotely activate vehicle security. The clearinghouse can offer remote activation of other vehicle features as well, such as locking/unlocking of doors, engine starting, and adjustment of the heating/cooling system. RECALL (Recall, London, England) is a system similar to POSSE, and future versions are proposed to incoφorate GPS links. Etak geographic databases (Etak, Menlo Park, CA, USA) have been used in conjunction with GPS units and wireless communications systems to allow delivery of geographic data to vehicles and personal computers via wireless communications.

The aforementioned systems do not solve the problem addressed by this disclosure, that is, the rapid, easy, and inexpensive addition of multiple aftermarket components into a vehicle, and/or removal and replacement of undesired components. Rather, the aforementioned systems are "closed-ended": they provide for the installation of integrated cellular, security, and (in some cases) GPS and other features, but they do not allow for safe and easy installation oi further aftermarket products or the removal or replacement of existing features. To add further features, these systems require

"upgrades" to entirely new models by replacement of system hardware. This limitation of the systems has thus far resulted in a race between manufacturers to add the most features to each new model of their systems, and as each vendor's new model adds newly-developed aftermarket features, it is compared to prior systems and touted to consumers as offering the most, best, and newest features. Thus far, this has resulted not so much in an increase in performance and utility as an increase in price and complexity. Owing to the complexity these systems add to the vehicle's electronics, this has also resulted in the disadvantageous (and perhaps intentional) effect of making it more difficult and risky to add additional aftermarket products to a vehicle, particularly those produced by other manufacturers.

These integrated systems also suffer from the disadvantage that their features are often not commensurate in quality with those of "dedicated" products made and sold by companies who specialize in particular fields of aftermarket products. As an example, the GPS systems in the aforementioned integrated systems are rather simple compared to those produced by companies that specialize in proprietary GPS tracking systems.

GPS systems such as the NVA-N751A (Alpine Electronics, Torrance, CA, 90501 ) and the JRC 8820DR (JRC, Forth Worth, TX, USA) provide GPS units designed for stand¬ alone use or for installation in a vehicle as an aftermarket product, and include sophisticated integrated databases with convenient output delivery via voice output or display screens. However, if an owner of one of the aforementioned integrated systems wished to "upgrade" to one of these sophisticated GPS units, the dedicated GPS unit would need to be installed in parallel with the integrated system (including its built-in GPS system, if present). As noted above, such installation is difficult owing to the complexity that the integrated system adds to the vehicle wiring harness, and additionally any GPS units already present in the integrated system are rendered redundant (and tantamount to a waste of money) by such installation. The aforementioned systems also have the drawback that they require calls to a clearinghouse (or other centralized source) to request data, e.g. , the telephone numbers of local emergency services or directions/geographic information. While this may be inconvenient to owners of the vehicles/integrated systems, it has heretofore been somewhat of a necessity. The systems could theoretically incorporate such databases by incorporating more memory to house the databases, but this raises the price points of the systems to levels which make them unattractive to consumers. Additionally, the upkeep required to keep the databases in each individual vehicle current and accurate would be burdensome and expensive. Use of a clearinghouse reduces system costs because database upkeep at a single centralized location is far easier than upkeep of multiple databases. Further, a clearinghouse is free to acquire its data from the most inexpensive source, whereas an information system built into a vehicle is more likely to use databases having proprietary formats and requiring proprietary software for access. This would tend to place the owners of the vehicles/systems at the mercy of the database vendor's pricing when database updates are required. Other systems have been proposed which offer a simpler and more hardware-oriented approach to allowing addition of aftermarket products. U.S. Patent 5,040,990 to Sii an et al. , assigned to Prince Coφoration, describes a modular vehicle console designed to allow the addition of aftermarket products to a roof-mounted overhead console. The console is installed in a vehicle in connection with the vehicle electrical system. The console includes a number of ports wherein aftermarket product modules such as lamps, compasses, garage door openers, etc. can be mounted, and the addition of an appropriately-configured shorting bar connects these modules to the desired circuits in the vehicle electrical system. However, the console requires the use of proprietary aftermarket products insofar as the console design dictates the form of the products that can be installed therein. Additionally, while the console is well-suited for rapidly and easily connecting aftermarket product modules, to the vehicle's power system, it does not provide for connections between two or more aftermarket products to allow them to interact or communicate, nor does it accommodate aftermarket products which require more complex data transfer and signal conditioning/buffering in relation to the vehicle electronics.

U.S. Patent No. 5, 179,503 to Fours et al. illustrates a power distribution box for vehicles having operational principles similar to that of the Suman et al. device.

Buffering modules containing diodes, fuses, relays, etc. may be installed in the box between vehicle aftermarket products and the vehicle battery /alternator to meet changing power demands in vehicles as new products are added or removed. While the Fonts et al. device addresses the problem of power distribution as new products are added, it does not directly address the installation and interactive/communicative interconnection of the products themselves, nor does it address the need for a system that provides rapid and easy installation of aftermarket products utilizing data and communications lines.

Several references are of interest for proposing systems for simplifying the vehicle's electrical system. Theoretically, simplification of the vehicle's wiring harness could in turn simplify the installation of aftermarket products. U.S. Patent 4,302.841 to

McCulloch illustrates a vehicle electrical system wherein the vehicle components are connected to the vehicle power source via digitally-controlled relays, and a central controller provides signals to turn the relays on and off to actuate the components. An important aspect of the invention rests in its scheme for allowing digital actuation of the vehicle components without having inadvertent actuation due to electronic noise, and without the speed -reducing effects of oversampling. French Patent 2,626, 1 16 to Renault Vehicles illustrates an apparatus similar to that of U.S. Patent 4,302,841 to McCulloch. These systems allow for a substantial reduction in vehicle wiring, since the conventional system of providing leads from the vehicle power source to the vehicle dashboard/controls to the components is replaced by shorter leads from the vehicle power source to the components, and leads from the vehicle dashboard/controls to the controller to the relays associated with the components. However, these systems do not directly address easier installation of aftermarket products and/or the establishment of interactive/communicative interconnection between aftermarket products. SUMMARY OF INVENTION

The disadvantages of the aforementioned systems are solved by use of the Data Communications Computer (DCC) defined by the claims set out at the end of this disclosure. The DCC is a device which serves as a nexus for data transmission between two or more aftermarket products which utilize electronic data, such as the vehicle electronics and one or more vehicle aftermarket products. The DCC is installed in the vehicle via plugging in or hardwiring the vehicle electronics at a DCC input-output (I/O) port in connection with the I/O port's data leads. Aftermarket products are then connected to the DCC in similar fashion, preferably at plug-in I/O ports (e.g. , RS-232 or SCSI-standard data leads) to allow fast and easy installation. However, the mere act of plugging in products will not enable them to communicate with the vehicle electronics, or to each other. This is done by providing the DCC's controller with programs which connect the desired ports in communicating relationship. Where the products at the ports of interest are not capable of direct communication owing to incompatible signal formats, the programs can also apply desired data translation protocols and/or enable signal conditioners (analog-to-digital converters, filters, etc.) to allow data to reach the receiving I/O port(s) in intelligible condition. Thus, given any two or more data-utilizing products having the ability to send and/or receive data, the DCC can interactively link the products for communication when the products are installed at respective I/O ports in the DCC and properly configured programs are executed in the controller to provide the desired switching, translation, and signal conditioning relations between the ports.

Apart from data leads, it is also recommended that each of the I/O ports of the DCC also include power supply leads. This allows products installed for data communications at the I/O ports to also be appropriately powered at the I/O ports, eliminating the need to tap the products directly into the vehicle's power system/leads. As an illustration, a

I/O port may include power/ground leads as well as data leads so that the DCC can power a product installed at the I/O port as well as sending and receiving data to and from the product.

It is further recommended that each of the I/O ports of the DCC include communications leads, e.g. , sockets for receiving CTS (cellular telephone system) or RTS

(radio telephone system) connects. This allows products such as cellular telephones and pagers to be plugged into the DCC in communication with the controller, and thus to other products.

The installation of the DCC in a vehicle allows vehicle and vehicle aftermarket product manufacturers, vendors and installers to provide customers with a wide variety of aftermarket products (i.e. , options and accessories) without costly and time-consuming installation. Improper installation may cause malfunction or destruction of the vehicle electronics and/or product components, thereby leading to expensive repairs, or worse yet potential legal liability if a critical component is damaged. The problem is compounded by some manufacturers intentionally suppressing dissemination of information about their data protocols so that they can maintain some degree of control over product installation, and thereby obtain a share of the profits.

The DCC can be installed into the wiring harness of a vehicle in communication with the vehicle's electronics, e.g., its sensors and control leads. The DCC's I/O ports, which are preferably configured in accordance with well-known standards (e.g. , the RS-232 standard for data), then allow easy and rapid connection of aftermarket products to the

DCC so that the DCC is inteφosed between the vehicle electronics and these products. Programs are provided in the DCC to allow it to provide the desired data transmission/conversion and signal conditioning between the vehicle electronics and the products. Different programs can provide different input/output relations and signal conditioning; for example, one program could allow a vehicle security system connected at one I/O port to correctly communicate with the vehicle electronics, while another program could allow a remote tracking system connected to another I/O port to correctly communicate with a cellular telephone system installed at another I/O port and/or with the vehicle electronics. Different products may have different I/O protocols, and the programs configure the DCC to provide these protocols when they are required between

I/O ports. As a result, a wide variety of products may be installed in a vehicle if the products are attached to the DCC and the proper programs are provided. The difficulty of product installation is greatly eased because all an installer needs to do is plug a product into a compatible I/O port and then install programs which are configured with the addressing and data translation/signal conditioning protocols required for the product to communicate with product(s) at other I/O port(s). Programs for allowing existing and new products to communicate are easily provided by programmers of ordinary skill provided they know the required data translation protocol involved (e.g. , conversion of data from a flat ASCII format to a proprietary format), and whether and what type of signal conditioning should be actuated. As an example, one program can provide the controller with the proper communication protocol between two products X and Y, while another could provide the controller with the communication protocol if product X was instead (or also) to communicate with product Z, and so on. To allow products to be installed at any of the DCC's I/O ports, multiple programs with the same translation/signal conditioning protocols but different addressing schemes can be easily prepared. For example, one program could allow communication between products X and Y installed at respective ports 1 and 2, another program could allow communication between products X and Y if they were instead installed at respective ports 1 and 3, and so on.

The DCC also has the potential to decrease the cost and bulk of aftermarket products because in some cases the DCC programs can configure the I/O relations, data collection and manipulation, and signal conditioning of the DCC to fulfill some or all of the functions of certain aftermarket products. As an example, the DCC controller may include sufficient volatile memory that it can store data on the vehicle's status (such data being supplied by sensors connected at an I/O port, or by the vehicle diagnostics system, which is connected to the DCC with the remainder of the vehicle wiring harness). Since this arrangement effectively allows the DCC to provide the functions of a "black box" event recorder, there is no need to install a separate black box recordation apparatus at an I/O port. Thus, it can be appreciated that the DCC's use of programs to dictate its functionality can alleviate the need to add additional hardware.

The DCC can also enhance the performance of aftermarket products installed at I/O ports, or reconfigure their appearance and/or performance to suit a vehicle owner's desires. As an example, it was noted above that existing integrated aftermarket products systems do not incoφorate geographic databases for use in conjunction with their GPS owing to the cost of memory and database upkeep. The DCC can duplicate this system if GPS and cellular telephone systems are installed and a clearinghouse is provided for allowing call-in access to geographic data. If the vehicle owner later grew tired of the inconvenience of calling the clearinghouse to receive data, the owner could install a "secondary memory" at one I/O port (e.g. , a personal computer, or solid-state or magneto-optical read-only or read-write memory devices) for storing and accessing geographic data. The owner can then install an output device (e.g. , a voicebox or display screen) at another I/O port for receiving data output in voice or visual form, or alternatively can install programs for allowing data output via voice delivery through the cellular telephone. The owner can then install the programs necessary for allowing the desired communications between the newly-added products. The vehicle owner can change databases, database media, and database output devices at a later date provided new programs are activated in the DCC to accommodate any new communication/translation protocols. In some cases, the user's desires for changes to the system may be met by a change of programs rather than changes of or additions to hardware. For example, if the user did not like the format of a display on a display screen, a new program might provide a format better suited to the user's desires. The vehicle owner is therefore not permanently stuck with unwanted or unwieldy and unchangeable features, as with the aforementioned integrated products systems. There are a number of other advantages associated with use of the DCC. By use of the DCC in vehicles or other data-utilizing products, consumers can allow for the easy and rapid installation of a wide variety of accessories, options, and aftermarket products by inteφosing the DCC between the products to be connected and installing properly- configured programs in the DCC. Because the DCC substantially reduces the difficulty of installing optional or accessory products, the risk of damage to the different products is decreased. Installers only need to know how to attach a product to the I/O ports and install the DCC programs (and perhaps configure the programs beforehand to fit particular products installed at particular I/O ports, but they do not have to be knowledgeable about vehicle electronics. Thus, installation of optional and aftermarket products is rapid and virtually foolproof. In addition, the programs can be rapidly reconfigured by programmers to allow adaptation of the DCC's I/O relations and signal conditioning, thereby allowing rapid and low-cost tuning or "re-tooling" of the DCC's communications if refinements are necessary.

Examples of products and options currently in existence which may be used in combination with the DCC are cellular communication systems, radio communication systems, GPS or other tracking systems, ledger data storage systems, custom data recording systems, computer access and recording systems, maintenance recording system, sales call report systems, accounting systems, remote start systems, security systems, emergency call systems, vehicle operations systems (e.g. , CAN networks), vehicle diagnostics reporting systems (e.g. , DDEC systems), accident recording ("'black box") or reporting systems, fleet management systems, mileage recording systems, vehicle operating costs systems, hijack prevention systems, and passenger recording systems.

BRIEF DESCRIPTION OF THE DRAWrNGS FIG. 1 illustrates a block diagram of a preferred embodiment of the DCC installed within a vehicle.

FIG. 2 is a schematic of the DCC of FIG. 1 installed within the vehicle wiring harness.

FIG. 3 is a more detailed schematic of the DCC of FIG. 1 installed within a vehicle wiring harness. FIG. 4 illustrates the connection of the DCC to a variety of exemplary products.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates a block diagram of an exemplary DCC in accordance with the present invention, and as it might appear when installed within a vehicle. The general structure and operation of the DCC will be described with reference to this block diagram, and alternate and more specific embodiments of the DCC will be discussed later in this Detailed Description.

In FIG. 1, the DCC is depicted at the center of the diagram inteφosed between the vehicle electronics and one or more optional or aftermarket products. The vehicle electronics and data collection devices are illustrated at the left-hand side of the diagram, and may include the vehicle power, vehicle starter, vehicle ignition, vehicle door locks, etc. These vehicle electronics are connected to the DCC by several leads.

At the right-hand side of the diagram, the DCC includes several I/O ports. As an example, FIG. 1 shows three I/O ports, each being adapted for connection of power leads, data leads, and communications leads. One or more of the I/O ports may include any other leads necessary for connecting aftermarket products to vehicle electronics, and can either be adapted for lead connection in accordance with a "generic" or proprietary standard (such as the one illustrated in FIG. 1) or known data, power, or telecommunications interface standards (e.g. , RS-232 for data, 12 V plug for power where automotive applications are concerned, etc.). This allows one or more aftermarket products to each be connected by its leads to a respective DCC I/O port having the appropriate interface. Signal conditioning (buffering, level conversion, and analog-digital conversion where necessary) is provided between the controller of the DCC and the vehicle electronics, and also (or alternatively) between the controller and the I/O ports. Thus, while the data leads are generally contemplated to transmit digital signals, they could instead transmit analog signals (e.g. , control and feedback signals) where analog aftermarket products are connected to the I/O ports. In this case, digital-to-analog conversion may occur in the signal conditioners associated with the DCC, or it can occur in the products themselves if they include the appropriate signal conditioning equipment.

The controller connects the products at the I/O ports with the vehicle electronics and data collection devices by providing the proper switching and signal conditioning relations therebetween, thereby connecting the vehicle electronics leads in communication with the desired I/O port leads. The controller's switching and signal conditioning relations are determined by one or more programs which are downloaded into the controller's memory as software, or which are alternatively provided as firmware (i .e. , are burned or otherwise permanently installed therein). If the programs are to be downloaded, this may be done at an unoccupied I/O port, at a separately provided dedicated data input port

(i.e., an I/O port including only data leads, not shown), or via the use of an accessory device which is already installed at an I/O port (e.g. , via a cellular telephone or other wireless communications device). It is most preferable to store the programs in erasable memory to allow the data processing functions of the DCC to be updated or replaced at a later time. The ability to modify the functions of the DCC by installation of new and different programs is regarded to be extremely valuable, since this "field programmability" feature allows the DCC to be modified to fit future data collection/processing requirements as they arise.

Depending on the capacity of the memory and the controller, each of the I/O ports may serially or simultaneously communicate with the vehicle electronics. If desired, the

DCC can allow communication between products at different I/O ports as well as between the products and the vehicle electronics. In effect, the DCC functions as a communications hub which is connected to vehicle electronics and I/O port "spokes, " and which allows each spoke to communicate with any other spoke. Additionally, certain commonly encountered aftermarket products (or portions thereof) may be hardwired or integrated into the DCC, rather than installed into an I/O port, e.g. , the remote control antenna illustrated in FIG. 1. Some aftermarket products can also be wholly provided by the DCC in the form of a program; for example, with the use of the proper programs, the DCC can function as a "black box" or event recorder without adding any products at an I/O port. Similarly, whereas the "universal" I/O ports illustrated in FIG. 1 are intended for connection to any type of aftermarket product, the DCC may also include "dedicated" I/O ports (not shown) which are specially designed for connection to particular types of aftermarket products. For example, an I/O port may be configured to include only data leads (e.g. , leads configured to RS-232 or SCSI standards), power leads (e.g. , leads configured to NEMA or IEC 12V, 9V or 5V outlet standards), or telecommunications leads (e.g. , CTS or RTS leads) if it is known that the DCC will likely interface with products which only require one of these types of leads. Similarly, an I/O port may be configured to include a combination of two types of these leads if it is contemplated that candidate products will not require leads of the omitted type.

A second embodiment of a DCC is shown in greater detail in FIG. 2 at the reference numeral 46. The DCC 46 is connected to the vehicle wiring harness 41 by a connector 42 including a series of leads 1-20. The leads 1-20 may be connected to any or all of the circuits and devices in the vehicle wiring harness 41 . FIG. 2 illustrates connection to such exemplary components as the battery 21 ; the ground 22; a start circuit 23 and a start enable circuit 24. which provide an optional security feature which is discussed in greater detail below; an ignition circuit 25; a door lock circuit 26; a brake circuit 27; speed count or speedometer circuit 28; a fuel pump circuit 29; an engine temperature circuit 30; an oil pressure circuit 31 ; a tachometer/engine rpm circuit 32; a right signal circuit 33; a left signal circuit 34; a headlight circuit 35; a fuel gauge circuit 36; and remaining circuits A 37, B 38, C 39, D 40, etc. , which represent other circuits within the wiring harness 41 that the installer wants to communicate with the DCC 46.

The DCC 46 includes one or more universal I/O ports depicted at 43-45, each of which includes data, power, and telecommunications leads. The leads of the I/O ports 43-45 may utilize male-female connects or any other type of connection for allowing aftermarket products to be easily installed, and preferably use well-known connectivity standards (e.g. , RS-232 for data). The I/O ports 43-45 can contain any number of data leads, but will generally have a number of data leads which are equal to or less than the number of leads provided by connector 42. For example, in the DCC 46 illustrated in

FIG. 2, the I/O ports 43-45 could have twenty data leads so that each I/O port can potentially connect to a product which communicates with all of leads 1-20 when the DCC 46 is active. In this case, it is understood that when an I/O port 43-45 is to connect to a device having less than twenty data I/O channels, some of the connection junctions of the ports 43-45 may stand idle. If desired, adapters may be provided for inteφosition between the device and an I/O port 43-45 which provide a conductive bridge between the active data leads and the product, and terminate any idle leads. To provide another illustration, if a DCC I/O port 43-45 has a data slot including two rows of ten holes each (corresponding to twenty data leads overall) and the leads from a product provide five pins, an adapter can terminate fifteen leads of the I/O port and bridge the five remaining leads to the appropriate product leads. Such adapters may also be useful if the interconnectivity standard (e.g. , the pin configuration) between the DCC and the product are different since the adapter can be configured to provide a bridge between different standards. As another example, if a DCC I/O port has two rows of ten holes each (corresponding to twenty data leads overall) and the leads from a product provide a single row of twenty pins, an adapter can bridge each of the twenty pins to the appropriate holes so that the desired port and product leads are connected.

As noted above, the DCC 46 may also include a number of dedicated I/O ports adapted for connection to particular species of products when it is highly likely that the DCC will be used in conjunction with these products. Three exemplary dedicated I/O ports are illustrated in FIG. 2: a radio frequency interface port 47, a display indicator/beeper port 48, and an instrument panel feed port 49. The radio frequency (RF) interface port 47 is specifically designed for connection to radio frequency controlled devices, e.g. , remote control systems for remotely unlocking doors or starting the vehicle. The RF port 47 could differ from the universal I/O ports 43-45 by, for example, including only power and communication leads and excluding data leads. The display indicator/beeper port 48 is specifically designed to provide a display or other signal to a vehicle user to indicate that the DCC 46 is active. As an example, the display port 48 may only include power leads for activating a display light plugged into the port 48, and it can exclude the data and communication leads. The instrument panel feed port 49 is specifically designed to connect to the instrument panel of the vehicle so that the instrument panel receives its input data from the DCC 46. It is understood that the functionality of all of the dedicated I/O ports 47-49 could be provided by universal I/O ports 43-45, and that dedicated ports 47-49 are shown merely to illustrate that the DCC 46 may include dedicated I/O ports which are specifically configured for certain types of connectivity. It is also understood that an essentially unlimited number of universal and/or dedicated I/O ports may be provided in the DCC 46 within the limitations of space constraints and controller speed and capacity.

FIG. 3 illustrates a third embodiment of the DCC. In this embodiment, the DCC's signal conditioner is provided at 87, between the controller 1 19 and the vehicle wiring harness 70. The signal conditioner 87 is connected to the vehicle wiring harness 70 via leads 50-69. The vehicle main battery and ground are connected to voltage/current protection devices 71 (e.g. , fuses) through leads 50 and 51 ; a voltage regulator 74 (e.g. , a three-terminal IC voltage regulator or series voltage regulator) through leads 72 and 73; and power conditioning devices 77 through leads 75 and 76. A backup battery 128 is connected to the power conditioning devices through leads 128 and 129 so that the controller 119 and memory 1 15 have power if the main battery is drained or removed.

The main battery and ground are ultimately connected to the controller 1 19 via leads 78 and 79.

The leads 54-69 from vehicle 70 are connected to the controller 1 19 via leads 88-103, with the signal conditioner 87 acting as a buffer to prevent possible damage to the controller 119. The controller 1 19 is in turn connected to a serial multiplexer 120 for serially connecting the controller leads 127 to the universal I/O ports 121 , 123, and 125 so that each I/O port will be allocated a time for communication with the controller 1 19.

No signal conditioners are illustrated between I/O ports 121 , 123, and 125 and the controller 119 because this embodiment is contemplated to use uniform power standards between the controller 1 19 and the products installed at the I/O ports. However, it is understood that a signal conditioner (or conditioners) may be provided at any of the I/O ports 121, 123 and 125 if the aftermarket products to be installed use a signal protocol different from that of the controller 1 19, e.g. , where the products use 12 VDC (the standard for many automotive products) and the controller uses 5 VDC (the standard for many commonly available controllers). Where commonly encountered standards like these are involved, routine off-the-shelf power conversion components are readily available for use as signal conditioners. On the other hand, if it is expected that the products will use irregular/non-standard signal levels, programmable signal conditioning circuitry (controlled by independent controllers or by the controller 1 19 and associated programs) may be required. Programmable signal conditioning circuitry of this type is available from PicoPower Technology, Inc. , Opti Inc. , National Semiconductor Coφ. , and other manufacturers of active power management chips/devices.

The start and start enable circuits 52 and 53 are provided as a security feature for the vehicle, and their leads 52 and 53 are situated in the ignition circuit. When the controller 119 provides the appropriate start signal to the start enable relay 81 via lead 80, leads 52 and 53 are connected to close the ignition circuit to allow the vehicle to start when the ignition switch is closed. An optional bypass switch 82 allows closure of the leads 52 and 53 to allow ignition to occur without triggering the start enable relay 80, and the lead 86 is provided so that the controller 119 may sense when the start and start enable circuits 52 and 53 are energized. The start signal may be provided to the start enable relay 81 when, for example, a security device at an I/O port 121 , 123, or 125 sends an appropriate command to the controller 1 19.

Two dedicated I/O ports are illustrated in FIG. 4, an antenna port 108 and a beeper/display port 109. One or more antennas may be installed at the antenna port 108 to allow transmission and reception of broadcast signals, such as cellular phone, GPS, or radio control signals. The beeper/display port 109 can be connected to buzzers, display indicator lights, display screens, etc. to indicate the status of the DCC. As an example, when the DCC is operational, a light could come on at the port 109. Both ports 108 and 109 are illustrated with the signal conditioner 87 interposed between the ports and the controller 1 19 because both ports will generally require signal conditioning. Either of these ports 108 and 109 may be located similarly to the I/O ports 121, 123, and 125 if these ports 108 and 109 include their own dedicated signal conditioners.

Numerous suitable controllers are available for use as controller 1 19, a particularly preferred embodiment being the IBM POWER PC 400 microprocessor. A crystal 118 is provided as a timing oscillator for the controller 1 19. The memory 1 15 stores the programs utilized by the controller 1 19 for providing switching and signal conditioning between the I/O ports 121 , 123, and 125, the vehicle leads 54-69, and GPS/cellular leads 132, 133. The memory 115 can store software modules to provide the desired signal conditioning and switching algorithms to the controller 119, or it could instead have the switching and signal conditioning programs permanently "burned in" as firmware rather than being downloaded. It is contemplated that if the programs are permanently installed in the memory 115, they may be provided in the DCC in disabled form, and the programs can be enabled by an aftermarket product installer by entering an activation code into the memory 115 via an I/O port 121/123/125 (e.g. , by plugging in a computer or PCMCIA card which provides the code), the communications leads 132/133 (e.g. , by transmitting the activation code to the DCC via wireless communications), or via a separately provided activation code entry port (not shown). As another alternative, the memory 1 15 may utilize a combination of permanent and downloaded programs so that some programs are initially provided with the DCC and other programs can be loaded in later, either in their entirety or via activation by an activation code. When the aforementioned IBM POWER PC 400 microprocessor is used for the controller 119, it is recommended that the programs be written in the IBM JAVA programming language.

The memory 115 is contemplated to generally have 64 KB-1.5MB capacity, though capacities may grow in the future if need arises and as higher capacities become less expensive. Exemplary forms of memory 1 15 are a battery-backed static random access memory (SRAM), and a 512 KB SRAM has been found to work well in the DCC illustrated in FIG. 3. Alternate exemplary embodiments utilize an electrically erasable programmable read only memory (EEPROM) to allow downloading, erasure, and upgrading of programs. The memory 1 15 may have space allocated for data storage so that data from the vehicle 70 or I/O ports 121 , 123, and 125 may be stored and later downloaded to an I/O port.

As noted above, the DCC can have specific types of aftermarket products (or portions of these products) hardwired or integrated directly into the DCC. As one example, FIG. 3 illustrates a global positioning system (GPS) module 132 and a cellular module 133 connected to the controller 1 19 via leads 130 and 131. The GPS module 132 and cellular module 133 are optional features which could be added at I/O ports 121 , 123, and 125, but which are instead provided by dedicated circuits in FIG. 3. The GPS module 132 can receive location data from a satellite and relay it to the controller 119 for processing (if necessary) and output to one or more of the vehicle 70 (e.g. , the instrument panel), a device provided at an I/O port 121 , 123, or 125, or to memory 115. A particularly preferred GPS module is provided by the Philips S A 1570 and SCI 575 chip sets. The cellular module 133 can be configured for personal communications or for remote data transmission. As an example, if the cellular module 133 is intended for use in remote data transmission, the cellular module 133 might communicate data from any or all of leads 54-69, an I/O port 121 , 123, or 125, or from another device (e.g. , the GPS module 132) to a remote data receiving device. A separate cellular telephone for personal communication might be provided by simply plugging it into any one of the I/O ports 121, 123, and 125; alternatively, one of these ports can be equipped with a cellular handset or other input/output device so that a cellular telephone is formed when used in conjunction with the cellular module (transceiver) 133. The crystal 1 10, clock 1 12, and associated leads 1 1 1 and 1 13 are other optional components which are recommended for hardwiring into the DCC due to their high utility. The clock 112 is a real-time clock which is connected to the controller 119 to provide a time signal to the I/O ports 121 , 123, and 125, the vehicle 70, or to another device (e.g. , the cellular module 133). For example, the clock 1 12 could be used to add a date/time stamp or a time display to the vehicle 70 display or a device at an I/O port

121 , 123, or 125. For example, the clock 1 12 can help to apply the TTI (Transmit Terminal Identification) stamp to facsimiles processed by the controller 1 19 and delivered via the cellular module 133.

The embodiment described above wherein the GPS module 132 and cellular module 133 are permanently connected to the controller 119 deserves special mention. It is believed that GPS and cellular features, when taken alone or together, are particularly useful in a DCC. However, the majority of currently available off-the-shelf GPS and cellular modules require their own dedicated microprocessors. As a result, it initially appeared that the addition of both GPS and cellular features to a DCC would result in a relatively expensive unit since three controllers would be required (one in the DCC and one in each of the GPS and cellular modules), and controllers are relatively expensive components. The alternative was to provide a more powerful controller in the DCC, one which could drive all of the cellular module, the GPS module, and any other aftermarket products installed at the I/O ports; however, the cost of such a controller is currently prohibitive. It was then discovered that GPS and cellular chips could be made to share a controller to form an integrated GPS/cellular module, which is then permanently connected to the DCC controller 1 19 or mounted thereon in the form of a card or the like. This arrangement has been found to have extremely favorable cost with little or no difference in performance compared to the embodiment wherein the GPS and cellular modules each include their own controller. Of course, as future developments result in increased controller capacity at decreased cost, at some point it may be cost-effective to have the controller of the DCC provide all of the processing functions for all of the products connected thereto.

As discussed above, some aftermarket products can be provided entirely by the DCC alone if the DCC includes programs which duplicate the functionality of such products. A vehicle diagnostics status recorder is a simple example of a product which can be entirely provided by the DCC. To provide the status recorder, the DCC need only make a running record of the status of the vehicle electronics in the memory 1 15. The programs can record and erase the data in first-in, first-out order to conserve memory. Another product which could easily be wholly replaced by programs in the DCC is an automotive security system. Where the door lock lead 55 triggers electronic door locks, the DCC programs may easily be configured to lock the vehicle doors upon the occurrence of certain events. In that case, no hardware need be plugged into the I/O ports 121, 123, and 125; the entirety of the security system is provided by the DCC.

Of course, it is understood from the discussion above that the DCC can simply provide a portion of the functionality of certain aftermarket products, with the remainder of the functionality being provided by components installed at the I/O ports 121 , 123, and

125. For example, with the aforementioned diagnostics status recorder, a secondary memory (e.g. , a personal computer, or more simply semiconductor memory devices, magneto-optical memories, etc.) could be plugged into an I/O port 121 , 123, or 125 to allow greater or permanent storage capacity for the data gathered by the DCC. Similarly, the DCC security system may have a peripheral security product (e.g. , a receiver for a radio frequency DALLAS key) at an I/O port so that the DCC programs plus the peripheral product form the complete security system. It is apparent that the DCC can perform all, some, or none of the functions of aftermarket products: it can be programmed to entirely replace products; to provide a part of the functionality of products so that less hardware components are needed at the I/O ports; or to merely function as an open circuit with a desired switching configuration and/or desired gain/attenuation between the vehicle electronics and one or more I/O ports. All of these choices are possible if properly-configured programs are provided in the DCC.

With reference to FIG. 4, the installation and operation of exemplary aftermarket products within the DCC will now be described. FIG. 4 illustrates the connection of a global positioning system (GPS), a cellular telephone, and a personal computer to the DCC. Each of these will be discussed in turn.

The GPS requires a power supply and a data output port in order to communicate with the vehicle. The GPS can be rapidly plugged into an I/O port, and the appropriate program (or access code) can be loaded into the memory of the DCC to allow communication with the vehicle. For example, with reference to the block diagram of FIG. 1, the POWER-POS, POWER-GND, and DATA IN leads of an I/O port can be activated by the controller to provide the GPS with power and a means for delivering data. The controller can then deliver this data to the vehicle electronics, and four of the unoccupied vehicle electronics leads, e.g. , A, B, C, and D, could form north, south, east, and west indicators to function as a compass on the dash of the vehicle. The controller could additionally or alternatively deliver the data to a different I/O port, or to a hardwired feature such as the cellular module 133 of FIG. 3 so that the data can be transmitted to a remote location. In any of these cases, the programs in. the memory of the DCC provide the proper signal conditioning and switching algorithms to the DCC so that data, power, etc. are appropriately routed and enabled, and so that the desired functionality is achieved.

The cellular telephone illustrated in FIG. 4 may simply require connection to the POWER-POS and POWER-GND leads of the I/O port so that it has a power supply. In this case, the program or access code entered into the DCC would simply have the controller complete a connection between the vehicle battery and ground and the POWER-POS and POWER-GND connections, plus providing any signal conditioning required for operation. Alternatively, if the cellular telephone requires an antenna, it can also be connected to one of the CTS (cellular telephone service) or RTS (radio telephone service) communication leads, which are then connected to an antenna, e.g. , the antenna port 108 illustrated in FIG. 3.

The personal computer may plug into an I/O port in connection with the DATA IN and DATA OUT ports illustrated in FIG. 1 , and additionally to the POWER-POS and POWER-GND ports if the computer requires a power supply. Provided the appropriate program or access code is entered in the DCC memory, the personal computer can then perform functions such as recording data from any one or more of the vehicle's leads (54-69 in FIG. 1); serving as a display for DCC program output; and so on.

Depending on the programs loaded into the DCC, a particular aftermarket product can be made to provide a far greater range of functions when connected to the DCC than the range of functions the product would provide when taken alone. As an example, consider the case where a DCC is installed in a vehicle between the vehicle's system diagnostics port and a cellular module. It is a relatively simple matter for a programmer of ordinary skill to develop programs for having the DCC receive diagnostic data from the diagnostics port (such data having a format in accordance with the vehicle manufacturer's chosen diagnostic data protocol, e.g. , EEC-IV or MCU) and convert it into a standard telephony data transmission format (e.g. , CCITT - Consultative Committee for International Telegraphy and Telephony or ITU/TS - International Telecommunications Union/Telecommunications Sector standards) so that it may be delivered to a remote location via the cellular module. There are then a near-infinite number of potential program options depending on when, why, and how one wishes to effect such delivery. As a first example, the program could be configured so that the DCC's detection of vehicle airbag deployment can cause the execution of a routine which determines vehicle location by use of GPS technology and then automatically delivers a voice message relaying the vehicle location to authorities via a cellular telephone call to 91 1 or other emergency number. As a second example, the program can be configured to allow vehicle manufacturers or servicers to remotely determine vehicle diagnostics via a cellular telephone call, thereby allowing convenient vehicle warranty checkups and malfunction diagnosis. As a third example, the program can also apply G3 (Group 3) facsimile processing algorithms to the examples noted above so that the message delivered to authorities or vehicle manufacturers/servicers is delivered in the form of a facsimile transmission. From these examples, it will be appreciated that for any one or more products connected to the DCC, the use of different programs can provide for a wide variety of different functions.

The foregoing discussion described the exemplary installation of the DCC within a vehicle. It is important to note that the use of the DCC is not limited to vehicles, and the DCC can be used with a wide variety of other products. In this case, the input leads from the vehicle in the Figures discussed above are simply replaced with input leads from the product in question. Alternatively, rather than connecting the DCC to the product in question via "hardwiring," the product in question could simply be connected to a DCC I/O port to allow it to communicate with products connected at other I/O ports. While the DCC could conceivably be installed in other products as well, it is contemplated that the DCC will achieve particularly high utility when installed in mobile or portable products, e.g. , vehicles and laptop computers. To illustrate, a DCC could be installed within or otherwise connected to wireless telecommunications devices within a laptop computer to allow wireless modem/fax capabilities. GPS could also be incoφorated to allow tracking of the computer for theft protection or other puφoses.

In this disclosure, the various existing and proposed programs for use in the DCC have not been described in great detail because one of ordinary skill in the art can readily develop such programs without undue experimentation when given this disclosure, the specifications of the product(s) to be attached to the DCC, and a description of the function(s) to be performed. Regarding product specifications, some aftermarket products communicate in well-known data formats, e.g., in flat ASCII format, whereas others communicate in proprietary formats requiring specially-designed translation programs to enable the DCC to allow them to communicate with other products. In either case, the development of a program for allowing the communication of two or more products is well within the capabilities of an ordinarily skilled programmer provided the data formats of the product in question are already known, or are discernible through the exercise of I/O analysis. Conveniently, the manufacturers of most data-utilizing products suitable for use in the DCC will upon purchase or request provide the details of the power, communications, and data I/O protocols used by the products. As an example. Philips Application Note AN96093 provides a description of the protocols used by the Philips EXACT GPS module, and specifications are also available for the individual components of the module if further information is needed. Some manufacturers provide not only the details of their data formatting, but also provide software development tools to promote the development of applications for use with their products. To illustrate, Etak (Menlo Park, CA. USA) provides geographic databases which may be combined with GPS systems to provide, for example, navigation and routing tools. These databases are available in a variety of media and data formats, and are provided with software development tools for use in exploiting these databases.

It is understood that preferred embodiments of the invention have been described above in order to illustrate how to make and use the invention. The invention is not intended to be limited to these embodiments, but rather is intended to be limited only by the claims set out below. Thus, the invention encompasses all alternate embodiments that fall literally or equivalently within the scope of these claims. In these claims, any means plus function clauses are intended to encompass the structures described above as performing their recited function, and also both structural equivalents and equivalent structures. As an example, though a nail and a screw may not be structural equivalents insofar as a nail employs a cylindrical surface to secure parts together whereas a screw employs a helical surface, in the context of fastening parts, a nail and a screw are equivalent structures.

Claims

CLAIMSWhat is claimed is:

1. An apparatus comprising: a. a plurality of ports, each including a port data lead; b. a controller inteφosed between the ports, the controller being capable of providing selective connection between the port data leads; and c. a memory in operative connection with the controller, the memory having a program therein actuating the controller to provide connections between selected port data leads, thereby allowing data- utilizing products installed in connection with the selected port data leads to communicate, the apparatus being installed within a vehicle.

2. The apparatus of claim 1 wherein the program further converts the format of the data to a different format.

3. The apparatus of claim 1 wherein at least one port further includes a power lead.

4. The apparatus of claim 1 wherein at least one port further includes a telecommunications lead.

5. The apparatus of claim 1 wherein the controller is in connection with vehicle data leads and is capable of providing connection between the vehicle data leads and selected port data leads.

6. The apparatus of claim 5 wherein the vehicle data leads are connected to the controller by connecting them to port data leads at one or more ports.

7. The apparatus of claim 1 further comprising a secondary memory connected to port data leads at one port, the secondary memory thereby being accessible by the controller.

8. The apparatus of claim 1 further comprising at least one dedicated port, each dedicated port including no more than two types of leads chosen from the following types of leads: data leads, power leads, and telecommunications leads.

9. The apparatus of claim 1 further comprising a signal conditioner between the controller and at least one port.

10. The apparatus of claim 9 further comprising power leads at one or more ports, the power leads being in connection with the signal conditioner.

11. An apparatus comprising: a. a controller; b. vehicle data leads connected to the controller; c. a plurality of ports, each port including a port data lead connected to the controller; d. a memory associated with the controller, the memory having a program therein actuating the controller to provide predetermined connection arrangements between data leads, allowing data communication therebetween.

12. The apparatus of claim 11 wherein the program further actuates the controller to translate the format of the data to a different format.

13. The apparatus of claim 11 wherein the vehicle data leads are connected to the controller at a port wherein the vehicle data leads are connected to port data leads.

14. The apparatus of claim 11 further comprising a signal conditioner between the controller and at least one port.

15. The apparatus of claim 14 wherein at least one port further includes a port power lead connected to the signal conditioner.

16. The apparatus of claim 11 wherein at least one port further includes a port telecommunications lead connected to the controller.

17. The apparatus of claim 11 further comprising at least one dedicated port including one of power leads and telecommunications leads.

18. The apparatus of claim 11 further comprising a secondary memory installed at one port in communication with the port data leads.

19. An apparatus comprising: a. a vehicle including vehicle data leads in connection with vehicle components; b. at least two ports, each port including a port data lead adapted for connection to a data-utilizing product; c. a controller connected to the vehicle data leads and port data leads and being capable of providing selective connection therebetween; d. a memory in operative connection with the controller, the memory having a program therein actuating the controller to provide connections between the vehicle data leads and selected port data leads.

20. The apparatus of claim 19 wherein the vehicle data leads are connected to the controller by connecting them to port data leads at one or more ports.

21. The apparatus of claim 19 wherein at least one port further includes a power lead.

22. The apparatus of claim 19 wherein at least one port further includes a telecommunications lead.

23. The apparatus of claim 19 further comprising at least one dedicated port, each dedicated port including at least one but not more than two types of leads chosen from the following types of leads: data leads, power leads, and telecommunications leads.

24. The apparatus of claim 19 further comprising a signal conditioner between the controller and at least one port.

25. The apparatus of claim 24 further comprising power leads at one or more ports, the power leads being in connection with the signal conditioner.

26. The apparatus of claim 19 further comprising a signal conditioner between the controller and the vehicle data leads.

27. The apparatus of claim 19 further comprising a secondary memory connected to port data leads at one port.

28. The apparatus of claim 19 wherein the program further translates the format of the data to a different format.