WO2008127247A1

WO2008127247A1 - Vehicle communication interface access management

Info

Publication number: WO2008127247A1
Application number: PCT/US2007/009251
Authority: WO
Inventors: Bryan P. Mcguan; Claus A. Kricke
Original assignee: Robert Bosch Gmbh
Priority date: 2007-04-13
Filing date: 2007-04-13
Publication date: 2008-10-23

Abstract

Methods and systems for managing communications in an automotive test network are disclosed. One method includes establishing a first session between a first application and a vehicle communication interface. The method also includes establishing a second session between a second application and the vehicle communication interface. The method further includes designating one of the first session and the second session as an active session.

Description

VEHICLE COMMUNICATION INTERFACE ACCESS MANAGEMENT

This application is being filed on April 13, 2007, as a PCT International Patent application in the name of Robert Bosch GmbH, a German national corporation, applicant for the designation of all countries except the US, and Bryan P. McGuan, a citizen of the U.S., applicant for the designation of the US only and Claus Kricke, a citizen of Germany, applicant for the designation of the US only.

Technical Field The present disclosure relates to automotive system testing and diagnostics.

More specifically, the present disclosure relates to managing communications in an automotive test network, such as by managing access to a vehicle communication interface.

Background Modern automobiles have multiple on-board computers which are interconnected via automobile-specific communications buses (ISO 9141, CAN, etc.). Diagnostic and reprogramming access to these on-board computers, commonly referred to as electronic control units ("ECUs") is provided by a vehicle communications interface ("VCI"). A VCI is typically a small, self contained computing system, designed to interface with automotive control systems. VCIs can work in conjunction with a personal computer, which can host diagnostic software for assistance in testing and calibrating an ECU, such as a diagnostic scan tool system which monitors data transmitted to the ECU.

The draft ISO22900-2 standard describes an approach to connecting many VCIs to a single personal computer ("PC"). However, there is no specification for connecting many PCs to a single VCI safely, such that the various PCs do not interfere with each other in communicating with the VCI. However, such a configuration is desirable in situations where a single PC programs many ECUs via VCI modules, while another PC maintains constant interaction with the same VCIs to perform the next production step in preparing the ECUs for use.

Therefore, improvements are desired. Summary

The above and other problems are solved by the following: In a first aspect, a method for managing communications in an automotive test network is disclosed. The method includes establishing a first session between a first application and a vehicle communication interface. The method also includes establishing a second session between a second application and the vehicle communication interface. The method further includes designating one of the first session and the second session as an active session.

In a second aspect, a system for managing communications in an automotive test network is disclosed. The system includes a vehicle communication interface including a first programmable circuit configured to execute program instructions. The system also includes a user interface device including a second programmable circuit configured to execute program instructions, the user interface device operatively connected to the vehicle communication interface. At least one of the first or second programmable circuits are configured to execute program instructions to: establish a first session between a first application and a vehicle communication interface; establish a second session between a second application and the vehicle communication interface; and designate one of the first session and the second session as an active session. In a third aspect, a method of managing communications in an automotive test network is disclosed. The method includes establishing a session between a first application executing on a user interface device and a vehicle communication interface. The method also includes designating the user interface device as an active session using a session manager executing on the vehicle communication interface. The method further includes establishing a second session between a second application executing on a second user interface device and the vehicle communication interface. The method also includes designating the second session as a passive session using a session manager executing on the vehicle communication interface.

Brief Description of the Drawings

Figure 1 shows methods and systems for managing communications in an automotive test network according to a possible embodiment of the present disclosure; Figure 2 shows a schematic of an exemplary system for establishing a communications session in an automotive test network, according to a possible embodiment of the present disclosure;

Figure 3 shows an exemplary computing environment with which various aspects of the present disclosure may be implemented;

Figure 4 shows an exemplary automotive test network in which aspects of the present disclosure may be employed;

Figure 5 shows a logical diagram of a portion of an automotive test network detailing the logical operations of a vehicle communication interface according to the present disclosure; ^■

Figure 6 shows a logical diagram of a portion of an automotive test network detailing the logical operations of a user interface device, according to a possible embodiment of the present disclosure;

Figure 7 shows methods and systems for managing communications at a vehicle communication interface in an automotive test network according to a possible embodiment of the present disclosure; and

Figure 8 shows methods and systems for managing communications at a user interface device in an automotive test network according to a possible embodiment of the present disclosure.

Detailed Description

Various embodiments of the present invention will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the invention, which is limited only by the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the claimed invention.

The logical operations of the various embodiments of the disclosure described herein are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a computer, (2) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a motor vehicle or vehicle test system; and/or (3) interconnected machine modules or program engines within the programmable circuits.

In general the present disclosure relates to methods and systems for managing communications in an automotive test network. The methods and systems disclosed allow a plurality of computing systems having user interfaces thereon, i.e. user interface devices, to connect to a single vehicle communication interface. The methods and systems disclosed likewise allow a plurality of vehicle communication interfaces to connect to a single user interface device. The systems and methods described provide an architecture that supports various usage scenarios of multiple computers interfaced to multiple vehicle communication interfaces, such as where a single PC, or user interface device, programs many ECUs via a VCI module, while another PC maintains constant interaction with the same VCIs to perform the next production step in preparing the ECUs for use.

Figure 1 shows methods and systems for managing communications in an automotive test network according to a possible embodiment of the present disclosure. The system 100 disclosed allows more than one session to be established between a vehicle communication interface and an application, as described more fully below. Operational flow instantiates at a start operation 102, which corresponds to initial setup of an automotive test network. An exemplary automotive test network is described below, in conjunction with Figure 4.

Operational flow proceeds to a session module 104. The session module 104 establishes a communication session between an application and a vehicle communication interface (VCI), such that the application can read and write data to an electronic control unit (ECU) in an automobile accessible through the VCI. A communication session refers generally to an established communication link between the software application and the vehicle communication interface; no specific protocol or network topology is dictated by the session. The various embodiments of the system 100 have been tested with sessions established via LAN, WiFi, USB, serial port, or other communications interface. In the various embodiments of the system 100, the application can reside on a user interface device, which can be any of a number of handheld or desktop computing devices, such as the one described below in conjunction with Figure 3. Similarly, the VCI can be an analogous computing system, and will additionally generally include one or more proprietary interfaces to vehicle control systems, such as those interfaces described in connection with Figure 2, below.

In certain embodiments of the session module 104, establishing a communication session between the application and VCI can include one or more precursor steps allowing the user interface device and the VCI to gain knowledge of the other devices communicatively connected within the automotive test network. For example, the user interface device or a third device may scan the automotive test network for active VCIs. The VCIs, in response, optionally identify themselves with a unique identifier, and can also optionally transmit the capabilities of that particular VCI to other systems within the network. The user interface device can initiate a request for a session on a desired VCI, which can in turn establish a provisional connection with the user interface device. Software resident on both the user interface device and the VCI, such as session management software configured to manage communications among a number of VCIs and user interface devices, can then confirm the connection.

In other embodiments of the session module 104, the communication session is established by the VCI, or by accessing a third computing device in the automotive network configured to manage communication sessions among various user interface devices and VCIs. In still other embodiments, the communication session uses more or fewer handshaking steps to establish a connection in the automotive test network.

Operational flow in the system 100 proceeds to a second session module 106. The second session module 106 operates analogously to the first session module 104, but operates in conjunction with a second application establishing a session with the same vehicle control interface as established during the first session module 104.

Operational flow proceeds to a session designation module 108, which designates one of the first and second sessions as the active session. The session designation module 108 can operate as a portion of a session manager, which is configured to ensure that various user interface devices communicate safely with a VCI. To ensure that communications from user interface modules do not interfere with each other, the session designation module 108 optionally also designates all other sessions as passive sessions. Alternately, an additional module designates other sessions as passive sessions, such as a remote session manager on a different computing system. An active session refers to an established communication link between an application and a VCI such that the application can both read and transmit data to the VCI which would affect operation or testing of the vehicle systems interfaced to the VCI. For example, an application may transmit instructions to the VCI for reprogramming an electronic control unit to which that VCI is interfaced. Conversely, a passive session refers to an established communication link between an application and a VCI such that the application can only read data from the VCI and corresponding vehicle electronics systems. A passive session cannot write data to the VCI or ECUs which would affect operation or testing of the vehicle electronics systems. For example, an application connected to a VCI in a passive session could read data within an ECU associated with the VCI, but could not transmit instructions to the VCI to reprogram the ECU, because other applications may be executing tests or reading data from the ECU concurrently.

Operational flow terminates at an end operation 110, which corresponds to completion of establishing connections in the system 100.

Optionally, additional modules may be incorporated into the system 100 to provide for disconnection and release of resources within the automotive test network. For example, modules configured to allow resources to be released, or to determine how and when to release a communication session may be implemented as well. Specific exemplary implementations of such modules are described below in conjunction with Figures 7-8.

Referring now to the system 100 as a whole, it is noted that the system 100 is general in that it is not dependent on any particular operating system. While the Microsoft Windows operating system is used in one embodiment of the present disclosure, this is solely because it is the predominant operating system of automotive shop computers; the methods and systems described herein have been tested on both Windows and Linux systems and have no internal restrictions as to application, e.g., on PalmOS, MacOS X, FreeBSD, or other common operating systems.

Figure 2 shows a schematic of an exemplary system 200 in which a communications session can be established, according to a possible embodiment of the present disclosure. The system 200 can form all or part of an automotive test network, and includes a PC 202, a VCI 204, and an ECU 206. The PC 202 can be any of a number of generalized personal computing systems, such as the one described below in conjunction with Figure 3. In a possible embodiment, the PC 202 is a user interface device, such as a handheld or desktop computing system capable of presenting information to a user and receiving user input in response.

The VCI 204 is also a generalized computing system, but may include one or more specialized interfaces to allow it to connect to one or more control systems of a motor vehicle, such as an ECU 206. The VCI 204 connects to the PC over one or more communication links 208a-c, shown as a USB link 208a, WiFi connection

208b, or wired Ethernet connection 208c. Other links are possible as well. The VCI 204 also connects to the ECU 206 via one or more specialized links 210, shown as a CAN link 210a, a FlexRay link 210b, a Jl 850 connection 210c, or a LIN connection 21Od. Other specialized vehicle communication links are possible as well. The ECU 206 generally executes one or more control functions related to systems in an automobile. Example ECU functions can include monitoring or controlling fuel distribution, exhaust systems, or other electrical or mechanical systems. The ECU can include one or more programmable logic units, and can communicate with the VCI via one or more of the communication links 210 previously mentioned, or some other standardized or proprietary vehicle communications system.

Referring now to Figure 3, an exemplary environment for implementing embodiments of the present disclosure includes a general purpose computing device in the form of a computing system 300, including at least one processing system 302. A variety of processing units are available from a variety of manufacturers, for example, Intel or Advanced Micro Devices. The computing system 300 also includes a system memory 304, and a system bus 306 that couples various system components including the system memory 304 to the processing unit 302. The system bus 306 might be any of several types of bus structures including a memory bus, or memory controller; a peripheral bus; and a local bus using any of a variety of bus architectures.

Preferably, the system memory 304 includes read only memory (ROM) 308 and random access memory (RAM) 310. A basic input/output system 312 (BIOS), containing the basic routines that help transfer information between elements within the computing system 300, such as during start up, is typically stored in the ROM 308.

Preferably, the computing system 300 also includes a secondary storage device 313, such as a hard disk drive, for reading from and writing to a hard disk (not shown), and/or a compact flash card 314.

The hard disk drive 313 and compact flash card 314 are connected to the system bus 306 by a hard disk drive interface 320 and a compact flash card interface 322, respectively. The drives and cards and their associated computer readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the computing system 300.

Although the exemplary environment described herein employs a hard disk drive 313 and a compact flash card 314, it should be appreciated by those skilled in the art that other types of computer-readable media, capable of storing data, can be used in the exemplary system. Examples of these other types of computer-readable mediums include magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, CD ROMS, DVD ROMS, random access memories (RAMs), read only memories (ROMs), and the like.

A number of program modules maybe stored on the hard disk 313, compact flash card 314, ROM 308, or RAM 310, including an operating system 326, one or more application programs 328, other program modules 330, and program data 332. A user may enter commands and information into the computing system 300 through an input device 334. Examples of input devices might include a keyboard, mouse, microphone, joystick, game pad, satellite dish, scanner, digital camera, touch screen, and a telephone. These and other input devices are often connected to the processing unit 302 through an interface 340 that is coupled to the system bus 306. These input devices also might be connected by any number of interfaces, such as a parallel port, serial port, game port, or a universal serial bus (USB). A display device 342, such as a monitor or touch screen LCD panel, is also connected to the system bus 306 via an interface, such as a video adapter 344. The display device 342 might be internal or external. In addition to the display device 342, computing systems, in general, typically include other peripheral devices (not shown), such as speakers, printers, and palm devices. When used in a LAN networking environment, the computing system 300 is connected to the local network through a network interface or adapter 352. When used in a WAN networking environment, such as the Internet, the computing system 300 typically includes a modem 354 or other means, such as a direct connection, for establishing communications over the wide area network. The modem 354, which can be internal or external, is connected to the system bus 306 via the interface 340. In a networked environment, program modules depicted relative to the computing system 300, or portions thereof, may be stored in a remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computing systems may be used.

The computing system 300 might also include a recorder 360 connected to the memory 304. The recorder 360 includes a microphone for receiving sound input and is in communication with the memory 304 for buffering and storing the sound input. Preferably, the recorder 360 also includes a record button 361 for activating the microphone and communicating the sound input to the memory 304.

A computing device, such as computing system 300, typically includes at least some form of computer-readable media. Computer readable media can be any available media that can be accessed by the computing system 300. By way of example, and not limitation, computer-readable media might comprise computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing system 300.

Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media. Computer-readable media may also be referred to as computer program product.

Referring now to Figures 4-6, aspects of an exemplary automotive test network are shown. Figure 4 shows an overall logical organization of an exemplary automotive test network 400 in which aspects of the present disclosure may be employed. The automotive test network 400 includes a plurality of PCs 402a-c and a plurality of VCIs 404a-d, with each VCI connected to a corresponding vehicle system 406, such as an ECU. The interconnections between the PCs, VCIs, and ECUs are described above in conjunction with Figure 2. In the configuration shown, one of the VCIs 404c establishes a communication session with two of the PCs 402b, 402c. In the embodiment shown, the VCI 404c establishes a first communication session with a PC 402b, and a second communication session with PC 402c with client applications 403 a-b, respectively. The client applications 403a-b are software programs resident on the PCs 402b-c configured to access data in the vehicle systems 406 or VCIs 404a-d. Other connections between the various PCs 402a-c and VCIs 404a-d are possible as well; also, more or fewer PCs or VCIs could be incorporated into the network 400.

Optionally, one of the PCs, in Figure 4 shown as PC 402a, can be configured as a VCI identification server 405. In such an embodiment, the PC 402a with the identification server 405 may be configured to scan the VCIs 404a-d upon initialization of the automotive test network. The VCIs 404a-d respond to the scan by providing a unique identifier to the PC 402a, and optionally by also providing information related to the capabilities and resources that are available via each of the VCIs. This information is provided to the client applications 403a-b on the PCs 402b-c establishing a session. The order in which this is accomplished is described in more detail in conjunction with Figures 5-8, below.

In the embodiment shown, the PC 402b that establishes a communication session is physically separate from the PC 402a configured as a VCI identification server 403. In a further embodiment, the VCI identification server 405 resides on the same computing system that is establishing the communication session, and can reside in each of the PCs configured to connect to the VCIs 404a-d.

Figure 5 shows a logical diagram of a portion of an automotive test network 500 detailing the logical operations of a vehicle communication interface 504 according to the present disclosure. The automotive test network 500 that is shown corresponds generally to the connected elements of the network 400 of Figure 4, with a single VCI connected to a plurality of PCs. In the embodiment shown, a plurality of PCs 502a-b are shown as interfaced to a single VCI 504, which is in turn interfaced with an automotive system 506, such as an ECU or other vehicle subsystem. The interface between the VCI 504 and the automotive system 506 can be any of a number of types of interfaces to automotive systems, as mentioned above in conjunction with Figure 2.

Each PC 502a-b includes an application 503a-b, respectively, which is a user interactive software application allowing the user to view or control data within the automotive system 506 or VCI 504, respectively. Additionally, as previously discussed, either a separate or integral VCI identification server 505 (both of which are shown in Figure 5) tracks the VCIs present in the network 500, as well as the capabilities and resources of each VCI. When one of the PCs 502a-b establishes a connection with a VCI 504, the VCI identification server 505 provides the information related to the capabilities of the VCI to the PC, such that the application 503a-b on that PC accesses and uses the capabilities of the VCI accordingly.

A session manager 508 executes on the VCI 504, and manages a plurality of sessions 510a-b. The sessions 510a-b include the connection information for use in conjunction with corresponding applications 503a-b, so as to define connection parameters and data access and writing privileges of the applications 503a-b. In one embodiment, the session manager 508 denotes one of the sessions 510a-b as an active session and denotes the other session(s) as passive sessions. The session manager 508 can also manage disconnection of sessions, as well as management and reallocation of VCI and automotive system resources. The active session allows its corresponding application to both read from and write to the VCI 504 and automotive system 506, while the remaining sessions, being passive sessions, can only read from the VCI 504 and automotive system 506. By allowing only one session to be active and only one application to alter operation of the VCI and/or automotive system, the session manager 508 ensures that the various PCs 502a-b can connect to the VCI 504 safely, i.e. without causing data collisions at the VCI or automotive system. In a further embodiment, the session manager 508 manages the number of applications allowed to connect to a single VCI 504, as dictated by bandwidth between the PCs 502a-b and the VCI 504, or more frequently, the bandwidth limitation posed between the VCI 504 and the automotive system 506.

Figure 6 shows a logical diagram of a portion of an automotive test network detailing the logical operations of a user interface device, according to a possible embodiment of the present disclosure. The automotive test network 600 that is shown corresponds generally to elements in the network 400 of Figure 4, with communication sessions established between a single application and a plurality of vehicle communication interfaces. The network 600 as shown operates in a complementary manner to the one shown in Figure 5, as it provides connectivity from a single application on a PC to multiple VCIs.

The network 600 as shown includes a PC 602 interconnected to a plurality of VCIs 604a-c. The PC 602 includes an application 603 running thereon, which provides a user interface to allow a user to access, read, and possibly modify data stored in a VCI 604a-c or a corresponding automotive system 606. An optional VCI identification server 605 interfaces with the application and provides an identification of the VCIs available in the network 600 as well as the capabilities and resources associated with each. Both the application 603 and VCI identification server 605 have been described previously.

The PC further includes a VCI session manager 608 operating thereon to manage multiple sessions 610a-c related to the same application 603 communicating with the various VCIs 604a-c. The VCI session manager 608 allows the application to read from or write to many sessions at once, and allows the application to establish an active session with many VCIs. However, if the application opens multiple sessions with the same VCI (as shown in session 610c-d corresponding to VCI 604c), only one of those sessions can be designated as the active session.

Additional configurations and interfaces for the session manager 608, application 603, and VCI identification server 605 are possible as well. Referring now to Figures 7-8, various methods and systems operating within the automotive test networks described above are shown. Figure 7 shows methods and systems for managing communications at a vehicle communication interface in an automotive test network according to a possible embodiment of the present disclosure. The system 700 is configured to manage one or more sessions established between applications executing on user interface devices and VCIs. The system 700 manages the communications in the session from the perspective of the vehicle communications interface, and can support connections from that user interface device to one or more applications executing on user interface devices. The system 700 is useable, for example, in the portion of the automotive test network described above in Figure 5, such as on a PC 502. In a possible embodiment, the system 700 is embodied, in part, in the session manager 508 or VCI identification server 505 of Figure 5.

Operational flow in the system 700 is instantiated at a start operation 702. The start operation 702 corresponds to initial setup and operation of an automotive test network, such as those described above in conjunction with Figures 4-6. Operational flow proceeds to a scan module 704. The scan module 704 scans the automotive test network, transmitting a request for each VCI to respond with a unique identifier. Optionally, the scan module 704 also requests a listing of the resources and capabilities available through each VCI. In one embodiment, the scan module executes on a VCI identification server, such as may be resident on one or more user interface devices, such as the PCs shown in Figures 4-6.

Operational flow proceeds to an identification receipt module 706. The identification receipt module 706 receives the information sent from each VCI in the automotive test network, in response to the request sent by the scan module 704^'. Operational flow proceeds to a VCI determination module 708. The VCI determination module 708 executes when a user interface device, such as a PC running one or more applications that interface with a VCI, is preparing to request that a session be opened to a VCI. The VCI determination module 708 submits a request from the user interface device to a VCI identification server which executes on that user interface device or an external device. The user interface device and corresponding application receive information related to the specific resources and capabilities of a VCI, as determined in the modules 704, 706, above. Operational flow proceeds to a session request module 710, which corresponds to the application on the user interface device requesting that a session be opened between that session and a VCI. In one embodiment, the session request is submitted from the application to a session manager in the VCI. In a further possible embodiment, the session request is submitted from the session manager in the user interface device, such as is shown in Figure 6, to a session manager in a VCI, as shown in Figure 5. Other configurations are possible as well.

Operational flow proceeds to a session confirmation module 712. The session confirmation module 712 corresponds to receiving a session request confirmation from the VCI, indicating that the session is successfully generated. The VCI can apply any of a number of tests to determine whether or not to confirm the session request and open the session, such as by determining available bandwidth between the VCI and corresponding automotive system, or other determination. Such determinations are transparent to the system 700 operating on a system seeking connection to the VCI, as such a system either does or does not receive a confirmation message based on the VCFs determination. The session confirmation module 712 optionally also transmits to the application an indication of whether that application has an active session or a passive session for connection to the VCI. Operational flow proceeds to a communication module 714. The communication module 714 corresponds to communication within the session, between the application resident on a user interface device and the VCI. The communication module 714 can, in various embodiments, correspond to read or read/write requests sent from the application to the VCI, depending upon whether the session is an active or passive session. In general, if the session is the first session established with a VCI, it will be denoted as an active session, while subsequent sessions with other applications (or the same application, as shown in Figure 6) may be treated as passive sessions.

Operational flow proceeds to an add session operation 716. The add session operation 716 determines whether an additional session is to be added, by determining whether a session request is pending. If no additional session is to be added, operational flow branches "no", returning to the communication module. If an additional session is to be added, operational flow branches "yes" and returns to the session request module 710 to allow a second session to be requested and instantiated. If this second session is requested and instantiated, it will generally be designated as a passive session by a session manager on either the user interface device or VCI to prevent conflicting data from being written to a VCI. When an application and its corresponding session with a VCI no longer requires a VCI resource to be maintained, operational flow proceeds to a resource release module 718. The resource release module 718 releases the resources reserved for that application and session, such as by updating the resources to be maintained in the session manager in either a user interface device or VCI, as related to the corresponding session. Operational flow proceeds to a session evaluation operation 720. The session evaluation operation 720 determines whether the resource to be released corresponds with a session that also is linked to other resources. If the session owns other resources, the session should stay open, and therefore operational flow branches "yes" to the communication module 714, corresponding to a session which is maintained in an open state. If no other resource corresponds with the session, the session is no longer needed, so operational flow branches "no" to an end operation 722. The end operation 722 corresponds to termination of a session on a PC, such as a user interface device. In this manner, the system 700 remains in the communication module so long as no additional sessions are opened or closed.

Figure 8 shows methods and systems for managing communications at a user interface device in an automotive test network according to a possible embodiment of the present disclosure. The system 800 is configured to manage one or more sessions established between applications executing on user interface devices and VCIs. The system 800 manages the communications in the session from the perspective of the user interface device, and can support connections from that user interface device to one or more VCIs. The system 800 is useable, for example, in the portion of the automotive test network described above in Figure 6, such as on the VCI 604. In a possible embodiment, the system 800 is embodied, at least in part, in the session manager 608 of Figure 6.

Operational flow in the system 800 is instantiated at a start operation 802. The start operation 802 corresponds to initial setup and operation of an automotive test network, such as those described above in conjunction with Figures 4-6. Operational flow proceeds to an identification request receipt module 804. The identification request receipt module 804 receives, such as from a VCI identification server or corresponding software on a PC, a request to identify the VCI on which the system 800 operates. The request also can optionally include a request for information about the resources and capabilities available to the VCI. Operational flow proceeds to an identification transmission module 806. The identification transmission module 806 transmits a unique identifier and optionally also transmits information about resources and capabilities of the VCI to the VCI identification server or other application from which the request was received in the request receipt module 804.

Operational flow proceeds to a connection establishment module 808. The connection establishment module 808 receives a connection request from an application residing on a user interface device or other PC, and establishes a provisional connection to that device. The connection establishment module 808 determines whether any previous connections have been established with the VCI, and determines the capability of the VCI to accept another connection. For example, the connection establishment module 808 can determine the number of existing connections to the VCI, and can determine whether available bandwidth exists between the VCI and the automotive system, such as by determining the timing and pendency of data requests and writes to the automotive system. The connection establishment module 810 also determines whether the new session will be an active session or a passive session. The connection establishment module 810 can denote the active session by, for example, making that session a master, with other sessions being passive. Other configurations are possible as well. Operational flow proceeds to a connection confirmation module 810, which generates and sends a confirmation message to the requesting application indicating that the session is successfully established and indicating the type of connection established (e.g. active or passive). Additional information can be transmitted to the requesting application by the connection confirmation module 810 as well. Operational flow proceeds to a communication module 812. The communication module 812 corresponds to communication within the session, between the application resident on a user interface device and the VCI. The communication module 812 is generally complementary to the communication module 714 of Figure 7, and can, in various embodiments, correspond to read or read/write requests sent from the application to the VCI, depending upon whether the session is an active or passive session.

Operational flow proceeds to a request arbitration operation 814. The request arbitration operation determines, among other operations, whether any additional requests to establish a session with the VCl exist and whether the communications links associated with the VCI can support an additional session, taking into account bandwidth between the VCI and automotive system, as well as bandwidth between the PC or user interface device and the VCI. If no session requests are outstanding or no capacity exists, operational flow branches "no" and returns to the communication module 812. If an additional session request exists and capacity to support an additional communication session exists at the VCI, operational flow branches "yes" and returns to the connection establishment module 808. The connection establishment module 808 then restarts the process of establishing a new session, based on the information in and source of the new session request. Subsequent sessions that are established will generally be assigned to be passive session by the session manager, particularly if the resources requested by the application have previously been requested by a different or the same application in a different session. When an application signifies that a resource or session is no longer in use, operational flow proceeds to a release module 816. The release module 816 releases a resource based on the information in a communication from the application corresponding to termination of use of that resource. Operational flow proceeds to a session arbitration module 818, which determines whether the resource to be released is being controlled by a session that is still controlling other resources which remain in use. If the session owns other resources, the session should stay open, and therefore operational flow branches "yes" to the communication module 812, corresponding to a session which is maintained in an open state. If no other resource corresponds with the session, the session is no longer needed, so operational flow branches "no" to an end operation 820. The end operation 820 corresponds to completion and termination of a session on a VCI.

Other implementations for session management than those described in Figures 7-8 are possible, and may include more or less information shared among applications resident on user interface devices, VCIs, and ECUs. For example, in some circumstances it may be advisable to allow multiple active sessions from separate applications, such as when the applications are otherwise coordinated to serve a common purpose. Additional configurations which provide session management by maintaining separate session information for each application to VCI connection are possible as well.

The various embodiments described above are provided by way of illustration only and should not be construed to limit the invention. Those skilled in the art will readily recognize various modifications and changes that may be made to the present invention without following the example embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the present invention, which is set forth in the following claims.

Claims

Claims:

1. A method of managing communications in an automotive test network, the method comprising: establishing a first session between a first application and a vehicle communication interface; establishing a second session between a second application and the vehicle communication interface; and designating one of the first session and the second session as an active session.

2. The method of claim 1, further comprising designating the other of the first session and the second session as a passive session.

3. The method of claim 2, further comprising accessing data associated with a vehicle component using the application associated with the passive session and the vehicle communication interface.

4. The method of claim 1 , further comprising writing data to a vehicle component using the application associated with the active session and the vehicle communication interface.

5. The method of claim 1, wherein the first application executes on a user interface device.

6. The method of claim 5, wherein the second application executes on the user interface device.

7. The method of claim 5, wherein the second application executes on a user interface device separate from the user interface device executing the first application.

8. The method of claim 5, wherein the user interface device is linked to the vehicle communication interface.

9. The method of claim 1, wherein a session manager designates one of the first session and the second session as an active session.

10. The method of claim 9, wherein the session manager is a session manager in a vehicle communication interface.

11. The method of claim 10, further comprising marking one of the first session and the second session as a master using the session manager in the vehicle communication interface.

12. The method of claim 1 , further comprising reserving a vehicle resource for use in a session.

13. The method of claim 11 , further comprising releasing the vehicle resource.

14. The method of claim 12, further comprising, upon releasing the vehicle resource, determining the existence of other vehicle resources associated with the session.

15. The method of claim 13, further comprising, upon determining that no other vehicle resources are associated with the session, releasing the session.

16. The method of claim 1, wherein the first session and the second session allow communication to the vehicle control interface simultaneously.

17. A system for managing communications in an automotive test network, the system comprising: a vehicle communication interface including a first programmable circuit configured to execute program instructions; a user interface device including a second programmable circuit configured to execute program instructions, the user interface device operatively connected to the vehicle communication interface; at least one of the first or second programmable circuits configured to execute program instructions to: establish a first session between a first application and a vehicle communication interface; establish a second session between a second application and the vehicle communication interface; and designate one of the first session and the second session as an active session.

18. The system of claim 17, wherein at least one of the first programmable circuit and the second programmable circuit is further configured to designate the other of the first session and the second session as a passive session.

19. The system of claim 17, wherein the first application executes on the user interface device.

20. The system of claim 17, further comprising a session manager executing on at least one of the first or second programmable circuits to designate one of the first session and the second session as an active session.

21. The system of claim 20, wherein the session manager executes on the user interface device.

22. The system of claim 20, wherein the session manager executes on the vehicle communication interface.

23. The system of claim 16, wherein the first programmable circuit is further configured to mark one of the first session and the second session as a master.

24. The system of claim 16, wherein at least one of the first programmable circuit or the second programmable circuit is further programmed to reserve a vehicle resource for use in a session.

21

25. The system of claim 22, wherein at least one of the first programmable circuit or the second programmable circuit is further programmed to release the vehicle resource.

26. The system of claim 23, wherein at least one of the first programmable circuit or the second programmable circuit is further programmed to, upon releasing the vehicle resource, determine the existence of other vehicle resources associated with the session.

27. The system of claim 24, wherein at least one of the first programmable circuit or the second programmable circuit is further programmed to, upon determining that no other vehicle resources are associated with the session, release the session.

28. The system of claim 16, further comprising a server configured to identify and determine the capabilities of the vehicle communications interface.

29. The system of claim 26, wherein the server is separate from the user interface device.

30. A method of managing communications in an automotive test network, the method comprising: establishing a session between a first application executing on a user interface device and a vehicle communication interface; designating the user interface device as an active session using a session manager executing on the vehicle communication interface; establishing a second session between a second application executing on a second user interface device and the vehicle communication interface; and designating the second session as a passive session using a session manager executing on the vehicle communication interface.

22