WO2020058008A1 - Verfahren zum ausführen einer applikation in einem fahrzeug, fahrzeugsystem, computerprogramm und datenträgersignal - Google Patents

Verfahren zum ausführen einer applikation in einem fahrzeug, fahrzeugsystem, computerprogramm und datenträgersignal Download PDF

Info

Publication number
WO2020058008A1
WO2020058008A1 PCT/EP2019/073909 EP2019073909W WO2020058008A1 WO 2020058008 A1 WO2020058008 A1 WO 2020058008A1 EP 2019073909 W EP2019073909 W EP 2019073909W WO 2020058008 A1 WO2020058008 A1 WO 2020058008A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
application
executing
data
checksum
Prior art date
Application number
PCT/EP2019/073909
Other languages
English (en)
French (fr)
Inventor
Albert Kos
Konrad Hilarius
Original Assignee
Continental Automotive Gmbh
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 Continental Automotive Gmbh filed Critical Continental Automotive Gmbh
Publication of WO2020058008A1 publication Critical patent/WO2020058008A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the invention relates to a method for executing an application in a vehicle system.
  • the invention relates to a vehicle system, a computer program and a data carrier signal.
  • DE 10037397 A1 discloses a method for loading software into a target device of a vehicle control system with a plurality of devices, with the following steps: dividing the loading of a software module into subtasks, namely at least one control device task, one update device task and one receiving device task, and assigning an implementation to the task Partial tasks to the target device, the devices and / or a control device outside the vehicle control system, the control device task including processing and forwarding control commands for loading the software module from outside the vehicle control system, the update device task controlling the loading of the software module between the Contains target device, the devices and / or the control device and the receiving device task provides an interface for the software module to be loaded from outside the vehicle control system.
  • DE 19620885 A1 discloses a method for updating data and / or parameters of a control device in a vehicle, in which the data are transmitted by radio from a control center together with a vehicle-specific identifier and that the data present in the control device are overwritten when the vehicle-specific identifier matches the identifier held in the vehicle.
  • DE 102009018761 A1 discloses a method for updating at least one software component of a motor vehicle, comprising at least the following steps: determination of vehicle configuration information, which at least includes the information as to which hardware components and / or which software components are present in the specific motor vehicle, by means of a condition determination -Device, providing a wireless telecommunication connection between an in-vehicle service interface and an in-vehicle service device, sending the vehicle configuration information determined by the condition-determining device and identification data of the motor vehicle in question from the motor vehicle via the telecommunications connection to the in-vehicle service -Device, check based on the vehicle configuration information by the vehicle-external service facility, whether one or more software components according to one at the fa is available to update the vehicle-external service facility, provision of a corresponding update instruction by the vehicle-external service facility and updating the software component to be updated on the basis of the update instruction, the driver updating the software component to be updated by the vehicle-external service facility in front of
  • EP 1276088 B1 discloses a method for the position-related output of image and / or sound contributions in a vehicle at least one playback device in which current position information about the location of at least the respective vehicle is transmitted to the vehicle via a radio interface and the contribution to be output is selected in the vehicle as a function of the position information from contributions present in the vehicle, the position information are transmitted in a position list, which is updated periodically and the position list contains the position of all vehicles recorded by a traffic control system, the respectively applicable position information being determined on the basis of a vehicle identification number in the respective vehicle in a DMB server, the selection with regard to the contributions to be output by the DMB server hits and that the position information is sent to the vehicle with a higher priority than the contributions together or separately with the contributions from a DMB transmitter.
  • the invention has for its object to provide a safe execution of an application in a vehicle, especially with regard to traffic safety.
  • This object is achieved by specifying a method for executing an application in a vehicle system with the features of claim 1 and by specifying a vehicle system with the features of claim 17. Furthermore, the object is achieved by specifying a computer program with the features of Claim 20 and the specification of a data carrier with the features of claim 21.
  • the output is solved by specifying a method for executing an application in a vehicle system, the vehicle system providing a communication interface, at least one execution unit with at least one vehicle component, and at least one vehicle parameter, the application being provided with a cryptographic checksum, in particular a hash value, on a distributed system on which blockchain technology or distributed ledger technology is used or on a central computer unit, the application being provided by a provider , the application comprising at least one permission parameter and the cryptographic checksum being created by the provider as a cryptographic checksum of the application, with the following steps:
  • the communication interface being designed for bidirectional communication with the central computer unit or the distributed system
  • the communication interface is in particular a wireless communication interface, which is designed for bidirectional communication.
  • the central computer unit typically has resources, in particular with regard to computing power, storage capacity and / or available software, which go beyond the resources of the vehicle.
  • the central computer unit can be, for example, an external server or a cloud.
  • the Distributed system is to be understood in particular as a peer-to-peer network.
  • the network can also be considered a private one Blockchain in which the participants, that is, the individual network nodes are known.
  • the network can also be designed as a service or service cluster.
  • the applications offered by the individual network nodes are provided in the network by the application programming interface. Access to the application programming interface is granted using an access key. This access key is preferably limited in time or quantity.
  • a distributed system which is operated using distributed ledger technology is preferably designed as a networked computer system, with the individual computers coming to a consensus on the sequence of certain transactions and that these transactions update data.
  • a well-known example of this technology is blockchain technology.
  • a blockchain provides an expandable list of data records, in each of which one or more transactions are combined, which are arranged in individual blocks. Transactions are data that are recorded in the chronological order, are traceable, unchangeable and without a central instance. Each transaction contains a public key of the node that created and signed the transaction.
  • the integrity of the individual blocks is ensured by concatenation using cryptographic hash values of the individual blocks.
  • the data record contains all transactions that were generated after the last data block was created.
  • each block comprises a cryptographic hash value of the preceding block, including the cryptographic checksum stored in the previous block, results in a concatenation of the blocks, in which each block comprises a hash value, which is based on the contents of all previous blocks based.
  • the blockchain is therefore based on a consensus of the underlying network, i.e. an agreement between the nodes of the network, about the validity of the data logged in the blockchain.
  • a blockchain is basically a distributed system of general ledgers, also called ledgers, that use an algorithm that connects data records together using cryptographic algorithms to maintain integrity and security.
  • Network nodes with equal rights are so-called network nodes.
  • An organization who "participates” in a blockchain, for example, is referred to as a “blockchain node” or “blockchain node”.
  • Each blockchain node always receives an up-to-date copy of the blockchain, which is continuously updated.
  • Each blockchain node that belongs to a "blockchain” therefore usually has the same rights to save the blockchain and add new blocks, i.e. to validate it.
  • the transactions are stored against manipulation in every verified blockchain.
  • the consensus algorithm determines which node can validate a new block and attach it to the system.
  • the consensus algorithms are based on cryptographic algorithms. There are various algorithms for producing the consensus.
  • the application can preferably be encrypted and stored as a reference or as an application programming interface, wherein the application can only be executed after a key has been acquired.
  • an application for example, a security-relevant application, which is paid for by the vehicle manufacturer and made available in some vehicles, for example, or an application in the form of advertising or entertainment applications, etc. is provided.
  • the invention has the effect that the application is accessed by means of the communication interface through a vehicle system.
  • the application is only executed if a comparison between the at least one permission parameter and the corresponding vehicle parameters by a comparison unit is positive. This ensures execution while ensuring road safety. For example, only in a traffic jam, i.e. when the vehicle is at a standstill, application data are transferred to the navigation device or another display device in the vehicle.
  • Functions are also included as applications.
  • the applications can be dynamically placed and started in the vehicle by the invention, and then stopped when the vehicle component is needed and / or the comparison between vehicle parameters and permit parameters is negative. This means that applications can be started depending on the situation.
  • the cryptographic checksum of the application ensures that the application has not been changed or is confused.
  • the cryptographic checksum is the hash value of the application, which means that a hash value, for example of the source code of the application, is created using a hash function.
  • the distributed system or the central computer unit preferably includes specifications for the provision of applications by individual providers, for example authentication of providers may be necessary.
  • the cryptographic checksum ensures that only legitimate applications can be executed on the vehicle system. This is for safety. Such an application can advantageously also be carried out in safety-relevant vehicle components.
  • a comparison between the at least one permission parameter and the corresponding vehicle parameters is preferably repeated by the comparison unit at predetermined time intervals. This ensures that the vehicle component (s) on which the application is running do not have to be used for any other purpose. This increases traffic safety.
  • the specified time interval can, for example, also be stored in the application as a parameter or specified in some other way. If the vehicle is in a traffic jam, for example, the display of the navigation device can be used to display an advertisement. The application is therefore run by displaying advertisements. If the car is driving again at a certain speed, the navigation route can be displayed again so as not to prevent the driver from doing his driving job. In addition, the display of advertising in traffic-relevant announcements can be interrupted. The same applies if the vehicle is in a self-driving operating mode.
  • the vehicle or the driver is advantageously rewarded by executing the application using a reward system.
  • This can also be stored on the central processing unit or the distributed system with the application.
  • the application is started by the driver.
  • the application is preferably ended by the driver. This enables the driver to maintain control over the execution of the application.
  • the application can be started and / or ended automatically, for example if the provider offered it as a subscription in contrast to a remuneration.
  • the method further comprises
  • the generated vehicle data can be stored in the distributed system or in the central computer unit and offered for sale.
  • the vehicle data are advantageously stored in encrypted form. This makes it possible for the vehicle data obtained by the application to be registered and sold on the data market, that is to say the distributed system or the central computer unit.
  • the computing capacity of the vehicle is used, for example, to generate vehicle data relevant to the provider / vehicle manufacturer.
  • One application is that advertisements are displayed in a traffic jam or traffic light when the vehicle is stationary. The driver is rewarded by playing an interesting video with voice output after the advertisement. This is currently the case, for example, on the Internet large publishing houses. At least the video is interrupted as soon as one of the vehicle parameters no longer matches the permission parameter or the driver stops the output.
  • the publishing house can adjust the advertising times to the respective stop times, import geographically regional advertising or adapt the advertising to the selected videos (i.e. the driver's area of interest).
  • the publishing house can put this vehicle data on the distributed system, on which blockchain technology or distributed ledger technology is used, on the central computer unit in encrypted form for sale or directly conclude contracts with the advertising providers. It is therefore possible to transfer the functions / applications that already exist on the Internet to a vehicle.
  • the cryptographic checksum and / or the application is signed by the vehicle system with a signature, the signature being created using a signature software.
  • the signature is advantageously transmitted and stored in the distributed system on which a block chain technology or a distributed ledger technology is used or in the central computer unit. This makes it possible to determine which vehicle the application was installed on. In addition, it can be determined which application (s) have been installed if several applications are available.
  • a registration number is preferably provided in the vehicle system for identifying the vehicle, the registration number for identifying the vehicle in the distributed system or in the central computer unit is stored ge.
  • a database checksum is provided in a database.
  • the thank-you bank checksum is preferably transmitted through the communication interface into the vehicle system, the communication interface being designed at least for unidirectional communication with the database for transmitting the database checksum.
  • the application is executed by the at least one vehicle component of the execution unit only if the database checksum and the checksum match.
  • the database with the database checksum can be provided, for example, by the vehicle manufacturer or by the provider. This ensures that the application can be carried out safely in the vehicle. The application itself can also be verified. This increases safety for the driver.
  • the application When executed, the application preferably outputs application data via a graphical user interface, the at least one vehicle component comprising the graphical user interface.
  • a graphical user interface is designed as a navigation device display.
  • the navigation device display is not required to display the navigation route when the vehicle is at a standstill.
  • the application data are preferably streamed as livestream application data, that is to say immediately discarded after the display / playback. This means that no storage space is required in the vehicle.
  • a smart contract is advantageously provided, which is provided by the provider in the distributed system.
  • the application is advantageously provided with the permission in a smart contract.
  • the application can be provided as an application programming interface or as a reference in the distributed system.
  • Smart contracts are programmable contracts that are defined by an executable program code and are automatically executed on the distributed system according to previously defined conditions. Smart contracts are a control or business rule within a technical protocol. Smart contracts are also computer protocols that depict or review contracts.
  • the conditions agreed in a smart contract are secured by the distributed system using distributed ledger technology or blockchain technology.
  • the implementation of the contractual conditions is controlled via the associated transactions.
  • follow-up actions provided in a programmed smart contract can be carried out depending on the transaction.
  • a supervisory authority is therefore superfluous.
  • At least the cryptographic checksum and / or the application is signed using a signature, the signature being created using a signature software, the signature being transmitted to the smart contract via the communication interface for storage. This makes it possible to understand which vehicle the application was installed on.
  • a state channel or a side chain is advantageously provided, at least the application being transmitted via the state channel or side chain.
  • the application advantageously comprises an executable computer program.
  • the computer program is encrypted by a key.
  • a state channel is essentially a two-way channel between two users, or here network nodes and users who want to complete transactions with one another. Each user signs these transactions with their private key. These transactions take place entirely outside the distributed ledger system (off-chain) and only between users, which means that they can be executed very quickly compared to on-chain transactions.
  • State channels can be closed at a predetermined point, for example when a predetermined amount of transactions has been carried out or after a certain period of time. Once a state channel is closed, the end result can be uploaded to the distributed system for it to become official. This means that the contracting parties can exchange application data directly.
  • the state channels can also be viewed as a side chain, whereby only the end result is stored in the actual block chain, for example.
  • the smart contract advantageously comprises a list of all vehicles and / or vehicle components on which the application can be carried out.
  • a registration number is preferably provided in the vehicle system for identifying the vehicle, the register number for identification of the vehicle is stored in the smart contract.
  • the registration number can also include vehicle-related parameters (equipment, vehicle type). This makes it possible to offer the vehicle or driver specific applications.
  • vehicle-related parameters equipment, vehicle type.
  • personal or driver-related or geographic parameters can also be included, so that applications can also be offered in relation to the person / driver or geographic position.
  • the application is designed as an executable computer program, the computer program for execution being stored in one or more vehicle components of the execution unit. This means that the application can also be run in the event of a radio interference.
  • the computer program is preferably encrypted by a key. This can increase security.
  • the object is achieved by specifying a vehicle system which is configured to carry out a method as described above, the method being designed to execute an application in a vehicle, the application having a cryptographic checksum, in particular a hash value, on a distributed system on which a blockchain technology or a distributed ledger technology is used or is provided on a central computer unit, the application being provided by a provider, the application comprising at least one permission parameter and the cryptographic checksum as cryptographic checksum of the application is created by the provider, comprising the vehicle system: a communication interface which is configured for bidirectional communication with the distributed system or for bidirectional communication with the central computer unit, at least one execution unit with at least one vehicle component,
  • the execution unit being configured with the at least one vehicle component such that, if the comparison is positive, the application by the at least one vehicle component the execution unit is executable.
  • the permission parameters include vehicle-related permission parameters, in particular a vehicle configuration, a vehicle type and / or vehicle-related identification data and / or situation-related permission parameters, in particular downtime of the vehicle in a traffic jam or at traffic lights or driving in an autonomous operating mode.
  • vehicle-related permission parameters in particular a vehicle configuration, a vehicle type and / or vehicle-related identification data and / or situation-related permission parameters, in particular downtime of the vehicle in a traffic jam or at traffic lights or driving in an autonomous operating mode.
  • vehicle parameters and permission parameters road safety during execution is guaranteed.
  • Situation-related parameters can also include the geographic position of the vehicle.
  • different applications can be offered or used by the provider for vehicles in geographically different areas. Different applications can also be used for different vehicle types.
  • the vehicle system is preferably a driver assistance system. This is particularly preferably installed in vehicles, in particular passenger vehicles or trucks.
  • the object is achieved by specifying a computer program that is programmed to carry out a method according to one or more of the described embodiments if the computer program is executed, for example, in a vehicle system as described above.
  • the object is achieved by specifying a data carrier signal that transmits the computer program described above.
  • a data carrier signal that transmits the computer program described above. This makes it easy to retrofit vehicles. This can be done, for example, by importing the computer program by means of a, preferably wireless, communication interface by the driver.
  • FIG. 2 shows a first embodiment of the invention as a block diagram
  • FIG. 3 shows a further embodiment of the invention as a block diagram
  • a provider 6 provides his application (s) for a vehicle system 1 (FIG. 2) in a vehicle 5 (FIG. 2) with an execution unit 2 (FIG. 2) which has vehicle components 3 (FIG. 2) and encrypts this application / s with a hash function and a hash value.
  • the hash value represents a fingerprint of the application or the source code of the application.
  • the provider 6 (FIG. 2) then makes the application with the hash value available in a further step S2 on a distributed system 8 (FIG. 2) with blockchain technology in a smart contract 9 (FIG. 2).
  • the distributed system 8 (FIG. 2) with blockchain technology makes it possible to provide several applications in a smart contract 9 from different providers 6 (FIG. 2).
  • the application is stored in the smart contract 9 by an application programming interface.
  • the smart contract 9 (FIG. 2) contains the permission parameters, for example a list on which vehicle components 3 (FIG. 2) in which vehicle 5 the application can be carried out. Such a list can be made available by the vehicle manufacturer, for example. Other permission parameters are also possible, for example the current speed, the operating mode, etc.
  • a vehicle system 1 accesses the smart contract 9 (FIG. 2) for executing the application by Communication interface 4 (FIG 2).
  • the permission parameters can be compared with currently available vehicle parameters.
  • the comparison can be provided in the smart contract 9 (FIG. 2), or the permission parameters are loaded into the vehicle system 1 (FIG. 2). If the comparison is positive, the application is loaded into the execution unit 2 (FIG. 2) of the vehicle 5 by a communication interface 4 (FIG. 2).
  • the application can start automatically after loading or can be started by the driver.
  • a first state channel 15 from provider 6 (FIG. 2) to vehicle 5 (FIG. 2) or from vehicle 5 (FIG. 2) to provider 6 (FIG. 2) is opened via smart contract 9 (FIG. 2).
  • the provider 6 (FIG 2) can now communicate directly with the vehicle 5 (FIG 2) off-chain.
  • at least the hash value and / or the application is signed with a signature by the vehicle system 1 (FIG. 2), the signature being created using signature software.
  • the signed hash value is transmitted to the distributed system 8 through the communication interface 4 (FIG. 2) and stored in the smart contract 9 (FIG. 2).
  • the signed hash value makes it possible to determine which application and by whom on which vehicle 5 (FIG. 2) was executed. This is important, for example, if the vehicle 5 is a rental car and the application was purchased, for example, by a rental car rental company as a buyer.
  • the application data can be streamed via the first state channel 15 directly to the vehicle 5 (FIG. 2) or the execution unit 2 (FIG. 2) for execution by the vehicle component 3.
  • the first state channel 15 is used to determine how often and which application data have been executed on the vehicle component 3. This information enables easier billing. Remuneration can be paid in a cryptocurrency.
  • vehicle data can be generated by the application / s executed in the vehicle 5 (FIG. 2). These can be transmitted to the distributed system 8 (FIG. 2) and stored in encrypted form in the smart contract 9 (FIG. 2). Interested parties can buy this vehicle data for a fee.
  • step S6 the execution of the application by the driver or by a negative comparison between permission parameters and vehicle parameters is ended.
  • the vehicle system 1 comprises an execution unit 2 and a communication interface 4 in a vehicle 5.
  • the execution unit 2 comprises at least one vehicle component 3, for example the navigation device with the display.
  • a provider 6 provides (at least) one application.
  • a hash value is created from the source code of the application or the binary code with a hash function as a cryptographic checksum.
  • the provider 6 creates a smart contract 9 on a distributed system 8 with blockchain technology.
  • the application and the hash value are stored in the smart contract 9.
  • an application programming interface can be provided in the smart contract 9, via which the application can be accessed, the application being stored in encrypted form.
  • the driver of the vehicle 5 has his vehicle 5 registered on the smart contract 9 using the registration number 10.
  • the registration number 10 also contains other vehicle-related vehicle parameters, for example which vehicle component 3 is installed in the respective execution unit 2.
  • a vehicle manufacturer (buyer) 11 receives, arrow 17, the registration numbers 10 of all registered vehicles 5 and uses the registration number 10 to create the permission parameters for the individual vehicles 5, that is to say on which vehicle 5 the application can be installed. These permission parameters can be stored in the smart contract 9, arrow 17.
  • the permission parameters and the vehicle parameters match; there is a positive comparison.
  • the application for example a security update or the provision of vehicle-specific sensor data, can be carried out in vehicle 5, arrow 12. If further permission parameters are provided, these must first be compared in advance.
  • the vehicle manufacturer 11 can also store the permission parameters without registration numbers in the smart contract 9, so that a separate comparison must be carried out. If this is positive, the application can be executed in the vehicle 5 after the application has been installed.
  • a first state channel 15 is opened between the vehicle system 1 and the provider 6.
  • the application data can be transmitted or streamed by the provider 6 by means of the first state channel 15 and can also be billed there according to the transmitted application data volume and / or time-based. Depending on the application, payment is made between vehicle manufacturer 11 and provider 6 (in the case of an application for increasing security or avoiding traffic jams), arrow 13 or in the generation of vehicle data by vehicle 5 and making the vehicle data available in smart contract 9 for provider 6 between provider 6 and Vehicle manufacturer 11, arrow 14.
  • Remuneration can also be paid directly from vehicle manufacturer 11 to vehicle 5 via a second state channel 16.
  • the application data stream from the provider 6 to the vehicle system 1 can be released either by the provider 6 or the driver or the vehicle system 1.
  • Generated vehicle data can be sent from the vehicle system 1 to the provider 6 via the first state channel 15 or to the vehicle manufacturer 11 via the second state channel 16. The generated vehicle data are released, for example, by the vehicle system 1.
  • the application data is streamed as multimedia data from the first state channel 15 from the provider 6 to the vehicle 5. Furthermore, the vehicle 5 sets up a second state channel 16 with counterfactual instantiation for the vehicle manufacturer 11. The application data can be billed off-chain via the second state channel 16 with counterfactual instantiation. If the application is ended, the remuneration / billing is stored in the distributed system 8 using blockchain technology.
  • the application data stream can be encrypted either by the provider 6, the vehicle manufacturer 11 or the vehicle 5.
  • a provider 6 would like to display advertising in vehicles 5. For this purpose, it generates an application in a step W1 and creates a hash value with the application's source code. Further In step W2, he creates a smart contract 9 on a distributed system 8. The application and the hash value are stored in the smart contract 9.
  • the provider also stores 6 permission parameters. In addition to the specific vehicle components on which the application can be executed, these also include other permission parameters.
  • Another permission parameter is, for example, that the advertisement is only switched when the vehicle 5 is in a standstill position (for example in a traffic jam or at a traffic light).
  • Another permission parameter is that the advertisement is only switched when the driver is at a given geographical location or near a supermarket. Further permission parameters can be specified by the vehicle manufacturer 11, for example with regard to the vehicle components 3 of the respective vehicles 5.
  • the vehicle 5 registers in the smart contract 9. In doing so, it specifies its registration number 10, on the basis of which the various vehicle components 3 can be determined. If the permission parameters with regard to the vehicle components 3 are met, the vehicle 5 can load the application into the execution unit 2. The hash value is also signed and the signature is stored in the distributed system 8. This makes it possible to determine which application has been installed on which vehicle 5.
  • a step W5 the vehicle parameters and the further permission parameters are compared.
  • the adjustment can be carried out in a first state channel 15, which is opened from the vehicle 5 to the provider 6, that is to say the vehicle 5 releases its vehicle-related vehicle parameters. If they match (vehicle standstill etc.), the advertising can be streamed to the vehicle component, here the display control unit (s).
  • the application data are transmitted via the first state channel 15.
  • the vehicle 5 is remunerated by the state channel 15 in a step W6 and the method is ended.
  • free parking or a cryptocurrency can be provided as remuneration.
  • the provider 6 can be paid for by the advertiser.
  • FIG. 5 shows a second application example of the invention as a block diagram.
  • a vehicle manufacturer 11 would like to equip a vehicle 5 with a new function as an application and still requires reference data for this.
  • the application for collecting such reference data is therefore provided 7 by a further vehicle manufacturer 18 via a smart contract 9 on a distributed system 8 with blockchain technology.
  • the application also provides a hash value.
  • both vehicle manufacturers 11, 18 can create permission parameters 7, 17 and save them in the smart contract 9.
  • a vehicle 5 can register on the smart contract 9 via a registration number 10.
  • the hash value is signed by the vehicle 5 and this signature is stored in the distributed system 8 with blockchain technology in the smart contract 9, arrow 10.
  • the signed hash value makes it possible to determine which application was installed on which vehicle 5.
  • the application is loaded into the vehicle 5, arrow 12 and executed when the permission parameters and the vehicle parameters result in a positive comparison.
  • the application data can be sent directly to the vehicle manufacturer 11 via the second state channel 16.
  • the reward of Vehicle 5 can also take place via the second state channel 16.
  • the second vehicle manufacturer 18 can be rewarded by the first vehicle manufacturer 11.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Computer Hardware Design (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Navigation (AREA)
  • Traffic Control Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Ausführen einer Applikation in einem Fahrzeugsystem (1), wobei durch das Fahrzeugsystem (1) eine Kommunikationsschnittstelle (4), zumindest eine Ausführeinheit (2) mit mindestens einer Fahrzeugkomponente (3), und zumindest ein Fahrzeugparameter bereitgestellt werden, wobei die Applikation mit einer kryptografischen Prüfsumme, auf einem verteilten System (8), oder auf einer zentralen Rechnereinheit bereitgestellt wird, wobei die Applikation durch einen Anbieter (6) bereitgestellt wird, wobei die Applikation mindestens einen Erlaubnisparameter umfasst und wobei die kryptografische Prüfsumme der Applikation durch den Anbieter (6) erstellt wird, mit den Schritten: - Zugreifen auf die Applikation mittels der Kommunikationsschnittstelle (4) durch das Fahrzeugsystem (1), - Abgleichen zwischen dem mindestens einen Erlaubnisparameter und den dazu korrespondierenden Fahrzeugparameter durch eine Vergleichseinheit, - Ausführen der Applikation durch die mindestens eine Fahrzeugkomponente (3) der Ausführeinheit (2) bei einem positiven Abgleich. Ferner betrifft die Erfindung ein Fahrzeugsystem, ein Computerprogramm und ein Datenträgersignal.

Description

Beschreibung
Verfahren zum Ausführen einer Applikation in einem Fahrzeug, Fahrzeugsystem, Computerprogramm und Datenträgersignal
Die Erfindung betrifft ein Verfahren zum Ausführen einer Ap plikation in einem Fahrzeugsystem. Zudem betrifft die Erfindung ein Fahrzeugsystem, ein Computerprogramm und ein Datenträ gersignal .
Die DE 10037397 Al offenbart ein Verfahren zum Laden von Software in ein Zielgerät eines Fahrzeugsteuerungssystems mit mehreren Geräten, mit folgenden Schritten: Unterteilen des Ladens eines Softwaremoduls in Teilaufgaben, nämlich wenigstens eine Kon trollgerätaufgabe, eine Updategerätaufgabe und eine Emp fangsgerätaufgabe, und Zuweisen einer Durchführung der Teil aufgaben an das Zielgerät, die Geräte und/oder ein Leitgerät außerhalb des Fahrzeugsteuerungssystems, wobei die Kontroll gerätaufgabe ein Verarbeiten und Weiterleiten von Steuerbefehlen für das Laden des Softwaremoduls von außerhalb des Fahrzeug steuerungssystems enthält, die Updategerätaufgabe eine Steu erung des Ladens des Softwaremoduls zwischen dem Zielgerät, den Geräten und/oder dem Leitgerät enthält und die Empfangsge rätaufgabe eine Bereitstellung einer Schnittstelle für das von außerhalb des Fahrzeugsteuerungssystems zu ladende Software modul enthält.
Die DE 19620885 Al offenbart ein Verfahren zum Aktualisieren von Daten und/oder Parametern eines Steuergeräts in einem Fahrzeug, bei dem die Daten per Funk von einer Zentrale aus zusammen mit einer fahrzeugindividuellen Kennung übertragen werden und dass die im Steuergerät vorhandenen Daten überschrieben werden, wenn die fahrzeugindividuelle Kennung mit der im Fahrzeug vorge haltenen Kennung übereinstimmt. Die DE 102009018761 Al offenbart ein Verfahren zur Aktualisierung zumindest einer Softwarekomponente eines Kraftfahrzeugs, um fassend zumindest die Schritte: Ermittlung von Fahrzeugkon figurationsinformation, die zumindest die Information umfasst, welche Hardwarekomponenten und/oder welche Softwarekomponenten im konkreten Kraftfahrzeug vorhanden sind, durch eine Zu- standsermittlungs-Vorrichtung, Bereitstellen einer drahtlosen Telekommunikationsverbindung zwischen einer fahrzeuginternen Service-Schnittstelle und einer fahrzeugexternen Ser vice-Einrichtung, Versenden der von der Zustandsermitt- lungs-Vorrichtung ermittelten Fahrzeugkonfigurationsinforma tion sowie von Identifikationsdaten des betreffenden Kraft fahrzeugs vom Kraftfahrzeug über die Telekommunikationsver bindung an die fahrzeugexterne Service-Einrichtung, Prüfung anhand der Fahrzeugkonfigurationsinformation durch die fahr zeugexterne Service-Einrichtung, ob eine oder mehrere Soft warekomponenten gemäß einer bei der fahrzeugexternen Ser vice-Einrichtung verfügbaren Kontrollvorschrift zu aktuali sieren ist, Bereitstellen einer entsprechenden Aktualisie rungsvorschrift durch die fahrzeugexterne Service-Einrichtung und Aktualisierung der zu aktualisierenden Softwarekomponente anhand der Aktualisierungsvorschrift, wobei die Aktualisierung der zu aktualisierenden Softwarekomponente dem Fahrer von der fahrzeugexternen Service-Einrichtung vor ihrer Durchführung angeboten wird, wobei die Aktualisierung auf das Angebot hin ausschließlich durch den Fahrer des Kraftfahrzeugs freigebbar ist und wobei das Versenden der Fahrzeugkonfigurationsinfor mation sowie der Identifikationsdaten ohne Mitwirkung und/oder Benachrichtigung des Fahrers zeitgesteuert und/oder ereig nisgesteuert wiederholt stattfindet.
Die EP 1276088 Bl offenbart ein Verfahren zur positionsbezogenen Ausgabe von Bild- und/oder Tonbeiträgen in einem Fahrzeug mit mindestens einer Wiedergabeeinrichtung, bei dem aktuelle Po sitionsinformationen über den Standort zumindest des jeweiligen Fahrzeuges über eine Funkschnittstelle an das Fahrzeug über mittelt werden und in dem Fahrzeug in Abhängigkeit der Posi tionsinformationen der auszugebende Beitrag aus in dem Fahrzeug gespeichert vorliegenden Beiträgen ausgewählt wird, wobei die Positionsinformationen in einer Positionsliste übertragen werden, die periodisch aktualisiert und die Positionsliste die Position aller von einem Verkehrsleitsystem erfassten Fahrzeuge enthält, wobei die jeweils zutreffende Positionsinformation anhand einer Fahrzeugidentifizierungsnummer in dem jeweiligen Fahrzeug in einem DMB-Server ermittelt wird, wobei die Auswahl bezüglich der auszugebenden Beiträge der DMB-Server trifft und dass die Positionsinformationen mit einer höheren Priorisierung als die Beiträge zusammen oder separat mit den Beiträgen von einem DMB-Sender an das Fahrzeug gesendet werden.
Der Erfindung liegt die Aufgabe zugrunde, ein, vor allem in Bezug auf die Verkehrssicherheit, sicheres Ausführen einer Applikation in einem Fahrzeug bereitzustellen.
Diese Aufgabe wird gelöst durch die Angabe eines Verfahrens zum Ausführen einer Applikation in einem Fahrzeugsystem mit den Merkmalen des Anspruchs 1 sowie durch die Angabe eines Fahr zeugsystems mit den Merkmalen des Anspruchs 17. Ferner wird die Aufgabe gelöst durch die Angabe eines Computerprogramms mit den Merkmalen des Anspruchs 20 als auch die Angabe eines Datenträgers mit den Merkmalen des Anspruchs 21.
Die Ausgabe wird gelöst durch die Angabe eines Verfahren zum Ausführen einer Applikation in einem Fahrzeugsystem, wobei durch das Fahrzeugsystem eine Kommunikationsschnittstelle, zumindest eine Ausführeinheit mit mindestens einer Fahrzeugkomponente, und zumindest ein Fahrzeugparameter bereitgestellt werden, wobei die Applikation mit einer kryptografischen Prüfsumme, insbesondere einem Hashwert, auf einem verteilten System, auf welchem eine Blockchain-Technologie oder eine Distribu- ted-Ledger-Technologie eingesetzt wird oder auf einer zentralen Rechnereinheit bereitgestellt wird, wobei die Applikation durch einen Anbieter bereitgestellt wird, wobei die Applikation mindestens einen Erlaubnisparameter umfasst und wobei die kryptografische Prüfsumme als kryptografische Prüfsumme der Applikation durch den Anbieter erstellt wird, mit den folgenden Schritten :
Zugreifen auf die Applikation mittels der Kommunikations schnittstelle durch das Fahrzeugsystem, wobei die Kommu nikationsschnittstelle zur bidirektionalen Kommunikation mit der zentralen Rechnereinheit oder dem verteilten System ausgestaltet ist,
Abgleichen zwischen dem mindestens einen Erlaubnisparameter und den dazu korrespondierenden Fahrzeugparameter durch eine Vergleichseinheit ,
Ausführen der Applikation durch die mindestens eine Fahr zeugkomponente der Ausführeinheit bei einem positiven Ab gleich .
Die Kommunikationsschnittstelle ist insbesondere eine drahtlos Kommunikationsschnittstelle, welche für eine bidirektionale Kommunikation ausgestaltet ist.
Typischerweise weist die zentrale Rechnereinheit Ressourcen, insbesondere in Bezug auf Rechenleistung, Speicherkapazität und/oder verfügbarer Software auf, die über die Ressourcen des Fahrzeugs hinausgehen. Die zentrale Rechnereinheit kann bei spielsweise ein externer Server oder eine Cloud sein.
Unter verteilten System ist insbesondere ein peer-to-peer Netzwerk zu verstehen. Auch kann das Netzwerk als eine private Blockchain ausgestaltet sein, in welcher die Teilnehmer, das heißt die einzelnen Netzwerkknoten bekannt sind. Das Netzwerk kann auch als ein Dienst- oder Servicecluster ausgestaltet sein. In dem Netzwerk werden die angebotenen Applikationen der einzelnen Netzwerkknoten durch Anwendungsprogrammierschnitt stelle bereitgestellt. Der Zugriff auf die Anwendungspro grammierschnittstelle wird mithilfe eines Zugriffsschlüssels gewährt. Dieser Zugriffsschlüssel ist bevorzugt zeitlich oder quantitativ beschränkt.
Ein verteiltes System, welches mit Distribu- ted-Ledger-Technologie betreiben wird, ist bevorzugt als vernetztes Rechnersystem ausgebildet, wobei die einzelnen Rechner zu einem Konsensus über die Reihenfolge von bestimmten Transaktionen kommen und darüber, dass diese Transaktionen Daten aktualisieren. Ein bekanntes Beispiel dieser Technologie ist die Blockchain Technologie. Eine Blockchain stellt eine erweiterbare Liste von Datensätzen, in denen jeweils eine oder mehrere Transaktionen zusammengefasst sind, bereit, welche in einzelnen Blöcken angeordnet sind. Transaktionen sind Daten, die in der Zeitfolge protokolliert, nachvollziehbar, unveränderlich und ohne Zentralinstanz abgebildet sind. Jede Transaktion enthält einen öffentlichen Schlüssel des Knotens, der die Transaktion erstellt und signiert hat.
Die Integrität der einzelnen Blöcke wird durch eine Verkettung unter Verwendung kryptografischer Hashwerte der einzelnen Blöcke gesichert. Der Datensatz enthält sämtliche Transaktionen, welche nach dem Zeitpunkt des Erstellens des letzten Datenblocks generiert wurden. Dadurch, dass jeder Block einen kryptogra- fische Hashwert des vorausgehenden Blocks inklusive der in dem vorausgehenden Block gespeicherten kryptografischen Prüfsumme umfasst, ergibt sich eine Verkettung der Blöcke, bei welcher jeder Block einen Hashwert umfasst, welche auf den Inhalten aller vorausgehenden Blöcke beruht. Die Blockchain beruht daher auf einem Konsens des zugrundeliegenden Netzwerks, d. h. eine Einigung der Knoten des Netzwerks, über die Gültigkeit der in der Blockchain protokollierten Daten.
Eine Blockchain ist quasi ein verteiltes System von Hauptbüchern, welche auch Ledger genannt werden, die einen Algorithmus verwenden, der Datensätze gemeinsam über kryptografische Al gorithmen verbindet, um Integrität und Sicherheit zu erhalten.
Gleichberechtigte Teilnehmer des Netzwerkes sind sogenannte Netzwerk-Knoten. Jeder, der beispielsweise an einer Blockchain "teilnimmt", wird als „Blockchain-Node" oder „Block- chain-Knoten" bezeichnet. Jeder Blockchain-Knoten erhält immer eine aktuelle Kopie der Blockchain, die fortlaufend aktualisiert wird. Jeder Blockchain-Knoten, welcher zu einer „Blockchain" gehört, hat daher für gewöhnlich die gleichen Rechte, die Blockchain zu speichern und neue Blöcke hinzuzufügen, d.h. zu validieren .
Die Transaktionen, wie hier beispielsweise die Applikation, sind also manipulationsgeschützt in jeder verifizierten Blockchain hinterlegt .
Der Konsensalgorithmus bestimmt, welcher Knoten einen neuen Block validieren und an das System anhängen darf. Die Kon sensalgorithmen beruhen dabei auf kryptografischen Algorithmen. Für die Herstellung des Konsenses gibt es verschiedene Algo rithmen .
Die Applikation kann dabei bevorzugt verschlüsselt und als Verweis oder als Anwendungsprogrammierschnittstelle abgelegt sein, wobei ein Ausführen der Applikation nur nach dem Erwerb eines Schlüssels möglich ist. Als Applikation kann bei- spielsweise eine sicherheitsrelevante Applikation, welche beispielsweise von dem Fahrzeughersteller bezahlt wird und in einigen Fahrzeugen zur Verfügung gestellt wird, oder eine Applikation in Form von Werbung- oder Entertain ment-Applikationen etc. bereitgestellt werden.
Erfindungsgemäß wurde erkannt, dass bei bestimmten, sich einstellenden Fahrzeugparametern Rechenleistung als auch Fahrzeugkomponenten im Fahrzeug ungenutzt bleiben, bei spielsweise ist das bei einem Navigationsgerät im Stau der Fall.
Die Erfindung bewirkt, dass auf die Applikation mittels der Kommunikationsschnittstelle durch ein Fahrzeugsystem zuge griffen wird. Ein Ausführen der Applikation findet jedoch nur statt, wenn ein Abgleich zwischen dem mindestens einen Er laubnisparameter und den dazu korrespondierenden Fahrzeugpa rameter durch eine Vergleichseinheit positiv ist. Dadurch ist ein Ausführen bei gleichzeitiger Verkehrssicherheit gewährleistet. So können beispielsweise nur im Stau, d.h. bei Stillstand des Fahrzeugs, Applikationsdaten auf das Navigationsgerät oder eine anderes Anzeigegerät im Fahrzeug übertragen werden. Als Ap plikationen sind auch Funktionen umfasst. Die Applikationen können durch die Erfindung dynamisch im Fahrzeug platziert und gestartet werden, und dann gestoppt werden, wenn die Fahr zeugkomponente gebraucht wird und/oder der Abgleich zwischen Fahrzeugparameter und Erlaubnisparameter negativ ist. Somit können Applikationen situationsabhängig gestartet werden.
Durch die kryptografische Prüfsumme der Applikation ist si chergestellt, dass die Applikation nicht verändert wurde oder verwechselt wird. Insbesondere ist die kryptografische Prüfsumme der Hashwert der Applikation, das heißt, dass mithilfe einer Hashfunktion ein Hashwert beispielsweise des Sourcecodes der Applikation erstellt wird. Aber auch Teile des Sourcecodes der Applikation, Verweise etc. sind hiermit umfasst und können als Prüfsumme verwendet werden. Das verteilte System oder die zentrale Rechnereinheit umfasst dabei bevorzugt Vorgaben zur Bereitstellung von Applikationen durch einzelne Anbieter, beispielsweise kann eine Authentifizierung von Anbietern notwendig sein. Durch die kryptografische Prüfsumme ist si chergestellt, dass lediglich legitimierte Applikationen auf dem Fahrzeugsystem ausgeführt werden können. Dies dient der Si cherheit. Eine solche Applikation kann vorteilhafterweise auch in sicherheitsrelevanten Fahrzeugkomponenten ausgeführt werden.
Bevorzugt wird ein Abgleich zwischen dem mindestens einen Erlaubnisparameter und den dazu korrespondierenden Fahrzeug parameter durch die Vergleichseinheit in vorgegebenen Zeit abständen wiederholt. Dadurch ist sichergestellt, dass die Fahrzeugkomponente/n, auf welche/r die Applikation ausgeführt wird, nicht anderweitig verwendet werden muss. Somit wird die Verkehrssicherheit erhöht. Der vorgegebene Zeitabstand kann beispielsweise ebenfalls in der Applikation als Parameter hinterlegt werden oder anderweitig vorgegeben werden. Steht das Fahrzeug beispielsweise in einem Stau, so kann das Display des Navigationsgerätes für das Anzeigen einer Werbung verwendet werden. Das Ausführen der Applikation besteht somit im Anzeigen von Werbung. Fährt das Auto wieder mit einer gewissen Ge schwindigkeit, so kann wieder die Navigationsroute angezeigt werden, um den Fahrer nicht von seiner Fahraufgabe abzuhalten. Zudem kann das Anzeigen der Werbung bei verkehrsrelevanten Durchsagen unterbrochen werden. Ähnliches gilt, wenn das Fahrzeug sich in einem selbstfahrenden Betriebsmodus befindet.
Vorteilhafterweise wird das Fahrzeug bzw. der Fahrer durch die Ausführung der Applikation durch ein Belohnungssystem entlohnt. Dieses kann ebenfalls auf der zentralen Recheneinheit oder dem verteilten System mit der Applikation hinterlegt sein. In einer bevorzugten Ausführungsform wird die Applikation durch den Fahrer gestartet. Bevorzugt wird die Applikation durch den Fahrer beendet. Dadurch kann der Fahrer über die Ausführung der Applikation die Kontrolle beibehalten. Alternativ kann die Applikation automatisiert gestartet und/oder beendet werden, beispielsweise wenn der Anbieter diese als Abo im Gegensatz für eine Entlohnung angeboten hat.
In einer bevorzugten Ausgestaltung der Erfindung umfasst das Verfahren weiterhin,
- ein Generieren von Fahrzeugdaten durch das Ausführen der Applikation durch die Ausführeinheit,
- ein Übermitteln der generierten Fahrzeugdaten an das ver teilte System oder die zentrale Rechnereinheit,
- und ein Speichern der generierten Fahrzeugdaten in dem verteilten System oder in der zentralen Rechnereinheit.
Die generierten Fahrzeugdaten können in dem verteilten System oder in der zentralen Rechnereinheit gespeichert und zum Verkauf angeboten werden. Vorteilhafterweise werden die Fahrzeugdaten verschlüsselt gespeichert. Dadurch ist es möglich, dass die jenigen Fahrzeugdaten, die durch die Applikation gewonnen werden, auf dem Datenmarkt also dem verteilten System oder der zentralen Rechnereinheit registriert und veräußert werden. Dadurch wird quasi die Rechenkapazität des Fahrzeugs genutzt, um beispielsweise für den Anbieter/ Fahrzeughersteller relevante Fahrzeugdaten zu generieren. So ist beispielsweise folgende Anwendung möglich: Eine Applikation besteht darin, dass Werbung bei Stillstand des Fahrzeugs in einem Stau oder einer Ampel angezeigt wird. Der Fahrer wird dadurch entlohnt, dass nach der Werbung ein für ihn interessantes Video mit Sprachausgabe abgespielt wird. Dies wird beispielsweise derzeit im Internet bei großen Verlagshäusern so durchgeführt. Zumindest das Video wird unterbrochen, sobald einer der Fahrzeugparameter nicht mehr mit dem Erlaubnisparameter übereinstimmt oder der Fahrer die Ausgabe stoppt. Gibt der Fahrer seine Fahrzeugdaten frei, so kann das Verlagshaus die Werbezeiten an die jeweiligen Stoppzeiten anpassen, sowie geografisch regional Werbung einspielen oder die Werbung den ausgewählten Videos (also dem Interessensgebiet des Fahrers) anpassen. Das Verlagshaus kann diese Fahrzeugdaten auf dem verteilten System, auf welchem eine Blockchain-Technologie oder eine Distributed-Ledger-Technologie eingesetzt wird oder auf der zentralen Rechnereinheit verschlüsselt zum Verkauf stellen oder mit den Werbeanbietern direkt Verträge abschließen. Somit ist es möglich, die bereits jetzt im Internet existieren Funktionen/Applikationen in ein Fahrzeug zu übertragen.
Dadurch ist es möglich, dass auch externe Anbieter auf zeitweise ungenutzte Fahrzeugkomponenten im Fahrzeug zugreift oder ge nerierte Fahrzeugdaten von Fahrzeugen nutzen.
Es ist vorteilhaft, wenn zumindest die kryptografische Prüfsumme und/oder die Applikation durch das Fahrzeugsystem mit einer Signatur signiert wird, wobei die Signatur mittels einer Signatursoftware erstellt wird. Vorteilhafterweise wird die Signatur in das verteilte System, auf welchem eine Block chain-Technologie oder eine Distributed-Ledger-Technologie eingesetzt wird oder in die zentrale Rechnereinheit übertragen und speichern. Dadurch kann festgesellt werden, auf welchem Fahrzeug die Applikation installiert wurde. Zudem kann fest gestelltwerden, welche Applikation/en installiert wurden, falls mehrere Applikationen zur Auswahl kommen.
Weiterhin bevorzugt ist eine Registriernummer in dem Fahr zeugsystem zur Identifikation des Fahrzeugs vorgesehen, wobei die Registriernummer zur Identifikation des Fahrzeugs in dem verteilten System oder in der zentralen Rechnereinheit ge speichert wird.
In bevorzugter Ausgestaltung wird eine Datenbank-Prüfsumme in einer Datenbank bereitgestellt. Bevorzugt wird die Dank- bank-Prüfsumme durch die Kommunikationsschnittstelle in das Fahrzeugsystem übertragen, wobei die Kommunikationsschnitt stelle zumindest zur unidirektionalen Kommunikation mit der Datenbank zur Übertragung der Datenbank-Prüfsumme ausgebildet ist. Dabei wird ein Ausführen der Applikation durch die zumindest eine Fahrzeugkomponente der Ausführungseinheit nur bei Über einstimmung zwischen der Datenbank-Prüfsumme und der Prüfsumme durchgeführt. Die Datenbank mit der Datenbank-Prüfsumme kann beispielsweise vom Fahrzeughersteller bereitgestellt werden oder vom Anbieter. Somit kann gewährleistet werden, dass die Applikation im Fahrzeug sicher ausführbar ist. Auch kann somit die Applikation selber verifiziert werden. Dies erhöht die Sicherheit für den Fahrer.
Bevorzugt gibt die Applikation beim Ausführen Applikationsdaten über eine grafische Benutzeroberfläche aus, wobei die mindestens eine Fahrzeugkomponente die grafische Benutzeroberfläche um fasst. Dadurch kann eine Bildfolge angezeigt werden. Insbe sondere ist die grafische Benutzeroberfläche als Navigati onsgerätdisplay ausgebildet. Das Navigationsgerätdisplay wird bei Stillstand des Fahrzeugs nicht zur Anzeige der Navigati onsroute benötigt. Bevorzugt werden die Applikationsdaten als Livestream-Applikationsdaten gestreamt, das heißt nach dem Anzeigen/der Wiedergabe sofort wieder verworfen. Somit wird kein Speicherplatz im Fahrzeug benötigt.
Vorteilhaftweise ist ein Smart Contract vorgesehen, welcher durch den Anbieter in dem verteilten System bereitgestellt wird. Vorteilhafterweise wird die Applikation mit den Erlaubnispa- rametern in einem Smart Contract, bereitgestellt. Insbesondere kann die Applikation als eine Anwendungsprogrammierschnitt stelle oder einen Verweis in dem verteilten System bereitgestellt werden. Smart Contracts (Smart-Verträge) sind programmierbare Verträge, welche durch einen ausführbaren Programmcode definiert und nach zuvor festgelegten Bedingungen automatisch auf dem verteilten System ausgeführt werden. Smart Contracts stellen eine Kontroll- oder Geschäftsregel innerhalb eines technischen Protokolls dar. Smart Contracts sind außerdem Computerproto kolle, die Verträge abbilden oder überprüfen.
Die in einem Smart Contract vereinbarten Bedingungen werden durch das verteilte System durch die Distributed-Ledger-Technologie oder die Blockchain-Technologie gesichert. Das Umsetzen der Vertragsbedingungen wird über dazugehörige durchgeführte Transaktionen kontrolliert. In einem programmierten Smart Contract vorgesehene Folgeaktionen können je nach erfolgter Transaktion durchgeführt werden. Durch die Verwendung eines Smart Contract ist daher eine Kontrollinstanz überflüssig.
Vorteilhafterweise wird zumindest die kryptografische Prüfsumme und/oder die Applikation mittels einer Signatur signiert, wobei die Signatur mittels einer Signatursoftware erstellt wird, wobei die Signatur über die Kommunikationsschnittstelle zur Spei cherung dem Smart Contract übermittelt wird. Dadurch kann nachvollzogen werden, auf welchem Fahrzeug die Applikation installiert wurde.
In vorteilhafter Weise ist ein Statechannel oder eine Sidechain vorgesehen, wobei zumindest die Applikation über den State channel oder Sidechain übertragen wird. Vorteilhafterweise umfasst die Applikation ein ausführbares Computerprogramm. Insbesondere ist das Computerprogramm durch einen Schlüssel verschlüsselt. Ein Statechannel ist im Wesentlichen ein Zwei-Wege-Kanal zwischen zwei Nutzern, oder hier Netzwerkknoten und Nutzer, die Transaktionen miteinander abschließen wollen. Jeder Nutzer unterzeichnet diese Transaktionen mit seinem privaten Schlüssel . Diese Transaktionen finden vollständig außerhalb des Distri- buted-Ledger-Systems (off-chain) und ausschließlich zwischen den Nutzern statt, was bedeutet, dass sie im Vergleich zu On-Chain-Transaktionen sehr schnell auszuführen sind. State- channels können zu einem vorgegebenen Punkt geschlossen werden, beispielsweise wenn eine vorbestimmte Menge der Transaktionen ausgeführt worden ist oder nach einer gewissen Zeitdauer. Sobald ein Statechannel geschlossen wird, kann das Endergebnis in das verteilte System hochgeladen werden, damit es offiziell wird. Das bedeutet, dass die Vertragspartner direkt Applikationsdaten austauschen können. Die Statechannel können auch als eine Sidechain betrachtet werden, wodurch in der beispielsweise eigentlichen Blockchain nur das Endergebnis gespeichert wird.
Nur im Falle eines Dissens im Smart Contract, also sozusagen einer Meinungsverschiedenheit zwischen den Vertragspartnern, wird der Contract auf der Blockchain ausgeführt, um einen Konsens zu „erzwingen" wobei die Chain als eine Art Richter fungiert. Dadurch wird der Datentransfer vereinfacht und die Belastung der verteilten Systeme minimal gehalten. Zudem führt dies zu einem höheren Grad an Privatsphäre der Vertragsparteien, da der Datenaustausch im Statechannel erfolgt.
Vorteilhafterweise umfasst der Smart Contract eine Liste aller Fahrzeuge und/oder Fahrzeugkomponenten, auf welchen die Ap plikation ausführbar ist.
Vorzugsweise ist eine Registriernummer in dem Fahrzeugsystem zur Identifikation des Fahrzeugs vorgesehen, wobei die Regist- riernummer zur Identifikation des Fahrzeugs im Smart Contract gespeichert wird. Dabei kann die Registriernummer auch fahr zeugbezogene Parameter umfassen (Ausstattung, Fahrzeugtyp) . Dadurch ist es möglich, dem Fahrzeug bzw. dem Fahrer gezielt Applikationen anzubieten. Ferner können auch personenbezogene bzw. fahrerbezogene oder geografische Parameter umfasst sein, so dass Applikationen auch in Bezug auf die Person/Fahrer oder geografische Position angeboten werden können. Durch die Speicherung der Registriernummer ist eine vereinfachte Ab rechnung der genutzten Applikationen durch den Anbieter möglich.
In bevorzugter Ausgestaltung wird die Applikation als ein ausführbares Computerprogramm ausgestaltet, wobei das Compu terprogramm zur Ausführung in eine oder mehrere Fahrzeugkom ponenten der Ausführungseinheit gespeichert wird. Dadurch lässt sich die Applikation auch bei einer Funkstörung ausführen. Bevorzugt wird das Computerprogramm durch einen Schlüssel verschlüsselt. Dadurch kann die Sicherheit erhöht werden.
Ferner wird die Aufgabe gelöst durch die Angabe eines Fahr zeugsystems, welches zur Durchführen eines wie oben beschrieben Verfahrens konfiguriert ist, wobei das Verfahren zum Ausführen einer Applikation in einem Fahrzeug ausgebildet ist, wobei die Applikation mit einer kryptografischen Prüfsumme, insbesondere einem Hashwert, auf einem verteilten System, auf welchem eine Blockchain-Technologie oder eine Distribu- ted-Ledger-Technologie eingesetzt wird oder auf einer zentralen Rechnereinheit bereitgestellt ist, wobei die Applikation durch einen Anbieter bereitgestellt ist, wobei die Applikation mindestens einen Erlaubnisparameter umfasst und wobei die kryptografische Prüfsumme als kryptografische Prüfsumme der Applikation durch den Anbieter erstellt ist, das Fahrzeugsystem aufweisend : eine Kommunikationsschnittstelle, welche zur bidirektionalen Kommunikation mit dem verteilten System oder zur bidirektionalen Kommunikation mit der zentralen Rechnereinheit konfiguriert ist, zumindest eine Ausführeinheit mit mindestens einer Fahrzeug komponente,
zumindest ein Fahrzeugparameter, und eine Vergleichseinheit, welche zum Abgleich zwischen den mindestens einen Erlaubnis parameter und den dazu korrespondieren Fahrzeugparameter ausgestaltet ist, wobei die Ausführungseinheit mit der min destens einen Fahrzeugkomponente so konfiguriert ist, dass bei einem positiven Abgleich die Applikation durch die mindestens eine Fahrzeugkomponente der Ausführungseinheit ausführbar ist.
Die Vorteile des Verfahrens können auch auf das Fahrzeugsystem übertragen werden.
In vorteilhafter Ausgestaltung umfassen die Erlaubnisparameter fahrzeugbezogene Erlaubnisparameter, insbesondere eine Fahr zeugkonfiguration, ein Fahrzeugtyp und/oder fahrzeugbezogene Identifikationsdaten und/oder situationsbezogene Erlaubnis parameter, insbesondere Stillstandszeit des Fahrzeugs im Stau oder an der Ampel oder fahren in einem autonomen Betriebsmodus. Durch den Abgleich zwischen Fahrzeugparameter und Erlaubnis parameter wird somit die Sicherheit im Straßenverkehr bei der Ausführung gewährleistet. Situationsbezogene Parameter können zudem auch die geografische Position des Fahrzeugs umfassen. Dadurch können bei Fahrzeugen in geografisch verschiedenen Gebieten unterschiedliche Applikationen vom Anbieter angeboten werden bzw. zum Einsatz kommen. Auch können für unterschiedliche Fahrzeugtypen unterschiedliche Applikationen zum Einsatz kommen . Vorzugsweise ist das Fahrzeugsystem ein Fahrerassistenzsystem. Besonders bevorzugt ist dieses in Fahrzeugen, insbesondere Personenfahrzeugen oder Lastkraftwagen installiert.
Ferner wird die Aufgabe gelöst durch die Angabe eines Compu terprogramms, das dazu programmiert ist, ein Verfahren nach einer oder mehrerer der beschriebenen Ausführungsformen auszuführen, wenn das Computerprogramm beispielsweise in einem wie oben beschriebenen Fahrzeugsystem ausgeführt wird.
Ferner wird die Aufgabe gelöst durch die Angabe eines Daten trägersignals, das das oben beschriebene Computerprogramm überträgt. Dadurch ist ein einfaches Nachrüsten von Fahrzeugen möglich. Dies kann beispielsweise durch Einspielen des Com puterprogramms mittels einer, bevorzugt drahtlosen Kommuni kationsschnittstelle durch den Fahrer vorgenommen werden.
Weitere Merkmale, Eigenschaften und Vorteile der vorliegenden Erfindung ergeben sich aus der nachfolgenden Beschreibung unter Bezugnahme auf die beiliegenden Figuren. Darin zeigen sche matisch :
FIG 1: das erfindungsgemäße Verfahren in einem ersten Aus führungsbeispiel als ein Flussdiaramm,
FIG 2: eine erste Ausführung der Erfindung als Blockschema,
FIG 3: eine weitere Ausführung der Erfindung als Blockschema,
FIG 4: ein Anwendungsbeispiel der Erfindung als Flussdiagramm,
FIG 5: eine weitere Ausführung der Erfindung als Blockschema. Obwohl die Erfindung im Detail durch das bevorzugte Ausfüh rungsbeispiel näher illustriert und beschrieben wurde, ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt. Variationen hiervon können vom Fachmann abgeleitet werden, ohne den Schutzumfang der Erfindung, wie er durch die nachfolgenden Patentansprüche definiert wird, zu verlassen.
FIG 1 zeigt ein Flussdiagramm des erfindungsgemäßen Verfahrens. In einem ersten Schritt S1 stellt ein Anbieter 6 seine Ap- plikation/en für ein Fahrzeugsystem 1 (FIG 2) in einem Fahrzeug 5 (FIG 2) mit einer Ausführungseinheit 2 (FIG 2), welche Fahrzeugkomponenten 3 (FIG 2) aufweist, bereit und verschlüsselt diese Applikation/en mit einer Hashfunktion und einem Hashwert. Der Hashwert stellt einen Fingerabdruck der Applikation bzw. des Source-Codes der Applikation dar.
Anschließend stellt der Anbieter 6 (FIG 2) die Applikation mit dem Hashwert in einem weiteren Schritt S2 auf einem verteilten System 8 (FIG 2) mit einer Blockchain-Technologie in einem Smart Contract 9 (FIG 2) zur Verfügung. Durch das verteilte System 8 (FIG 2) mit Blockchain-Technologie können mehrere Applikationen in einem Smart Contract 9 von unterschiedlichen Anbietern 6 zur Verfügung gestellt werden (FIG 2) . Die Applikation wird durch eine Anwendungsprogrammierschnittstelle in dem Smart Contract 9 hinterlegt. Der Smart Contract 9 (FIG 2) enthält dabei die Erlaubnisparameter, also beispielsweise eine Liste, auf welchen Fahrzeugkomponenten 3 (FIG 2) in welchem Fahrzeug 5 die Ap plikation ausführbar ist. Eine solche Liste kann beispielsweise vom Fahrzeughersteller zur Verfügung gestellt werden. Auch andere Erlaubnisparameter sind möglich, beispielsweise die aktuelle Geschwindigkeit, der Betriebsmodus etc.
In einem Schritt S3 greift ein Fahrzeugsystem 1 (FIG 2) auf den Smart Contract 9 (FIG 2) zur Ausführung der Applikation durch eine Kommunikationsschnittstelle 4 (FIG 2) zu. Durch den Zugriff können die Erlaubnisparameter mit aktuell vorhandenen Fahr zeugparametern abgeglichen werden. Der Abgleich kann im Smart Contract 9 (FIG 2) vorgesehen sein, oder die Erlaubnisparameter werden in das Fahrzeugsystem 1 (FIG 2) geladen. Bei einem positiven Abgleich wird die Applikation durch eine Kommuni kationsschnittstelle 4 (FIG 2) in die Ausführungseinheit 2 (FIG 2) des Fahrzeugs 5 geladen.
Die Applikation kann dabei automatisiert nach dem Laden starten oder vom Fahrer gestartet werden. Zur Applikationsdatenüber tragung wird über den Smart Contract 9 (FIG 2) ein erster Statechannel 15 vom Anbieter 6 (FIG 2) zum Fahrzeug 5 (FIG 2) oder vom Fahrzeug 5 (FIG 2) zum Anbieter 6 (FIG 2) geöffnet. Der Anbieter 6 (FIG 2) kann nun direkt mit dem Fahrzeug 5 (FIG 2) off-chain kommunizieren. Anschließend oder gleichzeitig wird zumindest der Hashwert und/oder die Applikation mit einer Signatur durch das Fahrzeugsystem 1 (FIG 2) signiert, wobei die Signatur mittels einer Signatursoftware erstellt wird. Der signierte Hashwert wird an das verteilte System 8 durch die Kommunikationsschnittstelle 4 (FIG 2) übermittelt und in dem Smart Contract 9 (FIG 2) gespeichert. Damit wird sichergestellt, dass nur eine legitimierte Applikation auf einer Fahrzeug komponente 3 (FIG 2) durch die Ausführungseinheit 2 (FIG 2) in einem Fahrzeugsystem 1 (FIG 2) ausgeführt wird. Der signierte Hashwert ermöglicht es, festzustellen, welche Applikation und vom wem auf welchem Fahrzeug 5 (FIG 2) ausgeführt wurde. Dies ist beispielsweise wichtig, wenn es sich bei dem Fahrzeug 5 um einen Leihwagen handelt und die Applikation zum Beispiel durch eine Mietwagenverleihfirma als Einkäufer eingekauft wurde. Die Applikationsdaten können über den ersten Statechannel 15 direkt an das Fahrzeug 5 (FIG 2) bzw. die Ausführungseinheit 2 (FIG 2) zur Ausführung durch die Fahrzeugkomponente 3 gestreamt werden. In einem Schritt S4 wird über den ersten Statechannel 15 er mittelt, wie oft und welche Applikationsdaten auf der Fahr zeugkomponente 3 ausgeführt wurden. Anhand dieser Information ist eine leichtere Abrechnung möglich. Eine Entlohnung kann dabei in einer Kryptowährung vorgenommen werden.
In einem zusätzlichen Schritt S5 können durch die im Fahrzeug 5 (FIG 2) ausgeführten Applikation/en Fahrzeugdaten generiert werden. Diese können dem verteilten System 8 (FIG 2) übermittelt und in dem Smart Contract 9 (FIG 2) verschlüsselt hinterlegt werden. Interessenten können diese Fahrzeugdaten gegen Ent lohnung einkaufen.
In einem Schritt S6 wird die Ausführung der Applikation durch den Fahrer oder durch einen negativen Abgleich zwischen Erlaub nisparameter und Fahrzeugparameter beendet.
FIG 2 zeigt ein erfindungsgemäßes Fahrzeugsystem 1 und das Verfahren als Blockschema. Das Fahrzeugsystem 1 umfasst eine Ausführungseinheit 2 und eine Kommunikationsschnittstelle 4 in einem Fahrzeug 5. Die Ausführungseinheit 2 umfasst zumindest eine Fahrzeugkomponente 3, beispielsweise das Navigationsgerät mit dem Display.
Ein Anbieter 6 stellt (zumindest) eine Applikation zur Verfügung . Von dem Source-Code der Applikation oder dem Binärcode wird mit einer Hashfunktion ein Hashwert als kryptografische Prüfsumme erstellt. Ferner erstellt, Pfeil 7, der Anbieter 6 auf einem verteilten System 8 mit Blockchain-Technologie einen Smart Contract 9. Die Applikation als auch der Hashwert werden im Smart Contract 9 gespeichert. Dabei kann eine Anwendungsprogram mierschnittstelle im Smart Contract 9 vorgesehen sein, über die auf die Applikation zugegriffen werden kann, wobei die Ap plikation verschlüsselt hinterlegt ist. Der Fahrer des Fahrzeugs 5 lässt sein Fahrzeug 5 mithilfe der Registriernummer 10 auf dem Smart Contract 9 registrieren. Dabei enthält die Registriernummer 10 auch fahrzeugbezogene andere Fahrzeugparameter, also beispielsweise welche Fahrzeugkompo nente 3 in der jeweiligen Ausführungseinheit 2 installiert ist.
Ein Fahrzeughersteller (Käufer) 11 erhält, Pfeil 17, die Re gistriernummern 10 aller registrierten Fahrzeuge 5 und erstellt anhand der Registriernummer 10 die Erlaubnisparameter für die einzelnen Fahrzeuge 5, das heißt, auf welchem Fahrzeug 5 die Applikation installiert werden können. Diese Erlaubnisparameter können in dem Smart Contract 9 gespeichert werden, Pfeil 17.
Die Erlaubnisparameter und die Fahrzeugparameter stimmen in diesem Fall überein; es liegt ein positiver Abgleich vor. Nach der Installation der Applikation kann die Applikation, bei spielsweise ein Sicherheitsupdate, oder ein Bereitstellen von fahrzeugspezifischen Sensordaten, im Fahrzeug 5 ausgeführt werden, Pfeil 12. Sind weitere Erlaubnisparameter vorgesehen, so müssen diese vorab erst abgeglichen werden.
Alternativ kann der Fahrzeughersteller 11 auch die Erlaub nisparameter ohne Registriernummern im Smart Contract 9 hin terlegen, so dass ein separater Abgleich durchgeführt werden muss. Ist dieser positiv, kann nach der Installation der Ap plikation, die Applikation im Fahrzeug 5 ausgeführt werden.
Zur Ausführung der Applikation wird zwischen dem Fahrzeugsystem 1 und dem Anbieter 6 ein erster Statechannel 15 geöffnet.
Die Applikationsdaten können mittels des ersten Statechannels 15 vom Anbieter 6 übertragen bzw. gestreamt werden und dort auch nach übertragenem Applikationsdatenvolumen und/oder zeitbasiert abgerechnet werden. Je nach Applikation erfolgt die Bezahlung zwischen Fahrzeughersteller 11 und Anbieter 6 (bei einer Ap plikation zur Erhöhung der Sicherheit oder Vermeidung von Staus) , Pfeil 13 oder bei der Generierung von Fahrzeugdaten durch das Fahrzeug 5 und zur Verfügungstellung der Fahrzeugdaten im Smart Contract 9 für den Anbieter 6 zwischen Anbieter 6 und Fahr zeughersteller 11, Pfeil 14.
Eine Entlohnung kann auch direkt vom Fahrzeughersteller 11 über einen zweiten Statechannel 16 an das Fahrzeug 5 erfolgen. Der Applikationsdatenstrom vom Anbieter 6 zum Fahrzeugsystem 1 kann entweder durch den Anbieter 6 oder den Fahrer bzw. das Fahr zeugsystem 1 freigegeben werden. Generierte Fahrzeugdaten können vom Fahrzeugsystem 1 an den Anbieter 6 über den ersten Sta techannel 15 oder an den Fahrzeughersteller 11 über den zweiten Statechannel 16 gesendet werden. Die generierten Fahrzeugdaten werden beispielsweise vom Fahrzeugsystem 1 freigegeben.
FIG 3 zeigt eine weitere Ausführung der Erfindung als Block schema. Die Applikationsdaten werden als Multimediadaten von dem ersten Statechannel 15 vom Anbieter 6 an das Fahrzeug 5 gestreamt. Ferner baut das Fahrzeug 5 einen zweiten Statechannel 16 mit Counterfactual Instantiation zu dem Fahrzeughersteller 11 auf. Die Applikationsdaten können über den zweiten Statechannel 16 mit Counterfactual Instantiation off-chain abgerechnet werden. Wird die Applikation beendet, so wird die Entlohnung/Abrechnung in das verteilte System 8 mit Blockchain-Technologie gespeichert. Der Applikationsdatenstrom kann dabei entweder durch den Anbieter 6, den Fahrzeughersteller 11 oder das Fahrzeug 5 verschlüsselt werden .
FIG 4 zeigt ein erstes Anwendungsbeispiel der Erfindung. Ein Anbieter 6 möchte Werbung in Fahrzeugen 5 darstellen. Dazu generiert er in einem Schritt W1 eine Applikation und erstellt mit dem Source-Code der Applikation einen Hashwert. Ferner erstellt er in einem Schritt W2 einen Smart Contract 9 auf einem verteilten System 8. In dem Smart Contract 9 wird die Applikation als auch der Hashwert hinterlegt. Ferner hinterlegt der Anbieter 6 Erlaubnisparameter. Diese umfassen neben den spezifischen Fahrzeugkomponenten auf welchen die Applikation ausgeführt werden kann noch weitere Erlaubnisparameter. Ein weiterer Erlaubnisparameter ist beispielsweise, dass die Werbung nur dann geschaltet wird, wenn sich das Fahrzeug 5 in einer Still standsposition (beispielsweise im Stau oder an einer Ampel) befindet. Ein weiterer Erlaubnisparameter ist, das die Werbung nur geschaltet wird, wenn sich der Fahrer an einem vorgegebenen geografischen Ort, bzw. in der Nähe eines Supermarktes , befindet. Weitere Erlaubnisparameter können vom Fahrzeughersteller 11 beispielsweise bzgl. der Fahrzeugkomponenten 3 der jeweiligen Fahrzeuge 5 vorgegeben werden.
In einem Schritt W3 registriert sich das Fahrzeug 5 in dem Smart Contract 9. Dabei gibt er seine Registriernummer 10 an, anhand deren die verschiedenen Fahrzeugkomponenten 3 ermittelbar sind. Sind die Erlaubnisparameter hinsichtlich der Fahrzeugkompo nenten 3 erfüllt, so kann das Fahrzeug 5 die Applikation in die Ausführeinheit 2 laden. Ferner wird der Hashwert signiert und die Signatur in dem verteilten System 8 hinterlegt. Dadurch ist es möglich, festzustellen, welche Applikation auf welchem Fahrzeug 5 installiert wurde.
In einem Schritt W5 werden die Fahrzeugparameter und die weiteren Erlaubnisparameter abgeglichen. Der Abgleich kann dabei in einem ersten Statechannel 15, welcher vom Fahrzeug 5 zum Anbieter 6 geöffnet wird, vorgenommen werden, das heißt das Fahrzeug 5 gibt seine fahrzeugbezogenen Fahrzeugparameter frei. Stimmen diese überein (Stillstand des Fahrzeugs etc.), so kann die Werbung auf die Fahrzeugkomponente, hier den/der Anzeigebedienteil/en, gestreamt werden. Dazu werden über den ersten Statechannel 15 die Applikationsdaten übertragen .
Nach Beendigung der Übertragung durch den Fahrer oder durch einen negativen Abgleich, wird das Fahrzeug 5 durch den Statechannel 15, in einem Schritt W6, entlohnt und das Verfahren beendet. Als Entlohnung kann beispielsweise ein freies Parken oder eine Kryptowährung vorgesehen sein.
Der Anbieter 6 kann von dem Werbenden bezahlt werden.
FIG 5 zeigt ein zweites Anwendungsbeispiel der Erfindung als Blockschema. Hier möchte ein Fahrzeughersteller 11 ein Fahrzeug 5 mit einer neuen Funktion als Applikation ausstattet und benötigt hierfür noch Referenzdaten. Die Applikation zur Er hebung solcher Referenzdaten wird daher von einem weiteren Fahrzeughersteller 18 über einen Smart Contract 9 auf einem verteilten System 8 mit Blockchain-Technologie zur Verfügung 7 gestellt. Ferner wird noch ein Hashwert von der Applikation zur Verfügung gestellt. Beide Fahrzeughersteller 11, 18 können in diesem Fall Erlaubnisparameter 7,17 erstellen und diese im Smart Contract 9 speichern. Ein Fahrzeug 5 kann sich über eine Re gistriernummer 10 auf dem Smart Contract 9 registrieren. Zudem wird der Hashwert durch das Fahrzeug 5 signiert und diese Signatur in dem verteilten System 8 mit Blockchain-Technologie im Smart Contract 9 gespeichert, Pfeil 10. Der signierte Hashwert er möglicht es, festzustellen, welche Applikation auf welchem Fahrzeug 5 installiert wurde. Damit ist es möglich, nachzu vollziehen, welche Applikation in welchem Fahrzeug 5 installiert wurde. Die Applikation wird in das Fahrzeug 5 geladen, Pfeil 12 und ausgeführt, wenn die Erlaubnisparameter und die Fahr zeugparameter einen positiven Abgleich ergeben. Die Applika tionsdaten können über den zweiten Statechannel 16 direkt an den Fahrzeughersteller 11 gesendet werden. Die Entlohnung des Fahrzeugs 5 kann ebenfalls über den zweiten Statechannel 16 erfolgen. Ferner kann der zweite Fahrzeughersteller 18 von dem ersten Fahrzeughersteller 11 entlohnt werden.
Bezugs zeichenliste :
1 Fahrzeugsystem
2 Ausführungseinheit
3 Fahrzeugkomponenten
4 Kommunikationsschnittstelle
5 Fahrzeug
6 Anbieter
7 Erstellen
8 Verteiltes System mit Blockchain-Technologie
9 Smart Contract
10 Registriernummer
11 Fahrzeughersteller
12 Pfeil
13 Pfeil
14 Pfeil
15 Statechannel
16 Statechannel
17 Pfeil
18 Zweiter Fahrzeughersteller
S,W Verfahrensschritte

Claims

Patentansprüche
1. Verfahren zum Ausführen einer Applikation in einem Fahr zeugsystem (1), wobei durch das Fahrzeugsystem (1) eine Kom munikationsschnittstelle (4), zumindest eine Ausführeinheit (2) mit mindestens einer Fahrzeugkomponente (3) , und zumindest ein Fahrzeugparameter bereitgestellt werden,
wobei die Applikation mit einer kryptografischen Prüfsumme, insbesondere einem Hashwert, auf einem verteilten System (8), auf welchem eine Blockchain-Technologie oder eine Distribu- ted-Ledger-Technologie eingesetzt wird oder auf einer zentralen Rechnereinheit bereitgestellt wird, wobei die Applikation durch einen Anbieter (6) bereitgestellt wird, wobei die Applikation mindestens einen Erlaubnisparameter umfasst und wobei die kryptografische Prüfsumme als kryptografische Prüfsumme der Applikation durch den Anbieter (6) erstellt wird, mit den Schritten :
- Zugreifen auf die Applikation mittels der Kommunikations schnittstelle (4) durch das Fahrzeugsystem (1), wobei die Kommunikationsschnittstelle (4) zur bidirektionalen Kommuni kation mit der zentralen Rechnereinheit oder dem verteilten System (8) ausgestaltet ist,
- Abgleichen zwischen dem mindestens einen Erlaubnisparameter und den dazu korrespondierenden Fahrzeugparameter durch eine Vergleichseinheit ,
- Ausführen der Applikation durch die mindestens eine Fahr zeugkomponente (3) der Ausführeinheit (2) bei einem positiven Abgleich .
2. Verfahren zum Ausführen einer Applikation nach Anspruch 1, dadurch gekennzeichnet, dass ein Abgleichen zwischen dem mindestens einen Erlaubnisparameter und den dazu korrespon- dierenden Fahrzeugparameter durch die Vergleichseinheit in vorgegebenen Zeitabständen wiederholt wird.
3. Verfahren zum Ausführen einer Applikation nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Applikation durch den Fahrer gestartet oder automatisiert gestartet wird.
4. Verfahren zum Ausführen einer Applikation nach einem der vorhergehenden Ansprüche, weiter gekennzeichnet durch:
- ein Generieren von Fahrzeugdaten durch das Ausführen der Applikation durch die Ausführeinheit (2),
- ein Übermitteln der generierten Fahrzeugdaten an das ver teilte System (8) oder die zentrale Rechnereinheit, und
- ein Speichern der generierten Fahrzeugdaten in dem verteilten System (8) oder in der zentralen Rechnereinheit.
5. Verfahren zum Ausführen einer Applikation nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zu mindest die kryptografische Prüfsumme und/oder die Applikation mit einer Signatur durch das Fahrzeugsystem (1) signiert wird, wobei die Signatur mittels einer Signatursoftware erstellt wird.
6. Verfahren zum Ausführen einer Applikation nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Registriernummer (10) in dem Fahrzeugsystem (1) zur Identi fikation des Fahrzeugs (5) vorgesehen ist, wobei die Regist riernummer (10) zur Identifikation des Fahrzeugs (5) in dem verteilten System (8) oder in der zentralen Rechnereinheit gespeichert wird.
7. Verfahren zum Ausführen einer Applikation nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Datenbank-Prüfsumme in einer Datenbank bereitgestellt wird.
8. Verfahren zum Ausführen einer Applikation nach Anspruch 7, dadurch gekennzeichnet, dass die Dankbank-Prüfsumme durch die Kommunikationsschnittstelle (4) in das Fahrzeugsystem (1) übertragen wird, wobei die Kommunikationsschnittstelle (4) zumindest zur unidirektionalen Kommunikation mit der Datenbank zur Übertragung der Datenbank-Prüfsumme ausgebildet ist, wobei ein Ausführen der Applikation durch die zumindest eine Fahr zeugkomponente (3) der Ausführungseinheit (2) nur bei Über einstimmung zwischen der Datenbank-Prüfsumme und der Prüfsumme durchgeführt wird.
9. Verfahren zum Ausführen einer Applikation nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Applikation beim Ausführen Applikationsdaten über eine grafische Benutzeroberfläche ausgibt, wobei die mindestens eine Fahr zeugkomponente (3) die grafische Benutzeroberfläche umfasst.
10. Verfahren zum Ausführen einer Applikation nach Anspruch 9, dadurch gekennzeichnet, dass die Applikationsdaten als Li- vestream-Applikationsdaten gestreamt werden.
11. Verfahren zum Ausführen einer Applikation nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Applikation mit den Erlaubnisparametern in einem Smart Contract (9) bereitgestellt wird.
12. Verfahren zum Ausführen einer Applikation nach Anspruch 11, dadurch gekennzeichnet, dass zumindest die kryptografische Prüfsumme und/oder die Applikation mittels einer Signatur signiert wird, wobei die Signatur mittels einer Signatursoftware erstellt wird, wobei die Signatur über die Kommunikations schnittstelle (4) zur Speicherung dem Smart Contract (9) übermittelt wird.
13. Verfahren zum Ausführen einer Applikation nach Anspruch 11 oder 12, dadurch gekennzeichnet, dass ein Statechannel (15) vorgesehen ist, wobei zumindest die Applikation über den Statechannel (15) übertragen wird.
14. Verfahren zum Ausführen einer Applikation nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Applikation als ein ausführbares Computerprogramm ausgestaltet wird, wobei das Computerprogramm zur Ausführung in eine oder mehrere Fahrzeugkomponenten (3) der Ausführungseinheit (2) gespeichert wird.
15. Verfahren zum Ausführen einer Applikation nach Anspruch 14, dadurch gekennzeichnet, dass das Computerprogramm durch einen Schlüssel verschlüsselt wird.
16. Verfahren zum Ausführen einer Applikation nach einem der Ansprüche 10 bis 15, dadurch gekennzeichnet, dass eine Re gistriernummer (10) in dem Fahrzeugsystem (1) zur Identifikation des Fahrzeugs (5) vorgesehen ist, wobei die Registriernummer (10) zur Identifikation des Fahrzeugs (5) im Smart Contract (9) gespeichert wird.
17. Fahrzeugsystem (1), welches zur Durchführen eines Ver fahrens nach einem der Ansprüche 1 bis 16 konfiguriert ist, wobei das Verfahren zum Ausführen einer Applikation in einem Fahrzeug (5) ausgebildet ist, wobei die Applikation mit einer krypto- grafischen Prüfsumme, insbesondere einem Hashwert, auf einem verteilten System (8), auf welchem eine Blockchain-Technologie oder eine Distributed-Ledger-Technologie eingesetzt wird oder auf einer zentralen Rechnereinheit bereitgestellt ist, wobei die Applikation durch einen Anbieter (6) bereitgestellt ist, wobei die Applikation mindestens einen Erlaubnisparameter umfasst und wobei die kryptografische Prüfsumme als kryptografische Prüfsumme der Applikation durch den Anbieter (6) erstellt ist, das Fahrzeugsystem (1) aufweisend:
eine Kommunikationsschnittstelle (4), welche zur bidirektio nalen Kommunikation mit dem verteilten System (8) oder zur bidirektionalen Kommunikation mit der zentralen Rechnereinheit konfiguriert ist,
zumindest eine Ausführeinheit (2) mit mindestens einer Fahr zeugkomponente (3) ,
zumindest ein Fahrzeugparameter und
eine Vergleichseinheit, welche zum Abgleich zwischen den mindestens einen Erlaubnisparameter und den dazu korrespondieren Fahrzeugparameter ausgestaltet ist, wobei die Ausführungs einheit (2) mit der mindestens einen Fahrzeugkomponente (3) so konfiguriert ist, dass bei einem positiven Abgleich die Ap plikation durch die mindestens eine Fahrzeugkomponente (3) der Ausführungseinheit (2) ausführbar ist.
18. Fahrzeugsystem (1) nach Anspruch 17, dadurch gekenn zeichnet, dass die Erlaubnisparameter fahrzeugbezogene Er laubnisparameter und/oder situationsbezogene Erlaubnispara meter umfassen.
19. Fahrzeugsystem (1), wobei das Fahrzeugsystem (1) als Fahrerassistenzsystem ausgestaltet ist.
20. Computerprogramm, umfassend Befehle, die bewirken, dass das Fahrzeugsystem (1) nach einem der vorhergehenden Ansprüche 17 bis 19, das Verfahren nach einem der vorhergehenden Ansprüche 1 bis 16 ausführt.
21. Datenträgersignal, das das Computerprogramm nach Anspruch 20 überträgt.
PCT/EP2019/073909 2018-09-20 2019-09-06 Verfahren zum ausführen einer applikation in einem fahrzeug, fahrzeugsystem, computerprogramm und datenträgersignal WO2020058008A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018216036.8A DE102018216036A1 (de) 2018-09-20 2018-09-20 Verfahren zum Ausführen einer Applikation in einem Fahrzeug, Fahrzeugsystem, Computerprogramm und Datenträgersignal
DE102018216036.8 2018-09-20

Publications (1)

Publication Number Publication Date
WO2020058008A1 true WO2020058008A1 (de) 2020-03-26

Family

ID=67953756

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/073909 WO2020058008A1 (de) 2018-09-20 2019-09-06 Verfahren zum ausführen einer applikation in einem fahrzeug, fahrzeugsystem, computerprogramm und datenträgersignal

Country Status (2)

Country Link
DE (1) DE102018216036A1 (de)
WO (1) WO2020058008A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230112806A1 (en) * 2021-10-07 2023-04-13 Capital One Services, Llc Secure serverless computing framework

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19620885A1 (de) 1996-05-23 1997-11-27 Bayerische Motoren Werke Ag Verfahren zum Aktualisieren von Daten und/oder Parametern eines Steuergeräts in einem Fahrzeug
DE10037397A1 (de) 2000-08-01 2002-02-14 Daimler Chrysler Ag Verfahren zum Laden von Software
EP1276088A2 (de) 2001-07-14 2003-01-15 Robert Bosch Gmbh Verfahren und System zur automatischen Erfassung der Anzahl von Personen
DE102007040093A1 (de) * 2007-08-24 2009-02-26 Continental Automotive Gmbh Verfahren und System zum Installieren eines Softwaremoduls
DE102009018761A1 (de) 2009-04-27 2010-10-28 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Aktualisierung von Softwarekomponenten
DE102011100938A1 (de) * 2011-05-09 2012-11-15 Lear Corporation Gmbh Fahrzeuginformations- und/oder Unterhaltungssystem mit Genehmigungssystem
US20180018723A1 (en) * 2016-07-18 2018-01-18 Royal Bank Of Canada Distributed ledger platform for vehicle records

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19620885A1 (de) 1996-05-23 1997-11-27 Bayerische Motoren Werke Ag Verfahren zum Aktualisieren von Daten und/oder Parametern eines Steuergeräts in einem Fahrzeug
DE10037397A1 (de) 2000-08-01 2002-02-14 Daimler Chrysler Ag Verfahren zum Laden von Software
EP1276088A2 (de) 2001-07-14 2003-01-15 Robert Bosch Gmbh Verfahren und System zur automatischen Erfassung der Anzahl von Personen
DE102007040093A1 (de) * 2007-08-24 2009-02-26 Continental Automotive Gmbh Verfahren und System zum Installieren eines Softwaremoduls
DE102009018761A1 (de) 2009-04-27 2010-10-28 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Aktualisierung von Softwarekomponenten
DE102011100938A1 (de) * 2011-05-09 2012-11-15 Lear Corporation Gmbh Fahrzeuginformations- und/oder Unterhaltungssystem mit Genehmigungssystem
US20180018723A1 (en) * 2016-07-18 2018-01-18 Royal Bank Of Canada Distributed ledger platform for vehicle records

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230112806A1 (en) * 2021-10-07 2023-04-13 Capital One Services, Llc Secure serverless computing framework
US11962705B2 (en) * 2021-10-07 2024-04-16 Capital One Services, Llc Secure serverless computing framework

Also Published As

Publication number Publication date
DE102018216036A1 (de) 2020-03-26

Similar Documents

Publication Publication Date Title
DE102020106368A1 (de) Teilen von fahrzeugdaten mit interessierten parteien
DE102019120937A1 (de) Verfahren und vorrichtung zum bereitstellen von kartenaktualisierungen unter verwendung einer blockchainplattform
DE102017201789B4 (de) Verfahren zum Betrieb eines Kraftfahrzeugs und Kraftfahrzeug
DE112018003781T5 (de) Kontoverwaltungsvorrichtung, kontoverwaltungssystem, und fahrzeuggebundene informationsbereitstellungsvorrichtung
DE102018212238A1 (de) Kontosystem, anbieter-endgerät, benutzer-endgerät, und knoten
WO2014202362A1 (de) Verfahren zum bereitstellen von parkinformationen zu freien parkplätzen
WO2020120696A1 (de) Verfahren, vorrichtung und computerprogramm für ein fahrzeug
DE112013005761B4 (de) System und Verfahren zum Verwenden eines Autoradios zum Steuern der Lieferung von Premiuminhalt an ein Smartphone
DE102013003044A1 (de) Übertragen von Informationen über ein Anzeigesystem eines Fahrzeugs
DE102021123067A1 (de) Sicherer Transportmittel-Datenaustausch
EP3723322A2 (de) Verfahren zur authentifizierung eines fahrzeugs, authentifizierungseinheit, diensteinheit und fahrzeugexterne zentrale recheneinheit
WO2020058008A1 (de) Verfahren zum ausführen einer applikation in einem fahrzeug, fahrzeugsystem, computerprogramm und datenträgersignal
DE102018008730A1 (de) Verfahren und Vorrichtung zum Erheben von fahrzeugbasierten Datensätzen für vorgegebene Streckenabschnitte
DE102020111877A1 (de) Verbesserte verwendbarkeit und funktionalität von bordeigener hardware und software von fahrzeugen
DE112021003100T5 (de) Verfahren zum Verwalten der Verteilung eines zum Ankunftspunkt fahrenden Fahrzeug, dazu verwendeter Verwaltungsserver, und Aufzeichnungsmedium, auf dem Programm zum Ausführen des Verfahrens aufgezeichnet ist
EP2503518A1 (de) Verfahren zum Validieren einer Mauttransaktion
DE102020200230A1 (de) Mittel zur Verarbeitung von fahrzeugspezifischen Fahrzeugdaten
DE102023130687A1 (de) Systeme und verfahren für intelligente fahrzeugverhandlung und -zusammenarbeit
DE102018214001B4 (de) Verfahren zum Betreiben einer Ausgabeeinrichtung eines Kraftfahrzeugs, Kommunikationseinrichtung, Kraftfahrzeug, und Servervorrichtung zum Betreiben im Internet
DE102022001720B3 (de) Verfahren zur Anonymisierung von Fahrzeugdaten
WO2018166732A1 (de) System und verfahren zur sicheren fahrzeugkommunikation
WO2020030390A1 (de) Verfahren zur bereitstellung von dynamischen verkehrsinformationen, fahrzeug, computerprogramm und datenträgersignal
EP2325806A1 (de) Verfahren zum Erzeugen von Mauttransaktionen
WO2019243359A1 (de) System, verfahren zum betreiben eines systems, computerprogramm und speicherprogrammierbares computerprogramm
DE102015213602A1 (de) System für den Vertrieb, die Kontrolle sowie die Verteilung kontinuierlicher Datenströme von vernetzten Endgeräten und eine entsprechende Plattform

Legal Events

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

Ref document number: 19768742

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19768742

Country of ref document: EP

Kind code of ref document: A1