Source: http://www.google.com/patents/US6505100?dq=7,339,580
Timestamp: 2016-09-25 06:21:57
Document Index: 387292058

Matched Legal Cases: ['art. 2', 'art.\n3', 'arts 1', 'art 2', 'art 3', 'art 1', 'arts 1', 'art 2', 'art 3', 'art 1', 'arts 1', 'art 1']

Patent US6505100 - Distributed vehicle information processing and vehicle control system - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA distributed vehicle information processing and vehicle control system has at least one first system part on board the vehicle side and at least a second system part, each for carrying out one or more vehicle-related application functions, with the system parts communicating with one another via an...http://www.google.com/patents/US6505100?utm_source=gb-gplus-sharePatent US6505100 - Distributed vehicle information processing and vehicle control systemAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS6505100 B1Publication typeGrantApplication numberUS 09/517,530Publication dateJan 7, 2003Filing dateMar 2, 2000Priority dateMar 2, 1999Fee statusPaidAlso published asDE19909157A1, EP1033691A2, EP1033691A3, EP1033691B1Publication number09517530, 517530, US 6505100 B1, US 6505100B1, US-B1-6505100, US6505100 B1, US6505100B1InventorsMatthias Stuempfle, Akthar Jameel, Axel FuchsOriginal AssigneeDaimlerchrysler AgExport CitationBiBTeX, EndNote, RefManPatent Citations (25), Non-Patent Citations (5), Referenced by (147), Classifications (11), Legal Events (8) External Links: USPTO, USPTO Assignment, EspacenetDistributed vehicle information processing and vehicle control system
US 6505100 B1Abstract
A distributed vehicle information processing and vehicle control system has at least one first system part on board the vehicle side and at least a second system part, each for carrying out one or more vehicle-related application functions, with the system parts communicating with one another via an associated data transmission network. The systems parts have a component-based construction composed of different components, which communicate with one another in order to carry out different functions. Each component has a function-calling interface, via which the function carried out by the component can be called up by other components, in this system part or in another system part, and a configuration interface via which its configuration can be defined and varied. A configuration manager unit, provided for this purpose, configures the components via this interface depending on what other components are present in the system.
What is claimed is: 1. A distributed vehicle information processing and vehicle control system comprising:
a first system part situated on board the vehicle and having hardware and software to perform at least a first vehicle-related information processing function; at least one second system part situated at a location physically separate from said first system part, and having hardware and software to perform at least a second vehicle-related information processing function; and a data transmission network via which said first system part and said at least one second system part communicate with one another, wherein: each of the first system part and the at least one second system part includes different software components which perform differing functionality, and which communicate and cooperate with one another to carry out different vehicle related applications using shared functionality of said components; each of said components has a function-calling interface, via which a function carried out by the component is accessible by other components in the same system part or in another system part, and a configuration interface, via which a configuration of the component is definable and variable; a configuration manager component is provided for configuring each component via its respective configuration interface, depending on what other components are present in the system, and depending on a location or relocation of components as between said first system part and said at least one second system part; and said system includes means for addition of components to or removal of components from, or movement of one or more components dynamically between, said first system part and said at least one second system part. 2. The distributed system according to claim 1, further comprising a component loader which is associated with the components of a respective system part.
3. The distributed system according to claim 1, wherein the components in a respective system part are grouped hierarchically on a function-specific basis in an application component layer, an interface component layer, and an intermediate aggregation component layer.
4. The distributed system according to claim 1, wherein respective application components communicate one of directly, using an interface-based model, and via a data-maintenance component, using an event-controlled model.
This application claims the priority of German patent document 199 09 157.9, filed Mar. 2, 1999, the disclosure of which is expressly incorporated by reference herein.
The invention relates to a distributed vehicle information processing and vehicle control system, having at least two system parts as network nodes which communicate via a data transmission network, and at least one of which is arranged on the vehicle side.
Overall, such systems are used for carrying out vehicle-related applications of widely varying types, for example in conjunction with user interfaces, internal and external communication, application support and with the actual applications and services themselves. The latter includes, for example, actuation of vehicle units, evaluation of vehicle sensor information and general services such as navigation, diagnosis, anti-theft devices and data interchange with remote network nodes, for example via the Internet.
Modern vehicle systems are distinguished by a data processing element that is becoming ever larger; that is to say telematics applications are becoming increasingly important. For example, breakdown services and dynamic navigation services as well as Internet-based applications demand the implementation of distributed systems, in which the vehicle is no longer regarded as an isolated individual system, but as an active node in a distributed data communications system, preferably with a worldwide range. System applications implemented aboard the vehicle will in this case in general carry out not only client functions but also server functions.
The layering of functionalities that are required for a vehicle system has already been proposed for a vehicle communications system disclosed in German Patent Document DE 196 25 002 A1, which uses adaptive application control, and allows a certain amount of variability in the assignment of the applications to various interfaces and appliance units on the vehicle side.
In the field of general data processing, a component-based system design has recently been proposed as an alternative to central system architectures. See, for example, the Journal article D. Kiely, “Are Components—The Future of Software?”, IEEE Computer Magazine, page 10, February 1998. In this case, the function to be provided by the overall system is broken down into individual functional units (“components”), which then provide the overall desired function by suitable linking and communication with one another. Such breakdown into components on the one hand simplifies their reuse and the design of complex systems from these components, and on the other hand simplifies the production of robust components themselves (since they need be equipped with only a limited, clear functional scope). The components are characterized by their external identical architecture, which makes it possible to link them to one another in a simple manner, such that the function provided by a particular component may initially be viewed independently of this architecture.
The explosive growth in the Internet and the Worldwide Web has led to distributed systems becoming increasingly important. To simplify the implementation of such systems, and to allow component-based systems to be provided, an increasing number of distributed object models have been established. The system developers are also making ever greater use of Internet-oriented solutions for these object models and are implementing them, for example, using Java RMI or “Java Beans”. See the corresponding Internet information from Sun Microsystems with DCOM from Microsoft; see also, the publications T. Albertson, “Best Practices in Distributed Object Application Development: RMI, CORBA and DCOM, February 1998, Internet page “http://developer.com/news/techfocus/022398_distl.htm” and P. E. Chung et al., “DCOM and CORBA Side by Side, Step by Step, and Layer by Layer, September 1997, Internet page “http://www.cs.wustl.edu/≈schmitt/submit/Paper.html”, or, on the basis of CORBA, see also A. Vogel, K. Duddy, “Java Programming with CORBA”, John Wiley & Sons, 1997.
As is evident from the cited literature, the trend towards object-oriented component models can be explained by the following advantages: first, by the capability for reuse of existing algorithms and software, and for “rapid prototyping” of applications by “plug-and-play” interaction of the components; second, mutually independent development and implementation of components; third efficient code maintenance including the systematic distribution of updates; and fourth “lightweight” and “thin clients” implementations, which communicate with infrastructure-based systems, which can be localized there at various points.
One of the characteristic features of such components is that they follow a standard architecture specification, which makes it easier to join them together to form an overall system. In this case, this architecture in principle has nothing to do with the actual function of the component. In fact, it defines how the components interact with one another, but not how they “converse”. This characterization is independent of whether the specific component is in the form of software or hardware.
The trend towards component models is evident in the increasing importance of technologies which support distributed component systems, such as “Java Remote Method Invocation (RMI)” as the basis for the JavaBeans components “Common Object Request Broker Architecture (CORBA)” and “Distributed Component Object Model (DCOM)” from Microsoft for implementation of ActiveX. All these models use the client/server approach.
In the past, when vehicles have been delivered to the customer at the end of production, their functionality in terms of services that can be carried out has been relatively greatly fixed. In the future, however, more and more services will be used in vehicles, in the same way that they are also being used in the office and business worlds, even though they still scarcely exist at all at the moment when the vehicle is manufactured. In future, the customer will therefore wish to be able to reequip the vehicle with corresponding new services, for the life of the vehicle. If the reequipment is done by additionally downloading software into the vehicle, then the memory space required for this purpose in the vehicle will at some time no longer be adequate. On the other hand, reequipment additional hardware is comparatively costly and susceptible to faults, and in most cases involves the vehicle being left in a workshop.
There is therefore a requirement for systems which can relatively easily be reequipped with additional functions which are provided, for example, as software modules, so that no hardware modification is required. Furthermore, it is desirable to be able to match the system optimally to changing requirements and conditions by dynamic movement, preferably of software modules, to or from the system part on the vehicle side, for the life of the vehicle. This applies, for example, to changing conditions for wireless communication. If only narrowband communication is available, as little communication as possible should be carried out and as much of the necessary software as possible should be accommodated in the vehicle. On the other hand, if a communications link with a high transmission capacity is available, certain operating software can more advantageously be accommodated in a system part outside the vehicle, in order to allow the generally greater computation capacities there to be utilized.
One object of the present invention is to provide a vehicle information processing and vehicle control system of the type mentioned initially, whose structure for carrying out various vehicle-related applications is designed comparatively flexibly, so that reequipping with further functions is possible at relatively low cost. Also, the precondition is provided to allow the required applications to be carried out such that they are distributed variably, dynamically and flexibly between the system parts, and such that the vehicle can be integrated as an active network node in a data network which may be worldwide.
These and other objects and advantages are achieved by the distributed vehicle information processing and vehicle control system according to the invention, whose system parts have a component-based construction, being composed of different components which communicate with one another in order to carry out the various desired application functions. Each of these components, which are defined in this way and are preferably in the form of software on the one hand, has a function-calling interface via which the function carried out by the component can be called up by all the active nodes in the network, and a configuration interface, via which its configuration can be defined. Thus, it can be varied, by means of a configuration manager unit provided for this purpose.
To this end, the configuration manager unit receives knowledge about the components that are present in the system, and configures the respective component, via its configuration interface, depending on what other components are present. In consequence, this configuration manager unit allows a component which has been newly fitted in a system part (irrespective of whether this is by reequipment of the system with the same system part or by movement from another system part) to be “configured” such that it can communicate optimally with the other components that are present.
Matching of the new components to the relevant system part may possibly also involve a modification of the configuration of one or more of those components which were already present. This design allows the vehicle-related system to be equipped with a general data processing platform, which allows flexible reloading of further executable vehicle-related applications at any time during the life of the vehicle, while allowing optimized-cost reaction by service implementations to variable external conditions.
In one embodiment of the invention, a component loader is provided for the respective system part (also referred to as a “bathtub” in general computer processing), which accommodates the respective components. The latter communicate via the component loader with an operating system in the system part to which, on the other hand, various external appliance units are coupled, depending on the system part.
In another embodiment of the invention, a function-based hierarchy of the components is provided in vehicle-component-related components or “interface” components, which are closely based on the existing hardware, vehicle appliance units and, for example, provide access to hardware interfaces for communications appliances or the display and control appliances of a user interface. Aggregation components offer services which aggregate raw information from the vehicle-component-related components, and in higher-level application components represent the actual services and have access not only to the aggregation components but also to an intermediate layer and to the vehicle-component-related components and user-interface components.
According to another feature of the invention, means are provided for dynamically moving one or more of the components between the involved system parts during the system life, and thus, in particular, at any desired times throughout the entire life of the vehicle. These means for moving components make use of the fact that the components are provided with a configuration interface and are “configurable” via this interface. Thus, they can be varied to match a new component environment of a different system part. In consequence, a respective component can, for example, be placed in one system part for certain times and in another system part for other times, depending on the changing external conditions, such as the available transmission capacity of the network communication path. Those components which are not closely related to vehicle-side hardware appliance units are particularly suitable for such movement.
Finally, according to another feature of the invention, communication between application-related components is direct, and thus the components must know the interfaces of those components which they use. Alternatively, communication takes place via a respective, jointly used data-maintenance component, to which the application components involved write new information; and information that has newly been written there can be read by other involved components. In this case, the application components do not need to know the interfaces of the other components, but it is necessary to agree what contents are written to the data-maintenance component.
FIG. 1 shows a schematic illustration of a distributed vehicle information processing and vehicle control system having system parts on board and external to the vehicle, which are networked with one another;
FIG. 2 shows a schematic block diagram of the environment of a port manager component in the system part on the vehicle side in FIG. 1;
FIG. 3 shows a schematic block diagram of the environment of a location manager component in the system shown in FIG. 1;
FIG. 4 shows a schematic block diagram of the environment of a presentation manger component in the system shown in FIG. 1;
FIG. 5 shows a schematic block diagram of the basic, component-based architecture of the system shown in FIG. 1;
FIG. 6 shows a schematic block diagram of the function-based, hierarchical breakdown of the components in the system shown in FIG. 1;
FIG. 7 shows a schematic block diagram which illustrates the dynamic movement of a component between system parts in FIG. 1;
FIGS. 8a and 8 b show schematic block diagrams which illustrate component movement, using the example of a voice control application;
FIG. 9 shows a schematic block diagram of a navigation subsystem of the system shown in FIG. 1, based on a service interface;
FIG. 10 is a schematic block diagram which shows a service interaction in the system shown in FIG. 1 via a data-maintenance component; and
FIG. 11 shows a schematic block diagram to illustrate the calling of a component method.
FIG. 1 shows, schematically, a distributed vehicle information processing and vehicle control system which comprises a plurality of physically separated system parts 1 a, 2 a, 3 a, which form active network nodes in a data transmission network 4, such as the Internet, and communicate with one another via this network. A first system part la is located in the vehicle 1 itself, which represents a “mobile host” in the network 4. A second, stationary system part 2 a is located in a service provider 2, while a third system part 3 a is located in a high-performance service center 3. Other vehicles may form active network nodes in the same way, which can access services from the service provider 2 and from the high-performance service center 3. (Although not shown, there may in each case also be a plurality of the two last-mentioned service providers in the data network 4.)
The service providers 2, 3, which are external to the vehicle, are normally used primarily to carry out such services for the vehicle 1 as require a relatively high computation capacity that is not per se available in the vehicle 1. This may include, for example, complex navigation services such as route finding based on the traffic situation. Similar to the stationary service providers 2, 3, the vehicle 1 has a network identity, by means of which it is known in the network 4. The function blocks of the three illustrated network nodes 1, 2, 3 schematically indicate that the system part 1 a, 2 a, 3 a respectively implemented there has a component-based design, which will be described in more detail below.
For the present application of vehicle systems, it appears, from the three conventional technologies mentioned above which support distributed component systems, namely RMI, CORBA and DCOM, that the Java-RMI technology is particularly suitable for this purpose, since this is not dependent on the platform and can be handled with relatively little complexity.
The components which are used to form the system parts 1, 2, 3, and thus the system overall, each include two interfaces: a function-calling (or remote) interface, via which the actual function of the relevant component (that is to say its service) can be called by another component in the same system part or elsewhere by a remote network node, and a configuration interface, which is used for variable configuration of the component, to match the situation. The configuration interface allows the component to be “configured” variably in different system environments, and existing components can be made aware of the newly positioned component via this interface.
This allows a component to be easily fitted and moved (even after the system generation) for the system life, and even if the system boundary conditions change. In this case, the newly fitted system components, and system components (which may already be present in some circumstances) would have to be matched to one another. This may mean, for example, that the addresses of the components would have to be made known to one another, for which purpose the components offer their own “home page” via which the necessary modifications can be carried out. A specific configuration manager unit is provided in this case in order to carry out this configuration task. This unit knows which components are currently in the system and, via the configuration interface, has access to the individual components, in order to modify their configuration.
The system part 2 a of the service provider 2 primarily contains application components for carrying out services with a vehicle-related functionality, while the system part 3 a of the high-performance service center 3 primarily contains application support components, which require high-performance computation capacities. Apart from application components which represent the actual service applications, the on board vehicle system part 1 a primarily also has components “close to the equipment”, which are used to control hardware appliance units installed in the vehicle 1, such as a presentation manager component 19, which accesses a visual display 24 and a loudspeaker 26.
In addition, communication manager components are used to handle data communication procedures between the system parts 1 a, 2 a, 3 a via the network 4. The entity formed by the components of the respective system part 1 a 2 a, 3 a has an associated component loader (“bathtub”) or component server 1 b, 2 b, 3 b. One suitable example of such a component loader is the ChaiServer from Hewlett-Packard, which is implemented in the Java programming language and supports the loading of the components as well as the routing of method calls to the appropriate components; for further details, see the Company information document Hewlett-Packard “HP ChaiServer: An Overview” on the Internet page “http://www.chai.hp.com/emso/pdf/chaiserverwp.pdf” and “HP Application Server” on the Internet page “http://www.hpconnect.com/embedded/vm/sweb.htm”.
FIGS. 2 to 4 show three examples of components of the vehicle information processing and vehicle control system. FIG. 2 shows a port manager component 5 in its system environment, for example within the system part located in the vehicle 1. The port manager component 5 is part of a group of interface components which support hardware and carry out functions which are closely linked to hardware appliance units on the vehicle side, for example driver functions. The port manager component 5 allows access to a serial interface 6 of the machine (in this case the vehicle 1, on which it runs). In this case, the access methods are provided such that any authorized remote component can access it. The port manager component 5 to this end knows the system interfaces and, inter alia, controls the assignment of the interfaces and of the connected appliances. It is also responsible for controlling concurrent calls by other components to the ports.
Via its remote interface 5 a, the port manager component 5 allows access to the system interfaces from any given point in the network, for example from two explicitly shown applications 7 a, 7 b. The configuration interface 5 a of the port manager component 5 is also shown schematically. The port manager component 5 has no information about the semantic content of the information which is called or written via it. In the chosen Java implementation, it is thus possible for the Java Virtual Machine (JVM) 8 to use additionally formed classes 9, that is to say “port classes” to allow physical access to the serial interface 6.
The function of the location manager component or position manager component 10, which is shown embedded in the architectural system environment in FIG. 3, is to collect position information and then to offer this information in aggregated form as a position information service. Possible information sources are, for example, a GPS receiver 11 and integrated navigation sensors 12, 13, such as a compass and wheel revolution counter. The location manager component 10 to this end accesses appropriate interface components, such as the port manager 5 mentioned above and a CAN manager component 14 which, for its part, accesses a CAN interface 16 via the JVM/operating system layer 15.
A movement arrow 17 shows a movement option, in which the location manager component 10 need not necessarily run on the same machine (for example the vehicle 1) as the interface components 5, 14 which it accesses; rather, it may form an external, remote component 10′, which is located in another system part. Whether such movement is expedient depends on the respective boundary conditions at that time, in particular the complexity and the costs for data communication between the system parts. Apart from this, the position manager component 10, like all the components in the system according to the invention, also in turn has a remote interface 10 a for communication with other services 18 a, 18 b, and a configuration interface 10 b. FIG. 4 shows, once again embedded in its system environment, a presentation manager component 19 with a remote interface 19 a for function calling from other applications 20 a, 20 b and a configuration interface 19 b. The presentation manager component 19 is responsible for passing on information relating to the applications 20 a, 20 b, and passes the information on to the user depending on interchangeable strategies. These strategies may, for example, include information being provided only via a voice output while driving and a visual display being activated only when stationary. Such strategies allow necessary safety precautions to be incorporated in the system so that the vehicle occupant or occupants is or are not distracted from their actual task.
Apart from appropriate interfaces, via respective interface manager components 21, 22 the presentation manager has access to user interface components in the vehicle, such as “text-to-speech” and “speech-to-text” appliances 23, visual displays 24 and “touchscreen” and “pointing” appliances to carry out its task. The presentation manager component 19 interacts closely with the system configuration management, since it requires information on the input and output appliances that are present in the vehicle. Furthermore, it is able to suitably resolve concurrent output requests from different applications, comparable to a “Window Manger”.
As stated, the architecture of the distributed vehicle information processing and vehicle control system is formed completely from components. (In order to assist in identification, these components are each marked in the figures by a small triangle in the top left-hand corner of their function block.)
FIG. 5 shows the basic architecture of the system, comprising a number n of components K1, . . . Kn, to which a component server KS is assigned and which accesses a number m of external appliances G, . . . Gm via the respective operating system BS. In consequence, from this software point of view, the system comprises a number of components K1, . . . Kn, which communicate with one another, although there are no hierarchies between the individual components K1, . . . Kn at this level.
The communication between the system objects is based on conventional procedures, such as “remote procedure call” (RPC) and its Java version, the “remote method invocation” (RMI). Methods relating to a component which are intended to be called by another component are described in an interface file, comparable with the “interface description language” (IDL) in CORBA. The required “stubs” are then generated from this file, and are linked to a component. The “uniform resource locator” (URL) is used for addressing the method, which is used to address that machine on which the addressed component is running and on which, furthermore, the component itself and the desired method, with an argument, can be specified. URL addressing results in position transparency, that is to say positioning independent of the components, since the machine address is resolved independently of the client entity, for example via a “domain name service” (DNS).
FIG. 6 shows a function-based arrangement of the system components. This illustration shows a three-level component hierarchy, in which a top layer comprises actual applications, a center layer comprises application-support functions, and a lower layer comprises interface control functions. The components in the top layer form the actual applications or services, that is to say application components AK1, AK2, AK3, . . . An initial message reader and a navigation component are shown by way of example. To carry out their tasks, the application components AK1, AK2, . . . access the center layer of application-supporting components UK1, UK2, UK3, . . . , which may also be referred to as aggregation components, since they appropriately aggregate raw data, which may come from various sources in the vehicle and from the network infrastructure external to the vehicle. Examples of such application-support components are the location manager and presentation manager components explained above, as well as the communication manager component. These application-supporting components UK1, UK2, UK3, . . . for their part access the interface components IK1, IK2, IK3, . . . in the lower layer, which represent components that are closely linked to hardware appliance units on the vehicle side, such as the (serial) port manager explained above, a CAN manager component, and a display manager component.
The component loader KL is assigned to all the components, and communication with external appliances, such as a visual display 24, an audio interface 27, modems 28, a GPS receiver 29 and a DVD 30 takes place via the JVM/operating system layer 15. In this way, the system supports external appliances which can be assigned to the user interface, as well as appliances which the user fits to the system for the first time. If there are no interface components for retrofitted external appliances, they can be loaded retrospectively. The said components, which are broken down on a functional basis into three layers, are jointly assigned a configuration manager component KM using which the components can be moved dynamically between the various system parts of the system.
A further application is subsequent loading of components, in particular in the top layer (that is, application components). The subsequent loading of such application components may be carried out using the present platform, and thus overcomes the difficulty that there is often insufficient knowledge at the time when the vehicle systems are configured as to what services will be of interest to the customer over the entire life of the vehicle. In particular, this also relates to services which load software required for their use into the vehicle, from a system part external to the vehicle, before the service is carried out. The central element for subsequent loading of components is the component loader KL, which not only allows new components to be incorporated in the relevant system part, but it also allows the removal of components which are no longer required.
The capability to move components dynamically is of interest for vehicle systems, particularly bearing in mind the limited computation capacities on the vehicle side. Thus, on the one hand, it is desirable to need to reserve only a relatively small computation capacity in the vehicle and for the main load of the calculations to be borne in the system infrastructure external to the vehicle. On the other hand, the communications costs for is coupling the vehicle-side system part to the network should be kept as low as possible. However, the communications costs now differ considerably in some cases, depending on the state or region. Bearing in mind the mobility of vehicles, these boundary conditions may even change during a journey. If, furthermore, the absolute availability of a communications service is also included in the cost model, then this results in an optimization problem which can be solved considerably better with the capability to remove components dynamically between the system parts than with a rigid structure and the components being distributed.
The configuration manager KM is now used to “configure” a respective moved component into its new environment and to “inform” the already existing components about the component which is to be newly added to the relevant system part, that is to say to match its configuration to this. To this end, the configuration manager KM has access via the configuration interfaces to the individual components in the relevant system part. The configuration manager KM knows which components there are in the system, checks their consistency, and then makes the suitable modified configuration accesses to the individual components.
FIG. 7 shows the capability for dynamic movement of a component between a vehicle 31, on the one hand, and a system infrastructure 32 external to the vehicle, on the other hand, using the example of a service support component 33 and based on three different scenarios which make such component movement desirable. In this context, see also the Journal article S. Hild and P. Robinson, “Mobilizing Applications”, IEEE Personal Communications, 4, No. 5, 1997, page 26. This is based on an upgraded client/server model, in which the service support component 33 is also connected, as a server, between a presentation manager component 34 in the vehicle 31 as the client, and a server component 35 on the infrastructure side, and which, to a reduced extent, can carry out certain server functions instead of the server component 35 on the infrastructure side.
If the communications costs between the vehicle 31 and the infrastructure 32 are high, the solution illustrated in the top part of FIG. 7 is chosen, in which the service support component 33 is positioned in the vehicle 31, so that it can handle its communication with the presentation manager 34 within the vehicle, and a high proportion of the calculations are carried out in the vehicle 31, thus keeping the communication with the infrastructure 32 minimal, or avoiding it entirely at times. In this case, the vehicle forms a “thick mobile host” which contains a reduced version of the server component 35 on the infrastructure side, in the form of the service support component 33.
If the cost of communication between the vehicle 31 and the infrastructure 32 is, on the other hand, comparatively low, it is advantageous to choose the solution shown in the center part of FIG. 7, in which the service support component 33 is arranged in the infrastructure 32, where it can exploit the advantages of the greater computation capacity and the availability of further resources located in the data network, such as up-to-date traffic data. In this case, the vehicle forms a “thin mobile host”.
The dynamic movement of components, such as the service support component 33 in this case, is now used to avoid a long-term restriction to one or the other of these two solutions and, instead, to be able to move the components backwards and forwards between the system parts, in this case between the infrastructure 32 and the vehicle 31, depending on the boundary conditions, throughout the system life; that is, to move the service support component 33 optionally into the vehicle 31 or into the infrastructure 32, as is shown in the lower part of FIG. 7. The vehicle 31 then forms a “component-based host” into which it is possible selectively to load components from the infrastructure 32, and from which components can be moved into the infrastructure 32.
This essential characteristic of the present system will be illustrated more specifically using the example of a voice control application in FIGS. 8a and 8 b. FIG. 8a shows a voice control system controller 36, which is equipped with a component system, that is to say with a component loader. The necessary hardware, that is to say a loudspeaker 37 and a microphone 38, are accessed via the controller 36. The following components run in this system part. A hardware-related component 39 is used to access the microphone 38 and the loudspeaker 37. A first application-supporting component 40 contains the vocabulary required for the desired voice control, for example in German. A second application-supporting component 41 forms a speech recognizer and synthesizer, which carries out the necessary speech recognition and speech synthesis. An application component in the form of an initial message reader 42 is used to control the application.
Based on this voice control system part, one possible scenario consists of the vocabulary component 40 being replaced by one using a different language in order to match the system, and thus the vehicle, to different countries. A different scenario may occur in the case of a rented vehicle in which the matching to the respective language desired by a customer is implemented by allowing the customer to use a menu to select the vocabulary component with the respective language, after which the relevant component is then loaded. Once the rented vehicle has been returned, the subsequently loaded component is then removed again.
A more complex situation relating to component movement for the system part in FIG. 8a is shown in FIG. 8b. This situation relates to as many components of the voice control system part as possible being moved out of the vehicle 36 into system parts external to the vehicle; that is, into the overall system infrastructure 43 that is external to the vehicle. Specifically, the present system's capability for dynamic component movement allows the application component 42 and the two application-supporting components 40, 41 to be moved into the infrastructure 43, where they can operate more efficiently owing to the greater computer power. The interface component 40, which is close to the vehicle equipment, remains in the vehicle 36. The data are transmitted via the interface component 40, which remains on the vehicle side, and a wireless connection 44 between the vehicle 36 and the infrastructure 43 external to the vehicle. Depending on the existing wireless communication, in particular its availability and its costs, it is in this way possible to choose an optimum compromise for the distribution of the components 39 to 42 of the voice control system between the vehicle 36 and the infrastructure 43 external to the vehicle.
Depending on the requirements for vehicle-related services, such as telematics services, the present distributed vehicle information processing and vehicle control system has a specific basic number of components in vehicles and in the infrastructure, which offer services such as “time”, “location/position” or “map matching”. These basic services may then be used by a number of other services. Thus, for example, the position information may be used not only by a navigation service but also by a breakdown service, in order to pass on the present vehicle position to the breakdown assistant. Service providers do not need to repeatedly remove such basic parts of the system, but can build on the existing basic components. Using the existing component-based system architecture, new services can be provided on the basis of existing components in two ways that are supported by the system architecture, to be precise using an interface-based service model, or an event-controlled service model.
In the interface-based model, it is assumed that the existing components and their service interfaces (which may in some circumstances be comprehensive) together with all the necessary methods are known. A new service can then easily be produced by use of the existing functions. This is dependent on the necessary knowledge being maintained relating to the fundamental existence of the component and its precise service scope.
FIG. 9 shows a navigation sub-system which is designed using such an interface-based model. In this case, a “navigation service” component 45 accesses the services of other components, such as a mapping component 46, a routing component 47, a wheel rotation-speed detection component 48, a presentation manager component 49 etc., in order to provide the user with their service. When the navigation service component 45 is being programmed, the interfaces of the components used must be known.
FIG. 10 shows the situation for an event-controlled model, which is provided by using a “shared-space” component 50 which represents a server-based data memory that is used jointly by a number of components that are involved, to which the components that are involved can write specific values/objects of interest, as is illustrated in FIG. 10 for a calendar application component 51 and a further application component 52. Furthermore, the components that are involved can be registered with this “shared-space” component 50, which thus acts as a data-maintenance component in order to be informed when a new value/object which is relevant for it occurs, referred to as a so-called “event-triggered notification”.
Approaches of this type move the knowledge problem relating to the existence of components (mentioned above) to a higher level, since the communication between components always takes place via the “shared-space” component 50, which can be provided using a very small API and is known to each component. The components need agree only on the contents, which are written to the “shared-space” component 50. Such approaches are well known, for example by the terms “Linda Space”, see Internet page “http://www.cs.yale.edu/HTML/YALE/CS/Linda/linda.html” and “Java Spaces”, Sun Microsystems, Internet page http://java.sun.com/products/javaspaces/specs”, in general computer processing.
In the example in FIG. 10, the calendar application 51 supplies new entries 53 to the data-maintenance component 50. If another application 52 is interested in such data, it obtains the relevant data information 54 from the data-maintenance component 50, provided it has registered with this component for that purpose. The other application 52 can generate new data 55 from this and make such data available to the other components, by writing the data to the data-maintenance component 50. If the calendar application 52 is interested in this new data 55, it can obtain the relevant information 56 from the data-maintenance component 50, after which the data replacement cycle can start once again from the beginning.
The advantage of this model is the mutually independent programming of the components and the small amount of “shared-space” API. Furthermore, new components can be integrated in the system without any problems, and immediately actively contribute to the provision of value-added services. To do this, applications must be written “cooperatively” that is to say such that they also actually write relevant information to the “shared-space” component. Suitable mechanisms, such as time monitoring, transaction models, etc., are implemented in the “shared-space” component and suppress the occurrence of oscillating effects between components when new values are alternately being written to the “shared-space” component.
A combined implementation of partially interface-based modeling and partially event-controlled modeling, depending on the respective applications, may be advantageous. Thus, for example, when processing an engine speed value, which is available all the time at intervals of a few milliseconds, an event-controlled model, in which each new speed value is written to the “shared-space” component and all potential recipient components are informed of this, makes little sense, so that interface-based modeling is to be preferred for this purpose.
A platform-independent implementation of the present distributed vehicle information processing and vehicle control system is feasible, as already explained, for example by choosing the development and implementation environment “Java”, since this already directly supports an object-oriented implementation of components at many points, and in this case, as has likewise been mentioned above, the ChaiServer from Hewlett-Packard, implemented in Java may, for example, be used as the component loader. To allow access to the system hardware, which is not envisaged as standard by Java, additional classes are introduced to the system, which are likewise monitored via the system configuration management and are loaded into the vehicle only when required. The removal of a component, in order to release the relevant resource once again, is likewise supported by the ChaiServer in the scope of the dynamic component movement process.
The Java implementation results in a high level of platform independence. Components may be stored in a component database, in the infrastructure external to the vehicle, and may be loaded into the appropriate systems as required. The components are preferably modeled and implemented using object-based viewpoints, and are in this case similar to the Java “Servlets”, which are used to increase the functionality of the server in a simple way, see for general computer processing, the publication “Servlets” from Sun Microsystems, Internet page “http://java.sun.com/products/javaserver/servlets”. Communication between the components is based on Java-RMI.
Methods for components which run in the context of the ChaiServer are called up by means of HTTP. See J. Morgan, “The HEHAW Invocation Model,” Broadband Information Systems, Hewlett-Packard, Palo Alto, 1997. The use of HTTP has the advantage that it is virtually universally supported and “firewalls” can also be transferred. The desired position transparency is achieved by the addressing and call syntax mentioned above using a “uniform resource locator” (URL).
FIG. 11 shows an application relating to this with an example of a component 57, which is implemented on a vehicle machine 58. The component 57 provides a “Foo” method, which is called up using a string argument. The result of the method may be an HTML document. The HTTP call syntax for a call 59 by another component 60 then contains the address of the vehicle machine 58, the designation of the example of a component 57, and the details of the “Foo” method with “html” characterization.
The above description of an advantageous exemplary embodiment and possible modifications to it makes it clear that the distributed vehicle information processing and vehicle control system according to the invention provides a flexible and dynamically adaptable environment for vehicle-related service applications. The object-based modeling and capability to combine the components easily by means of their standard interfaces allow new services to be set up quickly and easily. The capability to move components between the vehicle and the infrastructure external to the vehicle throughout the system life allows the system to be optimally matched to the dynamically changing boundary conditions in the infrastructure.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5365451 *Mar 4, 1994Nov 15, 1994Motorola, Inc.Mobile unit tracking systemUS5430656 *Sep 8, 1993Jul 4, 1995Dekel; ItzhakMobile communications systemUS5479157 *Feb 17, 1995Dec 26, 1995Prince CorporationRemote vehicle programming systemUS5625556 *Apr 28, 1995Apr 29, 1997Trimble Navigation LimitedAccurate time standard for vehicle operationUS5648769 *May 18, 1995Jul 15, 1997Toyota Jidosha Kabushiki KaishaVehicle data processing system which can communicate with information centerUS5848368 *Oct 28, 1996Dec 8, 1998Caterpillar Inc.Method for controllably loading haul vehicles by a mobile loading machineUS6064319 *Oct 22, 1998May 16, 2000Matta; David M.Method and system for regulating switching of a traffic lightUS6084510 *Apr 18, 1997Jul 4, 2000Lemelson; Jerome H.Danger warning and emergency response system and methodUS6097316 *Apr 20, 1998Aug 1, 2000Visteon Technologies, LlcCommunication protocol for a vehicle navigation systemUS6108591 *Jan 22, 1998Aug 22, 2000Qualcomm IncorporatedMethod and apparatus for validating vehicle operatorsUS6141611 *Dec 1, 1998Oct 31, 2000John J. MackeyMobile vehicle accident data systemUS6154689 *Jan 2, 1997Nov 28, 2000Integral Media S.A.Multimedia computer equipment for automatic transmission of multimedia entertainment programsUS6175789 *Sep 10, 1999Jan 16, 2001Microsoft CorporationVehicle computer system with open platform architectureUS6202008 *Sep 10, 1999Mar 13, 2001Microsoft CorporationVehicle computer system with wireless internet connectivityUS6208918 *Oct 7, 1998Mar 27, 2001Toyota Jidosha Kabushiki KaishaData recovery system and data recovery program recorded mediumUS6230097 *Aug 31, 1998May 8, 2001Trimble Navigation LimitedAccurate vehicle navigationUS6236911 *Apr 19, 2000May 22, 2001Supersensor (Proprietary) LimitedLoad monitoring system and method utilizing transponder tagsDE4140803A1Dec 11, 1991Jun 17, 1993Webasto Ag FahrzeugtechnikMatching circuitry adapting electric control devices for vehicle accessories - translates signals between vehicle transmission system and control devices using microcomputer under control of external interfaceDE4315494A Title not availableDE19620885A1May 23, 1996Nov 27, 1997Bayerische Motoren Werke AgData update method for vehicle controlDE19625002A1Jun 22, 1996Jan 2, 1998Daimler Benz AgFahrzeugkommunikationssystemDE19640735A1Oct 2, 1996Apr 23, 1998Bosch Gmbh RobertTelematikger�t f�r ein KraftfahrzeugDE19821500A1May 13, 1998Jan 28, 1999Siemens AgController of data transmission for e.g. airbag in motor vehicleEP0890937A2Jun 25, 1998Jan 13, 1999Robert Bosch GmbhDevice for transmitting data from a vehicleJPH1127749A Title not available* Cited by examinerNon-Patent CitationsReference1"Are Components the Future of Software?", Don Kiely, Industry Trands, pp. 10-11, Feb. 1998.2 *Opne System Interconnection (OSI)-3 pages.*3Opne System Interconnection (OSI)—3 pages.*4Seokhoon Lee et al., "Toward the Next Generation Public Traffic Information System Using Internet", 1997 IEEE, pp. 505-510.5Stefan G. Hild et al., "Mobilizing Applications", IEEE Personal Communications, Oct. 1997, pp. 26-34.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS6704564 *Sep 22, 2000Mar 9, 2004Motorola, Inc.Method and system for controlling message transmission and acceptance by a telecommunications deviceUS6747365 *Aug 31, 2001Jun 8, 2004Motorola, Inc.Vehicle active network adapted to legacy architectureUS6839710Jun 28, 2002Jan 4, 2005Motorola, Inc.Method and system for maintaining a configuration history of a vehicleUS6873940 *Mar 7, 2000Mar 29, 2005Laserdynamics, Inc.Measuring method and measuring service system using communication meansUS6874012 *Nov 1, 2000Mar 29, 2005Sun Microsystems, Inc.System and method for a display device using a priority messaging protocolUS6885916Aug 31, 2001Apr 26, 2005Motorola, Inc.Data packet for a vehicle active networkUS6931004 *Aug 31, 2001Aug 16, 2005Motorola, Inc.Vehicle active network with backbone structureUS6947760 *Jan 4, 2002Sep 20, 2005Motorola, Inc.Method of optimizing the transmission of data in a wireless communication networkUS6978206 *Jun 23, 2003Dec 20, 2005Infogation CorporationDistributed navigation systemUS7010682Jun 28, 2002Mar 7, 2006Motorola, Inc.Method and system for vehicle authentication of a componentUS7027387Aug 31, 2001Apr 11, 2006Motorola, Inc.Vehicle active network with data redundancyUS7039520 *Mar 28, 2002May 2, 2006Robert Bosch GmbhMethod for operating a navigation system for a vehicle and corresponding navigation systemUS7076665Jun 28, 2002Jul 11, 2006Motorola, Inc.Method and system for vehicle subassembly authentication of a componentUS7127611Jun 28, 2002Oct 24, 2006Motorola, Inc.Method and system for vehicle authentication of a component classUS7131005Jun 28, 2002Oct 31, 2006Motorola, Inc.Method and system for component authentication of a vehicleUS7135962 *Dec 20, 2004Nov 14, 2006Dei Headquarters, Inc.Security and remote access for vehicular entertainment, safety, and convenience systemsUS7137001Jun 28, 2002Nov 14, 2006Motorola, Inc.Authentication of vehicle componentsUS7137142Jun 28, 2002Nov 14, 2006Motorola, Inc.Method and system for vehicle authentication of a component using key separationUS7146260 *Apr 24, 2001Dec 5, 2006Medius, Inc.Method and apparatus for dynamic configuration of multiprocessor systemUS7170853Aug 31, 2001Jan 30, 2007Temic Automotive Of North America, Inc.Vehicle active network topologiesUS7173903Aug 31, 2001Feb 6, 2007Temic Automotive Of North America, Inc.Vehicle active network with communication path redundancyUS7181511 *Apr 15, 2002Feb 20, 2007Yazaki North America, Inc.System and method for using software objects to manage devices connected to a network in a vehicleUS7181615 *Jun 28, 2002Feb 20, 2007Motorola, Inc.Method and system for vehicle authentication of a remote access deviceUS7228420Jun 28, 2002Jun 5, 2007Temic Automotive Of North America, Inc.Method and system for technician authentication of a vehicleUS7254604 *Jul 31, 2002Aug 7, 2007Nissan Motor Co., Ltd.Distributed information collecting systemUS7269482 *Apr 22, 2002Sep 11, 2007Vetronix CorporationIn-vehicle information system and software frameworkUS7325135Jun 28, 2002Jan 29, 2008Temic Automotive Of North America, Inc.Method and system for authorizing reconfiguration of a vehicleUS7415331Jul 25, 2005Aug 19, 2008Lockheed Martin CorporationSystem for controlling unmanned vehiclesUS7415508Aug 31, 2001Aug 19, 2008Temic Automotive Of North America, Inc.Linked vehicle active networksUS7484008 *Oct 4, 2000Jan 27, 2009Borgia/Cummins, LlcApparatus for vehicle internetworksUS7549046Jun 28, 2002Jun 16, 2009Temic Automotive Of North America, Inc.Method and system for vehicle authorization of a service technicianUS7600114Jun 28, 2002Oct 6, 2009Temic Automotive Of North America, Inc.Method and system for vehicle authentication of another vehicleUS7646285 *Jan 12, 2010Dei Headquarters, Inc.Security and remote access for vehicular safety and convenience systemsUS7681448Mar 23, 2010Medius, Inc.System and method for aligning sensors on a vehicleUS7693656 *Apr 6, 2010Denso CorporationNavigation apparatusUS7734386Jul 25, 2005Jun 8, 2010Lockheed Martin CorporationSystem for intelligently controlling a team of vehiclesUS7778739Aug 17, 2010Medius, Inc.Method and apparatus for dynamic configuration of multiprocessor systemUS7783401Aug 24, 2010Denso CorporationMethod and device for managing tasks of in-vehicle electronic control unitUS7793136Dec 27, 2006Sep 7, 2010Eagle Harbor Holdings LLCApplication management system with configurable software applicationsUS7797367Oct 4, 2000Sep 14, 2010Gelvin David CApparatus for compact internetworked wireless integrated network sensors (WINS)US7844687Oct 4, 2000Nov 30, 2010Gelvin David CMethod for internetworked hybrid wireless integrated network sensors (WINS)US7849415 *Apr 20, 2000Dec 7, 2010Nokia CorporationCommunication terminalUS7869906Jan 11, 2011Ford Global TechnologiesWireless gateway apparatus and method of bridging data between vehicle based and external data networksUS7891004Oct 4, 2000Feb 15, 2011Gelvin David CMethod for vehicle internetworksUS7904569Mar 8, 2011Gelvin David CMethod for remote access of vehicle componentsUS7984184Oct 21, 2004Jul 19, 2011Leica Geosystems AgMethod and apparatus for managing information exchanges between apparatus on a worksiteUS8001860Feb 2, 2010Aug 23, 2011Eagle Harbor Holdings LLCMethod and apparatus for the alignment of multi-aperture systemsUS8006117Aug 23, 2011Eagle Harbor HoldingsMethod for multi-tasking multiple java virtual machines in a secure environmentUS8006118Aug 18, 2010Aug 23, 2011Eagle Harbor HoldingsSystem and method for application failure detectionUS8006119Aug 23, 2011Eagle Harbor HoldingsApplication management systemUS8020028Sep 13, 2011Eagle Harbor HoldingsApplication management system for mobile devicesUS8027268 *Oct 24, 2008Sep 27, 2011Eagle Harbor Holdings, LlcMethod and apparatus for dynamic configuration of multiprocessor systemUS8045729Oct 24, 2008Oct 25, 2011Eagle Harbor Holdings, LlcAudio system with application management system for operating different types of audio sourcesUS8050811 *Dec 12, 2006Nov 1, 2011General Motors LlcMethod for controlling the distribution of vehicle-related dataUS8060109Oct 31, 2007Nov 15, 2011Enovsys LlcAuthorized location reporting mobile communication systemUS8079118Dec 20, 2011Borgia/Cummins, LlcMethod for vehicle internetworksUS8140658Oct 4, 2000Mar 20, 2012Borgia/Cummins, LlcApparatus for internetworked wireless integrated network sensors (WINS)US8165057Sep 13, 2010Apr 24, 2012Eagle Harbor Holdings, LlcWireless telecommunications methodUS8194536Aug 31, 2001Jun 5, 2012Continental Automotive Systems, Inc.Vehicle active network with fault tolerant devicesUS8195188Jun 5, 2012Enovsys LlcLocation reporting satellite paging system with optional blocking of location reportingUS8331279Dec 11, 2012Eagle Harbor Holdings, LlcWireless telecommunications method and apparatusUS8346186Dec 27, 2010Jan 1, 2013Eagle Harbor Holdings, LlcMethod and apparatus for dynamic configuration of multiprocessor systemUS8364335Jul 22, 2011Jan 29, 2013Eagle Harbor Holdings, LlcMethod and apparatus for dynamic configuration of multiprocessors systemUS8369967Feb 5, 2013Hoffberg Steven MAlarm system controller and a method for controlling an alarm systemUS8375243Feb 12, 2013Eagle Harbor Holdings, LlcFailure determination systemUS8380383Feb 19, 2013Eagle Harbor Holdings, LlcDistributed vehicle control systemUS8386113Mar 28, 2012Feb 26, 2013Eagle Harbor Holdings, LlcMultiprocessor system for managing devices in a homeUS8417490May 11, 2010Apr 9, 2013Eagle Harbor Holdings, LlcSystem and method for the configuration of an automotive vehicle with modeled sensorsUS8463494Jun 11, 2013General Motors LlcAftermarket telematics unit and method for installation verificationUS8494447Jul 29, 2010Jul 23, 2013General Motors LlcAftermarket telematics unit for use with a vehicleUS8543289Sep 30, 2010Sep 24, 2013Genreal Motors LLCAftermarket telematics systemUS8559942Jan 31, 2011Oct 15, 2013Mundi FomukongUpdating a mobile device's locationUS8571752Aug 5, 2010Oct 29, 2013General Motors LlcVehicle mirror and telematics systemUS8583292May 7, 2010Nov 12, 2013Eagle Harbor Holdings, LlcSystem and method for restricting access to vehicle software systemsUS8601595Dec 1, 2011Dec 3, 2013Borgia/Cummins, LlcMethod for vehicle internetworksUS8604937Jul 29, 2010Dec 10, 2013General Motors LlcTelematics unit and method for controlling telematics unit for a vehicleUS8630196Sep 13, 2010Jan 14, 2014Eagle Harbor Holdings, LlcMultiprocessor system and method for conducting transactions from a vehicleUS8706078Mar 7, 2012Apr 22, 2014Enovsys LlcLocation reporting satellite paging system with privacy featureUS8744672Dec 27, 2010Jun 3, 2014Eagle Harbor Holdings, LlcMethod and apparatus for dynamic configuration of multiprocessor systemUS8751712Sep 30, 2011Jun 10, 2014Eagle Harbor Holdings, LlcMethod and apparatus for a priority based processing systemUS8762610Oct 6, 2011Jun 24, 2014Eagle Harbor Holdings, LlcProcessing method for reprioritizing software application tasksUS8812654Oct 21, 2010Aug 19, 2014Borgia/Cummins, LlcMethod for internetworked hybrid wireless integrated network sensors (WINS)US8832244Feb 22, 2010Sep 9, 2014Borgia/Cummins, LlcApparatus for internetworked wireless integrated network sensors (WINS)US8836503Apr 12, 2010Sep 16, 2014Borgia/Cummins, LlcApparatus for compact internetworked wireless integrated network sensors (WINS)US8886392Dec 21, 2011Nov 11, 2014Intellectual Ventures Fund 79 LlcMethods, devices, and mediums associated with managing vehicle maintenance activitiesUS8891784Jul 6, 2010Nov 18, 2014GM Global Technology Operations LLCMicrophone assembly for use with an aftermarket telematics unitUS8892495Jan 8, 2013Nov 18, 2014Blanding Hovenweep, LlcAdaptive pattern recognition based controller apparatus and method and human-interface thereforeUS8953816Aug 2, 2011Feb 10, 2015Eagle Harbor Holdings LLCMethod and apparatus to dynamically configure a vehicle audio systemUS8958315Jun 11, 2009Feb 17, 2015Eagle Harbor Holdings, LlcMethod and apparatus for dynamic configuration of multiprocessor systemUS8978439Jan 20, 2011Mar 17, 2015Eagle Harbor Holdings, LlcSystem and apparatus for the alignment of multi-aperture systemsUS9110775 *Jun 21, 2013Aug 18, 2015Lg Electronics Inc.In-vehicle infotainment device and data processing method using the sameUS9229903 *Aug 31, 2012Jan 5, 2016General Motors LlcProviding vehicle operating information using a wireless deviceUS9292334Apr 17, 2014Mar 22, 2016Eagle Harbor Holdings, LlcMethod and apparatus for dynamic configuration of multiprocessor systemUS9336043Sep 27, 2011May 10, 2016Dan Alan PrestonMethod and apparatus for a task priority processing systemUS9348637Mar 26, 2012May 24, 2016Eagle Harbor Holdings, LlcDynamic configuration of a home multiprocessor systemUS9358924May 7, 2010Jun 7, 2016Eagle Harbor Holdings, LlcSystem and method for modeling advanced automotive safety systemsUS20020154605 *Apr 24, 2001Oct 24, 2002Medius, Inc.Method and apparatus for dynamic configuration of multiprocessor systemUS20030028292 *Jul 31, 2002Feb 6, 2003Nissan Motor Co., Ltd.Distributed information collecting systemUS20030042792 *Aug 31, 2001Mar 6, 2003Juergen ReinoldVehicle active network adapted to legacy architectureUS20030043739 *Aug 31, 2001Mar 6, 2003Juergen ReinoldVehicle active network with fault tolerant devicesUS20030043793 *Aug 31, 2001Mar 6, 2003Juergen ReinoldVehicle active networkUS20030043824 *Aug 31, 2001Mar 6, 2003Remboski Donald J.Vehicle active network and deviceUS20030045234 *Aug 31, 2001Mar 6, 2003Remboski Donald J.Vehicle active network with reserved portionsUS20030045972 *Aug 31, 2001Mar 6, 2003Remboski Donald J.Data packet for a vehicle active networkUS20030046327 *Aug 31, 2001Mar 6, 2003Juergen ReinoldLinked vehicle active networksUS20030129961 *Jan 4, 2002Jul 10, 2003Weisshaar Bernhard P.Method of optimizing the transmission of data in a wireless communication networkUS20030194993 *Apr 15, 2003Oct 16, 2003Mundi FomukongLocation reporting satellite paging system with optional blocking of location reportingUS20040001593 *Jun 28, 2002Jan 1, 2004Jurgen ReinoldMethod and system for component obtainment of vehicle authenticationUS20040002799 *Jun 28, 2002Jan 1, 2004Dabbish Ezzat A.Method and system for maintaining a configuration history of a vehicleUS20040003228 *Jun 28, 2002Jan 1, 2004Fehr Walton L.Method and system for vehicle authentication of a remote access deviceUS20040003230 *Jun 28, 2002Jan 1, 2004Puhl Larry C.Method and system for vehicle authentication of a service technicianUS20040003231 *Jun 28, 2002Jan 1, 2004Levenson Samuel M.Method and system for component authentication of a vehicleUS20040003232 *Jun 28, 2002Jan 1, 2004Levenson Samuel M.Method and system for vehicle component authentication of another vehicle componentUS20040003233 *Jun 28, 2002Jan 1, 2004Jurgen ReinoldMethod and system for vehicle subassembly authentication of a componentUS20040003234 *Jun 28, 2002Jan 1, 2004Jurgen ReinoldMethod and system for vehicle authentication of a subassemblyUS20040003237 *Jun 28, 2002Jan 1, 2004Puhl Larry C.Method and system for vehicle authentication of a component using key separationUS20040003242 *Jun 28, 2002Jan 1, 2004Fehr Walton L.Method and system for vehicle authorization of a service technicianUS20040003245 *Jun 28, 2002Jan 1, 2004Dabbish Ezzat A.Method and system for multiple scope authentication of vehicle componentsUS20040003252 *Jun 28, 2002Jan 1, 2004Dabbish Ezzat A.Method and system for vehicle authentication of a component classUS20040039525 *Mar 28, 2002Feb 26, 2004Gerd DraegerMethod for operating a navigation system for a vehicle and corresponding navigation systemUS20050168071 *Dec 20, 2004Aug 4, 2005Directed Electronics, Inc.Security and remote access for vehicular entertainment, safety, and convenience systemsUS20060048015 *Aug 26, 2005Mar 2, 2006Daimlerchrysler AgSystem integration test rig for networked overall mechatronic systemsUS20060268930 *Aug 7, 2006Nov 30, 2006Medius, Inc.Method and apparatus for dynamic configuration of multiprocessor systemUS20070013494 *Sep 8, 2006Jan 18, 2007Dei Headquarters Inc.Security and remote access for vehicular safety and convenience systemsUS20070021879 *Jul 25, 2005Jan 25, 2007Lockheed Martin CorporationSystem for intelligently controlling a team of vehiclesUS20070032920 *Jul 25, 2005Feb 8, 2007Lockheed Martin CorporationSystem for controlling unmanned vehiclesUS20070050137 *Oct 21, 2004Mar 1, 2007Leica Geosystems AgMethod and apparatus for managing information exchanges between apparatus on a worksiteUS20070225909 *Feb 20, 2007Sep 27, 2007Denso CorporationNavigation apparatusUS20070271551 *Jun 24, 2004Nov 22, 2007Thomas ZurawkaElectronic Control Unit and Method for Specifying a Software Architecture for an Electronic Control UnitUS20080140571 *Dec 12, 2006Jun 12, 2008General Motors CorporationMethod for controlling the distribution of vehicle-related dataUS20090047904 *Oct 24, 2008Feb 19, 2009Medius, Inc.Method and apparatus for dynamic configuration of multiprocessor systemUS20090204400 *Jul 16, 2008Aug 13, 2009Shields T RussellSystem and method for processing a spoken request from a userUS20090204407 *Feb 8, 2008Aug 13, 2009Shields T RussellSystem and method for processing a spoken request from a userUS20100125387 *Sep 29, 2009May 20, 2010Chung-Ang University Industry-Academy Cooperation FoundationSystem of integrated telematics service and method of controlling the systemUS20100241312 *May 27, 2010Sep 23, 2010Medius, Inc.Wireless telecommunications methodUS20100312433 *Dec 9, 2010Medius, Inc.System and method for restricting access to vehicle software systemsUS20100332357 *Sep 13, 2010Dec 30, 2010Medius, Inc.Method and apparatus for dynamic configuration of multiprocessor systemUS20110066318 *Mar 17, 2011Medius, Inc.Wireless telecommunications methodUS20110136508 *Jun 9, 2011Mundi FomukongUpdating a Mobile Device's LocationUS20130103811 *Apr 6, 2011Apr 25, 2013Volker BlaschkeMethod for providing a communication for at least one deviceUS20130345898 *Jun 21, 2013Dec 26, 2013Lg Electronics Inc.In-vehicle infotainment device and data processing method using the sameUS20140067152 *Aug 31, 2012Mar 6, 2014General Motors LlcProviding vehicle operating information using a wireless deviceCN100565446CApr 26, 2005Dec 2, 2009宝马股份公司Configuration system of a vehicle and method for configuring at least one control unit of the configuration systemDE102004051414A1 *Oct 22, 2004Apr 27, 2006Volkswagen AgCommunication device for motor vehicle, has interface between connecting module and indicator or between connecting module and control unit for transferring data of independent format between indicator, control unit and connecting moduleWO2005041519A2 *Oct 21, 2004May 6, 2005Leica Geosystems AgMethod and apparatus for managing information exchanges between apparatus on a worksiteWO2005041519A3 *Oct 21, 2004Jun 16, 2005Leica Geosystems AgMethod and apparatus for managing information exchanges between apparatus on a worksiteWO2006114112A1 *Apr 26, 2005Nov 2, 2006Bayerische Motoren Werke AktiengesellschaftConfiguration system of a vehicle and method for configuring at least one control unit of the configuration system* Cited by examinerClassifications U.S. Classification701/1, 701/24, 701/36International ClassificationG08G1/09, G06F15/177, H04B7/26, G06F9/48, B60R21/01Cooperative ClassificationB60R2021/0104, G08G1/09European ClassificationG08G1/09Legal EventsDateCodeEventDescriptionJul 6, 2000ASAssignmentOwner name: DAIMLERCHRYSLER AG, GERMANYFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:STUEMPFLE, MATTHIAS;JAMEEL, AKTHAR;FUCHS, AXEL;REEL/FRAME:010898/0692;SIGNING DATES FROM 20000324 TO 20000612Jun 29, 2006FPAYFee paymentYear of fee payment: 4May 14, 2008ASAssignmentOwner name: DAIMLER AG, GERMANYFree format text: CHANGE OF NAME;ASSIGNOR:DAIMLERCHRYSLER AG;REEL/FRAME:020976/0889Effective date: 20071019Owner name: DAIMLER AG,GERMANYFree format text: CHANGE OF NAME;ASSIGNOR:DAIMLERCHRYSLER AG;REEL/FRAME:020976/0889Effective date: 20071019Jun 11, 2008ASAssignmentOwner name: DAIMLERCHRYSLER AG, GERMANYFree format text: CORRECTIVE ASSIGNMENT TO CORRECT THE IDENTIFYING INFORMATION IN THE ASSIGNMENT DOCUMENT PREVIOUSLY RECORDED ON REEL 010898 FRAME 0692. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT OF ASSIGNOR S INTEREST.;ASSIGNORS:STUEMPFLE, MATTHIAS;JAMEEL, AKTHAR;FUCHS, AXEL;REEL/FRAME:021078/0951;SIGNING DATES FROM 20000324 TO 20000612Owner name: DAIMLERCHRYSLER AG, GERMANYFree format text: CORRECTIVE ASSIGNMENT TO CORRECT THE IDENTIFYING INFORMATION IN THE ASSIGNMENT DOCUMENT PREVIOUSLY RECORDED ON REEL 010898 FRAME 0692;ASSIGNORS:STUEMPFLE, MATTHIAS;JAMEEL, AKTHAR;FUCHS, AXEL;REEL/FRAME:021078/0951;SIGNING DATES FROM 20000324 TO 20000612Oct 22, 2008ASAssignmentOwner name: RAMSLE TECHNOLOGY GROUP GMBH, LLC, DELAWAREFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DAIMLER AG;REEL/FRAME:021719/0080Effective date: 20080727Jun 22, 2010FPAYFee paymentYear of fee payment: 8Jun 24, 2014FPAYFee paymentYear of fee payment: 12Dec 22, 2015ASAssignmentOwner name: OL SECURITY LIMITED LIABILITY COMPANY, DELAWAREFree format text: MERGER;ASSIGNOR:RAMSLE TECHNOLOGY GROUP GMBH, LLC;REEL/FRAME:037358/0685Effective date: 20150826RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services