WO2003003200A1 - Verfahren zum übertragen von software-modulen - Google Patents

Verfahren zum übertragen von software-modulen Download PDF

Info

Publication number
WO2003003200A1
WO2003003200A1 PCT/EP2002/006994 EP0206994W WO03003200A1 WO 2003003200 A1 WO2003003200 A1 WO 2003003200A1 EP 0206994 W EP0206994 W EP 0206994W WO 03003200 A1 WO03003200 A1 WO 03003200A1
Authority
WO
WIPO (PCT)
Prior art keywords
software modules
configuration
transmission
mobile device
transmitted
Prior art date
Application number
PCT/EP2002/006994
Other languages
English (en)
French (fr)
Other versions
WO2003003200B1 (de
Inventor
Ferry Duerschmidt
Andrej Krauth
Michael Mueller
Original Assignee
Daimlerchrysler Ag
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 Daimlerchrysler Ag filed Critical Daimlerchrysler Ag
Publication of WO2003003200A1 publication Critical patent/WO2003003200A1/de
Publication of WO2003003200B1 publication Critical patent/WO2003003200B1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/64—Retargetable
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/005—Moving wireless networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Definitions

  • the invention relates to a method for transmitting software modules from a center to a target device with the aid of a device for data transmission in both directions.
  • the target device is a mobile device, preferably a means of transport.
  • “Software modules” refer in particular to programs or parts of programs that are carried out on board mobile devices, and data for such programs or for target devices and parameters of target devices. “Target devices” are those which process data Devices on board a mobile device referred to, for which software modules are to be transmitted, including in particular control devices such. B. for doors or air conditioning. One too The transmitting parameter influences, for example, the functioning of a target device or activates or deactivates a program on board the mobile device.
  • DE 68920462 T2 known.
  • the task of DE 68920462 T2 is an online problem solution in a customer system by means of a central remote maintenance system.
  • a problem management database receives service requests as search arguments and provides solutions for troubleshooting. It contains entries that combine a large number of components and symptoms as search arguments and problem solutions as output data.
  • the problem management database preferably consists of three separate units, namely a symptom exception table with entries for hardware components, an APAR table for software components with preliminary program corrections and an MTAR table with corrections for microcode.
  • the search arguments are preferably symptom sequences, formatted as reference keys, which identify field replaceable units (FRUs) and identify the number and exit point of a problem-solving process. For example, the symptom sequence consists of the two most likely errors.
  • the problem management database of DE 68920462 T2 requires symptoms that have been discovered as search arguments and exit points of problem determination methods.
  • a service request identifies a specific customer system and results of the problem determination process.
  • the problem management database is structured in such a way that its output data determine the problem solution.
  • the problem management database is necessarily complex and it takes some computing time to evaluate it. As a rule, a component can be disturbed by different errors, and an error on one component can cause errors on other components. Therefore, there are usually far more symptoms to be considered than there are components.
  • configuration data of the target device is accessed in DE 68920462 T2.
  • the configuration of the hardware and software components at the time of the fault is thereby detected.
  • This configuration data is preferably managed in a table by a resource manager system.
  • a resource manager system For mobile devices it is - e.g. B. because of scarce storage capacity on board - often not or only possible with effort to keep such a table on board and keep it up to date.
  • the table with the configuration does not match the actual configuration of the target device because a user or operator of the mobile device exchanges or supplements a target device.
  • Such an operator or user is usually not a DV specialist ann, but z. B. a driver. Therefore, it must not be assumed that a configuration table always contains the current configuration of the mobile device.
  • DE 19750372 AI discloses a method for transmitting programs and / or data from a central server to a vehicle. The transmission takes place via radio connection.
  • the vehicle and server each have a transmitting and receiving device. It is checked whether the user has access authorization for the requested programs and / or data. For this test, data is reported from the vehicle to the control center.
  • DE 19750372 AI does not disclose a solution to the problems that many variants of the mobile device can be in use and that target devices on board a mobile device can influence one another.
  • DE 19853000 AI discloses a method for supplying motor vehicles with data and for exchanging, querying, changing and updating data.
  • a wireless data transmission device is used.
  • the data are preferably monitoring data, e.g. B. operating data of brakes, chassis, oil level, or they are programs or program parts.
  • a method for programming data into a vehicle component is known from DE 19532067 C1.
  • Data is transferred from a central office to the requesting party.
  • information on the identity of the vehicle, component and user is transmitted to the head office.
  • the above-mentioned documents disclose methods to transmit software modules to a mobile device and to carry out authorization and release checks if necessary.
  • the tests relate to a single mobile device.
  • the method does not take into account the possibility that software modules are to be transmitted to mobile devices with a wide range of variants.
  • the wealth of variants is also not taken into account by the fact that, as in DE 19853000 AI, monitoring data are transmitted from the vehicle to the control center.
  • the wealth of variants results, for example, from the fact that in different examples of a family of mobile devices, e.g. B. a vehicle fleet, different target devices are installed or that target devices are used in different versions and variants or different software modules have been activated.
  • the invention has for its object to provide a method according to the preamble of claim 1, which also ensures that only the correct and no other software modules are transmitted when variant families of target devices with target -Devices from different manufacturers are available or if the possibility of subsequent changes to individual target devices about which the control center is not informed must be taken into account. Furthermore, a transmission device for performing the method is to be provided.
  • a device for wireless data transmission in both directions is used for the transmission, and a set of software modules is selected. This set consists of several software modules or just a single software module.
  • Information about the current configuration of the mobile device are transmitted to the control center. "Current configuration" refers to the actual configuration present at the start of the transmission. This information includes a list of which target devices and which software modules are actually present on board the mobile device at the beginning of the transmission. Which of these software is checked Modules are released for the current configuration The selected software modules that have been released for the current configuration are transferred.
  • release definitions are used, which are generated as follows:
  • Device type identifiers are defined for the target devices, that is, identifiers for the types of target devices.
  • Software type identifiers are defined for the software modules. Using the device type identifiers and software type identifiers, it is determined which of the selected software modules are released for which types of target devices. These release specifications are used to decide which software modules are released for the configuration that actually exists at the start of the transfer.
  • the method can be used in the same way for the supply of a single mobile device as well as for families of variant-rich or variant-poor mobile devices.
  • the correct and no other software modules are reliably selected and transmitted even if there are several target devices from different manufacturers in the mobile device and these target devices occur in different versions and variants that require different software modules.
  • the correct software modules are also selected and transmitted if a user or operator of the mobile device has replaced a target device with a different one or has subsequently added another target device. This is achieved in particular by determining which target devices and software modules are actually in the mobile device at the time of transmission. It is no longer necessary to run a query in a central len database with configurations of mobile devices. The entries in such a central database can be outdated, e.g. B. because a target device was replaced by another or a target device was added or removed without the manufacturer being informed.
  • a customer service measure is carried out for all vehicles of one type. For example, a new version of a software module is transmitted for all vehicles in a series and year of manufacture. Or a legal provision in a state is changed and software modules are transferred to vehicles in that state to comply with the changed laws. The owner and user of the mobile device are informed, and the software modules are transmitted according to the invention with the consent.
  • the method according to the invention does not require that a vehicle of the type be brought into a workshop, and it is ensured that the new version of the software module is only transmitted to those vehicles for whose configurations it is approved.
  • An owner of a mobile device buys additional or improved functionality from the manufacturer of the mobile device, which functionality is implemented exclusively by additional software modules on target devices already installed.
  • the method enables the software modules to be transferred without a visit to the workshop if a wireless connection can be established. It is ensured that the software modules are released for the mobile device.
  • a target device on board a vehicle has failed and the vehicle cannot continue its journey.
  • a maintenance technician drives to the vehicle with a new target device.
  • the new device is identical in terms of hardware or at least functionally identical to the failed device, but no software modules are stored in it.
  • the required software modules are transmitted by the method according to the invention.
  • the maintenance technician is responsible for a fleet of different vehicles with different devices on board, it is not possible due to the variety of variants that he carries with him all software modules that are needed if one of the target devices fails on board one of the vehicles.
  • the method according to the invention saves a considerable amount of time compared to the procedure in which the maintenance technician only determines which software modules are required for the new device after a device has failed, and then procures these software modules from a control center.
  • the set of software modules is selected, for example, as follows (claim 2):
  • the current configuration of the mobile device transmitted to the control center is compared with a desired or desired configuration.
  • a wish Configuration is generated, for example, by an owner of the mobile device acquiring additional functionalities, a target configuration by the manufacturer of the mobile device providing that all mobile devices in a series are supplied with a specific software module.
  • the software modules are depending on the difference between the current and desired or Target configuration selected. For example, all software modules are selected that appear in the desired or target configuration, but not at all in the current configuration or only in an older version.
  • Claim 3 provides that before the transmission of the software modules it is checked whether a transmission channel with a quality that is sufficient for the transmission can be set up with the aid of the wireless data transmission device. In particular, it is checked whether a connection is established at all and whether this connection has sufficient bandwidth.
  • the software modules are preferably compressed before the transmission and decompressed after the transmission in order to save transmission time.
  • the method according to the invention can also be carried out when the current configuration cannot be transmitted completely to the control center and the information required is therefore missing, for example because not all information about the current configuration has been stored on board or because the Data connection from the mobile device to the control center is disrupted. On the other hand, the information about the current configuration that has been transmitted to the control center and is not incorrect has priority over the stored configuration information.
  • information about a configuration of the mobile device known to the control center is stored in a configuration management system or documentation system.
  • the system includes a database in which a data set for the mobile device is created when it is completed. currency
  • an identifier of the mobile device is transmitted to the control center. This identifier distinguishes this mobile device from at least all other mobile devices from the same manufacturer.
  • the information about the current configuration transmitted to the control center is compared with the stored information about the configuration.
  • the data record for this mobile device is accessed.
  • Information about the current configuration that is not transmitted is supplemented by read access to the saved configuration.
  • the stored configuration is accessed in particular if the current configuration is only incompletely transmitted to the control center and therefore the information required about the current configuration, for example the type of a door control unit actually installed at the time of transmission, is missing.
  • the information about the current configuration transmitted to the control center is preferably subjected to a plausibility check in order to identify transmission errors in particular. If individual information is recognized as obviously inaccurate, the inaccurate information transmitted is replaced by the corresponding stored information.
  • the software modules are preferably first stored in a buffer memory on board the mobile device. They are then distributed to the respective target devices and transferred to them. Meta information which controls the distribution and / or transmission and / or activation of the software modules on board the mobile device is therefore preferably transmitted together with the software modules.
  • the wireless data connection between the control center and the mobile device can be disturbed, which is why the transmission of the software modules cannot be completed without errors.
  • the manufacturer of mobile devices is often legally obliged to document which software modules are used are on board the mobile devices manufactured by him.
  • the information is transmitted to the control center as to whether the software module was actually transmitted to the mobile device without errors (claim 5).
  • information about the result of the transmission is preferably transmitted to the control center. If errors occurred during the transmission, an error description is preferably also transmitted to the control center.
  • the current configuration of the mobile device is changed by the successful transmission of software modules.
  • back documentation is carried out according to claim 6.
  • the identifier of the mobile device is transmitted to the control center. This identifier distinguishes this mobile device from at least all other mobile devices from the same manufacturer.
  • the information is stored as to which target device types and which software modules are actually present on board the mobile device after the transmission has been completed. According to the invention, information about the target device types has already been transmitted to the control center for the release checks.
  • the information as to which software modules have been transmitted correctly and without errors is also used for synchronization after an error, e.g. B. after a connection is used. It is determined which software modules are intended for transmission in a second attempt.
  • the transmitted software modules are preferably only activated when the mobile device is in a safe state. Otherwise there is a risk that during the activation of a software module or the necessary deactivation of a previously existing software module, the mobile device will get into an undesired operating state. For example, it must be ensured that software modules for control units on board a motor vehicle can only be activated when the vehicle is stationary. Claim 7 provides that additional information about the current operating state of the mobile device is transmitted to the control center. Depending on the operating state information, a decision is made as to whether the mobile device is in a safe state. Then, when it is in a safe state, the transferred software modules are activated.
  • the transmission can be requested both from the control center and from a location outside the control center, for example an owner, driver or user of the mobile device, for example with the aid of a computer on the Internet.
  • the location can also be the mobile device or a target device that automatically requests transmission.
  • an authorization check is preferably carried out for the requesting body (claim 8).
  • information about the identity of the body requesting the transfer of the software modules is transmitted to the head office.
  • a PIN, a password or a fingerprint are determined by a requesting person and compared with stored information.
  • Software modules are only transferred if the authorization check is successful.
  • the authorization check in particular prevents a user from acquiring a paid software module without having paid for it, and from the transmission being triggered due to an error.
  • a correctness check is carried out (claim 9).
  • a signature is generated for at least one software module and stored on the mobile memory device.
  • the signature is preferably generated by treating the software module as a data stream and generating a hash value. With the help of a secret key, this hash value is created generated the signature. The signature therefore depends on the software module and the secret key.
  • a public key is stored on board the mobile device for at least one target device type.
  • the signature is checked with the help of this public key. Only if the test is positive is the software module recognized as not falsified and authorized.
  • a transmission device for carrying out a method according to any one of claims 1 to 9 comprises, according to claim 10, a device for wireless data transmission between the control center and the mobile device in both directions and a control device which enables the transmission of software modules from the control center to the mobile Device causes and controls.
  • the control device determines the configuration of the mobile device that actually exists at the start of the transmission, selects the number of software modules, and checks which of the selected software modules are released for the actually existing configuration. Furthermore, the control device causes the transmission of the selected and released software modules.
  • the control device preferably determines which software modules were transmitted to the mobile device without errors (claim 11).
  • the control device preferably responds to detected transmission errors. For example, it initiates a second transmission attempt, carries out error handling or terminates the transmission of the software modules.
  • 1 shows an exemplary embodiment of the invention in which the software modules are transmitted from a center to the mobile device with the aid of two different wireless data transmission devices; 2 shows an exemplary system architecture for the central and mobile device.
  • a data connection between the control center 10 and the first vehicle 20.1 and a further data connection between the control center 10 and the second vehicle 20.2 are established at least temporarily.
  • the wireless data connections can be made in the same or different ways.
  • 1 shows the wireless transmission using a satellite 50.1 and that via a mobile radio network 50.2 as two examples.
  • the software modules are e.g. B. transmitted over a wide area network or a local network.
  • the head office can be located in a single location or be spatially distributed. In particular if a vehicle 20.1 or 20.2 is moving during the transmission, the transmitting center can even change during the transmission.
  • an authorization check is carried out for the requesting body.
  • a fingerprint of a requesting person is ascertained or a PIN or a password is acquired by a requesting body and then the fingerprint, PIN or password is transmitted to the central office and evaluated during an authorization check.
  • After a successful authorization check it is determined whether the owner has given a binding consent to the transfer. The following steps are only carried out if consent is given or is not required.
  • a unique identifier of the vehicle preferably a vehicle identification number, is determined and transmitted to the control center.
  • This identifier distinguishes the vehicle from all other vehicles from this manufacturer.
  • the series, the model and the year of construction and the year of the last change are transmitted. This information can often be determined by read access to a central configuration management system. However, if they are transmitted from the vehicle to the control center, this often saves time-consuming read access.
  • the current configuration of the vehicle is determined and transmitted to the control center. In this case, it is determined which target devices are actually installed on board the vehicle before transmission begins and which software modules are actually activated and / or stored before transmission begins on board the vehicle.
  • Type identifiers for the currently installed devices and already existing software modules e.g. B. Part numbers and variant numbers are transmitted. This determination is preferably carried out by having a memory in each target device in which the configuration information about this target device is stored and the z. B. is addressed and read out via a data bus.
  • Alternative embodiments consist of reading out a central memory on board the vehicle or memory chips which are attached to the target devices. In particular, if a memory in a target device cannot be read due to a defect or if the memory of a new target device has not yet been filled, a makeshift solution is to mark devices, e.g. B. barcodes to optically detect.
  • the information about the current configuration is compared with a data record about the configuration of the vehicle, which is stored in a configuration management system. This is carried out, for example, when the transmitted information about the current configuration is incomplete or recognizable. bar are faulty. To identify such errors, a plausibility check of the information transmitted by the vehicle and the stored information about the configuration is preferably carried out.
  • a number of software modules are selected that are transferred from the control center to the vehicle. The selection depends on the current configuration of the vehicle, the application and customer requirements.
  • the software modules selected and released for the current configuration are compressed so that the compressed software modules take up less storage space than the uncompressed ones.
  • Various methods for compressing data are known.
  • the software modules selected and released for the current configuration are converted for transmission. If necessary, the software modules are divided into parts.
  • meta information is transmitted, which controls the distribution and transmission of the software modules on board and their activation. This meta information includes parameters that the on-board transmission protocol used requires.
  • the software modules selected and released for the current configuration are transferred from the control center to the vehicle.
  • a mobile radio standard e.g. B. GSM or UMTS used.
  • a protocol suitable for the selected transmission technology e.g. B. uses the file-based protocol zModer. This facilitates secure error handling with synchronization, which is described further below, in particular after the connection has been broken.
  • the transmitted software modules are preferably stored in a buffer memory on board the vehicle.
  • This information is transmitted to the head office. For example, after each successful transmission of a software module, feedback is transmitted to the central office, or after all software modules have been successfully transmitted, this information is transmitted to the central office. For the determination, a target checksum is preferably determined and transmitted for each software module or each software module part using the CRC method. After the transmission, an actual checksum is determined on board the mobile device and compared with the target checksum.
  • encryption information is transmitted together with the software modules in order to check whether the software modules originate from a trustworthy source and have been transmitted in an unadulterated manner.
  • a software module is encrypted in the control center and decrypted again on board the mobile device. A method for this is known from DE 195 32 067 Cl.
  • a software module is transmitted unencrypted, but together with a signature. The signature is generated with the aid of a secret key in the control center and compared with a public key that was previously transmitted to the mobile device, for example, on another channel.
  • Data on the current operating state of the vehicle are recorded and transmitted to the control center. These data include, for example, the current driving speed, the state of the engine, the state of charge of the battery and the current position of the vehicle. Based on the operating status, it is decided whether the transferred software modules are now activated. In particular, it is checked whether the vehicle is in a safe state. For example, the state of charge of the battery is taken into account to ensure that sufficient electrical voltage is available throughout the activation. The current position is evaluated, for example, to check in which country or z. B. US state the vehicle is located to check if necessary whether country-specific legal or technical boundary conditions are to be observed. If necessary, the driver of the vehicle is asked to bring the vehicle into a safe state, e.g. B. stop it and confirm it. This is e.g. B. through speech and input or thereby- led that messages are displayed and the driver is asked to confirm them.
  • a safe state e.g. B. stop it and confirm it.
  • the transferred software modules are transferred from the buffer memory to the target devices, preferably via a data bus on board of the vehicle. If necessary, they are decompressed beforehand. The meta information is selected for this process. After the transfer to the devices, the devices are deactivated if necessary, the software modules activated and then the devices reactivated.
  • the current configuration of the mobile device is stored after the transmission.
  • the current configuration includes the information as to which of the target devices are actually installed on board and which software modules have either been transmitted and activated without errors or have already been activated before the transmission and have not been changed by the transmission.
  • a configuration management system in the center comprises a data record for the vehicle. This data record is updated after the transmission, so that after the update it contains information about which of the target devices are actually installed on board. and which software modules are now activated.
  • Error handling is particularly necessary if a predetermined number of attempts attempts to transfer all software modules without errors, for example because no connection can be established between the control center and the vehicle. Synchronization is preferably carried out in the event of error handling. This determines which software modules were transferred without errors. The data record for the vehicle in the central configuration management system is updated and an error log is generated. At a later time a new transmission attempt is started that starts from a defined state.
  • FIG. 2 shows an exemplary system architecture for the control center 10 and the vehicle 20.
  • the control center 10 comprises the following components: a central remote flashing manager 160, which initiates and controls the transmission of software modules from the control center to the mobile device, and at the same time software -Module selects and checks whether they are released for the current configuration, a control and regulation device 110, with which the necessary measures for the transfer of software modules are recorded and listed and initiated and by which the implementation of the measures is monitored , a logistics system 130, which identifies, selects and provides the required software modules for the transfer, an accounting system 140, which handles the transfer processes commercially and in particular carries out the accounting and monitors the payment processes, an information system 150, which controls the owner and / or driver of the The vehicle is informed before the transmission about functional expansions and changes that can be implemented by software modules and software modules and after the transmission about the successful transmission or about errors that have occurred and that uses, for example, the Internet or the sending of letters, a decision support system 170, with the help of which software modules are selected
  • a transmitting and receiving device 190 which is connected to the vehicle 20.1, 20.2.
  • the transmitting and receiving devices 180 and 190 are, for example, as nodes of a mobile radio network which, for. B. work with the transmission method GSM or UMTS, or trained for transmission by satellite.
  • a plurality of transmitting and receiving devices 190 can be installed on board a vehicle.
  • two target devices on board a motor vehicle 20.1, 20.2 are supplied with software modules: a central unit of a system for voice output, which, for. B. Reads messages to the driver in natural language, and a control unit for the door system.
  • the central unit is connected to a transceiver for wireless data transmission and to the control unit via a data bus.
  • the two target devices come from different manufacturers and are installed in different versions in vehicles.
  • the voice output should be possible in several languages.
  • the software modules for all variants of the two target devices are generated and saved in the control center.
  • the type of a target device and that of a software module are each identified by a part number and a variant number.
  • the item number is a sequence of digits and letters that is unique within the product range of the vehicle manufacturer.
  • the variant is identified by a number with three digits.
  • the release specifications are stored, for example, in a relational database in the form of data records at the headquarters. This database is read in and evaluated for a release check.
  • a software module is only released for a type of target device if a corresponding release specification is noted in the release database, otherwise not.
  • series is meant the series of the vehicle to which the release data record refers, e.g. W212.
  • target device type and “software modules” device or software type Identifiers, which is explained below by way of example.
  • the time entered in the data field “valid_ab” defines the start of the release period for the data record.
  • the software modules mentioned in the data record are only released for the named target device types if the time of transmission is after the time specified by the data field "valid_ab”.
  • the release can be tied to a release condition, which is preferably is formulated as a Boolean expression.
  • the contents of the data fields "Description_Hardware” and “Description_Software” are not automatically evaluated. Rather, they explain the type identifiers to a processor.
  • the software for the central unit comes from the supplier XY, the software for the door control unit from the suppliers AB (for the European market) and FG (for the US market).
  • Types of target devices and software modules are identified by part numbers that begin with HW or SW, followed by three or four digits. Variants are identified by three digits.
  • SW-212-001 denotes e.g. B. a software module with the part number SW-212 and the variant number 001.
  • Type identifiers from part numbers and variant numbers are placed in square brackets [].
  • the software module [SW-101-001] is released by the 1st data set for the target device types [HW-1001-001] and [HW-1001-002] in Europe.
  • the software module [SW-111-001] is released in Europe by the 2nd data set for the target device types [HW-1001-001] and [HW-1001-002].
  • the software module [SW-102-001] is released by the 3rd data set for the target device types [HW-1002-001] and [HW-1002-002] in the USA.
  • the software module [SW-112-001] is released by the 4th data set for the target device types [HW-1002-001] and [HW-1002-002] in the USA, if the release condition is fulfilled is.
  • the release condition is met if
  • the software module [SW-221-001] is released by the 5th data set for the target device types [HW-2001-001] and [HW-2001-002] in Europe if the release condition is fulfilled , The release condition is met when on board
  • the software module [SW-111-001] is released by the 6th data record for the target device types [HW-1001-001] and [HW-1001-002] in the USA, if the software Module [SW-221-001] is activated.
  • the release database is searched for each target device that occurs in the vehicle. For each data record, the "Series" data field is compared and the "Target device types" data field is evaluated. tet. If a target device of a type named in the data field "target device types" is installed on board, it is determined whether a release condition has been formulated. If this is the case, a check is carried out to determine whether the release condition is fulfilled If the release condition is fulfilled or no release condition has been formulated, all software modules that are named in the data field "Software modules" of the data record are released for the vehicle. Which of the released software modules are actually transferred depends on which software modules have been selected.
  • configuration and security information is also generated, for example in two databases for software modules and two for software module parts, stored in the control center and evaluated during transmission.
  • One database is the configuration database, the other the security database.
  • the information in the configuration database determines which files belong to the software module, where these files are stored and in which order they go where. H. to which target device to be transferred. With the help of the safety information, transmission errors and manipulations are recognized.
  • a data record for a software module in the configuration database for software modules includes, for example, the following data fields:
  • the "Destination address" data field specifies the destination address of the destination device on the data bus in the vehicle, for example # 57 for the door control unit and # 20 for the central unit.
  • the "Size" data field specifies the size of the software module in KByte. This information is used, for example, for a progress indicator during the transfer. It is determined how many KByte have already been transferred and by specifying it in the configuration file Knows how many KBytes are to be transferred in total The quotient indicates the work progress, which is displayed, for example, as a bar.
  • the data field “storage location” indicates where this software module is stored in the central office, for example in the form of a path of an operating system or access information to a database.
  • Parts__IDs The data field "Parts__IDs" is only filled in if the software module is transferred in several parts rather than at once.
  • the data record for the software module [SW-111-001] in the configuration database includes the following entries:
  • the 7th data record specifies that the transmission of the software module [SW-111-001] with the CRC method is is checked. The check determines whether a transmission error has occurred during transmission to the vehicle and storage on board the vehicle. A CRC value, in this example the hexadecimal number 4758A08C, is given as the check sum.
  • the software module is transferred at once, so the data field "Parts_IDs" is empty.
  • each software module part is assigned its own test procedure and its own checksum.
  • the data field "storage location" indicates where this software module part is stored in the control center.
  • the software module [SW-111-001] has been released for two variants of target devices, namely for variants 001 and 002 of type HW-1001. Therefore, two different signatures are generated and stored in the 8th and 0th data sets, namely one signature per variant of the target device type.
  • the signature for a variant is preferably generated by treating the variant as a data stream and generating a hash value.
  • the signature is generated from this hash value with the help of a secret key.
  • the signature therefore depends on the software module and the secret key.
  • 1024-bit encryption based on the Rivest-Shamir-Adleman algorithm (RSA encryption) is used to generate the signature.
  • the generation of signatures is carried out on a computer that is strictly protected against unauthorized access and manipulation.
  • the supplier operates this computer and delivers the two variants and the two signatures to the manufacturer of the motor vehicle.
  • Another embodiment is that the supplier only delivers the two variants to the manufacturer and the manufacturer himself creates the signatures.
  • the manufacturer transmits the signatures to the supplier, who then transfers the software modules to his target devices and uses the signature for an inspection.
  • a third embodiment consists of a certified trust center generating the signatures and managing the secret keys.
  • a public key is stored in a permanent, non-overwritable memory of the target device. The public key can be read out, but it is protected against accidental as well as deliberate overwriting or falsification or deletion.
  • the supplier preferably provides the target device with the public key.
  • the signature is checked using the public key after the transfer and before activating the software module. This check ensures that the software module comes from a trustworthy source and has not been tampered with or manipulated.
  • the "Keyword Protocol 2000” (KWP2000), which is standardized by ISO 14230-1 and ISO 15765-1 to 15765-4 and VDA 14230-1 to VDA 14230-3, is used as the on-board transmission protocol, for example. Commands are in KWP2000 encoded by hexadecimal numbers, eg the command "ReadEDUIdentification” (reading a type identifier for a target device) by $ 1A, 86.
  • the meta information transmitted with a software module includes the communication parameters necessary for the KWP2000 protocol, which control the transmission on board from the buffer memory to a target device, e.g. B. block sizes, timing parameters, sequence information and address of the device on the data bus. Other transmission protocols are also suitable.
  • the meta information is also transmitted in the form of a table, for example. In contrast to the table for the release check, this table is only generated during the transfer process.
  • This information is stored in the head office, for example in a configuration management system, preferably in the data record for the vehicle. It is also stored there who initiated the transmission.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Übertragen von Software-Modulen von einer Zentrale zu einer mobilen Vorrichtung, insbesondere zu einem Verkehrs- oder Transportmittel. Für die Übertragung wird eine Einrichtung zur drahtlosen Datenübertragung in beiden Richtungen verwendet, und eine Menge von Software-Modulen wird ausgewählt. Die zu Beginn der Übertragung tatsächlich vorhandene Konfiguration der mobilen Vorrichtung wird an die Zentrale übermittelt. Geprüft wird, welche dieser Software-Module für die tatsächlich vorhandene Konfiguration freigegeben sind. Dabei werden für die Ziel-Geräte Geräte-Typ-Kennungen und für die Software-Module Software-Typ-Kennungen in Freigabe-Festlegungen verwendet. Diese Freigabe-Festlegungen werden bei einer Freigabe-Prüfung verwendet. Die ausgewählten und für die tatsächlich vorhandene Konfiguration freigegebenen Software-Module werden übertragen. Das Verfahren ist in gleicher Weise für die Versorgung einer einzelnen mobilen Vorrichtung wie auch für Familien von variantenreichen oder variantenarmen mobilen Vorrichtungen anwendbar.

Description

Verfahren zum Übertragen von Software-Modulen
Die Erfindung betrifft ein Verfahren zum Übertragen von Software-Modulen von einer Zentrale zu einer Ziel-Vorrichtung mit Hilfe einer Einrichtung zur Datenübertragung in beiden Richtungen. Die Ziel-Vorrichtung ist eine mobile Vorrichtung, vorzugsweise ein Verkehrs- oder Transportmittel.
In mobilen Vorrichtungen, insbesondere in Kraftfahrzeugen, wird eine steigende Anzahl von Geräten verwendet, die durch Software-Module gesteuert werden, z. B. Tür-Steuergeräte. Manche Geräte, z. B. elektronische Navigationssysteme und Systeme zur Sprachausgabe, benötigen umfangreiche Datenbibliotheken. Um mobile Vorrichtungen an individuelle Anforderungen und Wünsche von Benutzern oder Betreibern anzupassen, werden oft Ziel-Geräte in vielen unterschiedlichen Versionen und Varianten hergestellt und eingebaut, manchmal auch nachträglich. Durch die Kombination von Varianten entsteht eine hohe Zahl unterschiedlicher Konfigurationen von Ziel-Geräten an Bord von mobilen Vorrichtungen, die zu einer Familie von mobilen Vorrichtungen gehören. Der Hersteller einer mobilen Vorrichtung hat trotz der Variantenvielfalt zu gewährleisten, dass diese Ziel-Geräte in jeder freigegebenen Kombination im laufenden Betrieb sicher zusammenspielen.
Mit „Software-Module" werden insbesondere Programme oder Teile von Programmen, die an Bord von mobilen Vorrichtungen ausgeführt werden, und Daten für solche Programme oder für Ziel- Geräte sowie Parameter von Ziel-Geräten bezeichnet. Mit „Ziel-Geräten" werden diejenigen datenverarbeitenden Geräte an Bord einer mobilen Vorrichtung bezeichnet, für die Software-Module zu übertragen sind, hierzu zählen insbesondere Steuergeräte z. B. für Türen oder die Klimaanlage. Ein zu übertragender Parameter beeinflußt beispielsweise die Funktionsweise eines Ziel-Geräts oder aktiviert oder deaktiviert ein Programm an Bord der mobilen Vorrichtung.
Es ist heute noch üblich, zum nachträglichen Übertragen von Software-Modulen in mobile Vorrichtungen die Ziel-Geräte z. B. in einer Werkstatt auszubauen, mit den gewünschten Software-Modulen zu versehen und dann wieder einzubauen. In manchen Fällen muß das Ziel-Gerät sogar zum Hersteller geschickt werden, der zentral die Software-Module überträgt. Diese Wege sind teuer und zeitaufwendig.
Ein Verfahren nach dem Oberbegriff des Anspruchs 1 ist aus
DE 68920462 T2 bekannt. Die Aufgabe von DE 68920462 T2 ist eine On-line-Problemlösung in einem Kundensystem durch ein zentrales Fernwartungssystem.
Eine Proble verwaltungs-Datenbank erhält Serviceanforderungen als Suchargumente und liefert Lösungsansätze für die Fehlerbeseitigung. Sie enthält Einträge, die eine Vielzahl von Komponenten und Symptome als Suchargumente und Problemlösungen als Ausgabedaten miteinander verbinden. Vorzugsweise besteht die Problemverwaltungs-Datenbank aus drei getrennten Einheiten, nämlich eine Symptomausnahmetabelle mit Einträgen für Hardware-Komponenten, eine APAR-Tabelle für Software- Komponenten mit vorläufigen Programmkorrekturen und eine MTAR-Tabelle mit Korrekturen für Microcode. Die Suchargumente sind vorzugsweise Symptomfolgen, die als Referenzschlüssel formatiert sind, welche austauschbare Komponenten („field replaceable units", FRUs) kennzeichnen, und die Nummer und den Austrittspunkt eines Problemlösungsverfahrens kennzeichnen. Beispielsweise besteht die Symptomfolge aus den beiden wahrscheinlichsten Fehlern.
Die Problemverwaltungs-Datenbank von DE 68920462 T2 benötigt als Suchargumente entdeckte Symptome und Austrittspunkte von Problembestimmungsverfahren. Eine Serviceanforderung kennzeichnet ein bestimmtes Kundensystem und Ergebnisse des Problembestimmungsverfahrens. Die Problemverwaltungs-Datenbank ist so aufgebaut, dass ihre Ausgabedaten die Problemlösung festlegen. Die Problemverwaltungs-Datenbank ist notwendigerweise komplex, und ihre Auswertung benötigt einige Rechenzeit. Denn in der Regel kann ein Bauteil durch unterschiedliche Fehler gestört sein, und ein Fehler an einem Bauteil kann Fehler an anderen Bauteilen hervorrufen. Daher sind meist wesentlich mehr Symptome zu berücksichtigen, als Bauteile vorhanden sind.
Vor der Übertragung von Software-Modulen wird in DE 68920462 T2 auf Konfigurationsdaten der Ziel-Vorrichtung zugegriffen. Die Konfiguration der Hardware- und Software- Komponenten zum Zeitpunkt der Störung wird dadurch erfaßt. Diese Konfigurationsdaten werden von einem Ressourcen- Manager-System vorzugsweise in einer Tabelle verwaltet. Für mobile Vorrichtungen ist es - z. B. wegen knapper Speicherkapazität an Bord - oft nicht oder nur mit Aufwand möglich, eine solche Tabelle an Bord zu führen und aktuell zu halten. Insbesondere im Falle mobiler Vorrichtungen besteht darüber hinaus die Gefahr, dass die Tabelle mit der Konfiguration nicht mit der tatsächlichen Konfiguration der Ziel- Vorrichtung übereinstimmt, weil ein Benutzer oder Betreiber der mobilen Vorrichtung ein Ziel-Gerät austauscht oder ergänzt. Ein solcher Betreiber oder Benutzer ist in der Regel kein DV-Fach ann, sondern z. B. ein Autofahrer. Daher darf nicht davon ausgegangen werden, dass eine Konfigurations- Tabelle stets die aktuelle Konfiguration der mobilen Vorrichtung enthält .
Aus DE 19750372 AI ist ein Verfahren zum Übertragen von Programmen und / oder Daten von einem zentralen Server an ein Fahrzeug bekannt. Die Übertragung erfolgt per Funkverbindung. Fahrzeug und Server haben je ein Sende- und Empfangsgerät. Geprüft wird, ob der Benutzer eine Zugriffsberechtigung für die angeforderten Programme und/oder Daten besitzt. Für diese Prüfung werden Daten vom Fahrzeug an die Zentrale gemeldet.
In DE 19750372 AI wird keine Lösung für die Probleme offenbart, dass viele Varianten der mobilen Vorrichtung im Einsatz sein können und dass Ziel-Geräte an Bord einer mobilen Vorrichtung sich gegenseitig beeinflussen können. In DE 19853000 AI wird ein Verfahren zum Versorgen von Kraftfahrzeugen mit Daten sowie zum Austausch, Abfragen, Ändern, Aktualisieren von Daten offenbart. Verwendet wird eine drahtlose Datenübertragungseinrichtung. Die Daten sind vorzugsweise Überwachungsdaten, z. B. Betriebsdaten von Bremsen, Fahrwerk, Ölstand, oder sie sind Programme oder Programmteile.
Aus DE 19532067 Cl ist ein Verfahren zum Einprogrammieren von Daten in ein Fahrzeug-Bauteil bekannt. Daten werden von einer Zentrale an die anfordernde Stelle übertragen. Insbesondere um unberechtigten Zugriff auf die übertragenen Daten zuverlässig zu unterbinden, werden Informationen zur Identität von Fahrzeug, Bauteil und Nutzer an die Zentrale übermittelt.
Aus DE 19921845 AI ist eine Diagnosetestvorrichtung für Kraftfahrzeuge mit programmierbaren Steuergeräten bekannt. Ein externer Diagnosetester ist mit einer Programmerkennungsund Programmladevorrichtung ausgestattet. Bei Bedarf wird die jeweils aktuellste Version eines Programms in den Programmspeicher des entsprechenden Steuergeräts geladen.
Die oben genannten Druckschriften offenbaren Verfahren, um Software-Module an eine mobile Vorrichtung zu übermitteln und dabei bei Bedarf Berechtigungs- und Freigabeprüfungen durchzuführen. Die Prüfungen beziehen sich jeweils auf eine einzelne mobile Vorrichtung. Jedoch wird bei den Verfahren die Möglichkeit nicht berücksichtigt, dass Software-Module an variantenreiche mobile Vorrichtungen zu übertragen sind. Der Variantenreichtum wird auch nicht dadurch berücksichtigt, dass - wie in DE 19853000 AI - Überwachungsdaten vom Fahrzeug an die Zentrale übermittelt werden. Der Variantenreichtum resultiert beispielsweise daher, dass in verschiedenen Exemplaren einer Familie von mobilen Vorrichtungen, z. B. einer Fahrzeugflotte, unterschiedliche Ziel-Geräte eingebaut sind oder dass Ziel-Geräte in unterschiedlichen Versionen und Varianten verwendet werden oder verschiedene Software-Module aktiviert worden sind. Der Variantenreichtum kann zu einer riesigen Zahl unterschiedlicher Prüfungen führen, die nicht mit vertretbarem Aufwand definiert und validiert werden können. Weiterhin wird nicht die Möglichkeit berücksichtigt, dass ein Benutzer oder Betreiber einer mobilen Vorrichtung ein Ziel- Gerät erneuert oder nachträglich ergänzt, ohne dass der Hersteller der mobilen Vorrichtung hierüber informiert wird und dies bei einer Freigabe-Prüfung nach dem Stand der Technik berücksichtigen kann. Auch beim Verfahren nach DE 19532067 Cl, bei dem Informationen über die Fahrzeug- Identität an die Zentrale übermittelt werden, wird die Möglichkeit nachträglicher Änderungen nicht berücksichtigt. Zwar kann die Zentrale sich eine abgespeicherte Konfigurations- Datei des Fahrzeugs beschaffen, diese Informationen können a- ber falsch oder veraltet sein.
Variantenreichtum und nachträgliche Änderungen sind aber zu berücksichtigen, um sicherzustellen, dass zu jeder mobilen Vorrichtung die richtigen Software-Module übertragen werden und sichergestellt wird, dass die übertragenen Software- Module auf dem Fahrzeug fehlerfrei miteinander und mit den Ziel-Geräten an Bord zusammenspielen und nicht zu unerwünschten oder fehlerhaften Betriebszuständen führen.
Ausgehend von DE 68920462 T2 liegt der Erfindung die Aufgabe zugrunde, ein Verfahren nach dem Oberbegriff von Anspruch 1 zu schaffen, das auch dann gewährleistet, dass nur die richtigen und keine anderen Software-Module übertragen werden, wenn variantenreiche Familien von Ziel-Vorrichtungen mit Ziel-Geräten verschiedener Hersteller vorliegen oder wenn die Möglichkeit nachträglicher Änderungen an einzelnen Ziel- Vorrichtungen, über welche die Zentrale nicht informiert ist, zu berücksichtigen ist. Weiterhin ist eine Übertragungs- Vorrichtung zur Durchführung des Verfahrens bereitzustellen.
Die Aufgabe wird durch ein Verfahren nach Anspruch 1 und eine Übertragungs-Vorrichtung nach Anspruch 10 gelöst. Vorteilhafte Ausgestaltungen sind in den Unteransprüchen angegeben.
Für die Übertragung wird eine Einrichtung zur drahtlosen Datenübertragung in beiden Richtungen verwendet, und eine Menge von Software-Modulen wird ausgewählt. Diese Menge besteht aus mehreren Software-Modulen oder aus nur einem einzigen Software-Modul. Informationen über die aktuelle Konfiguration der mobilen Vorrichtung werden an die Zentrale übermittelt. Mit „aktueller Konfiguration" wird die tatsächliche zu Beginn der Übertragung vorhandene Konfiguration bezeichnet. Diese Informationen umfassen eine Auflistung, welche Ziel-Geräte und welche Software-Module zu Beginn der Übertragung an Bord der mobilen Vorrichtung tatsächlich vorhanden sind. Geprüft wird, welche dieser Software-Module für die aktuelle Konfiguration freigegeben sind. Die ausgewählten und für die aktuelle Konfiguration freigegebenen Software-Module werden übertragen.
Für eine Freigabe-Prüfung werden Freigabe-Festlegungen verwendet, die wie folgt erzeugt werden: Für die Ziel-Geräte werden Geräte-Typ-Kennungen festgelegt, also Kennungen für die Typen von Ziel-Geräten. Für die Software-Module werden Software-Typ-Kennungen festgelegt. Unter Verwendung der Geräte-Typ-Kennungen und Software-Typ-Kennungen wird festgelegt, welche der ausgewählten Software-Module für welche Typen von Ziel-Geräten freigegeben sind. Diese Freigabe-Festlegungen werden verwendet, um zu entscheiden, welche Software-Module für die zu Beginn der Übertragung tatsächlich vorhandene Konfiguration freigegeben sind.
Das Verfahren ist in gleicher Weise für die Versorgung einer einzelnen mobilen Vorrichtung wie auch für Familien von variantenreichen oder variantenarmen mobilen Vorrichtungen anwendbar. Insbesondere werden auch dann zuverlässig die richtigen und keine anderen Software-Module ausgewählt und übertragen, wenn in der mobilen Vorrichtung mehrere Ziel-Geräte unterschiedlicher Hersteller vorhanden sind und diese Ziel- Geräte in unterschiedlichen Versionen und Varianten vorkommen, die unterschiedliche Software-Module benötigen.
Die richtigen Software-Module werden auch dann ausgewählt und übertragen, wenn ein Benutzer oder Betreiber der mobilen Vorrichtung ein Ziel-Gerät durch ein andersartiges ersetzt hat oder nachträglich ein weiteres Ziel-Gerät ergänzt hat. Dies wird insbesondere dadurch erreicht, dass ermittelt wird, welche Ziel-Geräte und Software-Module sich zum Zeitpunkt der Übertragung tatsächlich in der mobilen Vorrichtung befinden. Nicht mehr erforderlich ist es, eine Abfrage in einer zentra- len Datenbank mit Konfigurationen von mobilen Vorrichtungen durchzuführen. Die Einträge in einer solchen zentralen Datenbank können veraltet sein, z. B. weil ein Ziel-Gerät durch ein andersartiges ersetzt wurde oder ein Ziel-Gerät ergänzt oder entfernt wurde, ohne dass der Hersteller hierüber informiert wurde.
Dank der Verwendung einer drahtlosen Datenübertragungseinrichtung ist es nicht erforderlich, dass die mobile Vorrichtung zum Übertragen in eine Werkstätte gefahren oder transportiert wird. Es ist möglich, ein Software-Modul bereits unmittelbar nach seiner Fertigstellung und / oder Freigabe zu übertragen.
Einige beispielhafte Anwendungen, in denen das erfindungsgemäße Verfahren Vorteile gegenüber dem Stand der Technik erbringt, sind die folgenden:
• Auf Initiative des Kundendienstes eines Fahrzeugherstellers wird eine Kundendienstmaßnahme für alle Fahrzeuge eines Typs durchgeführt. Beispielsweise wird für alle Fahrzeuge einer Baureihe und eines Baujahrs eine neue Version eines Software-Moduls übertragen. Oder eine gesetzliche Bestimmung in einem Staat wird geändert, und Software-Module werden an Fahrzeuge in diesem Staat übertragen, um den geänderten Gesetzen nachzukommen. Besitzer und Nutzer der mobilen Vorrichtung werden informiert, und die Software-Module werden bei Einverständnis erfindungsgemäß übertragen. Durch das erfindungsgemäße Verfahren ist es nicht erforderlich, dass ein Fahrzeug des Typs in eine Werkstatt gebracht wird, und es wird sichergestellt, dass die neue Version des Software-Moduls nur auf diejenigen Fahrzeuge übertagen wird, für deren Konfigurationen sie freigegeben ist.
• Für einen bestimmten Fahrzeugtyp sollen umfangreiche Betriebsdaten an Bord aufgezeichnet, vorverarbeitet und an eine Zentrale übermittelt werden. Ein Programm, das die Aufzeichnung, Vorverarbeitung und Übermittlung übernimmt und dabei die Daten gegen unbefugten Zugriff sichert, wird durch das erfindungsgemäße Verfahren übertragen, nachdem der Eigentümer hierzu sein Einverständnis gegeben hat. Durch die Kenntnis der aktuellen Konfiguration wird sichergestellt, dass das übertragene Programm auf die tatsächlich an Bord vorhandenen Geräte zugeschnitten ist.
• Ein Besitzer einer mobilen Vorrichtung kauft vom Hersteller der mobilen Vorrichtung eine zusätzliche oder verbesserte Funktionalität, die ausschließlich durch zusätzliche Software-Module auf bereits eingebauten Ziel-Geräten realisiert wird. Durch das Verfahren wird es ermöglicht, dass die Software-Module ohne einen Werkstattbesuch übertragen werden, wenn eine drahtlose Verbindung hergestellt werden kann. Sichergestellt wird, dass die Software-Module für die mobile Vorrichtung freigegeben sind.
• Ein Ziel-Gerät an Bord eines Fahrzeugs ist ausgefallen, und das Fahrzeug kann seine Fahrt nicht fortsetzen. Ein Wartungstechniker fährt mit einem neuen Ziel-Gerät zum Fahrzeug. Das neue Gerät ist hinsichtlich der Hardware baugleich oder wenigstens funktionsgleich zum ausgefallenen Gerät, jedoch sind keine Software-Module in ihm abgespeichert. Die benötigten Software-Module werden durch das erfindungsgemäße Verfahren übertragen. Dadurch ist es nicht erforderlich, dass der Wartungstechniker die Software- Module sowie eine Einrichtung zur Konfigurations-Ermittlung und Freigabe-Prüfung mit sich führt. Da der Wartungstechniker für eine Flotte von unterschiedlichen Fahrzeugen mit verschiedenen Geräten an Bord verantwortlich ist, ist es wegen der Variantenvielfalt nicht möglich, dass er alle Software-Module mit sich führt, die beim Ausfall eines Ziel-Geräts an Bord eines der Fahrzeuge benötigt werden. Das erfindungsgemäße Verfahren spart erheblich Zeit gegenüber dem Vorgehen ein, dass der Wartungstechniker erst nach einem Ausfall eines Geräts ermittelt, welche Software- Module für das neue Gerät benötigt werden, und diese Software-Module dann von einer Zentrale beschafft.
Die Menge von Software-Modulen wird beispielsweise wie folgt ausgewählt (Anspruch 2) : Die an die Zentrale übermittelte aktuelle Konfiguration der mobilen Vorrichtung wird mit einer Wunsch- oder Soll-Konfiguration verglichen. Eine Wunsch- Konfiguration wird beispielsweise dadurch erzeugt, dass ein Eigentümer der mobilen Vorrichtung zusätzliche Funktionalitäten erwirbt, eine Soll-Konfiguration dadurch, dass der Hersteller der mobilen Vorrichtung vorsieht, dass alle mobilen Vorrichtungen einer Baureihe mit einem bestimmten Software- Modul versorgt werden. Die Software-Module werden in Abhängigkeit von der Abweichung zwischen aktueller und Wunschbzw. Soll-Konfiguration ausgewählt. Beispielsweise werden alle Software-Module ausgewählt, die in der Wunsch- bzw. Soll- Konfiguration auftreten, aber in der aktuellen Konfiguration gar nicht oder nur in einer älteren Version.
Anspruch 3 sieht vor, dass vor der Übertragung der Software- Module geprüft wird, ob mit Hilfe der drahtlosen Datenübertragungseinrichtung ein Übertragungskanal mit einer für die Übertragung ausreichenden Güte aufgebaut werden kann. Insbesondere wird geprüft, ob überhaupt eine Verbindung aufgebaut wird und ob diese Verbindung eine ausreichende Bandbreite besitzt. Bevorzugt werden die Software-Module vor der Übertragung komprimiert und nach der Übertragung dekomprimiert, um Übertragungszeit einzusparen.
Dank der Ausgestaltung nach Anspruch 4 kann das erfindungsgemäße Verfahren auch dann durchgeführt werden, wenn die aktuelle Konfiguration nicht komplett an die Zentrale übermittelt werden kann und daher benötigte Informationen fehlen, beispielsweise weil nicht alle Informationen über die aktuelle Konfiguration an Bord abgespeichert worden sind oder weil die Datenverbindung von der mobilen Vorrichtung zur Zentrale gestört ist. Hingegen haben diejenigen Informationen über die aktuelle Konfiguration, die an die Zentrale übermittelt wurden und nicht unzutreffend sind, Vorrang vor den abgespeicherten Konfigurations-Informationen.
Gemäß der Ausgestaltung nach Anspruch 4 werden Informationen über eine der Zentrale bekannte Konfiguration der mobilen Vorrichtung in einem Konfigurations-Management-System oder Dokumentations-System abgespeichert. Beispielsweise umfaßt das System eine Datenbank, in der ein Datensatz für die mobile Vorrichtung bei ihrer Fertigstellung angelegt wird. Wäh- rend der Übertragung wird eine Kennung der mobilen Vorrichtung zur Zentrale übermittelt. Diese Kennung unterscheidet diese mobile Vorrichtung wenigstens von allen anderen mobilen Vorrichtungen desselben Herstellers. Die an die Zentrale übermittelten Informationen über die aktuelle Konfiguration werden mit den abgespeicherten Informationen über die Konfiguration verglichen.
Nachdem die Kennung der mobilen Vorrichtung an die Zentrale übermittelt wurde, wird auf den Datensatz für diese mobile Vorrichtung zugegriffen. Nicht übermittelte Informationen über die aktuelle Konfiguration werden durch Lesezugriff auf die abgespeicherte Konfiguration ergänzt. Auf die abgespeicherte Konfiguration wird insbesondere dann zugegriffen, wenn die aktuelle Konfiguration nur unvollständig an die Zentrale übermittelt wird und daher benötigte Informationen über die aktuelle Konfiguration, beispielsweise der Typ eines tatsächlich zum Zeitpunkt der Übertragung eingebauten Tür- Steuergerätes, fehlen. Bevorzugt werden die an die Zentrale übermittelten Informationen über die aktuelle Konfiguration einer Plausibilitätsprüfung unterzogen, um insbesondere Übertragungsfehler zu erkennen. Werden hierbei einzelne Informationen als offensichtlich unzutreffend erkannt, so werden die unzutreffenden der übermittelten Informationen durch die entsprechenden abgespeicherten Informationen ersetzt.
Bevorzugt werden die Software-Module nach der Übertragung zunächst in einem Pufferspeicher an Bord der mobilen Vorrichtung abgespeichert. Sie werden dann an die jeweiligen Ziel- Geräte verteilt und zu diesen übertragen. Vorzugsweise werden daher gemeinsam mit den Software-Modulen Meta-Informationen übertragen, die die Verteilung und / oder Übertragung und / oder Aktivierung der Software-Module an Bord der mobilen Vorrichtung steuern.
Die drahtlose Datenverbindung zwischen Zentrale und mobiler Vorrichtung kann gestört sein, weswegen die Übertragung der Software-Module nicht fehlerfrei abgeschlossen werden kann. Oft ist der Hersteller von mobilen Vorrichtungen gesetzlich verpflichtet, zu dokumentieren, welche Software-Module sich an Bord der von ihm hergestellten mobilen Vorrichtungen befinden. Beispielsweise aus diesen beiden Gründen wird nach der Übertragung mindestens eines der Software-Module die Information an die Zentrale übermittelt, ob das Software-Modul tatsächlich fehlerfrei an die mobile Vorrichtung übermittelt wurde (Anspruch 5) . Bevorzugt wird nach jeder Übertragung eines Software-Moduls eine Information über das Ergebnis der Übertragung an die Zentrale übermittelt. Falls bei der Übertragung Fehler auftraten, wird bevorzugt zusätzlich eine Fehlerbeschreibung an die Zentrale übermittelt.
Durch die erfolgreiche Übertragung von Software-Modulen wird die aktuelle Konfiguration der mobilen Vorrichtung verändert. Insbesondere um gesetzlichen Auflagen nach einer Produktdokumentation nachzukommen, wird gemäß Anspruch 6 eine Rückdokumentation durchgeführt. Hierfür wird die Kennung der mobilen Vorrichtung zur Zentrale übermittelt. Diese Kennung unterscheidet diese mobile Vorrichtung wenigstens von allen anderen mobilen Vorrichtungen desselben Herstellers. In einem Konfigurations-Management-System wird die Information abgespeichert, welche Ziel-Geräte-Typen und welche Software- Module nach Abschluß der Übertragung an Bord der mobilen Vorrichtung tatsächlich vorhanden sind. Informationen über die Ziel-Geräte-Typen wurden erfindungsgemäß bereits für die Freigabe-Prüfungen an die Zentrale übermittelt.
Die Information, welche Software-Module fehlerfrei und unverfälscht übertragen wurden, wird auch für eine Synchronisation nach einem Fehlerfall, z. B. nach einem Verbindungsabbruch, verwendet. Ermittelt wird, welche Software-Module bei einem zweiten Versuch für die Übertragung vorgesehen werden.
Die übertragenen Software-Module werden bevorzugt nur dann aktiviert, wenn die mobile Vorrichtung sich in einem sicheren Zustand befindet. Ansonsten besteht die Gefahr, dass während der Aktivierung eines Software-Moduls oder der dafür erforderlichen Deaktivierung eines zuvor vorhandenen Software- Moduls die mobile Vorrichtung in einen unerwünschten Betriebszustand gerät. Beispielsweise ist sicherzustellen, dass Software-Module für Steuergeräte an Bord eines Kraftfahrzeu- ges nur bei stehendem Fahrzeug aktiviert werden. Anspruch 7 sieht vor, dass zusätzlich Informationen über den aktuellen Betriebszustand der mobilen Vorrichtung an die Zentrale übermittelt werden. In Abhängigkeit von den Betriebszustands- Informationen wird entschieden, ob die mobile Vorrichtung sich in einem sicheren Zustand befindet. Dann, wenn sie sich in einem sicheren Zustand befindet, werden die übertragenen Software-Module aktiviert.
Die Übertragung kann sowohl von der Zentrale als auch von einer Stelle außerhalb der Zentrale, beispielsweise einem Eigentümer, Fahrer oder Nutzer der mobilen Vorrichtung, angefordert werden, beispielsweise mit Hilfe eines Rechners im Internet. Die Stelle kann auch die mobile Vorrichtung oder ein Ziel-Gerät sein, das automatisch die Übertragung anfordert. Bevorzugt wird vor der Übertragung eine Berechtigungsprüfung für die anfordernde Stelle durchgeführt (Anspruch 8) . Hierfür werden Informationen über die Identität der Stelle, welche die Übertragung der Software-Module anfordert, an die Zentrale übermittelt. Beispielsweise werden von einer anfordernden Person eine PIN, ein Paßwort oder ein Fingerabdruck ermittelt und mit abgespeicherten Informationen verglichen. Nur bei erfolgreicher Berechtigungsprüfung werden Software- Module übertragen. Durch die Berechtigungsprüfung wird insbesondere vermieden, dass ein Nutzer sich in den Besitz eines kostenpflichtigen Software-Moduls bringt, ohne dafür bezahlt zu haben, und dass die Übertragung aufgrund eines Fehlers ausgelöst wird.
Um zu verhindern, dass ein Software-Modul beispielsweise bei der Abspeicherung auf der mobilen Speicher-Einrichtung oder der Übertragung verfälscht oder manipuliert oder eine unberechtigt angefertigte Kopie verwendet wurde, wird eine Korrektheitsprüfung durchgeführt (Anspruch 9) . Hierzu wird für mindestens ein Software-Modul eine Signatur erzeugt und auf der mobilen Speicher-Einrichtung abgespeichert. Die Signatur wird vorzugsweise dadurch erzeugt, dass das Software-Modul als Datenstrom behandelt wird und ein Hash-Wert erzeugt wird. Mit Hilfe eines geheimen Schlüssels wird aus diesem Hash-Wert die Signatur erzeugt. Die Signatur hängt also vom Software- Modul und vom geheimen Schlüssel ab.
Weiterhin wird an Bord der mobilen Vorrichtung für mindestens einen Ziel-Geräte-Typ ein öffentlicher Schlüssel abgespeichert. Mit Hilfe dieses öffentlichen Schlüssels wird die Signatur geprüft. Nur bei positivem Ausgang der Prüfung wird das Software-Modul als nicht verfälscht und als berechtigt erkannt .
Eine Übertragungs-Vorrichtung zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 9 umfasst gemäß Anspruch 10 eine Einrichtung zur drahtlosen Datenübertragung zwischen Zentrale und mobiler Vorrichtung in beiden Richtungen und eine Steuerungs-Einrichtung, welche die Übermittlung von Software-Modulen von der Zentrale zur mobilen Vorrichtung veranlaßt und steuert. Die Steuerungs-Einrichtung ermittelt die zu Beginn der Übertragung tatsächlich vorhandene Konfiguration der mobilen Vorrichtung, wählt die Menge von Software- Modulen aus, und prüft, welche der ausgewählten Software- Module für die tatsächlich vorhandene Konfiguration freigegeben sind. Weiterhin veranlaßt die Steuerungs-Einrichtung die Übertragung der ausgewählten und freigegebenen Software- Module. Vorzugsweise ermittelt die Steuerungs-Einrichtung, welche Software-Module fehlerfrei an die mobile Vorrichtung übertragen wurden (Anspruch 11) .
Bevorzugt reagiert die Steuerungs-Einrichtung auf erkannte Ü- bertragungsfehler . Beispielsweise veranlaßt sie einen zweiten Übertragungs-Versuch, führt eine Fehlerbehandlung durch oder bricht die Übertragung der Software-Module ab.
Im folgenden wird ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens anhand der beiliegenden Zeichnungen näher beschrieben. Dabei zeigen:
Fig. 1. eine beispielhafte Ausführungsform der Erfindung, bei der die Software-Module von einer Zentrale mit Hilfe zweier verschiedener drahtloser Datenübertragungseinrichtungen zur mobilen Vorrichtung übertragen werden; Fig. 2. eine beispielhafte Systemarchitektur für Zentrale und mobile Vorrichtung.
Im Beispiel der Fig. 1 wird wenigstens zeitweise eine Datenverbindung zwischen der Zentrale 10 und dem ersten Fahrzeug 20.1 und eine weitere Datenverbindung zwischen der Zentrale 10 und dem zweiten Fahrzeug 20.2 hergestellt. Die drahtlosen Datenverbindungen können auf die gleiche oder auf unterschiedliche Weisen hergestellt werden. Als zwei Beispiele sind in Fig. 1 die drahtlose Übertragung mit Hilfe eines Satelliten 50.1 und die über ein Mobilfunknetz 50.2 dargestellt. Die Software-Module werden z. B. über ein Weitverkehrsnetz oder ein lokales Netz übertragen. Die Zentrale kann sich an einem einzigen Ort befinden oder räumlich verteilt sein. Insbesondere falls ein Fahrzeug 20.1 oder 20.2 sich während der Übertragung bewegt, kann die übertragende Zentrale sogar während der Übertragung wechseln.
Bei der Übertragung von Software-Modulen werden für jedes der beiden Fahrzeuge 20.1 und 20.2 die folgenden Verfahrensschritte ausgeführt:
• Insbesondere dann, wenn der Fahrzeug-Hersteller die Software-Module nur dann übermittelt, wenn der Eigentümer der Übertragung der Software-Module zugestimmt hat und / oder die Software-Module bezahlt hat, wird eine Berechtigungsprüfung für die anfordernde Stelle durchgeführt. Hierfür wird beispielsweise ein Fingerabdruck einer anfordernden Person ermittelt oder eine PIN oder ein Paßwort von einer anfordernden Stelle erfaßt und anschließend Fingerabdruck, PIN oder Paßwort an die Zentrale übermittelt und bei einer Berechtigungsprüfung ausgewertet. Nach erfolgreicher Berechtigungsprüfung wird festgestellt, ob der Eigentümer der Übertragung verbindlich zugestimmt hat. Die folgenden Schritte werden nur dann durchgeführt, wenn eine Zustimmung vorliegt oder nicht erforderlich ist. • Eine eindeutige Kennung des Fahrzeugs, vorzugsweise eine Fahrzeug-Ident-Nummer, wird ermittelt und an die Zentrale übermittelt. Diese Kennung unterscheidet das Fahrzeug von allen anderen Fahrzeugen dieses Herstellers. Zusätzlich werden die Baureihe, das Baumuster und das Baujahr und das Jahr der letzten Änderung übermittelt. Diese Informationen lassen sich zwar oft durch Lesezugriff auf ein zentrales Konfigurations-Management-System ermitteln. Werden sie aber vom Fahrzeug zur Zentrale übermittelt, so wird ein oft zeitraubender Lesezugriff eingespart.
• Die aktuelle Konfiguration des Fahrzeugs wird ermittelt und an die Zentrale übermittelt. Hierbei wird ermittelt, welche Ziel-Geräte vor Beginn der Übertragung an Bord des Fahrzeugs tatsächlich eingebaut sind und welche Software-Module vor Beginn der Übertragung an Bord des Fahrzeugs tatsächlich aktiviert und / oder abgespeichert sind. Vorzugsweise werden Typ-Kennungen für die aktuell eingebauten Geräte und bereits vorhandenen Software-Module, z. B. Sachnummern und Variantennu mern, übermittelt. Diese Ermittlung wird bevorzugt dadurch ausgeführt, dass in jedem Ziel-Gerät ein Speicher vorhanden ist, in dem die Konfigurations-Informationen über dieses Ziel-Gerät abgespeichert sind und der z. B. über einen Datenbus angesprochen und ausgelesen wird. Alternative Ausführungsformen bestehen daraus, einen zentralen Speicher an Bord des Fahrzeugs oder Speicherchips, die an den Ziel-Geräten angebracht sind, auszulesen. Insbesondere dann, wenn ein Speicher in einem Ziel-Gerät aufgrund eines Defekts nicht ausgelesen werden kann oder wenn der Speicher eines neuen Ziel-Geräts noch nicht gefüllt ist, besteht ein Notbehelf darin, Markierungen an Geräten, z. B. Strichcodes, optisch zu erfassen.
• Bei Bedarf werden die Informationen über die aktuelle Konfiguration mit einem Datensatz über die Konfiguration des Fahrzeugs verglichen, der in einem Konfigurations- Management-System abgespeichert ist. Dies wird beispielsweise dann durchgeführt, wenn die übermittelten Informationen über die aktuelle Konfiguration lückenhaft oder erkenn- bar fehlerhaft sind. Zur Erkennung von derartigen Fehlern wird bevorzugt eine Plausibilitätsprüfung der vom Fahrzeug übermittelten und der abgespeicherten Informationen über die Konfiguration durchgeführt.
• Ausgewählt wird eine Menge von Software-Modulen, die von der Zentrale zum Fahrzeug übertragen werden. Die Auswahl hängt von der aktuellen Konfiguration des Fahrzeugs, vom Anwendungsfall und von der Kundenanforderung ab.
• Nur diejenigen Software-Module werden übertragen, die für die aktuelle Konfiguration des Fahrzeugs freigegeben sind. Für jedes Software-Modul wird eine Freigabe-Prüfung durchgeführt, indem Freigabe-Festlegungen ausgewertet werden. Diese Freigabe-Festlegungen umfassen Typ-Kennungen für Ziel-Geräte und Software-Module. Eine Ausführungsform wird weiter unten beschrieben. Mögliche Ergebnisse der Freigabe- Prüfung sind, dass alle, einige oder gar keines der ausgewählten Software-Module als freigegeben erkannt werden.
• Überprüft wird, ob die ausgewählten Software-Module jetzt übertragen werden können. Hierbei wird festgestellt, ob mit Hilfe der drahtlosen Datenübertragungseinrichtung überhaupt eine Verbindung zwischen Zentrale und Fahrzeug vorhanden ist oder aufgebaut werden kann und ob der Übertragungskanal eine für die Übertragung ausreichende Güte, insbesondere eine ausreichende Bandbreite besitzt. Diese Güte kann von dem sende- und Empfangsgerät 190 an Bord des Fahrzeugs abhängen. Beispielsweise wird eine untere Schranke für die Bandbreite oder eine obere Schranke für den Zeitraum, den die Übertragung in Anspruch nimmt, vorgegeben und mit der tatsächlich verfügbaren Bandbreite verglichen. Aus der tatsächlich verfügbaren Bandbreite und der Gesamtgröße der ausgewählten Software-Module wird bei Bedarf ein Wert für den Zeitbedarf der Übertragung vorhergesagt.
• Die ausgewählten und für die aktuelle Konfiguration freigegebenen Software-Module werden komprimiert, so dass die komprimierten Software-Module weniger Speicherplatz als die nicht komprimierten einnehmen. Bekannt sind verschiedene Verfahren zum Komprimieren von Daten. • Die ausgewählten und für die aktuelle Konfiguration freigegebenen Software-Module werden für die Übertragung konvertiert. Bei Bedarf werden die Software-Module in Teile aufgeteilt. Gemeinsam mit jedem Software-Modul oder Software- Modul-Teil werden Meta-Informationen übertragen, die die Verteilung und Übertragung der Software-Module an Bord sowie deren Aktivierung steuern. Zu diesen Meta-Informationen zählen Parameter, die das verwendete On-Board- Übertragungsprotokoll benötigt.
• Die ausgewählten und für die aktuelle Konfiguration freigegebenen Software-Module werden von der Zentrale zum Fahrzeug übertragen. Als Übertragungstechnik wird beispielsweise ein Mobilfunk-Standard, z. B. GSM oder UMTS, eingesetzt. Vorzugsweise wird ein zur gewählten Übertragungstechnik passendes Protokoll, z. B. das dateibasierte Protokoll zMo- dem, verwendet. Dadurch wird insbesondere nach einem Abbruch der Verbindung eine sichere Fehlerbehandlung mit Synchronisation erleichtert, die weiter unten beschrieben wird.
• Vorzugsweise werden die übertragenen Software-Module an Bord des Fahrzeugs in einem Pufferspeicher abgespeichert.
• Festgestellt wird, welche Software-Module fehlerfrei übertragen wurden. Diese Information wird an die Zentrale übermittelt. Beispielsweise wird nach jeder erfolgreichen Übertragung eines Software-Moduls eine Rückmeldung an die Zentrale übermittelt, oder nach erfolgreicher Übertragung aller Software-Module wird diese Information an die Zentrale übermittelt. Für die Feststellung wird vorzugsweise für jedes Software-Modul oder jedes Software-Modul-Teil eine Soll-Prüfsumme nach dem CRC-Verfahren ermittelt und übertragen. Nach der Übertragung wird an Bord der mobilen Vorrichtung eine Ist-Prüfsumme ermittelt und mit der Soll- Prüfsumme verglichen.
• Vorzugsweise werden Verschlüsselungs-Informationen gemeinsam mit den Software-Modulen übertragen, um zu prüfen, ob die Software-Module aus einer vertrauenswürdigen Quelle stammen und unverfälscht übertragen wurden. Beispielsweise wird ein Software-Modul in der Zentrale verschlüsselt und an Bord der mobilen Vorrichtung wieder entschlüsselt. Ein Verfahren hierfür ist aus DE 195 32 067 Cl bekannt. Oder ein Software-Modul wird unverschlüsselt, aber gemeinsam mit einer Signatur übertragen. Die Signatur wird mit Hilfe eines geheimen Schlüssels in der Zentrale erzeugt und mit einem öffentlichen Schlüssel verglichen, der beispielsweise zuvor auf einem anderen Kanal zur mobilen Vorrichtung übermittelt wurde.
• Falls festgestellt wurde, dass ein Software-Modul nur fehlerhaft, verfälscht oder gar nicht übertragen wurde, so wird ein zweiter Versuch der Übertragung durchgeführt. Falls zwischen erstem und zweiten Versuch eine größere Zeitspanne verstrichen ist, wird erneut die aktuelle Konfiguration des Fahrzeugs ermittelt, denn diese kann in der Zwischenzeit verändert worden sein. Scheitert auch der zweite Versuch, so wird die unten beschriebene Fehlerbehandlung durchgeführt.
• Daten über den aktuellen Betriebszustand des Fahrzeugs werden erfaßt und an die Zentrale übermittelt . Diese Daten umfassen beispielsweise die aktuelle Fahrgeschwindigkeit, den Motorzustand, den Ladezustand der Batterie und die aktuelle Position des Fahrzeugs. Aufgrund des Betriebszustands wird entschieden, ob die übertragenen Software-Module jetzt aktiviert werden. Dabei wird insbesondere geprüft, ob das Fahrzeug sich in einem sicheren Zustand befindet. Beispielsweise wird der Ladezustand der Batterie berücksichtigt, um sicherzustellen, dass während der gesamten Aktivierung genügend elektrische Spannung zur Verfügung steht. Die aktuelle Position wird beispielweise ausgewertet, um zu prüfen, in welchem Land oder z. B. US-Bundesstaat sich das Fahrzeug befindet, um bei Bedarf zu prüfen, ob länderspezifische gesetzliche oder technische Randbedingungen zu beachten sind. Bei Bedarf wird der Fahrer des Fahrzeugs gebeten, das Fahrzeug in einen sicheren Zustand zu bringen, z. B. es anzuhalten, und dies zu bestätigen. Dies wird z. B. durch Sprachausgabe und -eingäbe oder dadurch durch- geführt, dass Meldungen angezeigt werden und der Fahrer gebeten wird, diese zu bestätigen.
• Falls alle Software-Module fehlerfrei und unverfälscht übertragen wurden oder der Pufferspeicher vollständig gefüllt ist und falls das Fahrzeug sich in einem sicheren Zustand befindet, werden die übertragenen Software-Module aus dem Pufferspeicher in die Ziel-Geräte übertragen, vorzugsweise über einen Datenbus an Bord des Fahrzeugs. Bei Bedarf werden sie zuvor dekomprimiert . Für diesen Vorgang werden die Meta-Informationen ausgewählt. Nach der Übertragung zu den Geräten werden die Geräte bei Bedarf deaktiviert, die Software-Module aktiviert und danach die Geräte wieder aktiviert.
• In der Zentrale, z. B. in einem Konfigurations-Management- System, wird die aktuelle Konfiguration der mobilen Vorrichtung nach der Übertragung abgespeichert. Die aktuelle Konfiguration umfaßt die Informationen, welche der Ziel- Geräte an Bord tatsächlich eingebaut sind und welche Software-Module entweder fehlerfrei übertragen und aktiviert wurden oder bereits vor der Übertragung aktiviert und durch die Übertragung nicht verändert wurden.
• Ein Konfigurations-Management-System in der Zentrale umfaßt einen Datensatz für das Fahrzeug. Dieser Datensatz wird nach der Übertragung aktualisiert, so dass er nach der Aktualisierung Informationen darüber enthält, welche der Ziel-Geräte an Bord tatsächlich eingebaut . sind und welche Software-Module nunmehr aktiviert sind.
• Eine Fehlerbehandlung ist insbesondere dann erforderlich, wenn eine vorgegebene Anzahl von Versuchen Versuche scheitern, alle Software-Module fehlerfrei zu übertragen, beispielsweise weil keine Verbindung zwischen Zentrale und Fahrzeug hergestellt werden kann. Bevorzugt wird bei einer Fehlerbehandlung eine Synchronisation durchgeführt. Hierbei wird festgestellt, welche Software-Module fehlerfrei übertragen wurden. Der Datensatz für das Fahrzeug im zentralen Konfigurations-Management-System wird aktualisiert, und ein Fehlerprotokoll wird generiert. Zu einem späteren Zeitpunkt wird ein erneuter Übertragungsversuch begonnen, der von einem definierten Zustand ausgeht.
Fig. 2 zeigt eine beispielhafte Systemarchitektur für die Zentrale 10 und das Fahrzeug 20. Die Zentrale 10 umfaßt die folgenden Komponenten: ein Central Remote Flashing Manager 160, der die Übermittlung von Software-Modulen von der Zentrale zur mobilen Vorrichtung veranlaßt und steuert und dabei Software-Module auswählt und prüft, ob sie für die aktuelle Konfiguration freigegeben sind, eine Steuerungs- und Regelungs-Einrichtung 110, mit dem die erforderlichen Maßnahmen zum Übertragen von Software- Modulen erfaßt und aufgelistet und veranlaßt werden und durch das die Durchführung der Maßnahmen überwacht wird, ein Logistiksystem 130, das die benötigten Software-Module identifiziert, auswählt und für die Übertragung bereitstellt, ein Abrechnungs-System 140, das die Übertragungsvorgänge kaufmännisch abwickelt und dabei insbesondere die Rechnungslegung durchführt und die Zahlungsvorgänge überwacht, ein Informationssystem 150, das den Eigentümer und / oder Fahrer des Fahrzeugs vor der Übertragung über angebotene und durch Software-Module realisierbare funktionale Erweiterungen und Änderungen durch Software-Module und nach der Übertragung über die erfolgreiche Übertragung oder über aufgetretene Fehler informiert und das beispielsweise das Internet verwendet oder die Versendung von Briefen auslast, ein Entscheidungsunterstützungs-System 170, mit dessen Hilfe Software-Module in Abhängigkeit von der aktuellen Fahrzeug-Konfiguration und der durchzuführenden Kundendienst- Maßnahme ausgewählt werden, eine Sende- und Empfangseinrichtung 180 in der Zentrale (10) und
- eine Sende- und Empfangseinrichtung 190, die mit dem Fahrzeug 20.1, 20.2 verbunden ist. Die Sende- und Empfangseinrichtungen 180 und 190 sind beispielsweise als Knoten eines Mobilfunknetzes, das z. B. mit den Übertragungsverfahren GSM oder UMTS arbeiten, oder für eine Übertragung mittels Satelliten ausgebildet. An Bord eines Fahrzeugs können mehrere Sende- und Empfangseinrichtungen 190 eingebaut sein.
Im folgenden wird an einem Ausführungsbeispiel beschrieben, wie die Freigabe-Prüfung durchgeführt wird und welche Freigabe-Festlegungen hierfür ausgewertet werden. In dem Ausführungsbeispiel werden zwei Ziel-Geräte an Bord eines Kraftfahrzeugs 20.1, 20.2 mit Software-Modulen versorgt: eine Zentraleinheit eines Systems zur Sprachausgabe, die z. B. Meldungen an den Fahrer in natürlicher Sprache vorliest, und ein Steuergerät für das Türsystem. Die Zentraleinheit ist mit einem Sende- und Empfangsgerät für drahtlose Datenübertragung und über einen Datenbus mit dem Steuergerät verbunden.
Die beiden Ziel-Geräte stammen von unterschiedlichen Herstellern und werden in verschiedenen Varianten in Fahrzeuge eingebaut. Die Sprachausgabe soll in mehreren Sprachen möglich sein. Die Software-Module für alle Varianten der beiden Ziel- Geräte werden erzeugt und in der Zentrale abgespeichert.
Der Typ eines Ziel-Geräts und der eines Software-Moduls werden durch jeweils eine Sachnummer und eine Variantennummer gekennzeichnet. Die Sachnummer ist eine Abfolge von Ziffern und Buchstaben, die innerhalb des Produktspektrums des Fahrzeug-Herstellers eindeutig ist. Die Variante wird durch eine Zahl mit drei Ziffern gekennzeichnet.
Die Freigabe-Festlegungen sind beispielsweise in einer relationalen Datenbank in Form von Datensätzen in der Zentrale abgespeichert. Für eine Freigabe-Prüfung wird diese Datenbank eingelesen und ausgewertet. Ein Prinzip ist, dass ein Software-Modul nur dann für einen Typ von Ziel-Geräten freigegeben ist, wenn eine entsprechende Freigabe-Festlegung in der Freigabe-Datenbank vermerkt ist, ansonsten nicht.
Jeder Freigabe-Datensatz umfaßt folgende Datenfelder:
- Baureihe, Region,
Ziel-Geräte-Typen,
Zulieferer,
- Beschreibung_Hardware,
- Art_der_Software, Software-Module, Beschreibung_Software, gültig_ab,
- Voraussetzung.
Mit „Baureihe" ist die Baureihe des Fahrzeugs gemeint, auf das sich der Freigabe-Datensatz bezieht, z. B. W212. In den Datenfeldern „Ziel-Geräte-Typ" und „Software-Module" werden Geräte- bzw. Software-Typ-Kennungen aufgeführt, was im folgenden beispielhaft erläutert wird. Der in dem Datenfeld „gültig_ab" eingetragene Zeitpunkt legt für den Datensatz den Beginn des Freigabe-Zeitraums fest. Die im Datensatz genannten Software-Module sind nur dann für die genannten Ziel- Geräte-Typen freigegeben, wenn der Zeitpunkt der Übertragung nach dem durch das Datenfeld „gültig_ab" festgelegten Zeitpunkt liegt. Die Freigabe kann an eine Freigabe-Bedingung gebunden sein, die vorzugsweise als Boole' scher Ausdruck formuliert wird. Die Inhalte der Datenfelder „Beschrei- bung_Hardware" und „Beschreibung_Software" werden nicht automatisch ausgewertet. Sie erläutern vielmehr einem Bearbeiter die Typ-Kennungen.
In dem folgenden Beispiel stammt die Software für die Zentraleinheit vom Zulieferer XY, die für das Tür-Steuergerät von den Zulieferern AB (für den europäischen Markt) und FG (für den US-amerikanischen Markt) . Typen von Ziel-Geräten und Software-Module werden durch Sachnummern gekennzeichnet, die mit HW bzw. SW beginnen, gefolgt von drei oder vier Ziffern. Varianten sind durch drei Ziffern gekennzeichnet. SW-212-001 bezeichnet z. B. ein Software-Modul mit der Sachnummer SW-212 und der Variantennummer 001. Typ-Kennungen, zusammengesetzt aus Sachnummern und Variantennummern, sind in eckige Klammern [] gesetzt.
1. Datensatz
Figure imgf000025_0001
Das Software-Modul [SW-101-001] ist durch den 1. Datensatz für die Ziel-Geräte-Typen [HW-1001-001] und [HW-1001-002] in Europa freigegeben.
Datensatz
Figure imgf000025_0002
Figure imgf000026_0001
Das Software-Modul [SW-111-001] ist durch den 2. Datensatz für die Ziel-Geräte-Typen [HW-1001-001] und [HW-1001-002] in Europa freigegeben.
Datensatz
Figure imgf000026_0002
Das Software-Modul [SW-102-001] ist durch den 3. Datensatz für die Ziel-Geräte-Typen [HW-1002-001] und [HW-1002-002] in den USA freigegeben.
Datensatz
Figure imgf000026_0003
Figure imgf000027_0001
Das Software-Modul [SW-112-001] ist durch den 4. Datensatz für die Ziel-Geräte-Typen [HW-1002-001] und [HW-1002-002] in den USA freigegeben, falls die Freigabe-Bedingung erfüllt ist. Die Freigabe-Bedingung ist erfüllt, wenn
- ein Ziel-Gerät vom Typ HW-1102 und einer der Varianten 001 bis 009
- und ein Ziel-Gerät vom Typ HW-2102 und der Variante 001 o- der 002
- und kein Ziel-Gerät vom Typ HW-2302, das von einer der Varianten 001 bis 009 ist, eingebaut ist. Hierbei ist OOn eine abkürzende Bezeichnung für die Varianten 001 bis 009.
Datensatz
Figure imgf000027_0002
Freigabe-Bedingung [HW-2002-001] OR [HW-2302-00n]
Das Software-Modul [SW-221-001] ist durch den 5. Datensatz für die Ziel-Geräte-Typen [HW-2001-001] und [HW-2001-002] in Europa freigegeben, falls die Freigabe-Bedingung erfüllt ist. Die Freigabe-Bedingung ist erfüllt, wenn an Bord
- ein Ziel-Gerät vom Typ [HW-2002-001]
- oder ein Ziel-Gerät vom Typ HW-2302, das von einer der Varianten 001 bis 009 ist, eingebaut ist.
6. Datensatz
Figure imgf000028_0001
Das Software-Modul [SW-111-001] ist durch den 6. Datensatz für die Ziel-Geräte-Typen [HW-1001-001] und [HW-1001-002] in den USA freigegeben, falls an Bord das Software-Modul [SW- 221-001] aktiviert ist.
Bei der Auswertung der Freigabe-Datei wird für jedes Ziel- Gerät, das im Fahrzeug vorkommt, die Freigabe-Datenbank durchsucht. Für jeden Datensatz wird das Datenfeld „Baureihe" abgeglichen und das Datenfeld „Ziel-Geräte-Typen" ausgewer- tet. Ist an Bord ein Ziel-Gerät eines er im Datenfeld „Ziel- Geräte-Typen" genannten Typen eingebaut, so wird festgestellt, ob eine Freigabe-Bedingung formuliert ist. Ist dies der Fall, so wird geprüft, ob die Freigabe-Bedingung auf Erfülltsein geprüft. Ist die Freigabe-Bedingung erfüllt oder ist keine Freigabe-Bedingung formuliert, so sind alle Software-Module für das Fahrzeug freigegeben, die im Datenfeld „Software-Module" des Datensatzes genannt sind. Welche der freigegebenen Software-Module tatsächlich übertragen werden, hängt davon ab, welche Software-Module ausgewählt worden sind.
Für jedes Software-Modul werden weiterhin Konfigurations- und Sicherheits-Informationen beispielsweise in zwei Datenbanken für Software-Module und zwei für Software-Modul-Teile erzeugt, in der Zentrale abgespeichert und bei der Übertragung ausgewertet. Die eine Datenbank ist die Konfigurations- Datenbank, die andere die Sicherheits-Datenbank.
Die Informationen in der Konfigurations-Datenbank legen fest, welche Dateien zum Software-Modul gehören, wo diese Dateien abgespeichert sind und in welcher Reihenfolge sie wohin, d. h. zu welchem Ziel-Gerät, übertragen werden. Mit Hilfe der Sicherheits-Informationen werden Übertragungsfehler und Manipulationen erkannt.
Ein Datensatz für ein Software-Modul in der Konfigurations- Datenbank für Software-Module umfaßt beispielsweise folgende Datenfelder:
- Software-Modul, Ziel-Adresse,
- Größe,
- Speicherort,
- Prüfverfahren,
- Prüfsumme,
- Teile_Kennungen. Das Datenfeld „Ziel-Adresse" gibt die Ziel-Adresse des Ziel- Geräts auf dem Datenbus im Fahrzeug an, z. B. #57 für das Tür-Steuergerät und #20 für die Zentraleinheit.
Das Datenfeld „Größe" gibt die Größe des Software-Moduls in KByte an. Diese Angabe wird z. B. für eine Fortschrittsanzeige beim Übertragen verwendet. Festgestellt wird, wie viele KByte bereits übertragen sind, und durch die Angabe in der Konfigurations-Datei ist bekannt, wie viele KByte insgesamt zu übertragen sind. Der Quotient gibt den Arbeitsfortschritt an, der z. B. als Balken angezeigt wird.
Das Datenfeld „Speicherort" gibt an, wo dieses Software-Modul in der Zentrale abgespeichert ist, beispielsweise in Form ei- nes Pfades eines Betriebssystems oder einer Zugriffsinformation auf eine Datenbank.
Das Datenfeld „Teile__Kennungen" ist nur dann ausgefüllt, wenn das Software-Modul nicht auf einmal, sondern in mehreren Teilen übertragen wird.
Beispielsweise umfaßt der Datensatz für das Software-Modul [SW-111-001] in der Konfigurations-Datenbank folgende Einträge:
7. Datensatz
Figure imgf000030_0001
Durch den 7. Datensatz wird festgelegt, dass die Übertragung des Software-Moduls [SW-111-001] mit dem CRC-Verfahren ge- prüft wird. Durch die Prüfung wird festgestellt, ob bei der Übermittlung zum Fahrzeug und der Speicherung an Bord des Fahrzeugs ein Übertragungsfehler aufgetreten ist. Als Prüf- sum e wird ein CRC-Wert, in diesem Beispiel die Hexadezimalzahl 4758A08C, angegeben. Das Software-Modul wird auf einmal übertragen, daher ist das Datenfeld „Teile_Kennungen" leer.
Falls ein Software-Modul in mehreren Teilen übertragen wird, so werden jedem Software-Modul-Teil ein eigenes Prüfverfahren und eine eigene Prüfsumme zugewiesen.
Für jedes der Software-Modul-Teile wird in der Konfigurations-Datenbank für Teile ein eigener Datensatz mit folgenden Feldern angelegt:
- Teile-Kennung,
- Größe,
- Speicherort,
- Prüfverfahren,
- Prüfsumme.
Das Datenfeld „Speicherort" gibt an, wo dieser Software- Modul-Teil in der Zentrale abgespeichert ist.
Ein Datensatz in der Sicherheits-Datenbank umfaßt folgende Datenfelder:
- Software-Modul,
- Ziel-Geräte-Typ, Signatur.
. Datensatz
Figure imgf000031_0001
9. Datensatz
Figure imgf000032_0001
Das Software-Modul [SW-111-001] ist in diesem Beispiel für zwei Varianten von Ziel-Geräten freigegeben, nämlich für die Varianten 001 und 002 des Typs HW-1001. Daher werden zwei verschiedene Signaturen erzeugt und in dem 8. und 0. Datensatz abgespeichert, nämlich eine Signatur pro Variante des Ziel-Geräte-Typs. Die Signatur für eine Variante wird vorzugsweise dadurch erzeugt, dass die Variante als Datenstrom behandelt wird und ein Hash-Wert erzeugt wird. Mit Hilfe eines geheimen Schlüssels wird aus diesem Hash-Wert die Signatur erzeugt. Die Signatur hängt also vom Software-Modul und vom geheimen Schlüssel ab. Für die Erzeugung der Signatur wird beispielsweise eine 1024-Bit-Verschlüsselung nach dem Algorithmus von Rivest-Shamir-Adleman (RSA-Verschlüsselung) verwendet .
Die Erzeugung von Signaturen wird auf einem Rechner durchgeführt, der streng gegen unberechtigten Zugriff und gegen Manipulationen geschützt wird. Beispielsweise betreibt der Zulieferer diesen Rechner und liefert die beiden Varianten und die beiden Signaturen an den Hersteller des Kraftfahrzeuges. Eine andere Ausführungsform ist die, dass der Zulieferer lediglich die beiden Varianten an den Hersteller liefert und dieser selber die Signaturen erzeugt. Beispielsweise übermittelt der Hersteller die Signaturen an den Zulieferer, und dieser überträgt die Software-Module auf seine Ziel-Geräte und verwendet dabei die Signatur für eine Prüfung. Eine dritte Ausführungsform besteht daraus, dass ein zertifiziertes Trust Center die Signaturen erzeugt und die geheimen Schlüssel verwaltet. In einem permanenten, nicht überschreibbaren Speicher des Ziel-Geräts wird ein öffentlicher Schlüssel abgespeichert. Der öffentliche Schlüssel kann ausgelesen werden, er ist aber sowohl vor versehentlichem als auch vor vorsätzlichem Überschreiben oder Verfälschen oder Löschen geschützt. Vorzugsweise versieht der Zulieferer das Ziel-Gerät mit dem öffentlichen Schlüssel. Die Signatur wird nach dem Übertragen und vor dem Aktivieren des Software-Moduls mit Hilfe des öffentlichen Schlüssels geprüft. Durch diese Prüfung wird sichergestellt, dass das Software-Modul von einer vertrauenswürdigen Quelle kommt und nicht verfälscht oder manipuliert wurde.
Als On-Board-Übertragungsprotokoll wird beispielsweise das „Keyword Protocol 2000" (KWP2000) verwendet, das durch ISO 14230-1 und ISO 15765-1 bis 15765-4 und VDA 14230-1 bis VDA 14230-3 standardisiert wird. Befehle werden in KWP2000 durch Hexadezimal-Zahlen codiert, z.B. der Befehl „ReadEDUIdentifi- cation" (Auslesen einer Typ-Kennung für ein Ziel-Gerät) durch $1A,86. Die mit einem Software-Modul übertragenen MetaInformationen umfassen die für das Protokoll KWP2000 notwendigen Kommunikations-Parameter, die die Übertragung an Bord vom Pufferspeicher an ein Ziel-Gerät steuern, z. B. Blockgrößen, Timing-Parameter, Ablaufinformationen und Adresse des Geräts auf dem Datenbus. Andere Übertragungsprotokolle sind ebenfalls geeignet. Die Meta-Informationen werden beispielsweise ebenfalls in Form einer Tabelle übertragen. Diese Tabelle wird im Gegensatz zu der Tabelle für die Freigabe- Prüfung erst während des Übertragungsvorganges generiert.
Nachdem festgestellt wird, dass die ausgewählten und als freigegeben erkannten Software-Module fehlerfrei und unverfälscht übertragen wurden, werden mindestens folgende Informationen an die Zentrale übermittelt:
- eine eindeutige Kennung des Fahrzeugs,
- welche Software-Module fehlerfrei und unverfälscht übertragen wurden,
- welches Gerät, z. B. welcher Diagnosetester, für die Übertragung verwendet wurde - und das Datum und der Zeitpunkt, zu dem die Übertragung abgeschlossen wurde.
Diese Informationen werden in der Zentrale, beispielsweise in einem Konfigurations-Management-System, abgespeichert, und zwar bevorzugt in dem Datensatz für das Fahrzeug. Dort wird weiterhin abgespeichert, wer die Übermittlung veranlaßt hat.
Figure imgf000035_0001

Claims

Patentansprüche
Verfahren zum Übertragen von Software-Modulen von einer Zentrale (10) zu einer Ziel-Vorrichtung (20.1, 20.2) mit Hilfe einer Einrichtung zur Datenübertragung in beiden Richtungen, wobei
- an Bord der Ziel-Vorrichtung (20.1, 20.2) Ziel-Geräte vorhanden sind, für die Ziel-Geräte Geräte-Typ-Kennungen festgelegt werden,
- für die Software-Module Software-Typ-Kennungen festgelegt werden,
Informationen über die Konfiguration der Ziel- Vorrichtung (20.1, 20.2) an die Zentrale (10) übermittelt werden
- und eine Menge von Software-Modulen ausgewählt wird, d a d u r c h g e k e n n z e i c h n e t , dass
- die Datenübertragungseinrichtung eine drahtlose ist,
- die Ziel-Vorrichtung (20.1, 20.2) eine mobile Vorrichtung, insbesondere ein Verkehrs- oder Transportmittel, ist,
- die Informationen über die Konfiguration eine Auflistung umfassen, welche Ziel-Geräte und welche Software- Module zu Beginn der Übertragung an Bord der Ziel- Vorrichtung (20.1, 20.2) tatsächlich vorhanden sind, Freigabe-Festlegungen vorgegeben sind, die unter Verwendung der Geräte-Typ-Kennungen und Software-Typ- Kennungen festlegen, welche Software-Module für welche Ziel-Geräte-Typen freigegeben sind,
- unter Verwendung der Freigabe-Festlegungen geprüft wird, welche der ausgewählten Software-Module für die tatsächlich vorhandene Konfiguration freigegeben sind
- und die für die Konfiguration freigegebenen Software- Module übertragen werden.
Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , dass bei der Auswahl der Menge von Software-Modulen die tatsächlich vorhandene Konfiguration der mobilen Vorrichtung (20.1, 20.2) mit einer Soll-Konfiguration verglichen wird und die Software-Module in Abhängigkeit von der Abweichung zwischen der tatsächlich vorhandenen und der Soll- Konfiguration ausgewählt werden.
3. Verfahren nach Anspruch 1 oder Anspruch 2, d a d u r c h g e k e n n z e i c h n e t , dass vor der Übertragung der Software-Module geprüft wird, ob mit Hilfe der drahtlosen Datenübertragungseinrichtung ein Übertragungskanal mit einer für die Übertragung ausreichenden Güte aufgebaut werden kann.
4. Verfahren nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n n z e i c h n e t , dass
Informationen über eine der Zentrale bekannten Konfiguration der mobilen Vorrichtung (20.1, 20.2) in einem Konfigurations-Management-System oder Dokumentations- System abgespeichert werden eine Kennung der mobilen Vorrichtung (20.1, 20.2) zur Zentrale (10) übermittelt wird, die an die Zentrale (10) übermittelten Informationen über die tatsächlich vorhandene Konfiguration mit denen über die abgespeicherten Konfiguration verglichen werden und mindestens eine nicht übermittelte Information ü- ber die tatsächlich vorhandene Konfiguration durch Lesezugriff auf die abgespeicherte Konfiguration ersetzt oder ergänzt wird.
Verfahren nach einem der Ansprüche 1 bis 4, d a d u r c h g e k e n n z e i c h n e t , dass nach der Übertragung mindestens eines der Software- Module die Information an die Zentrale (10) übermittelt werden, ob das Software-Modul tatsächlich fehlerfrei an die mobile Vorrichtung (20.1, 20.2) übermittelt wurde.
Verfahren nach Anspruch 5, d a d u r c h g e k e n n z e i c h n e t , dass
- eine Kennung der mobilen Vorrichtung (20.1, 20.2) zur Zentrale (10) übermittelt wird,
- und in einem Konfigurations-Management-System die Information abgespeichert wird, welche Ziel-Geräte und welche Software-Module nach Abschluß der Übertragung an Bord der mobilen Vorrichtung (20.1, 20.2) tatsächlich vorhanden sind. Verfahren nach einem der Ansprüche 1 bis 6, d a d u r c h g e k e n n z e i c h n e t , dass
- dass zusätzlich Informationen über den aktuellen Betriebszustand der mobilen Vorrichtung (20.1, 20.2) an die Zentrale (10) übermittelt werden, in Abhängigkeit von den Betriebszustands-Informationen entschieden wird, ob die mobile Vorrichtung (20.1, 20.2) sich in einem sicheren Zustand befindet,
- und dann, wenn sie sich in einem sicheren Zustand befindet, die übertragenen Software-Module aktiviert werden.
Verfahren nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t , dass
Informationen über die Identität der Stelle, die die Übertragung der Software-Module anfordert, an die Zentrale (10) übermittelt werden
- und eine Berechtigungsprüfung für die anfordernde Stelle durchgeführt wird.
Verfahren nach einem der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t , dass für mindestens ein Software-Modul mit Hilfe eines geheimen Schlüssels eine Signatur erzeugt wird,
- an Bord der mobilen Vorrichtung für mindestens ein Ziel-Gerät ein öffentlicher Schlüssel abgespeichert wird
- und die Signatur mit Hilfe des öffentlichen Schlüssels geprüft wird.
10. Übertragungs-Vorrichtung zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 9, folgende Bestandteile umfassend:
- eine Einrichtung zur drahtlosen Datenübertragung zwischen der Zentrale (10) und der mobilen Vorrichtung (20.1, 20.2) in beiden Richtungen
- und eine Steuerungs-Einrichtung zur Veranlassung der Übermittlung von Software-Modulen von der Zentrale (10) zur mobilen Vorrichtung (20.1, 20.2), wobei die Steuerungs-Einrichtung
- eine Einrichtung zur Ermittlung der zu Beginn der Ü- bertragung tatsächlich vorhandenen Konfiguration der mobilen Vorrichtung (20.1, 20.2), eine Einrichtung (170) zur Auswahl der Menge von Software-Modulen,
- eine Einrichtung (160) für eine Prüfung, welche Software-Module für die tatsächlich vorhandene Konfiguration freigegeben sind,
- und eine Einrichtung zur Auswertung der Freigabe- Festlegungen umfaßt .
11. Übertragungs-Vorrichtung nach Anspruch 10, d a d u r c h g e k e n n z e i c h n e t , dass die Steuerungs-Einrichtung eine Einrichtung zur Er-
I mittlung, welche Software-Module fehlerfrei an die mobile
Vorrichtung (20.1, 20.2) übertragen wurden, umfaßt. 1/2
2/2
Figure imgf000042_0001
PCT/EP2002/006994 2001-06-28 2002-06-25 Verfahren zum übertragen von software-modulen WO2003003200A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10131395A DE10131395B4 (de) 2001-06-28 2001-06-28 Verfahren zum Übertragen von Software- Modulen
DE10131395.0 2001-06-28

Publications (2)

Publication Number Publication Date
WO2003003200A1 true WO2003003200A1 (de) 2003-01-09
WO2003003200B1 WO2003003200B1 (de) 2003-10-30

Family

ID=7689904

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2002/006994 WO2003003200A1 (de) 2001-06-28 2002-06-25 Verfahren zum übertragen von software-modulen

Country Status (2)

Country Link
DE (1) DE10131395B4 (de)
WO (1) WO2003003200A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1699031A1 (de) * 2003-12-15 2006-09-06 Hitachi, Ltd. Informations-aktualisierungsverfahren für eine im fahrzeug angebrachte steuervorrichtung, aktualisierungs-informationskommunikationssystem, im fahrzeug angebrachte steuervorrichtung und informationsverwaltungs-basisstations-vorrichtung
FR2923038A1 (fr) * 2007-10-26 2009-05-01 Peugeot Citroen Automobiles Sa Procede et dispositif de mise a jour autonome de donnees d'un equipement de vehicule
WO2014193524A1 (en) * 2013-05-31 2014-12-04 Itron, Inc. Utility application delivery platform
US9342288B2 (en) 2013-05-31 2016-05-17 Itron, Inc. Surfacing cross platform applications
US10205769B2 (en) 2013-05-31 2019-02-12 Itron, Inc. Distributed applications across platforms
CN112955347A (zh) * 2018-06-29 2021-06-11 布鲁萨电子公司 感应式交通工具充电系统的交通工具模块和运行这种交通工具模块的方法

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7289611B2 (en) * 1999-01-22 2007-10-30 Pointset Corporation Method and apparatus for setting programmable features of motor vehicle
US6256378B1 (en) 1999-01-22 2001-07-03 Pointset Corporation Method and apparatus for setting programmable features of an appliance
US7415102B2 (en) 1999-01-22 2008-08-19 Pointset Corporation Method and apparatus for setting programmable features of an appliance
DE10243093B4 (de) * 2002-09-16 2020-10-15 Volkswagen Ag Vorrichtung und Verfahren zum System-Check von Fahrzeugen
DE10313389A1 (de) * 2003-03-25 2004-10-07 Endress + Hauser Process Solutions Ag Verfahren zur Übertragung von Softwarecode von einer Steuereinheit zu einem Feldgerät der Prozessautomatisierungstechnik
DE10309507A1 (de) * 2003-03-05 2004-09-16 Volkswagen Ag Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges
DE10312946B4 (de) * 2003-03-22 2015-12-03 GM Global Technology Operations LLC (n. d. Ges. d. Staates Delaware) Vorrichtung und Verfahren zur Datenübertragung
WO2004114131A1 (de) 2003-06-24 2004-12-29 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher
DE10331874A1 (de) 2003-07-14 2005-03-03 Robert Bosch Gmbh Fernprogrammieren eines programmgesteuerten Geräts
US20050194456A1 (en) 2004-03-02 2005-09-08 Tessier Patrick C. Wireless controller with gateway
US7506309B2 (en) * 2004-03-23 2009-03-17 General Motors Corporation Method for managing vehicle software configuration updates
DE102004016289A1 (de) * 2004-04-02 2005-11-10 Daimlerchrysler Ag Verfahren zur Datensicherung in Fahrzeugbauteilen und zugehöriges Fahrzeugbauteil
US7366589B2 (en) * 2004-05-13 2008-04-29 General Motors Corporation Method and system for remote reflash
SE528103C2 (sv) * 2004-08-31 2006-09-05 Smarttrust Ab Förfarande och system för kontrollering av apparatidentitet
DE102004058614A1 (de) 2004-12-04 2006-06-22 Bosch Rexroth Aktiengesellschaft Energieversorgung für Widerstandsschweißanlagen
DE102005038471A1 (de) * 2005-08-13 2007-02-15 Daimlerchrysler Ag Verfahren und Vorrichtung zur Sicherung von Fahrzeugen vor unbefugter Nutzung
DE102006017644B4 (de) * 2006-04-12 2008-04-17 Dr.Ing.H.C. F. Porsche Ag Erfassung und Diagnose von Fahrzeugdaten
US9513898B2 (en) 2014-06-30 2016-12-06 Google Inc. Systems and methods for updating software in a hazard detection system
DE102017217668A1 (de) 2017-10-05 2019-04-11 Bayerische Motoren Werke Aktiengesellschaft Verfahren und zentrale Datenverarbeitungsvorrichtung zum Aktualisieren von Software in einer Vielzahl von Fahrzeugen
DE102017124910A1 (de) 2017-10-25 2019-04-25 Iav Gmbh Ingenieurgesellschaft Auto Und Verkehr Verfahren und Vorrichtung zum Übertragen von Daten

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0778520A2 (de) * 1995-12-08 1997-06-11 Sun Microsystems, Inc. Vorrichtung und Verfahren zur Ausführung nachprüfbarer Programme mit Möglichkeit zur Nutzung von nicht-nachprüfbaren Programmen aus vertrauten Quellen
US5867714A (en) * 1996-10-31 1999-02-02 Ncr Corporation System and method for distributing configuration-dependent software revisions to a computer system
GB2352539A (en) * 1999-04-30 2001-01-31 Hugh Symons Group Plc A method and system for managing distribution of content to a device

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0644242B2 (ja) * 1988-03-17 1994-06-08 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータ・システムにおける問題解決方法
DE4218804A1 (de) * 1992-06-06 1993-12-09 Vdo Schindling Einrichtung zur Darstellung, Aufbereitung und Speicherung von Informationen in einem Kraftfahrzeug
DE19750372C2 (de) * 1997-11-14 2002-09-19 Bosch Gmbh Robert Verfahren zum Betreiben von datenverarbeitenden Geräten

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0778520A2 (de) * 1995-12-08 1997-06-11 Sun Microsystems, Inc. Vorrichtung und Verfahren zur Ausführung nachprüfbarer Programme mit Möglichkeit zur Nutzung von nicht-nachprüfbaren Programmen aus vertrauten Quellen
US5867714A (en) * 1996-10-31 1999-02-02 Ncr Corporation System and method for distributing configuration-dependent software revisions to a computer system
GB2352539A (en) * 1999-04-30 2001-01-31 Hugh Symons Group Plc A method and system for managing distribution of content to a device

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1699031A1 (de) * 2003-12-15 2006-09-06 Hitachi, Ltd. Informations-aktualisierungsverfahren für eine im fahrzeug angebrachte steuervorrichtung, aktualisierungs-informationskommunikationssystem, im fahrzeug angebrachte steuervorrichtung und informationsverwaltungs-basisstations-vorrichtung
EP1699031A4 (de) * 2003-12-15 2008-01-23 Hitachi Ltd Informations-aktualisierungsverfahren für eine im fahrzeug angebrachte steuervorrichtung, aktualisierungs-informationskommunikationssystem, im fahrzeug angebrachte steuervorrichtung und informationsverwaltungs-basisstations-vorrichtung
US8290659B2 (en) 2003-12-15 2012-10-16 Hitachi, Ltd. Information updating method of vehicle-mounted control apparatus, update information communication system, vehicle-mounted control apparatus, and information management base station apparatus
FR2923038A1 (fr) * 2007-10-26 2009-05-01 Peugeot Citroen Automobiles Sa Procede et dispositif de mise a jour autonome de donnees d'un equipement de vehicule
WO2014193524A1 (en) * 2013-05-31 2014-12-04 Itron, Inc. Utility application delivery platform
US9342288B2 (en) 2013-05-31 2016-05-17 Itron, Inc. Surfacing cross platform applications
US10198254B2 (en) 2013-05-31 2019-02-05 Itron, Inc. Surfacing cross platform applications
US10205769B2 (en) 2013-05-31 2019-02-12 Itron, Inc. Distributed applications across platforms
US11328344B2 (en) 2013-05-31 2022-05-10 Itron, Inc. Utility application delivery platform
CN112955347A (zh) * 2018-06-29 2021-06-11 布鲁萨电子公司 感应式交通工具充电系统的交通工具模块和运行这种交通工具模块的方法

Also Published As

Publication number Publication date
DE10131395A1 (de) 2003-01-23
DE10131395B4 (de) 2006-08-17
WO2003003200B1 (de) 2003-10-30

Similar Documents

Publication Publication Date Title
DE10131395B4 (de) Verfahren zum Übertragen von Software- Modulen
DE10213165B3 (de) Verfahren und Vorrichtung zum Übernehmen von Daten
DE60313810T2 (de) Verfahren zur bereitstellung eines softwaremoduls für eine kraftfahrzeug-steuereinheit und computerprogramm zur ausführung des verfahrens
DE112012003795B4 (de) Verfahren und system für eine fahrzeug-information-integritätsverifikation
DE102008021030B4 (de) Verfahren zum Betreiben eines Fahrzeugs sowie entsprechende Vorrichtung und entsprechendes Fahrzeug
WO2010054920A1 (de) Vorrichtung zum steuern einer fahrzeugfunktion und verfahren zum aktualisieren eines steuergerätes
DE10238095B4 (de) Verfahren zum Schutz vor Manipulationen an einem Steuergerät für mindestens eine Kfz-Komponente und Steuergerät
EP1185026A2 (de) Verfahren zur Datenübertragung
EP1399813A2 (de) Verfahren zum übertragen von software-modulen
EP1760623A2 (de) Sicherheitseinrichtung für elektronische Geräte
WO2019137773A1 (de) Absicherung eines softwareupdates eines steuergerätes eines fortbewegungsmittels
EP1665031A2 (de) Verfahren zur installation einer programmkomponente
EP3384411B1 (de) Verfahren zum übertragen eines funktionsbefehls zwischen einem kraftfahrzeug und einer fahrzeugexternen einrichtung sowie schnittstellenvorrichtung und system
DE102022104321A1 (de) Center, aktualisierungsmanagementverfahren und nicht-transitorisches speichermedium
EP3793868B1 (de) Ein verfahren zum betreiben einer steuervorrichtung
DE10238094B4 (de) Verfahren zum Schutz gegen Manipulationen in einem Steuergerät für mindestens eine Kfz-Komponente und Steuergerät
DE102014213503A1 (de) Verfahren zum Überwachen einer Software in einem Straßenfahrzeug
DE10130493B4 (de) Verfahren zur Freigabe eines Zugriffs auf ein elektronisches Steuergerät
EP3693233B1 (de) Sicherheitsmodus bei ersetzten ecus
DE10143556A1 (de) Fahrzeugmanagementsystem
DE102016219207A1 (de) Verfahren und vorrichtung zum zertifizieren einer sicherheitskritischen funktionskette
EP1918839A1 (de) Modifizieren eines Softwarestands einer Steuergerätesoftware für ein Steuergerät und Erkennen einer solchen Modifikation
DE102020003321A1 (de) System zum Übertragen zumindest eines Aktualisierungspakets, sowie Verfahren
EP4250146A1 (de) Interaktion physischer entitäten
DE102022128289A1 (de) Leistungsabstimmung für elektronische steuereinheit

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
B Later publication of amended claims

Free format text: 20030117

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP