WO2010060541A1 - Verfahren und vorrichtung zur verteilten konfiguration von telematik-diensten in kraftfahrzeug-systemen - Google Patents

Verfahren und vorrichtung zur verteilten konfiguration von telematik-diensten in kraftfahrzeug-systemen Download PDF

Info

Publication number
WO2010060541A1
WO2010060541A1 PCT/EP2009/008051 EP2009008051W WO2010060541A1 WO 2010060541 A1 WO2010060541 A1 WO 2010060541A1 EP 2009008051 W EP2009008051 W EP 2009008051W WO 2010060541 A1 WO2010060541 A1 WO 2010060541A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
format
computer
motor vehicle
data format
Prior art date
Application number
PCT/EP2009/008051
Other languages
English (en)
French (fr)
Inventor
Christian Gerstberger
Ralph Harry Goeckelmann
Dirk Lehmann
Teodora Nikolaeva Guenkova-Luy
Original Assignee
Bayerische Motoren Werke Aktiengesellschaft
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 Bayerische Motoren Werke Aktiengesellschaft filed Critical Bayerische Motoren Werke Aktiengesellschaft
Priority to CN200980147425.2A priority Critical patent/CN102227727B/zh
Publication of WO2010060541A1 publication Critical patent/WO2010060541A1/de
Priority to US13/117,499 priority patent/US20110282889A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station

Definitions

  • the invention relates to a method and a device for the computer-aided processing of data, in particular configuration data, for one or more telematics services in a motor vehicle.
  • data In a motor vehicle, data must be provided for the provision of telematics services, which includes information, for example about the establishment of a connection setup to a computer of a service provider, portal access data, vehicle profiles, configuration parameters and the like. Since in a motor vehicle, the resources of the computer installed therein (so-called control devices) are limited in terms of their computing power and storage capacity, the data must be kept in such a way that they have the least possible storage space and access to this can be done with the lowest possible computing power. An efficient storage of the data is also necessary in order to keep the response times to the receipt of the desired data as low as possible when querying certain data.
  • the invention provides a method for computer-aided processing of data, in particular configuration data, for one or more telematics devices in a motor vehicle.
  • the data is provided in a hierarchical data structure (i.e., data tree) in a first predetermined data format.
  • the provision of the data in the first data format can take place, for example, on a computer of the provider of the telematics service.
  • the data is then transferred from the first data format to a second data format in which the data is placed in one or more tabular data structures that include the contents of the first data format but no longer the hierarchical structure. These are made available in the motor vehicle for further processing.
  • the data contained in the second data format is reproduced in a textual data structure as a readable format or as a persistent database.
  • the data in the first data format are specified according to an XML (eXtectual Markup Language) specification, i. in XML format.
  • the data is available in the hierarchical data structure.
  • the tabular data structure is generated therefrom and made available in the motor vehicle.
  • MOST Media Oriented Systems Transport
  • MOST Media Oriented Systems Transport
  • MOST is a vehicle-specific architecture for metadata and media transmission. Therefore, the generated data structures correspond to objects that are transferable via MOST and can be used in the different motor vehicle computers.
  • the usual known XML validation forms include either complete validation of the data tree or no validation at all. However, to achieve the target format on MOST, a minimum of validation is necessary.
  • map the data in the first predetermined data format into a predetermined data model having a previously known data structure.
  • the data model comprises one or more configurations, to each of which one or more semantic data blocks can be assigned.
  • one or more XML instance documents are expediently provided for each configuration on the computer of a service provider. If required, they are transferred to the vehicle computer of the service user via Internet technologies.
  • the data for the internal configuration of the vehicle control units for telematics services must be prepared.
  • the individual data blocks of the configuration have a specific structure that can be represented in a table.
  • the inventive method has the advantage that after the transformation into the second data format in which the data are arranged in the tabular data structure, the plurality of original XML documents is no longer needed, so that the processing in the motor vehicle is considerably simplified.
  • the validation of the data is simplified because the heuristic validator requires only a specific recognition of the XML elements at the XML tree root area. The rest of the data block can be split off. The preparation is based only on the depth of the sub-trees. This heuristic procedure is referred to in this specification as "partial validation".
  • the data blocks are formal representations of ISO-OSI 0 Layers 2-3 (Connectivity) and Layers 4-7 (Services), they have specific, previously known, structures that can be specified as a structuring model for MOST objects.
  • This data block is also referred to as a "connectivity" or "connection object.”
  • one of the data blocks comprises data relating to services and / or interference features .
  • This data block is also referred to as a "services" or service objects.
  • Another of the data blocks includes data concerning restrictions.
  • the data model which preferably comprises all of the said data blocks, already enables simplified administration in the provision of the data in the first data format in the second Date ⁇ format and the provision in a data structure corresponding to the hierarchical data structure in the motor vehicle simplified access to the data, which can be made in particular self-sufficient by the computer of the motor vehicle.
  • the data of a Date ⁇ blocks can be arranged and stored according to a further embodiment in one or more sub-data blocks.
  • a further structuring of the data is possible, whereby the data access is further improved by the computer of the motor vehicle. That is, the further recognition and validation of the configuration data (down to individual parameters and values in the model) is done specifically in the telematics services and applications that are the actual users of the configurations.
  • Partial Validation is also a computational and software module-distributed validation, unlike traditional XML validation methods.
  • each parameter and the associated parameter value are assigned a path, wherein the path statement comprises at least one identifier for the relevant data block and the optional sub-data block (s).
  • the tabular data format each parameter of a Date ⁇ blocks is thus preceded by a path. In this way, it is possible, on the one hand, the tabular representation in text form again manufacture.
  • XPath 0 as the basis for the link representation, it is possible to perform database queries on the MOST objects.
  • the data in the first predetermined data format from a first computer of a computer network to a second computer of the motor vehicle, in particular wireless, transmitted and transferred from the second computer of the motor vehicle in the second data format.
  • the processing of the data in the first data format for the motor vehicle is a hindrance, the conversion into the second data format is performed by a computer of the motor vehicle, which offers the described advantages in the processing.
  • the data model is valid.
  • the check is based on the tabular data structure.
  • the verification of the data model is carried out after one, in particular after each, modification and / or supplementation of the data in the first data format and subsequent transfer to the second Date ⁇ format.
  • a change and / or addition of the data can be made by adding corresponding parameters with their parameter value and the path specification either to the data in the second data format or overwriting a changing value.
  • data that exists in XML data format must be updated by completely overwriting the entire XML document. As a result, however, an increased compared to the inventive procedure time required for data transmission and for the processing of the data in the motor vehicle.
  • the checking of the data model is carried out in a simple manner by checking the presence of at least one of the identifiers of one of the data blocks. Accordingly, it is sufficient if the data transferred to the second data format is checked only for the presence of a single identifier of one of the data blocks. This allows verification in a simple way and in a short time respectively. A check of the consistency of the parameters or parameter values of each date, however, does not take place at this time.
  • a non-validating, event-based parser such as SAXO and 0 is used for processing the data in the motor vehicle, which performs the processing of the data without prior semantic verification and only checks the structure of the XML instances to be processed ( Only a "Wellformness” check is performed.) This can increase the efficiency and performance of the computer system in the motor vehicle since the specific semantic check is performed as a distributed task between multiple applications and computers as needed (ie "Partial validation ").
  • the data in the second data format, in particular in or by the same or a second computer, in the motor vehicle is mapped in a third data format which reproduces a textual representation which can be displayed as a human-readable format or on a computer persistent medium can be stored as a database.
  • the invention further encompasses a computer program product which is stored on a computer-suitable medium and can be loaded directly into the internal memory of a digital computer or a plurality of computers which are in communication with one another and comprises software code sections with which the steps of the method described are carried out. if the product is running on the computer (s).
  • the invention further provides a device for the computer-aided processing of data, in particular configuration data, for one or more telematics services in a motor vehicle.
  • the device comprises a first means for providing the data of a hierarchical data structure in a first predetermined data format.
  • the apparatus further comprises a second means for transferring the data into a tabular data structure.
  • the device comprises a third means for providing the data contained in the second data format in a textual form.
  • the device may comprise further means for carrying out the method described above.
  • FIG. 2 shows a data model according to the invention for mapping the data, in particular configuration data
  • Fig. 3 is a schematic representation of an architecture for partial validation of the data.
  • Fig. 1 shows a schematic representation of the invention underlying the procedure.
  • a computer e.g. a computer of a computing network of a service provider
  • data such as e.g. Configuration data provided for one or more telematics services in a hierarchical data structure in a first predetermined data format. It is useful if the data in the first format is provided as XML data. This is indicated by the reference numeral 4.
  • the data present in the first data format is transmitted to a computer 2 of a motor vehicle via a communication link 3, which is designed in particular wirelessly.
  • the present in the hierarchical data structure data of the first Date ⁇ formats be converted into a second data format 5, in which the data are arranged in a tabular data structure.
  • the data are hereby stored in data blocks (BL1, BL2, BL3).
  • the data contained in the second data format 5 are made available to the motor vehicle for further processing or displayed in a third format in textual data form as a readable format.
  • the design of the data structures will be explained in more detail below.
  • Telematics services in the automotive environment require communication with an infrastructure providing the services.
  • the communication between the computer 2 of the motor vehicle and the computer 1 of the infrastructure is preferably carried out via wireless communication technologies.
  • the corresponding services or applications with different transmission technologies eg CSD and GPRS in conjunction with GSM, UMTS, etc.
  • different service provider environments such as Roami ⁇ g
  • the computer 2 used in the motor vehicle must therefore be able to perform different characteristics in order to avoid interruption of an executed service.
  • the computer must be able to use different transmission technologies and perform handovers.
  • telematics services used in the automotive industry must support the data exchange with the network infrastructure in different configurations (see eg [1]).
  • a telematics application includes three main types of configuration associated with different functional abstractions of the services. These are connection configurations, end-to-end performance settings, and related limitations. Constraints represent links between connectivity configurations and end-to-end performance configurations, which may be due to hardware configurations and / or user requirements and / or service provider agreements Level Agreement, SLA) are defined with the users (see [1] to [4]).
  • SLA Level Agreement
  • Hardware restrictions may include, for example, the availability of a particular NAD module, such as a NAD module. a GSM or UMTS device.
  • a user restriction may include permission to activate a particular web address or telephone service.
  • a provider SLA may e.g. specify that only certain types of transmission technologies can be activated, although an NAD module can support more or different technologies through the technologies mentioned in the SLA. Such configurations are stored in the configuration data of a motor vehicle.
  • the model may alternatively be represented by a group of protocols. be part of the model to a session layer protocol and parts belong to a attached presentation layer protocol. This is the case, for example, in the case of SIP [1 1] and SDP [12].
  • the data or configuration model comprises a model route root 10 ("model ID") which can be used as an identifier for the entire model.
  • model ID a model route root 10
  • the identifier may be the name space of the schema or, in the case of DTD (Document Type Definition), the name of the DTD model. Additional identification of the model may be through a content-related definition within a protocol that includes the configuration model. This is described for example in IANA MIME [13], SIP [11] and HTTP [14].
  • the data model may include one or more complete configurations represented by a configuration object 20.
  • the configuration object 20 also includes an identifier: "Config ID.”
  • Config ID Each of the configurations must be identifiable in order to associate the configuration with a specific communication infrastructure. For telematics applications, these may be layers 2 and / or 3 of the OSI reference model [10], protocol identification, such as e.g. GSM SIM [15] or IP Adressieru ⁇ g [16], [17] or the identification of the provider infrastructure via DNS [18].
  • connection object 21 Connected to the configuration object 20 are a connection object 21 ("connectivity"), a service object 22 (“services”) and a restriction object 23 (“contraints”).
  • connection object 21 Connected to the configuration object 20 are a connection object 21 (“connectivity”), a service object 22 (“services”) and a restriction object 23 (“contraints”).
  • service object 22 service objects
  • restriction object 23 constraints
  • children represent the above-described classes of configurations necessary for complete end-to-end performance of a telematics service within a specific technology and / or provider domain.
  • Each of these objects 21, 22, 23 may in turn have one or more "child” configurations:
  • An access data object 31 (“access”) with an access ID identifies a specific access technology and uses as an identifier, for example, the name of the technology (eg, CSD, GPRS, etc.).
  • the access data object 31 is associated with a sub-tree or sub-tree (41) which facilitates the parameterization of the access tech ⁇ ology describes. This includes, for example, the name of an access router to a network, a so-called access point (APN), such as an IP address or a dial-in number or a specific technology performance parameter, such as QoS parameters.
  • APN access point
  • This information is used to configure the automotive telematics system to connect to layer 2 and / or 3 of the OSI reference model.
  • An application object 32 (“application”) with an identifier (“application ID”) identifies layer 3 and the accessibility to an end-to-end connection of an infrastructure service, such as an Internet service provider. a www portal.
  • the associated sub-tree 42 of objects describes parameterizations of the specific applications, e.g. www addresses and QoS service states, such as a retry interval or log time-outs.
  • a constraint object 33 with a contraint ID identifies specific connections between access elements or application elements and between access and application elements.
  • the sub-tree elements 43 define configuration states for executing the telematics function or a class of similar applications.
  • This data model unlike the validation of an XML document, allows partial validation of the data represented by the data model.
  • the specific application for partial validation arises from the case of distributed telematics applications, where different devices and software parts of the application must be configured by the same model to provide data consistency and interoperability. However, the individual devices and software subsystems only retrieve parts of the entire model for their specific configuration.
  • the software architecture for only partially checking the data transmitted to the vehicle is shown in FIG.
  • the architecture is based on a so-called XML Non-Validating Parser 140.
  • This uses classical XML rules for validation to check the (top-level) structure 160 of the data model. These rules are specified via a configurational model class 1 10 and correspond to a semantic model validation.
  • the extracted sub-trees may be structurally checked (150) by a validator 130 to classify data before conditioning into a bus-accessible format.
  • the rules for such a procedure are defined as "model part" class 100.
  • the rules for sub-tree validation follow the natural structure of the sub-model associated with the telematics application.
  • an application and its parameters may expose a two-level sub-tree to divide the model into an application (as a "parent” element), its parameters (as a "child” element), and the parameter values (as element values).
  • a more general definition of a structural verification rule is e.g. An element has at least one child element and at least one grand-child element, where the grand-child element does not have an empty value. None of the elements in the structure has any attributes. " Such specifications define additional restrictions to a predefined XML infoset [20].
  • An XML set defines the rules for the classic "XML-Wellform ⁇ ess" and the validation of documentary documents.These rules can be defined by the reuse of XML schema specifications. The interpretation of a structural validation affects only the shape of the tree, but not its contents (see also Synthetic Infoset [20]).
  • the classic XML representation has a nested structure. This means that it has a start and an end element that "wrapes" content from child and / or grand children definitions, as shown below. ⁇ Xml>
  • Such content is usually represented as an object tree.
  • object trees or sub-trees can be tricky in the case of applications that share the common XML configuration model, since the disassembly / unpackaging of content is necessary to access the data for different software entities and different transport media represent.
  • the invention makes use of a tabular data structure of XML contents which converts the data in a manner similar to the MOST dynamic arrays 0 form.
  • Each individual table represents a configuration block.
  • this tabular form can not be easily read or stored persistently.
  • the invention makes use of a linear data structure of XML contents in which the structure " ⁇ &>" is used as a separator of the so-called XPaths of individual element contents, as shown below:
  • each entry includes a path (here: / xml / configuration / co ⁇ ectivity / conn1 /) and a parameter associated with a value (here, for example, accessnr as a parameter and +1234567890 as a value).
  • a path here: / xml / configuration / co ⁇ ectivity / conn1 /
  • a parameter associated with a value here, for example, accessnr as a parameter and +1234567890 as a value.
  • the separator " ⁇ &>” since the symbols " ⁇ ", ">” and "&" used as separators are XML-reserved symbols (see [22]) ensures backward compatibility in re-compiling the linear data into a classic XML format.
  • the format according to the invention can easily be brought into a vector form, as shown below. This is done by searching for the separator " ⁇ &>".
  • It can be used in software and / or transfer media data containers that correspond to vectors.
  • the data can be easily searched for and extracted using the XPath convention (see [21]) because the internal representation is XPath-based on separators or in a vector. That is, only a comparison of strings without additional decomposition of the data is necessary.
  • the text form can also be transferred via MOST. This is used in the event that the transfer of the data into the text form and the persistent medium are in different control units in the vehicle.
  • the mechanism for representing configuration data can be used for various MOST devices.
  • the data may be represented on a MOST bus in the form of a dynamic data array. This may be done, for example, in a vector form or a classified stream (e.g., in linearized form).
  • the streaming of the data can be done, for example, using the so-called MoCCA middleware from HarmanBecker [23] to type the data for a serial transport. This can be used, for example, to define a new lANA media data type:
  • MoCCA can be used in vehicle-to-vehicle communication. It can be used as a "shared agent system" between motor vehicles and / or Internet-based infrastructures, and in the case where motor vehicles share telematics platforms, the data handling and arrangement mechanisms for configuration information can be provided via Internet protocols such as HTTP or The specification of a common media type is a prerequisite for interoperability between data transfer systems.
  • the software which represents the data via a data transfer system, includes software pieces such as adapters and proxy [24].
  • the interface API, Application Pro- gramable Interface
  • the software depends on the sub-validation algorithm. List of abbreviations used
  • first computer second computer Data transfer path Data in first data format Data in second data format Data in third data format Root of configuration model Configuration object Connection object Service object Restriction object Access data object Application object Restriction object

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Die Erfindung beschreibt ein Verfahren zur rechnergestützten Verarbeitung von Daten, insbesondere Konfigurationsdaten, für einen oder mehrere Telematik-Dienste in einem Kraftfahrzeug. Bei dem Verfahren werden die Daten in einer hierarchischen Datenstruktur in einem ersten vorgegebenen Datenformat (4) bereitgestellt. Des Weiteren werden die Daten von dem ersten Datenformat (4) in ein zweites Datenformat (5) überführt, in dem die Daten in einer tabellarischen Datenstruktur angeordnet werden und in dem Kraftfahrzeug zur weiteren Verarbeitung zur Verfügung gestellt. Schließlich werden die in dem zweiten Datenformat (5) enthaltenen Daten in einer textuelle Form dargestellt als lesbare bzw. persistent abzuspeichernde Daten dargestellt.

Description

Verfahren und Vorrichtung zur verteilten Konfiguration von Telematik- Diensten in Kraftfahrzeug-Systemen
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur rechnergestützten Verarbeitung von Daten, insbesondere Konfigurationsdaten, für einen oder mehrere Telematik- Dienste in einem Kraftfahrzeug.
In einem Kraftfahrzeug müssen zur Bereitstellung von Telematik-Diensten Daten bereitgestellt werden, welche Informationen beispielsweise über die Herstellung eines Verbindungsaufbaus zu einem Rechner eines Dienstanbieters, Portalzugangsdaten, Fahrzeug- Profile, Konfigurationsparameter und dergleichen umfasst. Da in einem Kraftfahrzeug die Ressourcen der darin verbauten Rechner (sog. Steuergeräte) hinsichtlich ihrer Rechenleistung und ihrer Speicherkapazität begrenzt sind, müssen die Daten derart vorgehalten werden, dass diese einen möglichst geringen Speicherbedarf aufweisen und der Zugriff auf diese mit möglichst geringer Rechenleistung erfolgen kann. Eine effiziente Speicherung der Daten ist auch notwendig, um bei Abfragen bestimmter Daten die Antwortzeiten bis zum Erhalt der erwünschten Daten möglichst gering zu halten. Um eine möglichst hohe Performance der in einem Kraftfahrzeug verbauten Rechner ermöglichen zu können, ist es deshalb wünschenswert, dass möglichst viele oder sogar alle der verbauten Rechner auf die gespeicherten Daten zugreifen können. Damit dieser gemeinsame Zugriff gewährleistet werden kann und damit der Speicherbedarf begrenzt werden kann, ist die Unterstützung von einem gemeinsam verständlichen Datenformat notwendig, wodurch auch multiples Kopieren ein und desselben Datensatzes in unterschiedlichen Formaten vermieden wird.
Es ist daher Aufgabe der vorliegenden Erfindung, ein Verfahren und eine Vorrichtung zur rechnergestützten Verarbeitung von Daten, insbesondere Konfiguratioπsdaten, für einen oder mehrere Telematik-Dienste in einem Kraftfahrzeug anzugeben, welche die oben genannten Anforderungen erfüllen.
Diese Aufgabe wird gelöst durch ein Verfahren mit den Merkmalen des Patentanspruches 1 bzw. eine Vorrichtung mit den Merkmalen des Patentanspruches 19. Die Aufgabe wird ferner gelöst durch ein Computerprogrammprodukt mit den Merkmalen des Patentanspru- ches 18. Vorteilhafte Ausgestaltungen sind jeweils in den abhängigen Patentansprüchen wiedergegeben.
Die Erfindung schafft ein Verfahren zur rechnergestützten Verarbeitung von Daten, insbesondere Konfigurationsdaten, für einen oder mehrere Telematik-Dieπste in einem Kraftfahrzeug. Erfindungsgemäß werden die Daten in einer hierarchischen Datenstruktur (d.h. Daten-Baum) in einem ersten vorgegebenen Datenformat bereitgestellt. Das Bereitstellen der Daten in dem ersten Datenformat kann beispielsweise auf einem Rechner des Anbieters des Telematik-Dienstes erfolgen. Die Daten werden dann von dem ersten Datenformat in ein zweites Datenformat überführt, in dem die Daten in einer oder mehreren tabellarischen Datenstrukturen angeordnet werden, die die Inhalte des ersten Datenformats beinhalten, jedoch nicht mehr die hierarchische Struktur. Diese werden in dem Kraftfahrzeug zur weiteren Verarbeitung zur Verfügung gestellt. Schließlich werden die in dem zweiten Datenformat enthaltenen Daten in einer textuellen Datenstruktur als lesbares Format oder als persistente Datenbank wiedergegeben.
Gemäß einer Ausgestaltung des erfindungsgemäßen Verfahrens werden die Daten in dem ersten Datenformat gemäß einer XML (eXteπsible Markup Language)-Spezifikation, d.h. im XML-Format, bereitgestellt. Dabei liegen die Daten in der hierarchischen Datenstruktur vor. Die tabellarische Datenstruktur wird daraus generiert und in dem Kraftfahrzeug zur Verfügung gestellt. Eines der meist verwendeten Kommunikationssysteme im automobilen Infotainment Bereich ist das MOST (Media Oriented Systems Transport) 0. MOST ist eine fahrzeugspezifische Architektur für Meta-Daten und Medienübertragung. Daher entsprechen die generierten Datenstrukturen Objekte, die über MOST übertragbar sind und in den unterschiedlichen Kraftfahrzeug-Rechner verwendbar sind.
Die Anpassung des allgemeinen XML Formats an die für den Fahrzeug übliche MOST Technologie ermöglicht, dass Rechner des Kraftfahrzeugs direkt auf die Daten zugreifen können, so dass eine große Performanz ohne Zwischeπformatierung und Zwischenspei- cherung der Daten erzielt werden kann. Ferner ist es aufgrund der Rechenleistung und der speziellen Betriebssysteme im Fahrzeug ist es auch nicht möglich Standard-XML- Hilfwerkzeuge zu benutzen, da die Fahrzeugumgebung dafür nicht geeignet bzw. nicht performant genug ist. Zum Beispiel erfordert die Verwendung von DOM-Parsern (beschrieben in 0 und 0) eine Zwischendarstellung als Objekt-Baum. Ein Standard-XML- Validierer erfordert das Laden eines zusätzlichen Models für die Datenverarbeitung und Gültigkeitsüberprüfung des Instanzdatensatzes. Daher basiert diese Erfindung nur auf der Nutzung eines simplen SAX-basierten Parsers (beschrieben in 0 und 0) ohne XML- Validierung unter Verwendung von darunter beschriebenen heuristischen Verfahren.
Die üblichen bekannten XML Gültigkeitsüberprüfungsformen umfassen entweder eine Komplettvalidierung des Daten-Baumes oder gar keine Validierung. Allerdings, um das Zielformat auf MOST zu erreichen, ist ein Mindestmass an Gültigkeitsüberprüfung notwendig. Um zu umgehen, die üblicherweise notwendige Komplettvalidierung von im XML- Format vorliegenden Daten vornehmen zu müssen, ist gemäß einer weiteren Ausgestaltung vorgesehen, die Daten in dem ersten vorgegebenen Datenformat in ein vorgegebenes Datenmodell, das eine im Voraus bekannte Datenstruktur aufweist, abzubilden. Insbesondere umfasst das Datenmodell ein oder mehrere Konfigurationen, denen jeweils eine oder mehrere semantische Datenblöcke zugeordnet werden können. Solange die Daten noch in dem ersten Dateπformat, d.h. gemäß XML-Spezifikation, vorliegen, werden für jede Konfiguration auf dem Rechner eines Dienstanbieters zweckmäßigerweise ein oder mehrere XML-Instanzdokumeπte bereitgestellt. Bei Bedarf werden sie über Iπternet- technologien auf den Fahrzeugrechner des Dienstnutzers übertragen. Angekommen im Fahrzeugrechner, müssen die Daten für die interne Konfiguration der Fahrzeugsteuergeräte für Telematikdienste aufbereitet werden. Die einzelnen Datenblöcke der Konfiguration weisen eine spezifische Struktur auf, die entsprechend tabellarisch darstellbar ist. Das erfindungsgemäße Verfahren weist den Vorteil auf, dass nach der Transformation in das zweite Datenformat, bei dem die Daten in der tabellarischen Datenstruktur angeordnet sind, die Mehrzahl an ursprünglichen XML Dokumenten nicht mehr benötigt wird, so dass die Verarbeitung in dem Kraftfahrzeug erheblich vereinfacht ist. Darüber hinaus wird die Validierung der Daten vereinfacht, dadurch dass der heuristische Validierer nur eine konkrete Erkennung der XML Elemente am XML-Baum-Wurzel-Bereich benötigt. Der restliche Dateπblock kann abgespalten werden. Die Aufbereitung basiert nur auf der Tiefe der Sub-Bäume. Dieses heuristische Verfahren wird in dieser Beschreibung als „Partielle Validierung" bezeichnet.
Da die Datenblöcke formale Darstellungen von ISO-OSI 0 Layers 2-3 (Connectivity) und Layers 4-7 (Services) sind, weisen sie spezifische, im Voraus bekannte, Strukturen auf, die als Strukturierungsmodell für MOST Objekte spezifizierbar sind. Insbesondere umfasst einer der Datenblöcke Verbindungsdaten und/oder einen Verbindungsaufbau betreffende Daten. Dieser Datenblock wird auch als „Connectivity" oder Verbindungs-Objekt bezeichnet. Einer der Datenblöcke umfasst gemäß einer weiteren Ausführungsform Dienste und/oder Dieπstmerkmale betreffende Daten. Dieser Datenblock wird auch als „Services" oder Dienste-Objekt bezeichnet. Ein weiterer der Datenblöcke umfasst Beschränkungen betreffende Daten. Dieser wird auch als „Constraints" oder Beschränkungen-Objekt bezeichnet. Das Datenmodell, das vorzugsweise sämtliche der genannten Datenblöcke umfasst, ermöglicht bereits bei der Bereitstellung der Daten in dem ersten Datenformat eine vereinfachte Administration. Darüber hinaus ermöglicht es das Datenmodell nach der Cl- berführung in das zweite Dateπformat und der Zurverfügungstellung in einer zu der hierarchischen Datenstruktur korrespondierenden Datenstruktur in dem Kraftfahrzeug einen vereinfachten Zugriff auf die Daten, welcher insbesondere autark durch die Rechner des Kraftfahrzeugs vorgenommen werden kann.
Die Daten eines Dateπblocks können gemäß einer weiteren Ausgestaltung in einem oder in mehreren Sub-Datenblöcken angeordnet und abgespeichert werden. Auf diese Weise ist eine weitere Strukturierung der Daten möglich, wodurch der Datenzugriff durch die Rechner des Kraftfahrzeugs weiter verbessert wird. Das heißt die weitere Erkennung und Validierung der Konfigurationsdaten (bis zu einzelnen Parametern und Werten im Modell) wird spezifisch in den Telematik-Diensten und -Applikationen vorgenommen, die die eigentlichen Nutzer der Konfigurationen sind. Dadurch ist die „Partielle Validierung" auch eine Rechner- und Software-Modul-verteilte Validierung, im Unterschied zu üblichen XML- Validierungsverfahren.
Auf Grund der Modellkomplexität muss für Debugging- und Diagnose-Zwecke die interne MOST Darstellung auch in menschenlesbarer Form als Text wiederherzustellen sein. Die einzelnen Zeilen der generierten Tabellen sind textuell als Links zu dem einzelnen Parameter darstellbar. Gemäß einer weiteren Ausgestaltung ist in dem zweiten Datenformat jedem Parameter und dem zugeordneten Parameterwert eine Pfadangabe zugeordnet, wobei die Pfadangabe zumindest einem Keπnzeichner für den betreffenden Datenblock und den oder die optionalen Sub-Datenblöcke umfasst. In dem tabellarischen Datenformat wird somit jedem Parameter eines Dateπblocks eine Pfadangabe vorangestellt. Auf diese Weise ist es möglich, einerseits die tabellarische Darstellung in Textform wieder herzustellen. Bei Verwendung von XPath 0 als Basis für die Link-Darstellung ist es möglich, Datenbankanfragen auf die MOST Objekte durchzuführen.
Gemäß einer weiteren Ausgestaltung werden die Daten in dem ersten vorgegebenen Datenformat von einem ersten Rechner eines Rechnernetzwerks an einen zweiten Rechner des Kraftfahrzeugs, insbesondere drahtlos, übertragen und von dem zweiten Rechner des Kraftfahrzeugs in das zweite Datenformat überführt. Mit anderen Worten bedeutet dies, dass die Übertragung der Daten von dem Rechner des Dienst-Anbieters an das Kraftfahrzeug in dem ersten Datenformat, insbesondere gemäß XML-Spezifikation, erfolgt. Dies weist den Vorteil auf, dass die Datenübertragung mit bekannten Übertragungsmechanismen erfolgen kann. Hierdurch lässt sich bei der Übertragung eine hohe Effizienz erzielen. Da die Verarbeitung der Daten in dem ersten Datenformat für das Kraftfahrzeug jedoch hinderlich ist, wird durch einen Rechner des Kraftfahrzeugs die Überführung in das zweite Datenformat vorgenommen, welches die beschriebenen Vorteile in der Verarbeitung bietet.
Insbesondere wird nach der Überprüfung der Daten in das zweite Datenformat überprüft, ob das Datenmodell gültig ist. Die Überprüfung erfolgt anhand der tabellarischen Datenstruktur. Dabei wird die Überprüfung des Datenmodells nach einer, insbesondere nach jeder, Änderung und/oder Ergänzung der Daten in dem ersten Datenformat sowie anschließender Überführung in das zweite Dateπformat vorgenommen. Eine Änderung und/oder Ergänzung der Daten kann dadurch vorgenommen werden, dass entsprechende Parameter mit ihrem Parameterwert und der Pfadangabe entweder den Daten im zweiten Datenformat hinzugefügt werden oder ein sich verändernder Wert überschrieben wird. Demgegenüber müssen Daten, die im XML-Datenformat vorliegen, durch ein vollständiges Überschreiben des gesamten XML-Dokuments aktualisiert werden. Hierdurch ist jedoch ein im Vergleich zum erfindungsgemäßen Vorgehen erhöhter Zeitaufwand für die Datenübertragung sowie für die Verarbeitung der Daten in dem Kraftfahrzeug notwendig.
Die Überprüfung des Dateπmodells erfolgt auf einfache Weise dadurch, dass das Vorhandensein zumindest eines der Kennzeichner eines der Datenblöcke überprüft wird. Demgemäß ist es ausreichend, wenn die in das zweite Datenformat überführten Daten lediglich auf das Vorhandensein eines einzigen Kennzeichners eines der Datenblöcke überprüft werden. Hierdurch kann die Überprüfung auf einfache Weise und in kurzer Zeit erfolgen. Eine Überprüfung der Konsistenz der Parameter bzw. Parameterwerte eines jeden Datums findet zu diesem Zeitpunkt hingegen nicht statt.
Es ist weiterhin vorgesehen, dass ein nicht validierender, Ereigπis-basierter Parser wie SAXO und 0 zur Verarbeitung der Daten in dem Kraftfahrzeug verwendet wird, welcher die Verarbeitung der Daten ohne vorherige semantische Überprüfung vornimmt und nur die Struktur der zu verarbeitenden XML-Instanzen überprüft (Es wird nur eine „Wellformness" 0 0 Überprüfung vorgenommen). Hierdurch kann die Effizienz und Performanz des Rechnersystems in dem Kraftfahrzeug gesteigert werden, da die spezifische semantische Ü- berprüfuπg als verteilte Aufgabe zwischen mehreren Anwendungen und Rechnern nach Bedarf vorgenommen wird (d.h. „Partielle Validierung").
Gemäß einer weiteren Ausgestaltung werden die Daten in dem zweiten Datenformat, insbesondere in dem oder durch den gleichen oder einen zweiten Rechner, in dem Kraftfahrzeug in einem dritten Datenformat abgebildet, das eine textuelle Darstellung wiedergibt, welche als menschlichlesbares Format angezeigt werden kann bzw. auf einem persistenten Medium als Datenbank abgespeichert werden kann.
Von der Erfindung ist ferner ein Computerprogrammprodukt umfasst, das auf einem computergeeigneten Medium gespeichert ist und direkt in den internen Speicher eines digitalen Rechners oder mehrerer miteinander in Kommunikationsverbindung zueinander stehenden Rechnern geladen werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte des beschriebenen Verfahrens ausgeführt werden, wenn das Produkt auf dem oder den Rechnern läuft.
Die Erfindung schafft ferner eine Vorrichtung zur rechπergestützten Verarbeitung von Daten, insbesondere Konfigurationsdaten, für einen oder mehrere Telematik-Dienste in einem Kraftfahrzeug. Die Vorrichtung umfasst ein erstes Mittel zur Bereitstellung der Daten einer hierarchischen Datenstruktur in einem ersten vorgegebenen Datenformat. Die Vorrichtung umfasst weiter ein zweites Mittel zur Überführung der Daten in eine tabellarische Datenstruktur. Schließlich umfasst die Vorrichtung ein drittes Mittel zur Bereitstellung der in dem zweiten Datenformat enthaltenen Daten in eine textuelle Form. In einer zweckmäßigen Ausgestaltung kann die Vorrichtung weitere Mittel zur Durchführung des oben beschriebenen Verfahrens aufweisen.
Die Erfindung wird nachfolgend näher anhand der Zeichnungen erläutert. Es zeigen:
Fig. 1 eine schematische Darstellung des dem erfinduπgsgemäßen Verfahren zu Grunde liegenden Vorgehens,
Fig. 2 ein erfindungsgemäßes Datenmodell zur Abbildung der Daten, insbesondere Konfigurationsdaten, und
Fig. 3 eine schematische Darstellung einer Architektur zur teilweisen Validierung der Daten.
Fig. 1 zeigt in einer schematischen Darstellung das der Erfindung zu Grunde liegende Vorgehen. In einem Rechner 1 , z.B. einem Rechner eines Rechπernetzwerks eines Dienste-Anbieters, werden Daten, wie z.B. Konfigurationsdaten, für einen oder mehrere Telematik-Dienste in einer hierarchischen Datenstruktur in einem ersten vorgegebenen Datenformat bereitgestellt. Es ist zweckmäßig, wenn die Daten in dem ersten Dateπformat als XML-Daten bereitgestellt werden. Dies ist mit dem Bezugszeichen 4 gekennzeichnet. Die in dem ersten Datenformat vorliegenden Daten werden über eine Kommunikationsstrecke 3, die insbesondere drahtlos ausgebildet ist, an einen Rechner 2 eines Kraftfahrzeugs übermittelt. Durch den Rechner 2 werden die in der hierarchischen Datenstruktur vorliegenden Daten des ersten Dateπformats in ein zweites Datenformat 5 überführt, in dem die Daten in einer tabellarischen Datenstruktur angeordnet werden. Die Daten werden hierbei datenblockweise (BL1 , BL2, BL3) abgespeichert. Dabei werden die in dem zweiten Datenformat 5 enthaltenen Daten dem Kraftfahrzeug zur weiteren Verarbeitung zur Verfügung gestellt bzw. in einem dritten Format in textueller Datenform als lesbares Format dargestellt. . Die Ausgestaltung der Datenstrukturen wird weiter unten näher erläutert.
Das Vorgehen wird nachfolgend näher beschrieben. Telematik-Dieπste im automobilen Umfeld benötigen eine Kommunikation mit einer die Dienste bereitstellenden Infrastruktur. Die Kommunikation zwischen dem Rechner 2 des Kraftfahrzeugs und dem Rechner 1 der Infrastruktur erfolgt dabei bevorzugt über drahtlose Kommunikationstechnologien. Dabei ist insbesondere zu berücksichtigten, dass die entsprechenden Dienste bzw. Applikationen mit unterschiedlichen Übertragungstechnologien (z.B. CSD und GPRS in Verbindung mit GSM, UMTS usw.) und unter unterschiedlichen Service-Providerumgebungen, wie z.B. Roamiπg, verwendet werden können müssen. Der in dem Kraftfahrzeug verwendete Rechner 2 muss deshalb zur Vermeidung einer Unterbrechung eines ausgeführten Dienstes unterschiedliche Charakteristika ausführen können. Insbesondere muss der Rechner in der Lage sein, unterschiedliche Übertra- gungstechπologien zu verwenden und Handover auszuführen. Im automobilen Umfeld eingesetzte Telematik-Dienste müssen deshalb den Datenaustausch mit der Netzwerkinfrastruktur in unterschiedlichen Konfigurationen unterstützen (vgl. z.B. [1]).
Eine Telematik-Anwendung umfasst drei Haupt-Konfigurationstypen, die unterschiedlichen funktionellen Abstraktionen der Dienste zugeordnet sind. Dies sind Verbindungskonfigurationen, Ende-zu-Ende-Performanz-Einstellungen und diesbezügliche Beschränkungen. Die Beschränkungen (Constraints) repräsentieren Verknüpfungen zwischen Verbindungskonfigurationen (Connectivity) und den Ende-zu-Ende-Performanz-Konfigurationen (end-to-end Performance configuration), welche aufgrund von Hardware-Konfigurationen und/oder Nutzererfordernissen und/oder Serviceprovidervereinbarungen (Provider Service Level Agreement, SLA) mit den Nutzern festgelegt sind (vgl. [1] bis [4]).
Hardware-Restriktionen können beispielsweise die Verfügbarkeit eines bestimmten NAD- Moduls, wie z.B. ein GSM- oder UMTS-Gerät, sein. Eine Nutzer-Restriktion (user restricti- on) kann die Erlaubnis umfassen, eine bestimmte Web-Adresse oder einen Telefonservice zu aktivieren. Ein Provider-SLA kann z.B. festlegen, dass nur bestimmte Übertragungstechnologiearten aktiviert werden können, obwohl ein NAD-Modul mehr oder andere Technologien über die in der SLA genannten Technologien unterstützen kann. Derartige Konfigurationen werden in den Konfiguratioπsdaten eines Kraftfahrzeugs hinterlegt.
Dies erfolgt erfindungsgemäß dadurch, dass die Daten in einem vorgegebenen Datenmodell abgebildet werden. Dies ist schematisch in Fig. 2 in einem UML-Klassen-Diagramm [9] dargestellt. Das Modell kann alternativ auch durch eine Gruppe von Protokollen reprä- sentiert sein, bei dem Teile des Modells zu einem Session-Layer-Protokoll und Teile zu einem daran angehängten Presentation-Layer-Protokoll gehören. Dies ist beispielsweise im Falle von SIP [1 1] und SDP [12] der Fall.
Das Daten- oder Koπfigurationsmodell umfasst eine Wurzel 10 („model route") mit einem eindeutigen Kennzeichner („model ID"), welcher als Kennzeichner für das gesamte Modell verwendet werden kann. Beispielsweise kann im Fall eines im XML-Spezifikation vorliegenden Modells der Kennzeichner der Namensraum des Schemas oder im Falle von DTD (Document Type Definition) der Name des DTD-Modells sein. Eine zusätzliche Kennzeichnung des Modells kann durch eine inhaltsbezogene Definition innerhalb eines Protokolls erfolgen, welche das Konfigurationsmodell umfasst. Dies ist beispielsweise in IANA MIME [13], SIP [11] und HTTP [14] beschrieben.
Das Datenmodell kann eine oder mehrere vollständige Konfigurationen umfassen, welche durch ein Konfigurations-Objekt 20 („configuration") repräsentiert ist. Das Konfigurations- Objekt 20 umfasst ebenfalls einen Kennzeichner: „Config ID". Jede der Konfigurationen muss identifizierbar sein, um die Konfiguration mit einer spezifischen Infrastruktur für die Kommunikation in Verbindung bringen zu können. Für Telematik-Applikationen können dies die Schichten 2 und/oder 3 des OSl-Referenzmodells [10], Protokollidentifikation, wie z.B. GSM SIM [15] oder IP-Adressieruπg [16], [17] oder die Identifikation der Provider- Infrastruktur über DNS [18] sein.
Mit dem Konfigurations-Objekt 20 sind ein Verbindungs-Objekt 21 („Connectivity"), ein Dienste-Objekt 22 („Services") und ein Beschränkungen-Objekt 23 („Contraints") verbunden. Diese sog. „Kinder"- oder „Child"-Objekte stellen die oben beschriebenen Klassen von Konfigurationen dar, welche notwendig sind für eine vollständige Ende-zu-Ende- Performanz eines Telematik-Dientes innerhalb einer spezifischen Technologie und/oder einer Provider-Domaiπe. Jedes dieser Objekte 21 , 22, 23 kann wiederum ein oder mehrere „Child"-Konfigurationeπ aufweisen:
Ein Zugangsdaten-Objekt 31 („access") mit einem Keππzeichner („access ID") identifiziert eine spezifische Zugangstechnologie und verwendet als Kennzeichner beispielsweise den Namen der Technologie (z.B. CSD, GPRS, usw.). Das Zugangsdateπ-Objekt 31 ist zugehörig zu einem Sub-Baum oder Sub-Tree (41 ), der die Parametrisierung der Zugangs- techπologie beschreibt. Dies umfasst beispielsweise den Namen eines Zugangsrechπers zu einem Netzwerk, einem sog. Access Point (APN), wie z.B. eine IP-Adresse oder eine Einwahlnummer oder einen spezifischen Technologie-Performanzparameter, wie z.B. QoS-Parameter. Diese Informationen werden verwendet, um das Telematik-System des Kraftfahrzeugs zu konfigurieren, um eine Verbindung zur Schicht 2 und/oder 3 des OSI- Referenzmodells herzustellen.
Ein Applikations-Objekt 32 („applicatioπ") mit einem Kennzeichner („application ID") identifiziert Schicht 3 und die Zugänglichkeit zu einer Ende-zu-Ende-Verbinduπg eines Infrastruktur-Dienstes, wie z.B. ein www-Portal. Der dazugehörige Sub-Tree 42 von Objekten beschreibt Parametrisierungen der spezifischen Applikationen, wie z.B. www-Adressen und QoS-Servicezustände, wie z.B. ein Retry-Intervall oder Protokoll-Time-outs.
Ein Beschränkungen-Objekt 33 („constraint") mit einem Kennzeichner („contraint ID") i- dentifiziert spezifische Verbindungen zwischen Zugaπgselementen oder Applikations- Elementen sowie zwischen Zugangs- und Applikations-Elementen. Die Sub-Tree- Elemente 43 definieren Konfigurationszustände zur Ausführung des Telematik-Dieπstes oder einer Klasse ähnlicher Applikationen.
Dieses Datenmodell ermöglicht im Gegensatz zur Validierung eines XML-Dokuments die teilweise Validierung der durch das Datenmodell repräsentierten Daten. Die spezifische Anwendung für eine partielle Validierung entsteht aus dem Fall verteilter Telematik- Applikationen, bei denen unterschiedliche Geräte und Softwareteile der Applikation durch dasselbe Modell konfiguriert werden müssen, um Datenkoπsistenz und InterOperabilität bereitstellen zu können. Die einzelnen Geräte und Software-Sub-Systeme rufen jedoch nur Teile des gesamten Modells für ihre spezifische Konfiguration ab.
In solchen Fällen kann der Zugang und die Validierung vollständiger XML- Datenmodellteile nicht als Ganzes durchgeführt werden, da entsprechende Sub-Systeme bestimmte Modellteile nicht verstehen oder nicht verstehen dürfen, wenn sie nicht für deren Zwecke notwendig sind.
Bei der Erfindung ist deshalb vorgesehen, dass ein Rechner des Kraftfahrzeugs zwar das vollständige Datenmodell erhält, dieses jedoch in Datenblöcke aufspaltet, welche später als busspezifische Modelle bereitgestellt werden. Insbesondere können diese als MOST- spezifische Inhaltsmodelle bereitgestellt werden [19]. Dies bedeutet, dass die Empfänger einer MOST-spezifischen Repräsentierung des Datenmodells die Validierung auch selbst durchführen können müssen.
Die Softwarearchitektur zur lediglich teilweisen Überprüfung der an das Fahrzeug übertragenen Daten ist in Fig. 3 dargestellt. Die Architektur basiert auf einem sog. XML Non- Validating Parser 140. Dieser verwendet klassische XML-Regeln zur Validierung, um die (Top-Level-)Struktur 160 des Datenmodells zu überprüfen. Diese Regeln sind über eine Konfiguratioπsmodell-Klasse 1 10 spezifiziert und entsprechen einer semantischen Modellvalidierung. Die extrahierten Sub-Trees können durch einen Validator 130 strukturell überprüft werden (150), um eine Klassifikation von Daten vorzunehmen, bevor eine Aufbereitung in ein für Bus-Zugriff geeignetes Format erfolgt. Die Regeln für ein solches Vorgehen sind als „Modellteil"-Klasseπ 100 definiert. Die Regeln für die Sub-Tree-Validierung folgen der natürlichen Struktur des Sub-Modells, das der Telematik-Anwendung zugeordnet ist.
Beispielsweise können eine Applikation und seine Parameter einen zweistufigen Sub- Tree darlegen, um das Modell in eine Applikation (als „Parenf'-Elemeπt), seine Parameter (als ,,Child"-Element) und die Parameterwerte (als Elementwerte) aufzuteilen.
Eine allgemeinere Definition einer strukturellen Überprüfungsregel ist z.B. „Ein Element weist mindestens ein „Child"-Element und mindestens ein „Grand-Child"-Element auf, wobei das „Grand-Child"-Element keinen leeren Wert umfasst. Keines der Elemente in der Struktur hat keine Attribute". Solche Spezifikationen definieren zusätzliche Restriktionen zu einem vordefinierten XML-Infoset [20]. Ein XML-Iπfoset definiert die Regeln für die klassische „XML-Wellformπess" und die Gültigkeitsbestätigung von Belegdokumenten. Solche Regeln können durch die Wiederverwendung von XML-Schemaspezifikationen definiert werden. Die Interpretation einer strukturellen Validierung betrifft nur die Form des Baums, jedoch nicht seiner Inhalte (vgl. ebenfalls Synthetic Infoset [20]).
Die klassische XML-Repräsentation weist eine verschachtelte Struktur auf. Dies bedeutet, sie hat ein Start- und ein Ende-Element, das Inhalte von Child- und/oder Grand-Children- Definitionen „einwickelt". Dies ist nachfolgend exemplarisch dargestellt. <xml>
<configuration> <conπectivity>
<conn1>
<accessnr>+ 1234567890</accessnr>
<user>myFunnyUser</user>
<pwd>myFunnyPWD</pwd> </conn1 >
<conn2>
<accessurl>xyz.my-funny-provider.org</accessurl>
<user>myFunπyUser</user>
<pwd>myFunnyPWD</pwd> </conn2>
</connectivity> <service>
</service> <coπstraints>
</constraints>
</configuratioπ> </xml>
In einer Software-Entität werden solche Inhalte üblicherweise als ein Objektbaum repräsentiert. Die Übertragung von Objektbäumen oder Sub-Trees kann im Falle von Applikationen, die das gemeinsame XML-Konfigurationsmodell teilen, heikel sein, da die Anord- nung/Entpackung (deserializatioπ) von Inhalten notwendig ist, um die Daten für unterschiedliche Softwareentitäten und unterschiedliche Traπsportmedien zu repräsentieren.
Es ist natürlich möglich, dass XML Inhalte auch über MOST übertragen werden, allerdings setzt diese Möglichkeit voraus, dass jede Einheit, die die Daten verwenden will über XML Parser und Generator verfügt. Aus diesem Grund greift die Erfindung auf eine tabellarische Datenstruktur von XML-Inhalten zurück, die die Daten in ähnlicher zu den MOST Dynamic Arrays 0 Form überführt. Jede einzelne Tabelle stellt einen Konfigurationsblock dar. Allerdings ist diese tabellarische Form nicht ohne weiteres lesbar bzw. persistent abzuspeichern. Aus diesem Grund greift die Erfindung auf eine lineare Datenstruktur von XML-Inhalten zurück, bei denen als Separator der sog. XPaths einzelner Elementinhalte die Struktur „<&>" verwendet wird, wie dies nachfolgend dargestellt ist:
/xml/configuration/connectivity/conn1/[accessnr=+1234567890]<&>
/xml/configuration/connectivity/conn1/[user=myFuππyUser]<&>
/xml/configuration/coπnectivity/conn1/[pwd=myFunnyPWD]<&>
/xml/configuration/conπectivity/conπ2/[accessurl=xyz.my-funny-provider.org]<&>
/xml/configuration/connectivity/conn2/[user=myFunnyUser]<&>
/xml/configuration/connectivity/conn2/[pwd=myFunnyPWD]<&>
Wie dieser Darstellung ohne Weiteres entnehmbar ist, umfasst jeder Eintrag eine Pfadangabe (hier: /xml/configuration/coππectivity/conn1/) sowie einen Parameter in Verbindung mit einem Wert (hier z.B. accessnr als Parameter und +1234567890 als Wert). Am Ende eines jeweiligen Zeileneintrags ist der Separator „<&>" vorgesehen. Da die Symbole „<", „>" und „&", die als Separator verwendet werden, XML-reservierte Symbole sind (vgl. [22]), ist eine Rückwärtskompatibilität bei der Re-Kompilierung der in linearer Form vorliegenden Daten in ein klassisches XML-Format sichergestellt. Darüber hinaus kann erfindungsgemäße Format auf einfache Weise in eine Vektorform gebracht werden, wie dies nachfolgend gezeigt ist. Dies erfolgt durch eine Suche nach dem Separator „<&>".
0 /xml/configuration/conπectivity/conn1/[accessnr=+1234567890]
1 /xml/configuration/connectivity/conn1/[user=myFunnyUser]
2 /xml/configuration/connectivity/conn1/[pwd=myFunnyPWD]
3 /xml/configuration/connectivity/conn2/[accessurl=xyz.my-funny-provider.org]
4 /xml/configuration/connectivity/conn2/[user=myFunnyUser]
5 /xml/configuratioπ/connectivity/conn2/[pwd=rnyFunnyPWD]
Das lineare Datenformat weist eine Vielzahl von Vorteilen im Vergleich zum herkömmlichen XML-Format auf:
Es kann in Software und/oder Transfer-Mediendaten-Containern verwendet werden, die mit Vektoren korrespondieren.
Die Daten können unter Verwendung der XPath-Konvention (vgl. [21]) auf einfache Weise gesucht und extrahiert werden, da die interne Repräsentation auf Separatoren oder in einem Vektor XPath-basiert. Das heißt, nur ein Vergleich von Strings ohne zusätzliche Zerlegung der Daten ist notwendig. Auch die Textform ist über MOST übertragbar. Dies findet Verwendung im Falle, dass die Überführung der Daten in die Textform und das persistente Medium sich in verschiedenen Steuergeräten im Fahrzeug befinden.
Der Mechanismus zum Repräsentieren von Konfigurationsdaten kann für verschiedene MOST-Geräte verwendet werden. Beispielsweise können die Daten auf einem MOST-Bus in der Form eines dynamischen Datenarrays repräsentiert sein. Dies kann beispielsweise in einer Vektor-Form oder einem klassifizierten Stream (z.B. in linearisierter Form) erfolgen. Das Streaming der Daten kann beispielsweise unter Verwendung der sog. MoCCA Middleware der Firma HarmanBecker [23] erfolgen, um die Daten für einen seriellen Transport zu typisieren. Damit kann beispielsweise ein neuer lANA-Mediendatentyp definiert werden:
„application/HBMOCCAObject" („;" parameter)
Beispiele für die Verwendung dieser Datentypen sind:
"Content-Type=application/HBMOCCAObject; type=THBVector" oder
"Content-Type=application/HBMOCCAObject; type=CHBString"
MoCCA kann beispielsweise in einer Fahrzeug-zu-Fahrzeug-Kommunikation eingesetzt werden. Es kann als „Shared Agent System" zwischen Kraftfahrzeugen und/oder Internetbasierten Infrastrukturen verwendet werden. Für den Fall, in dem sich Kraftfahrzeuge Te- lematik-Plattformen teilen, können das Daten-Handling und die Anordnungsmechanismen für Konfigurationsinformationen über Internetprotokolle, wie z.B. HTTP oder SIP, durchgeführt werden. Die Spezifikation eines gemeinsamen Medientyps ist Voraussetzung für die InterOperabilität zwischen Datentransfersystemen.
Die Software, welche die Daten über ein Datentransfersystem repräsentiert, schließt Softwarestücke wie Adapter und Proxy [24] ein. Die Schnittstelle (API, Application Pro- gramable Interface) zur Repräsentierung der transportablen Sub-Strukturen hängt jedoch von dem Teil-Validierungsalgorithmus ab. Liste der verwendeten Abkürzungen
Figure imgf000017_0001
Liste der Veröffentlichungen
[I] T. Guenkova-Luy, "Multimedia Networking - Coordination of Multimedia Services in Next Generation Mobile Networks", VDM Verlag Dr. Mueller, 2007
[2] M. Alfano, N. Radouniklis, "A Cooperative Multimedia Environment with QoS Con- trol: Architectural and Implementation Issues", ICSI Technical Report TR-96-040, International Computer Science Institute, Berkeley (CA1 USA), Sept. 1996
[3] A. Watson, M. A. Sasse, "Measuring Perceived Quality of Speech and Video in Multimedia Conferencing Applications", Sixth ACM international Conference on Multimedia, Bristol (UK), September 1998
[4] Y. Ito, Sh. Tasaka, Y. Fukuta, "Psychometric Analysis of the Effect of End-to-End Delay on User-Level QoS in Live Audio-Video Transmission", IEEE International Conference on Communications (ICC2004), Paris (France), June 2004
[7] Ch. Valentine, "XML Schemas", SYBEX, 2002
[8] B. Marchai, "XML by Example", QUE, 2002
[9] H.-E. Eriksson et al., "UmI 2 Toolkit", Wiley Publishing, 2004
[10] International Organization for Standardization, International Electrotechnical Com- mission and International Telecommunication Union, "Information Processing Systems - OSI Reference Model - The Basic Model", International Standard ISO/IEC 7498-1 :1994 and ITU-T Recommendation X.200, 1994
[I I] J. Rosenberg et al., "SIP: Session Initiation Protocol", IETF RFC 3261 , June 2002
[12] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol", IETF RFC 4566, JuIy 2006
[13] IANA, "MIME Media Types", http://www.iana.org/assignments/media-types/
[14] R. Fielding et al., "Hypertext Transfer Protocol - HTTP/1.1", IETF RFC 2616, June 1999
[15] GSM 02.17 V8.0.0 (1999-11 ), "Digital cellular telecommunications System (Phase 2+); Subscriber Identity Modules (SIM); Fuπctional characteristics", Technical Speci- fication, Nov. 1999
[16] DARPA INTERNET PROGRAM, "Internet Protocol", IETF RFC 791 , Sept. 1981 [17] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)", IETF RFC 2460, Dec. 1998
[18] P.V. Mockapetris , "Domain Names - Concepts And Facilities", IETF RFC 1034, Nov. 1987
[19] MOST Cooperation, "MOST Media Orieπted Systems Transport - Multimedia and Control Networking Technology", MOST Specification, Rev 2.5, 10/2006, http://www.mostcooperation.com/publications/Specifi cations_Organizatioπal_Proced ures/index.html?dir=97
[20] W3C, "XML Information Set (Second Edition)", W3C Recommendation, February 2004, http://www.w3.org/TR/xml-infoset/
[21] W3C, "XML Path Language (XPath), Version 1.0", W3C Recommendation, Nov. 1999, http://www.w3.org/TR/xpath
[22] W3C, "XML Primer", Oxford Brookes University 2002, http://www.w3c.rl.ac.uk/primers/xml/xmlprimer.htm
[23] HBAS, "MoCCA User's Guide", MoCCAUsers-
Guide_Version1_9_Release_D2_5.pdf, Revision 1.9 January, 2008
[24] E. Gamma, R. Helm, R. Johnson , J. M. Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software", Addison-Wesley, 1995
Bezugszeichenliste
erster Rechner zweiter Rechner Datenübertragungsstrecke Daten in erstem Datenformat Daten in zweiten Datenformat Daten in drittem Datenformat Wurzel des Konfigurationsmodells Konfigurations-Objekt Verbindungs-Objekt Dienste-Objekt Beschränkungen-Objekt Zugangsdaten-Objekt Applikations-Objekt Beschränkungen-Objekt

Claims

Patentansprüche
1. Verfahren zur rechnergestützten Verarbeitung von Daten, insbesondere Konfigurationsdaten, für einen oder mehrere Telematik-Dienste in einem Kraftfahrzeug, bei dem die Daten in einer hierarchischen Datenstruktur in einem ersten vorgegebenen Datenformat (4) bereitgestellt werden; die Daten von dem ersten Datenformat (4) in ein zweites Datenformat (5) überführt werden, in dem die Daten in einer oder mehreren tabellarischen Datenstrukturen angeordnet werden und in dem Kraftfahrzeug zur weiteren Verarbeitung zur Verfügung gestellt werden; die in dem zweiten Dateπformat (5) enthaltenen Daten in einer textuellen Datenstruktur als lesbares Format oder als persistente Datenbank wiedergegeben werden.
2. Verfahren nach Anspruch 1 , bei dem die Daten in dem ersten Datenformat (4) gemäß XML-Spezifikation bereitgestellt werden.
3. Verfahren nach Anspruch 1 oder 2, bei dem die Daten in dem ersten vorgegebenen Datenformat (4) ein vorgegebenes Datenmodell abbilden.
4. Verfahren nach Anspruch 3, bei dem das Datenmodell ein oder mehrere Konfigurationen umfasst, denen jeweils eine oder mehrere semantische Datenblöcke zugeordnet werden.
5. Verfahren nach Anspruch 4, bei dem einer der Datenblöcke („Connecitivity") Verbindungsdaten und/oder einen Verbiπdungsaufbau betreffende Daten umfasst.
6. Verfahren nach Anspruch 4 oder 5, bei dem einer der Datenblöcke („Services") Dienste und/oder Dienstmerkmale betreffende Daten umfasst.
7. Verfahren nach einem der Ansprüche 4 bis 6, bei dem einer der Datenblöcke („Constraints") Beschränkungen betreffende Daten umfasst.
8. Verfahren nach einem der Ansprüche 4 bis 7, bei dem die Daten eines Datenblocks in einem oder mehreren Sub-Datenblöcken angeordnet und abgespeichert werden.
9. Verfahren nach einem der Ansprüche 4 bis 9, bei dem in dem zweiten Datenformat (5) jedem Parameter und dem zugeordneten Parameterwert eine Pfadangabe zugeordnet ist, wobei die Pfadangabe zumindest einen Kennzeichner für den betreffenden Datenblock und den oder die optionalen Sub-Datenblöcke umfasst.
10. Verfahren nach einem der vorherigen Ansprüche, bei dem eine Validierung verteilt über mehrere Rechner und/oder Software-Module erfolgt.
11. Verfahren nach einem der vorherigen Ansprüche, bei dem die Daten in dem ersten vorgegebenen Datenformat von einem ersten Rechner (1 ) eines Rechnerπetz- werks an einen zweiten Rechner (2) des Kraftfahrzeugs, insbesondere drahtlos, übertragen werden und von dem zweiten Rechner (2) des Kraftfahrzeugs in das zweite Datenformat (5) überführt werden.
12. Verfahren nach Anspruch 11 , bei dem nach der Überführung der Daten in das zweite Datenformat (5) überprüft wird, ob das Datenmodell gültig ist.
13. Verfahren nach Anspruch 12, bei dem die Überprüfung des Datenmodells nach einer, insbesondere jeder, Änderung und/oder Ergänzung der Daten in dem ersten Datenformat (4) sowie anschließender Überführung in das zweite Datenformat (5) vorgenommen wird.
14. Verfahren nach Anspruch 12 oder 13, bei dem die Überprüfung des Datenmodells das Vorhandensein zumindest eines der Kennzeichner eines der Datenblöcke umfasst.
15. Verfahren nach einem der vorherigen Ansprüche, bei dem ein nicht validierender, Ereignis-basierter Parser zur Verarbeitung der Daten in dem Kraftfahrzeug verwendet wird, welcher die Verarbeitung der Daten ohne vorherige semantische Ü- berprüfung vornimmt und nur die Struktur der zu verarbeitenden XML-Instanzen überprüft.
16. Verfahren nach einem der vorherigen Ansprüche, bei dem die Daten in dem zweiten Datenformat, insbesondere in dem oder durch den gleichen oder einen zweiten Rechner (2), in dem Kraftfahrzeug in einem dritten Datenformat (6) abgebildet werden, das eine textuelle Darstellung wiedergibt, welche als menschlichlesbares Format angezeigt werden kann bzw. auf einem persistenten Medium als Datenbank abgespeichert werden kann.
17. Verfahren nach Anspruch 16, bei dem die in dem dritten Dateπformat abgespeicherten Daten für die weitere Verarbeitung, insbesondere für einen Zugriff auf Busebene, Datenblockweise zur Verfügung gestellt werden.
18. Computerprogrammprodukt, das auf einem computergeeigneteπ Medium gespeichert ist und direkt in den internen Speicher eines digitalen Rechners oder mehrerer miteinander in Kommunikationsverbindung zueinander stehenden Rechnern geladen werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte gemäß einem der vorherigen Ansprüche ausgeführt werden, wenn das Produkt auf dem oder den Rechnern läuft.
19. Vorrichtung zur rechnergestützten Verarbeitung von Daten für einen oder mehrere Telematik-Dienste in einem Kraftfahrzeug, mit einem ersten Mittel zu Bereitstellung der Daten in einer hierarchischen Datenstruktur in einem ersten vorgegebenen Datenformat (4); einem zweiten Mittel zur Überführung der Daten von dem ersten Datenformat (4) in ein zweites Datenformat (5), in dem die Daten in einer tabellarischen Datenstruktur angeordnet werden; einem dritten Mittel zur Bereitstellung der in dem zweiten Datenformat (5) enthaltenen Daten in einer textuellen Form.
20. Vorrichtung nach Anspruch 19, bei dem die Vorrichtung weitere Mittel zur Durchführung des Verfahrens nach einem der Ansprüche 2 bis 16 aufweist.
PCT/EP2009/008051 2008-11-27 2009-11-12 Verfahren und vorrichtung zur verteilten konfiguration von telematik-diensten in kraftfahrzeug-systemen WO2010060541A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN200980147425.2A CN102227727B (zh) 2008-11-27 2009-11-12 机动车系统内分布地配置远程信息处理业务的方法和设备
US13/117,499 US20110282889A1 (en) 2008-11-27 2011-05-27 Method and Device for Distributed Configuration of Telematics Services in Motor Vehicle Systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008059197A DE102008059197A1 (de) 2008-11-27 2008-11-27 Verfahren und Vorrichtung zur verteilten Konfiguration von Telematik-Diensten in Kraftfahrzeug-Systemen
DE102008059197.1 2008-11-27

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/117,499 Continuation US20110282889A1 (en) 2008-11-27 2011-05-27 Method and Device for Distributed Configuration of Telematics Services in Motor Vehicle Systems

Publications (1)

Publication Number Publication Date
WO2010060541A1 true WO2010060541A1 (de) 2010-06-03

Family

ID=41664707

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/008051 WO2010060541A1 (de) 2008-11-27 2009-11-12 Verfahren und vorrichtung zur verteilten konfiguration von telematik-diensten in kraftfahrzeug-systemen

Country Status (4)

Country Link
US (1) US20110282889A1 (de)
CN (1) CN102227727B (de)
DE (1) DE102008059197A1 (de)
WO (1) WO2010060541A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9094304B2 (en) 2012-05-10 2015-07-28 Cognex Corporation Systems and methods for dynamically configuring communication data items
ITBS20130037A1 (it) 2013-03-21 2014-09-22 Bsh Italia S R L Macchina da caffe'
KR101601228B1 (ko) * 2014-11-26 2016-03-21 현대자동차주식회사 텔레매틱스의 프로비저닝 방법
GB201511175D0 (en) * 2015-06-25 2015-08-12 Mclaren Applied Technologies Ltd Analysing physical systems
DE102018218927A1 (de) 2018-11-07 2020-05-07 Volkswagen Aktiengesellschaft Datenvermittlungsvorrichtung und Datenvermittlungsverfahren für ein Fahrzeug, Vorrichtung und Verfahren für eine Fahrzeugkomponente eines Fahrzeugs und Computerprogramm

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6611843B1 (en) * 2000-10-26 2003-08-26 Docent, Inc. Specification of sub-elements and attributes in an XML sub-tree and method for extracting data values therefrom
US20050245272A1 (en) * 2004-04-29 2005-11-03 Spaur Charles W Enabling interoperability between distributed devices using different communication link technologies

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7228211B1 (en) * 2000-07-25 2007-06-05 Hti Ip, Llc Telematics device for vehicles with an interface for multiple peripheral devices
US7487168B2 (en) * 2001-11-01 2009-02-03 Microsoft Corporation System and method for loading hierarchical data into relational database systems
US20040034455A1 (en) * 2002-08-15 2004-02-19 Craig Simonds Vehicle system and method of communicating between host platform and human machine interface
US7017112B2 (en) * 2003-02-28 2006-03-21 Microsoft Corporation Importing and exporting markup language data in a spreadsheet application document
US7587667B2 (en) * 2003-09-04 2009-09-08 Oracle International Corporation Techniques for streaming validation-based XML processing directions
US7437374B2 (en) * 2004-02-10 2008-10-14 International Business Machines Corporation Efficient XML schema validation of XML fragments using annotated automaton encoding
US20050262115A1 (en) * 2004-05-05 2005-11-24 Jingkun Hu Extensible constraint markup language
US20060085451A1 (en) * 2004-10-15 2006-04-20 Microsoft Corporation Mapping of schema data into data structures
EP1842140A4 (de) * 2005-01-19 2012-01-04 Truecontext Corp Durch richtlinien gesteuerte mobil-formular-anmeldungen
US8347088B2 (en) * 2005-02-01 2013-01-01 Newsilike Media Group, Inc Security systems and methods for use with structured and unstructured data
US8200700B2 (en) * 2005-02-01 2012-06-12 Newsilike Media Group, Inc Systems and methods for use of structured and unstructured distributed data
US7752224B2 (en) * 2005-02-25 2010-07-06 Microsoft Corporation Programmability for XML data store for documents
US7587415B2 (en) * 2005-03-14 2009-09-08 Microsoft Corporation Single-pass translation of flat-file documents into XML format including validation, ambiguity resolution, and acknowledgement generation
CN101263477B (zh) * 2005-09-09 2011-10-19 微软公司 用于管理与计算机生成文档相关联的数据的系统和方法
US7774321B2 (en) * 2005-11-07 2010-08-10 Microsoft Corporation Partial XML validation
US20070156721A1 (en) * 2005-12-02 2007-07-05 Norbert Bollow Efficient Webservice Data Format and Protocol Suite
US7647298B2 (en) * 2006-03-23 2010-01-12 Microsoft Corporation Generation of query and update views for object relational mapping
US7962919B2 (en) * 2006-03-29 2011-06-14 Intel Corporation Apparatus and method for modifying an initial event queue for extending an XML processor's feature set
US7992081B2 (en) * 2006-04-19 2011-08-02 Oracle International Corporation Streaming validation of XML documents
US20080147692A1 (en) * 2006-12-14 2008-06-19 General Motors Corporation Method for manipulating the contents of an xml-based message
US20080147605A1 (en) * 2006-12-15 2008-06-19 Business Objects, S.A. Apparatus and method for creating a customized virtual data source
EP2546745B1 (de) * 2011-07-13 2017-11-29 Harman Becker Automotive Systems GmbH Anzeigen von Zuständen in einem Telematiksystem

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6611843B1 (en) * 2000-10-26 2003-08-26 Docent, Inc. Specification of sub-elements and attributes in an XML sub-tree and method for extracting data values therefrom
US20050245272A1 (en) * 2004-04-29 2005-11-03 Spaur Charles W Enabling interoperability between distributed devices using different communication link technologies

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
VERSTICHEL ET AL: "Ontology-driven middleware for next-generation train backbones", SCIENCE OF COMPUTER PROGRAMMING, ELSEVIER SCIENCE PUBLISHERS BV., AMSTERDAM, NL, vol. 66, no. 1, 30 March 2007 (2007-03-30), pages 4 - 24, XP022006253, ISSN: 0167-6423 *

Also Published As

Publication number Publication date
DE102008059197A1 (de) 2010-06-02
CN102227727A (zh) 2011-10-26
CN102227727B (zh) 2016-02-10
US20110282889A1 (en) 2011-11-17

Similar Documents

Publication Publication Date Title
EP1176482B1 (de) Verfahren und Computerprogramm zum Herstellen einer Regelung oder Steuerung
DE60015423T2 (de) Verfahren und Vorrichtung zur Objektwiedergabe in einem Netzwerk
DE60118487T2 (de) Kommunikationsystem auf Basis von WDSL Sprache
DE60224849T2 (de) Verfahren und einrichtung zur verwaltung des baumdatenaustauschs
DE10048940A1 (de) Erzeugen von Dokumenteninhalten durch Transcodierung mit Hilfe von Java Server Pages
WO2010060541A1 (de) Verfahren und vorrichtung zur verteilten konfiguration von telematik-diensten in kraftfahrzeug-systemen
EP1303819A1 (de) System und verfahren zur generierung eines xml-basierten fehlermodells
Nußbaumer Entwicklung und Evolution dienstorientierter Anwendungen im Web Engineering
DE102006028311B4 (de) Mehrseitige Synchronisation einer Ausführung in einer drahtlosen Testumgebung
EP1030254B1 (de) Verfahren und System zum Verwalten von Dokumenten
DE102006027664B4 (de) Kommunikationssystem zum Verarbeiten von Daten
DE10118064A1 (de) Erweiterung Browser-Bezogener Internetseiteninhaltskennzeichen und Kennwortüberprüfung auf Kommunikationsprotokolle
WO2012017056A1 (de) Verfahren und vorrichtung zur automatischen verarbeitung von daten in einem zellen-format
EP3991064B1 (de) Verfahren und prozessoreinrichtung zum wechseln eines datenformats von kommunikationsdaten für eine gerätekommunikation sowie kraftfahrzeug
WO2005116867A1 (de) Verfahren und system zur automatisierten erzeugung von computergestützten steuerungs- und analysevorrichtungen
EP2899920B1 (de) System und Verfahren zur Filterung und Speicherung von Daten
EP1556789A1 (de) Verwaltung von mit einer erweiterbaren auszeichnungssprache beschriebenen daten
EP1282295A2 (de) Konvertierungseinrichtung und Konvertierungsverfahren für einen akustischen Zugang zu einem Computernetzwerk
WO2008113599A2 (de) Portable datenträger als web-server
DE102022113104A1 (de) Eindeutige Identitätskennung für Lognachrichtenquellen in Fahrzeugen
DE10134093C2 (de) Verfahren und Anordnung zum Entfernen von Verbindungen aus einem Netzwerk mit Knoten und Verbindungen
WO2020119882A1 (de) Verfahren sowie system zum übermitteln eines anwendungsspezifischen datenpakets aus maschinenlesbaren tripeln
EP1515521A9 (de) Verfahren und Vorrichtung zum automatischen Verarbeiten textbasierter Nachrichten zur Abfrage von Internet-basierten Applikationen
DE10215538A1 (de) Verfahren zur Übertragung von Nutzdatenobjekten von einer Datenbereitstellungskomponente zu einer Telekommunikationseinrichtung
DE10147872A1 (de) Verfahren, Vorrichtung und Speichermedium mit Software zum Anzeigen von Eigenschaften eines Objektes einer Server-Software in einem Client-Rechner

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980147425.2

Country of ref document: CN

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

Ref document number: 09760725

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 09760725

Country of ref document: EP

Kind code of ref document: A1