Patent Application
20170324844
The invention generally relates to vehicle intra-communication systems and, more particularly, the invention relates to managing data traffic on an internal vehicle communication system.
Automobile onboard diagnostics (a/k/a OBD, OBD II, OBD 2) provide an interface for various entities, such as dealers, mechanics and third parties (e.g., insurance companies or mobile application providers) to access internal computer systems. Among other things, those internal computer systems may have vehicle information, such as speed, temperatures, vehicle type, etc., that such entities may retrieve and process. Entities accessing these computer systems typically use an external device to recover the requisite information.
Undesirably, prior art techniques for accessing such information can adversely affect operation of one or more features on the vehicle. For example, a device accessing this information may disable important features, such as E911 assist, and less important features, such as information-entertainment functions. Such devices used in this manner also have the potential to 1) introduce stalling, 2) cause check engine lights or other warning indicators to illuminate, 3) set diagnostic trouble codes, and 4) impact other vehicle functionality.
In accordance with one embodiment of the invention, a method and apparatus manage data traffic in a vehicle controller area network having a plurality of functional modules. To that end, the method and apparatus passively receive data messages transmitted across the controller area network of the vehicle. The data messages are formatted in one of a plurality of proprietary protocols. Next, the method and apparatus determine the protocol of the data messages transmitted across the controller area network. The determined protocol is one of the plurality of proprietary protocols.
After determining the protocol, protocol logic is controlled to translate the data messages (transmitted across the controller area network) from the determined protocol to a given protocol. The protocol logic thus is configured to translate the data messages from any of the plurality of proprietary protocols into the given protocol. The method and apparatus then transmit the data messages, in the given protocol, onto the controller area network for use by at least one of the functional modules.
The method and apparatus may passively receive the messages in a manner that does not forward a request for the data messages across the controller area network. Alternatively or in addition, the process of passively receiving the messages during normal vehicle operation may involve receiving messages without inhibiting the execution of the functions performed by the functional modules (during normal vehicle operation). Among other things, the functional modules may include engine control units.
The protocol logic may translate no more than a sub-set of the plurality of data messages transmitted across the control area network. In a similar manner, the data messages may be transmitted by a) determining a sub-set of data messages to transmit in the controller area network in the given protocol, and b) transmitting the sub-set of data messages in the controller area network in the given protocol.
Some embodiments may passively receive data messages via an on-board diagnostics port of the controller area network. For example, the protocol logic may include a dongle coupled with the on-board diagnostics port. Alternatively or in addition, the protocol logic may be hard-wired directly to the controller area network. Among other types, the vehicle may be an automobile, and the plurality of proprietary protocols may include a first proprietary protocol of a first automobile company, and a second proprietary protocol of a second automobile company.
An after-market party may install the apparatus and/or engage in the process of managing the data messages. To that end, an after-market party may couple the protocol logic to the vehicle to receive the data messages. As such, the vehicle is fully manufactured before the after-market party couples the protocol logic to the vehicle. Moreover, to provide further functionality, the data messages may be transmitted, in the given protocol, to an off-network apparatus having program code configured to cooperate with the at least one functional module. For example, the program code may control the functional module as a function of the data messages.
In accordance with another embodiment, an apparatus for managing data traffic in a controller area network of a vehicle with a plurality of functional modules includes a CAN interface configured to passively receive data messages transmitted across the controller area network on the vehicle. The data messages are formatted in one of a plurality of proprietary protocols. The apparatus also has 1) a protocol selector configured to determine the protocol of the data messages transmitted across the controller area network, 2) a first translation module (operatively coupled with the protocol selector) configured to translate the received data messages from a first proprietary protocol to a common given protocol, and 3) a second translation module (operatively coupled with the protocol selector) configured to translate the received data messages from a second proprietary protocol to the common given protocol. The first proprietary protocol preferably is different from the second proprietary protocol. The CAN interface is configured to transmit the data messages, in the common given protocol, onto the controller area network for use by at least one of the functional modules on the controller area network.
Illustrative embodiments of the invention are implemented as a computer program product having a computer usable medium with computer readable program code thereon. The computer readable code may be read and utilized by a computer system in accordance with conventional processes.
Those skilled in the art should more fully appreciate advantages of various embodiments of the invention from the following “Description of Illustrative Embodiments,” discussed with reference to the drawings summarized immediately below.
In illustrative embodiments, a data monitoring device passively monitors and translates data messages transmitted within a vehicle network (e.g., a controller area network) for use by other portions of the vehicle network. To that end, the device determines the protocol of the data messages, and then translates those messages from the determined protocol to another protocol or format that is usable by the other portions of the vehicle network (e.g., a module controlling the exhaust system). Importantly, by passively monitoring the messages, preferred embodiments of the data monitoring device do not interrogate other network components/devices, interrupt the functionality of other network components/devices, send requests for data messages, or actively interact with other network components/devices to obtain the data messages. Instead, the device simply “listens” to the data traffic in the network. Details of illustrative embodiments are discussed below.
To those ends, the network 10 of
The network 10 shown in
The functional module labeled “other 18” may represent any of a wide variety of other functional modules. For example, this additional functional module may represent one or more similar or disparate functional modules, such as a computer or processor. As another example, the other module may also include a valve controller that controls the flow of exhaust gasses through the internal automobile exhaust system. For more information regarding this valve controller, see co-pending U.S. patent application Ser. No. 14/797,791, incorporated above.
In a manner similar to other controller area networks, the network 10 of
As a physical component, the onboard diagnostic connector 20 preferably has a standardized interface for receiving a complementary device. For example, the onboard diagnostic connector 20 may connect to a coupling mechanism at the end of a harness extending from a large engine testing computer system. As another example, the onboard diagnostic connector 20 may connect to a unitary, self-contained portable device, such as a dongle.
As known by those skilled in the art, a dongle typically is a small, hand-held device that can be configured to perform any of a wide variety of functions. Insurance companies often use dongles in this manner to monitor driver habits. Undesirably, prior art dongles used for these purposes typically send request messages or otherwise interrogate various specific functional modules 14 and/or 18 within the controller area network 10 to receive their required information. In addition, further compounding problems, these prior art dongles also can reduce or interfere with functionality of other important modules in the network 10. For example, some of these dongles can turn off emergency 911 call-out functionality, unnecessarily illuminating hazard lights, or prevent hazard lights from illuminating.
Recognizing these problems, the inventors developed the noted traffic monitor 12, which passively monitors network data traffic without requesting data or interfering with the functions of other modules 14 and 18 in the network 10.
Other embodiments, however, may connect to the network 10 in other ways. For example, the traffic monitor 12 may simply transmit selected network data off-network, or to another device using wireless technology (e.g., satellite transmission, Bluetooth, WiFi, etc.).
The traffic monitor 12 preferably enables entities that are not related to the manufacture of the vehicle access to the data. These entities often are called “aftermarket” entities, which often add or augment components or functionality to an already produced or manufactured vehicle. As known by those skilled in the art, aftermarket parts or components are not sourced from the vehicles manufacturer. For example, an aftermarket company or aftermarket service person could add an aftermarket exhaust control system like that described in the incorporated patent application.
As noted above, the traffic monitor 12 passively listens to data traffic in the network 10. To that end, the traffic monitor 12 has an interface 22 for sending and receiving data to and from the network 10, which includes passively listening to the network data traffic. As an aftermarket product, illustrative embodiments of the traffic monitor 12 are not necessarily custom-made for one particular type of vehicle. Specifically, different vehicle manufacturers commonly each have their own proprietary protocol or format for communicating information relating to operation of the vehicle. Accordingly, the traffic monitor 12 has a plurality of modules that each are capable of reading and understanding at least one such proprietary protocol.
More particularly, the traffic monitor 12 has a plurality of translators (generically identified by reference number “26”) that each are configured to understand at least one proprietary protocol, and translate information from that proprietary protocol to a common protocol. For example, Translator 1 may be configured to translate the FORD™ protocol to the common protocol, while Translator 2 may be configured to translate the GENERAL MOTORS™ protocol to the same common protocol. Those skilled in the art with knowledge of the proprietary protocol can use conventional translation techniques to make those translations. As discussed below with respect to
As known by those skilled in the art, there are different types of protocols. One type of protocol may simply specify the format that messages or forwarded through the network 10 (a “transmission” protocol), while another protocol may specify the meaning of the data transmitted in the various messages across the network 10 (a “data” protocol). Accordingly, in some embodiments, for received messages, a given translator 26 may translate/decode the messages using first the transmission protocol (e.g., Ethernet) to produce the data encoded in the data protocol. Next, the given translator 26 may then translate/decode the data parsed from the messages. Then, as discussed below with regard to
Many modern automobiles, however, have a common transmission protocol. Accordingly, each translator 26 may use the same transmission protocol decoding technique, but use different, proprietary data protocol decoding techniques to decode the data in the messages. For example, Translator 1 may use a decoding technique common to five automobile manufacturers for decoding the messages (i.e., based on the transmission protocol), but use a single automobile manufacture decoding technique for reading the data in the message.
The traffic monitor 12 thus also has a selector 30 that determines the appropriate translator 26 based upon the message traffic. Indeed, it should be noted that
Those skilled in the art should understand that the traffic monitor 12 may have many other physical and functional components, such as short-term and long term memory for locally storing translated data messages, a modem or transmitter for wirelessly transmitting translated data, and microprocessors providing further functionality. Accordingly, this discussion in no way suggests that
The process begins at step 400, which couples the traffic monitor 12 with the network 10. For example, when using a dongle form factor, the traffic monitor 12 may be connected through the onboard diagnostic connector 20 (
The process continues to step 402, which determines the protocol of the network 10. As noted above, the network 10 is part of a vehicle produced by a specific vehicle manufacturer that encodes its network traffic using its own proprietary protocols. Accordingly, the selector 30 determines the proprietary protocol used by the vehicle. Those skilled in the art can use any of a number of techniques for doing so. For example, the selector 30 may intercept/receive and parse data traffic to determine the proprietary protocol. As a second example, the selector 30 may engage in some other “handshake” initialization processes with other functional modules in the network 10 to determine the proprietary protocol. For example, when the vehicle starts, the controller 28 may interact with a functional module of the network 10 to determine the required information. In fact, the selector 30 may be configured to execute a series of different techniques until it is able to determine the appropriate protocol for the vehicle.
After determining the proprietary protocol, the selector 30 selects one of the plurality of translators 26 (step 404), and then enables the selected translator 26 to translate messages from the proprietary protocol to a common protocol (step 406). In illustrative embodiments, after decoding the messages and their data, the selected translator 26 encodes the decoded data into a single, common protocol. The selected translator 26 may translate all of the messages it intercepts in the network 10.
In other embodiments, however, the selected translator 26 may be configured to translate only selected messages in the network 10. For example, when used with the exhaust controlling module of the incorporated patent application, the translator 26 may be configured to translate messages relating only to parameters required by the exhaust valve controller module. Among others, those messages may include information relating to throttle position, speed, etc.
Those skilled in the art can select from any of a variety of types of messages or messages carrying selected types of data. Of course, in a manner similar to the valve controller example noted above, the type of data selected depends on the use of that data. Without limitation, that type of data may include one or more of:
Accordingly, the controller 28, selector 30, and/or the translators 26 may be configured to selectively translate the data messages that the traffic monitor 12 passively receives.
The process concludes at step 408, in which the controller 28 transmits messages to the network 10 for use by other functional modules that understand the common protocol. For example, the controller may transmit the translated messages to the valve controller of the incorporated patent application. Those specific messages may include speed and throttle position information encoded in the common protocol. The valve controller may decode these messages and use this information to control the position of its exhaust valve.
Some embodiments may simply transmit all translated data messages (e.g., if only selected data messages were translated), or transmit selected translated data messages (e.g., if more data messages than required were translated). Other embodiments, however, may translate the data messages to off-network devices, such as to the Internet, a server or storage device across the Internet, to a cloud service, or to a computer system executing an application program. For example, a user may have an application executing a graphical user interface that displays charts and data obtained by the traffic monitor 12. In fact, this application may enable a user to control various functional modules in the network 10 as a function of the obtained data.
Rather than directly transmitting the translated data messages, some embodiments may simply broadcast the translated data messages to the network 10. Accordingly, functional modules in the network 10 may read or ignore the incoming translated data messages.
Various aftermarket implementations may be produced as a kit, having the traffic monitor 12 and necessary equipment configured to couple the traffic monitor 12 to the network 10. Accordingly, a technician or other skilled person may use the components in the kit to couple the traffic monitor 12 with the controller area network 10.
Illustrative embodiments therefore permit the traffic monitor 12 to couple with the controller area network 10 of any of a variety of different types of vehicles. Moreover, by passively receiving data traffic across the network 10, the traffic monitor 12 does not significantly add to network congestion or interfere with the operation of other functional modules in the network 10.
Various embodiments of the invention may be implemented at least in part in any conventional computer programming language. For example, some embodiments may be implemented in a procedural programming language (e.g., “C”), or in an object oriented programming language (e.g., “C++”). Other embodiments of the invention may be implemented as a pre-configured, stand-along hardware element and/or as preprogrammed hardware elements (e.g., application specific integrated circuits, FPGAs, and digital signal processors), or other related components.
In an alternative embodiment, the disclosed apparatus and methods (e.g., see the various flow charts described above) may be implemented as a computer program product for use with a computer system. Such implementation may include a series of computer instructions fixed either on a tangible, non-transitory medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk). The series of computer instructions can embody all or part of the functionality previously described herein with respect to the system.
Those skilled in the art should appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Furthermore, such instructions may be stored in any memory device, such as semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, microwave, or other transmission technologies.
Among other ways, such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the network (e.g., the Internet or World Wide Web). In fact, some embodiments may be implemented in a software-as-a-service model (“SAAS”) or cloud computing model. Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments of the invention are implemented as entirely hardware, or entirely software.
Although the above discussion discloses various exemplary embodiments of the invention, it should be apparent that those skilled in the art can make various modifications that will achieve some of the advantages of the invention without departing from the true scope of the invention.
This patent application claims priority from provisional U.S. patent application No. 62/331,050, filed May 3, 2016, entitled, “METHOD AND APPARATUS FOR ACCESSING DATA TRAFFIC IN A CONTROL AREA NETWORK,” and naming Justin G. Schroeder as inventor, the disclosure of which is incorporated herein, in its entirety, by reference. This patent application is related to U.S. patent application Ser. No. 14/797,791, filed Jul. 13, 2015, entitled, “EXHAUST CONTROL SYSTEM,” and naming Erin M. Dmytrow, Ryan L. Martin, and Justin G. Schroeder as inventors, the disclosure of which is incorporated herein, in its entirety, by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62331050 | May 2016 | US |
