WO2008019333A2 - Procédé et système pour intégrer et gérer des composants et sous-systèmes - Google Patents

Procédé et système pour intégrer et gérer des composants et sous-systèmes Download PDF

Info

Publication number
WO2008019333A2
WO2008019333A2 PCT/US2007/075250 US2007075250W WO2008019333A2 WO 2008019333 A2 WO2008019333 A2 WO 2008019333A2 US 2007075250 W US2007075250 W US 2007075250W WO 2008019333 A2 WO2008019333 A2 WO 2008019333A2
Authority
WO
WIPO (PCT)
Prior art keywords
control
hardware components
client
abstraction layer
server
Prior art date
Application number
PCT/US2007/075250
Other languages
English (en)
Other versions
WO2008019333A3 (fr
Inventor
Allan Dale
Thomas Bayerl
Craig Mahaney
Original Assignee
Lectronix, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lectronix, Inc. filed Critical Lectronix, Inc.
Priority to CA002659271A priority Critical patent/CA2659271A1/fr
Priority to EP07800020A priority patent/EP2047362A4/fr
Publication of WO2008019333A2 publication Critical patent/WO2008019333A2/fr
Publication of WO2008019333A3 publication Critical patent/WO2008019333A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers

Definitions

  • the present invention relates to a method and system for integrating, developing and controlling components and subsystems for use in an embedded system.
  • a method and system for integrating and controlling components and subsystems for use in an embedded system includes a computer-implemented method for development of a module for controlling an embedded system is disclosed.
  • the method includes providing an abstraction layer for the one or more operating systems of the embedded system.
  • One or more device drivers compatible for use with the one or more hardware components and operating systems of the embedded system are provided and may be used by the abstraction layer to function under the one or more operating systems of the embedded systems to create a control module.
  • a client server architecture may be created for the control module to use the abstraction layer to function under the one or more operating systems of the embedded system to interface between the one or more device drivers to control the functions of the one or more hardware components.
  • the system and method may also include a tangible machine readable medium having instructions for generating a control module for one or more embedded systems, that when executed cause the machine to create the module as described herein.
  • FIGURE 1 shows a diagram of a method for development of a control module for integrating components and subsystems according to one exemplary embodiment of the present invention
  • FIGURE 2 shows a diagram of a control module for use in an embedded system incorporated in a product according to one exemplary embodiment of the present invention
  • FIGURE 3 shows a diagram of a control module of an embedded system having multiple components created with the method of the present invention
  • FIGURE 4 shows a diagram of abstraction and device layers of an exemplary control created in accordance with the method of the present invention
  • FIGURE 5 shows a diagram of an exemplary client-server architecture of a control module illustrated in Figure 2 and configured for use in connection with the present invention
  • FIGURE 6 shows a diagram of a user interface process in a three server application in a control module created with the method of the present invention.
  • FIG. 1 the architecture of the method and system for creating a control module for use with an embedded system developed with the present invention is illustrated. It is understood that the control module used with the system may be of various configurations and may contain greater or fewer number of components to accomplish similar objectives.
  • An embedded system for exemplary purposes, may be considered a set of hardware and software dedicated to a particular purpose or use.
  • An embedded system may be embedded in a higher level system to perform the particular function or any electronic system that uses a processor. Such systems generally use microprocessors, or they may use custom-designed chips or both. It is understood that the system and method described herein may also be used in a computing environment, such as a distributed computing environment.
  • the method for developing a control module for use in controlling an embedded system includes the use of an architecture that allows for portability, modularity, is easily distributable and accommodates replaceable user interfaces. Portability addresses the need to be able to move the system functionality rapidly to new hardware platforms and operating systems. At least two of the elements used to achieve this are the operating system abstraction (OSAPI) shared library, which may provide a generic portable abstraction of operating system specific calls, and the use of layered device drivers, which can be rapidly ported across different hardware and operating system platforms.
  • OSAPI operating system abstraction
  • Modularity deals with the ability to easily create control module builds that include or exclude sets of features.
  • One element of modularity is packaging functionality into separate processes, since this helps prevent functions from becoming entwined with one another.
  • processes that may be geographically diverse intercommunicate over a networked communication path to produce a single cohesive system out of independent processing modules.
  • the system and method of the present invention may be configured for use with derivative products requiring the user interface process be maintained as a discrete module that can be modified or replaced on a per-product basis. This allows the functionality of the platform to be repackaged with entirely unique look and feel. While the architecture as a whole has been constructed to achieve these goals, it is still important to consider underlying rationales while implementing specific software components to avoid practices that defeat the intended flexibility. For example, a user interface that talks extensively to device drivers and other local services may still be portable and modular, but loses the ability to be distributed across the network, whereas this distribution is possible if the application limits its access to client-server calls to the servers.
  • Control module 10 for use in an embedded system created with the method according to the present invention is illustrated in Figure 1.
  • Control module 10 includes a client-server architecture 12 interfacing with one or more device drivers 14 and a shared operating system abstraction library (OSAPI) 16. These components cooperate with a user interface application shown in block 18 to present various information to an operator.
  • User interface 18 may cooperate with one or more clients 23 configured work in connection with a discrete hardware component 20 as shown in Figure 2 or may be configured to work with a variety of third party devices to display relevant information or controls to the user. It is contemplated that the user interface and high-level applications act as clients to the servers.
  • a computer-implemented method for development of a module for controlling an embedded system may comprise at least the following steps of providing an abstraction layer for the one or more operating systems of the embedded system.
  • the method identifies the one or more client hardware components and one or more operating systems of the embedded system.
  • One or more device drivers compatible for use with the one or more hardware components of the embedded system using the abstraction layer to function ⁇ nder the one or more operating systems of the embedded system are obtained.
  • a client server architecture using the abstraction layer to function under the one or more operating systems of the embedded system to interface between the one or more device drivers to control the functions of the one or more hardware components is created for the control module.
  • the system and method may also include a tangible machine readable medium having instructions for generating a control module for one or more embedded systems, that when executed cause the machine to create the module as described herein.
  • software components of the control module 10 may include one or more client-server processes, device drivers and shared runtime libraries, all of which may utilize OSAPI for use in the embedded system 19, for example, in a vehicle 21.
  • OSAPI 16 provides a layer that converts abstracted calls into operating specific calls as will be described in greater detail below.
  • a client-server process may be an independent executable module, containing one or more execution threads, that runs within its own protected memory space.
  • user interface client process 18 communicates to and controls a set of middleware logic or server processes 22 that each provide a specific service. These processes communicate using a client-server model shown by reference numeral 12.
  • middleware may function, but is not required to, function as a server element.
  • Functionality may be implemented in servers 22 in the client server model 12 to monitor and control the integrated technology connected to the system.
  • Servers 22 maintain portability by using the OSAPI abstraction layer for its operating system and hardware access requirements.
  • the functionality incorporated as part of the client server architecture includes creating logic in communication with the abstraction layer for management and control of the one or more hardware components and creating a user interface in communication with the servers to display commands for use by an operator of the embedded system to control the one or more hardware components.
  • the abstraction layer provides operating system and hardware component access requirements to the client server architecture to allow control of the embedded system.
  • Client-server architecture may also include a single user interface for one or more servers to display commands for use by the user to operate the embedded system that may be graphically displayed on a video display screen incorporated in the embedded system.
  • FIG. 3 illustrates an exemplary system with multiple components in a vehicle 21.
  • the client-server interfaces of the servers are described and illustrated.
  • the interface consists of client object method functions used to control the corresponding server, and server responses that are generated in response or to notify of changed status.
  • the message pay load of the client calls to the server may be completely hidden within the client interface objects.
  • One or more device drivers 14, individually represented by reference numeral 24, may include elements to provide connection, access and/or control to the hardware devices within the system. In some cases, common services may be required for use by multiple processes or device drivers.
  • Device drivers may be program routines that link the operating system to a component or device. The drivers typically contain the machine language necessary to perform the functions requested by the application.
  • a single instance of such code can be placed into a shared common library 16.
  • the mechanism to support this may vary by operating system used in connection with the components or subsystem, such as Windows CE and QNX.
  • the library 16 may be used for services such as the OSAPI abstraction layer and configuration file access.
  • System platform device drivers 14 may comprise layered drivers having two or more layers associated therewith.
  • layered device driver includes a first layer or command layer and a second layer or access layer.
  • the layered drivers may be configured to work with the client server architecture to provide instructions and/or commands to the components to access, operate and/or control one or more components and features of the components.
  • the application layer 26 includes the user interface 28 and servers 30.
  • the user interface box represents the graphics rendering and other operating system specific input/output portions of the application.
  • the user interface communicates with the servers through TCP/IP InterProcess Communication (IPC).
  • IPC TCP/IP InterProcess Communication
  • the system architecture considers the graphics rendering of the user interface 28 to be operating system dependent. However, the user interface 28 may also run on multiple operating systems with a component designed to handle operating system specific matters.
  • Servers 30 provide the core application functions including radio, jukebox, audio media player, trip computer and overall system control among other modules. The servers maintain portability by using the OSAPI abstraction layer for its operating system and hardware access requirements.
  • the system includes an OSAPI adaptation layer 32 that converts abstracted calls into operating system specific calls.
  • An abstraction layer typically implies that there are two or more implementations of the target program, so that one set of program calls, or application programming interfaces (API) works on different platforms or environments.
  • An API may include a language and message format used by an application program to communicate with the operating system or some other control program such as a communications protocol. APIs may be implemented by writing function calls in the program, which provide the linkage to the required subroutine for execution.
  • the OSAPI adaptation layer 32 cooperates with an operating specific API layer 34 for various operating systems such as Windows NT, Windows CE and QNX among others.
  • the OSAPI adaptation layer does not preclude the use of existing off-the-shelf applications in the system. While the applications may be operating system specific, they may also include internal operating system abstractions of their own that make them portable for use in various systems and configurations.
  • the client server portion 12 of the application may be configured for use in connection with one or more embedded systems in a vehicle.
  • the method and system of the present invention may be configured for use in various industries for a variety of applications, such as in the consumer electronics industry with cell phones and personal digital assistants (PDA) or in connection with point of sale terminals sold to retailers.
  • PDA personal digital assistants
  • a client-server architecture 12 utilizes high-level InterProcess Communications (IPC) abstracted components consisting of a client portion and a server portion.
  • IPC InterProcess Communications
  • the software interface to the IPC may be built to use a variety of communication methods and/or communications protocols, such as the TCP/IP BSD socket layer.
  • the interface may be incorporated within OSAPI or programming language client objects that expose method calls for all middle- ware services.
  • the Transmission Control Protocol (TCP) stream socket type may be used to provide guaranteed and in-order delivery of packets. Additionally, the keep- alive property is used to ensure the sockets stay connected even when data flows are sparse. Further, the client side will attempt to reconnect to the server if a broken link is detected. Thus, clients will gravitate to a new server if a server was shut down and restarted for any reason.
  • TCP Transmission Control Protocol
  • socket connections For each client-server connection, two socket connections may be established. Each of these connections carries a full-duplex packet stream between client and server. One of two connections used to carry asynchronous messages (commands) from the client to the server. When the server receives messages on this connection, the protocol layer automatically responds with an acknowledgment over that same connection back to the client.
  • the second connection is used in a similar manner, but in the reverse direction for messages that originate from the server (such as responses or status updates) and are acknowledged by the client.
  • a client object exposes method functions for control to the client application. These method functions transmit appropriate commands over the TCP/IP socket to the server where a function is invoked to process the command. Once the client interface transmits the command to the server, it enters into a blocking wait for an acknowledgment from the server. In the event of a timeout, the request is retransmitted. Otherwise, until the acknowledgment is received, execution of the calling client thread is stalled.
  • the protocol layer automatically sends the acknowledgment back to the client.
  • This acknowledgment is sent prior to processing the command, and is an indication only that the packet was received, not that its contents are valid. Sending the acknowledgment prior to processing the message ensures that the stalled client thread is freed to continue execution as quickly as possible.
  • the server process generates a status message back to the client in response to the command.
  • the server process may send back to the client information regarding the frequency to which the radio server is tuned. This message travels across the second socket connection.
  • a dedicated thread in the client process receives the incoming status message, returns an immediate acknowledgment to the server, and then invokes the application's function to process the incoming message or status update.
  • the application's function is registered by the application layer when it initiates the client interface object.
  • the basic execution thread may include the main user interface (UI) event thread blocks waiting for user inputs, such as button presses.
  • the UI server process calls the appropriate client object methods to control the servers.
  • the main server thread blocks waiting for commands over the client-server connection.
  • the server When executing received commands, the server generates response messages, such as status updates back to the client.
  • client interface threads for which there may be one for each client in the user interface process, block waiting for status updates from the server or servers.
  • Figure 6 illustrates the basic threads that might exist in a typical three-server application of the system framework.
  • a basic user interface process 64 would typically consist of a single input event thread, and a dedicated listener thread for each client interface that receives status updates from the server.
  • the user interface application may explicitly create these threads or create the threads as part of the client interface object instantiation and are the threads that are active whenever the application's functions are invoked due to incoming server status messages. More complex processing requirements often introduce additional client or server worker threads that are not depicted in the Figure.
  • this acknowledgment generation is protected with a mutex that only permits processing of one command at a time. This protection introduces some synchronization between the client and servers. Assuming an initial idle state, when client or server initially sends a message, the opposite side will take the mutex, send an immediate acknowledgment, and then begin processing the message. If an additional message is sent while the first message is still being processed, the sending process will wind up blocked waiting for its acknowledgment until the first message completes and the mutex is released.
  • the responses and status events from the servers are handled as asynchronous events.
  • the typical execution flow is the client-side sends a command and then is later notified by an asynchronous message from the server of any status changes.
  • an additional layer to block the calling client until a response is received by way of a synchronous response has been implemented, most notably for query calls to the SQL database server.
  • system platform may be configured to control a plurality of systems and components for vehicles, including vehicle control systems, vehicle condition monitoring systems, communications, telematics, climate control and navigation and entertainment components, such as portable media devices, mobile telephones, media players tuners and storage devices. Exemplary components are described for reference purposes.
  • Block 40 represents a radio component.
  • the AM/FM radio server handles all tuning aspects of the AM/FM tuner module in the system platform. It provides basic tune, seek, and scan support. Radio servers are implemented with and without built in preset support. Preset information may be maintained by the user interface application using the database server rather than built in to the radio server.
  • the AM/FM radio server component 40 typically includes a connection to one or more device drivers 41 that cooperate with the component 41 to allow the client-server platform to control the device.
  • Block 42 represents a satellite radio component.
  • the satellite radio server may communicate to the satellite receiver module via a communications link, such as a serial communications link.
  • a communications link such as a serial communications link.
  • Block 44 represents a video server and video media player.
  • Hardware component 20 of the system 10 illustrated in Figure 1 supports display of video-in-a- window on its main LCD display.
  • This server component manages the video overlay region size and position and provides an interface to control what video source is displayed in the overlay window.
  • Block 46 represents a local database service.
  • a local database is used by various server components to hold information about internal and removable content, such as audio content.
  • the user interface layer code utilizes the information in the database both for display purposes during playback and to assist in the creation of song lists.
  • the interface to the database engine is raw SQL commands.
  • a single-threaded interface to the local database service is desirable in most every instance of its use.
  • Block 48 represent an audio media player (AMP) server.
  • AMP audio media player
  • Several different types of audio media players conform to this class, including but not limited to File Server Players, ATAPI players, and Smart Device Players.
  • Each Audio Media Player has a Song Selector, Play List Selector, and an associated Media Device.
  • the Media Device may be responsible for detecting the presence and status, such as the insertion and ejection, of media.
  • the Media Device may also be responsible for interrogating the media for file types and processing them.
  • the Audio Media Player establishes a client to the Audio Zone
  • the AZM broadcasts what audio source is in each zone.
  • Audio Media Player can use this to determine when to request or relinquish use of the particular shared Sound Device Driver the Audio Media Player may be associated with at the time.
  • Block 50 represents a system player.
  • the system player server component allows user interface code access to retrieve current real-time clock data and to power down the system. Additionally the component handles the controls for the audio amplifiers with respect to sleep and mute, though there is no direct client control.
  • Block 52 represents a display server.
  • the display server component handles manipulations of display parameters according to user requests and vehicle controls.
  • One such example is the LCD display backlight intensity.
  • the user may wish to modify the intensity to different values when the headlamps are on and when they are off. Additionally, the backlight intensity may change according to the dash illumination dimmer control.
  • the display server makes a connection to the Trip Player to obtain the parameter for use in setting the display backlight intensity.
  • Block 54 represents an update manager component.
  • the update manager server component handles the specifics of updating various system software and data file components from removable media.
  • the update manager can accomplish updates of the boot image and application image in Flash, license files, and other content such as navigation and entertainment databases.
  • the update manager detects the presence of update media, as indicated by the presence of one or more update files and/or license files.
  • the update manager works with the license manager to accomplish updates.
  • Block 56 represents an Audio Zone Manager (AZM).
  • the system may be designed to manage either a single zone or multiple zone configurations.
  • the AZM is the point of control for what audio source is playing in which zone. Audio characteristics (e.g. volume, tone, equalization, balance, etc.) are controllable on a per-zone basis.
  • the AZM also provides a method whereby a priority audio message can be played over any audio source in a zone. This feature is useful for handling high priority messages for applications such as voice-assisted navigation prompts.
  • Block 58 represents a system monitor or trip player component.
  • the trip player server component provides an IPC interface to vehicle information. It aggregates information provided by any number of device drivers that implemented the Vehicle Information interface. Limits on each parameter are driven from configuration files. As well as raw information the trip player provides trip computer functions including calculating values such as gallons-of-fuel-to-go to complete trip, etc.
  • the trip player maintains a central repository for checklists (e.g. departure, arrival, etc.). The number of checklists and their contents is driven by configuration files.
  • the trip player maintains a central repository for maintenance items, e.g. tire rotation, oil change, etc.
  • the service rate for maintenance items is specified in terms of miles.
  • the maintenance items are driven by configuration files.
  • the checklists are configurable text that does not change dynamically, so clients can request it as required. Vehicle parameters do change dynamically.
  • Clients can register to receive periodic updates of any number of parameters.
  • the update rate is a configuration parameter for the trip player as a whole.
  • Block 60 represents a license manage server, which accesses licensing information for use by the system.
  • Block 62 represents a navigation system having a variety of functions for monitoring and displaying driver assistance information, including route guidance, map rendering and vehicle location. It is contemplated that the system may manage and control a variety of other components.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

La présente invention concerne un procédé et un système pour intégrer et commander un dispositif matériel ayant un ou plusieurs système(s) imbriqué(s) comprenant un ou plusieurs composant(s) matériel(s) configurable(s) à utiliser avec le dispositif matériel et un ou plusieurs système(s) d'exploitation intervenant avec un ou plusieurs composant(s) matériel(s). Un module de commande configurable en vue d'une utilisation avec le ou les dit(s) composant(s) matériel(s) et avec un ou plusieurs système(s) d'exploitation accède au(x) dit(s) composant(s) matériel(s) et le(s) commande avec le dispositif matériel. Le module de commande génère et affiche les commandes d'accès et de commande sur le dispositif matériel pour permettre à l'utilisateur d'exploiter et de gérer le système imbriqué.
PCT/US2007/075250 2006-08-04 2007-08-06 Procédé et système pour intégrer et gérer des composants et sous-systèmes WO2008019333A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CA002659271A CA2659271A1 (fr) 2006-08-04 2007-08-06 Procede et systeme pour integrer et gerer des composants et sous-systemes
EP07800020A EP2047362A4 (fr) 2006-08-04 2007-08-06 Procédé et système pour intégrer et gérer des composants et sous-systèmes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US83555806P 2006-08-04 2006-08-04
US60/835,558 2006-08-04

Publications (2)

Publication Number Publication Date
WO2008019333A2 true WO2008019333A2 (fr) 2008-02-14
WO2008019333A3 WO2008019333A3 (fr) 2009-05-22

Family

ID=39033601

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/075250 WO2008019333A2 (fr) 2006-08-04 2007-08-06 Procédé et système pour intégrer et gérer des composants et sous-systèmes

Country Status (3)

Country Link
EP (1) EP2047362A4 (fr)
CA (1) CA2659271A1 (fr)
WO (1) WO2008019333A2 (fr)

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU3109399A (en) * 1998-03-23 1999-10-18 Claude Cajolet Application program interfaces in an operating system
US6253122B1 (en) * 1999-06-14 2001-06-26 Sun Microsystems, Inc. Software upgradable dashboard
JP3739615B2 (ja) * 1999-11-30 2006-01-25 三菱電機株式会社 車載用情報処理装置および記録媒体
US7092803B2 (en) * 2000-08-18 2006-08-15 Idsc Holdings, Llc Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components
US7269482B1 (en) * 2001-04-20 2007-09-11 Vetronix Corporation In-vehicle information system and software framework
US7069546B2 (en) * 2001-12-03 2006-06-27 Corrigent Systems Ltd. Generic framework for embedded software development
US20050120340A1 (en) * 2003-12-01 2005-06-02 Skazinski Joseph G. Apparatus, system, and method for automated generation of embedded systems software
US20050209832A1 (en) * 2004-02-05 2005-09-22 Electronic Data Systems Corporation System and method for developing embedded systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of EP2047362A4 *

Also Published As

Publication number Publication date
EP2047362A2 (fr) 2009-04-15
CA2659271A1 (fr) 2008-02-14
EP2047362A4 (fr) 2010-12-29
WO2008019333A3 (fr) 2009-05-22

Similar Documents

Publication Publication Date Title
US7681201B2 (en) Method and system for integrating and controlling components and subsystems
US20040056890A1 (en) Method and system for provisioning mobile device machine interfaces
US8352282B2 (en) System and method for managing and deploying functional services to a vehicle client
EP1347377B1 (fr) Gestionnaire d'interface utilisateur avec prioritisation
US20190303212A1 (en) Method for managing application configuration state with cloud based application management techniques
US8659505B2 (en) Auxiliary display device driver interface
US7779427B2 (en) Automated application configuration using device-provided data
US8498629B2 (en) Extensible human machine interface (HMI) plugin architecture for radio software system and related method
US20060036356A1 (en) System and method of vehicle policy control
US7747683B2 (en) Method and system for operating applications for remote terminal devices
WO2007006126A1 (fr) Procede et systeme pour heberger et executer une application a composants
CN111126895A (zh) 一种复杂场景下调度智能分析算法的管理仓库及调度方法
KR102262926B1 (ko) 차량용 소프트웨어 제어 장치
JP4892933B2 (ja) 車両用マルチメディア装置
EP1347619B1 (fr) Méthode et système de stockage de préférences utilisateur
JP2007503031A (ja) ウェブ・サービス許可及び展開の基盤
US8768412B2 (en) Extensible infotainment/telematics system having fixed base unit control of a portable communication device
WO2008019333A2 (fr) Procédé et système pour intégrer et gérer des composants et sous-systèmes
CN116225362A (zh) 多系统播放音频的方法、装置、存储介质及电子设备
JP6285579B2 (ja) ロングポーリング処理方法およびシステム、並びに記録媒体
EP4322474A1 (fr) Commande de système à capacité limitée
US20230367579A1 (en) Method and apparatus for controlling virtualized vehicle structure-based system
Bhaskaran et al. Distributed Java Architecture for Telematics Services
CN117812099A (zh) 数据显示方法、车机系统、车辆以及存储介质
CN115002729A (zh) 车载信息处理方法、装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07800020

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 127/MUMNP/2009

Country of ref document: IN

ENP Entry into the national phase in:

Ref document number: 2659271

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2007800020

Country of ref document: EP

NENP Non-entry into the national phase in:

Ref country code: DE

NENP Non-entry into the national phase in:

Ref country code: RU