WO2013171122A2 - Funktional erweiterbares fahrzeugsteuergerät und verfahren zum ergänzen der funktionalität eines fahrzeugsteuergeräts - Google Patents

Funktional erweiterbares fahrzeugsteuergerät und verfahren zum ergänzen der funktionalität eines fahrzeugsteuergeräts Download PDF

Info

Publication number
WO2013171122A2
WO2013171122A2 PCT/EP2013/059663 EP2013059663W WO2013171122A2 WO 2013171122 A2 WO2013171122 A2 WO 2013171122A2 EP 2013059663 W EP2013059663 W EP 2013059663W WO 2013171122 A2 WO2013171122 A2 WO 2013171122A2
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle control
module
control unit
modules
memory
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/EP2013/059663
Other languages
English (en)
French (fr)
Other versions
WO2013171122A3 (de
Inventor
Olaf Krieger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Volkswagen AG
Original Assignee
Volkswagen AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Volkswagen AG filed Critical Volkswagen AG
Priority to CN201380024821.2A priority Critical patent/CN104272255B/zh
Priority to US14/400,565 priority patent/US9880927B2/en
Publication of WO2013171122A2 publication Critical patent/WO2013171122A2/de
Publication of WO2013171122A3 publication Critical patent/WO2013171122A3/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1433—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a module or a part of a module
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7201—Logical to physical mapping or translation of blocks or pages

Definitions

  • the invention relates to a vehicle control unit whose functionality can be subsequently changed, and to a method for supplementing the functionality of a vehicle control unit.
  • Modern vehicles particularly modern motor vehicles, include one or more vehicle control devices that provide individual functionality for controlling, controlling, or diagnosing vehicle components.
  • the range of functions provided by a control unit is defined here during the development of the respective control unit.
  • the functions often rely on signals or information from certain sensors or other controllers to provide their specific functionality.
  • a vehicle control unit for controlling a vehicle having sensors for determining an operating condition of the vehicle and the vehicle device having control actuators for controlling the vehicle based on the sensor signals which includes a single-chip microcomputer having a first memory storing a program for controlling the actuators, and a CPU, which performs the calculation of the program.
  • the program includes an application software program for controlling the vehicle equipment and an interface software program.
  • the CPU is configured to execute the application software program and the interface software program.
  • the single-chip microcomputer includes a second memory for storing data, such as the result of processing the application software.
  • the program stored in the first memory is configured so that the interface software program can be changed according to the vehicle type changes independently of the application software program, so that the Application software program can be used together for different vehicle types without modification and only changes of the interface software program from vehicle to vehicle are necessary.
  • US 2010/0179720 A1 is concerned with a system and method for performing maintenance and repair of a vehicle.
  • a system is described in which parts of a program code of a software are supplemented or replaced by patches, for example.
  • the invention is therefore based on the technical problem of providing improved control devices in which a functional extension or change after their completion and / or operation is possible and possible side effects are limited by the change in functionality, at least in terms of their effects. Likewise, an improved method for supplementing the functionalities of a control unit is needed.
  • the object is achieved by a device having the features of claim 1 and a method having the features of claim 7.
  • the invention is based on the idea to program the ECU functionalities in the production in one or more application modules, which provide the desired functionality at the time of construction.
  • another software application is integrated into the controller, which provides a runtime environment for executing program codes.
  • the application modules that provide the basic functionality at the time of construction of the controller, as well as the application module that provides the runtime environment, are implemented in the controller to be assigned static processor access times as well as static memory areas.
  • the extended functionality is thus provided by the program code of the supplementary module executed in the runtime environment.
  • a vehicle control unit which comprises: at least one processor, a memory coupled to the processor, wherein executable program codes of an operating system and a plurality of application modules that provide the functionalities of the control unit are stored in the memory on the processor and at least one communication interface to Data exchange with others Vehicle control devices or an external device, wherein the application modules are each statically associated with the program and data storage areas of the memory required for their respective execution and wherein the operating system is adapted to the individual application modules access to the execution of their program code to previously statically fixed periods of time to the processor permit, wherein one of the plurality of application modules is designed as an update module to receive and store in the memory via the at least one communication interface, a program code of one or more supplemental modules to effect an extension and / or change the functionality of the vehicle control device, wherein one of the plurality Application modules is designed as a runtime environment module, which provides a runtime environment to execute the program code of the one or more supplemental modules, and the update module is formed to store the program code of the
  • a method for supplementing the functionality of a vehicle control device as described above comprising the steps of: providing or generating a program code of a supplementary module which effects a new or changed functionality of the vehicle control device when executed, forming a communication link with the Updating module of the vehicle control unit via the at least one communication interface, transmitting the program code of the supplementary module to the vehicle control unit and storing the program code in a the program memory area assigned to the runtime environment module, so that the runtime environment module executes the program code of the supplementary module.
  • a significant advantage of the invention is that an introduced at a later time extension in the form of a supplementary module in their creation, the specific expression of the control unit or the control units on which or the supplementary module is to be executed, do not need to know. This applies above all to the processor derivative used, the number of processor cores and the memory layout of the controller.
  • the extension is therefore implemented in a platform-independent form as program code or script code of a supplementary module that is executed in the controller by the runtime environment.
  • it is customary to store parameters in a non-volatile memory area which influence the provided functionalities.
  • the memory comprises a nonvolatile area in which parameters for the application modules are stored or can be stored, wherein one of the application modules provides a functionality which allows readout and / or replacement of the parameters via a Communication via the at least one communication interface allows, and wherein parameters for supplementary modules in the form of key-value pairs are stored in the parameter memory.
  • a format in the form of a key-value pair is advantageous because a number of the parameters required for the individual supplementary modules and their format are not known in advance.
  • the key can be used to simply and reliably identify the respective required parameter and to find the corresponding associated parameter value.
  • the memory area in which the parameters are mapped, or at least the memory area in which the key parameter value pairs are stored, is preferably mirrored into the statically allocated memory area which is assigned to the runtime environment module.
  • the supplemental modules can access the parameter values without immediate access to memory areas at the operating system level of the controller.
  • the use of memory areas by multiple application modules carries the risk that unintended effects occur. While using statically allocated memory areas, it is possible to realize communication between different application modules or different program code strings by accessing a common memory area. However, this communication is only reliable if it is ensured that, for example, values written by one program code string are read out from the other program code string before the one program code string updates the values again. Since communication between the application modules and the supplementary modules should not be realized in this way, in order to avoid side effects which are not intended, it is provided in a preferred embodiment that the communication structure in the control unit is or are statically fixed at the time of manufacture of the vehicle control unit.
  • An advantage of the realization of an intermodule communication ie a communication between different application modules, via message queues is that a data exchange can take place asynchronously.
  • the data to be exchanged is stored by one application in a defined message queue and read out by another application from the message queue at another time. This can in turn store data in the same or a different message queue in order to transfer data back to the one process.
  • the application modules preferably also use static message queues for the intermodule communication.
  • the runtime environment module provides a message queue manager in its runtime environment, which provides static runtime environment message queues that are mapped to the static message queues of the operating systems and the supplementary modules enable communication with the other application modules and allow dynamic message queuing at runtime to allow communication between the supplementary modules.
  • the message queue manager of the runtime environment must thus also allow and manage dynamic message queues, since it is not known in advance which data exchange between the individual supplementary modules might be necessary.
  • a particularly simple implementation of a runtime environment module which is economical in terms of resource consumption, comprises a virtual machine in the form of a stack machine.
  • the program code of the supplementary modules must be implemented in such a way that the virtual machine can interpret it and convert it into machine instructions of the actually existing processor.
  • the concrete memory allocation is also made by the virtual machine in this implementation, so that in the implementation of the supplementary modules no absolute memory addresses are used.
  • it is achieved for the supplementary modules that they can be programmed independently of the actually existing hardware.
  • the knowledge is necessary via the individual functions and interfaces provided by the application modules, which the supplementary modules can access via communication via the provided message queues.
  • Metadata are added to the supplementary module, which at least comprise request information about resources required for execution, and the metadata prior to a transmission of the program code or with the program code is transmitted to the vehicle control unit and the update module, that module which allows installation of supplementary modules in the control unit, checks on the basis of the metadata whether the vehicle control unit fulfills the requirements regarding the required resources and, if so, the program data in the program data storage area of the Runtime environment module stores or otherwise, if the requirements for the required resources are not met, a transfer of the program data of the supplementary module aborts, rejects, discards or already done gte program data from the memory clears again.
  • the required resources of a supplementary module include in particular: required memory, required processor time, communication interfaces to other application or supplementary modules.
  • a further embodiment provides that the program code and the metadata of a supplementary module are protected by a cryptographic hash function known to the update module, so that inadvertent changes and concomitant inconsistencies between the description of the functionality in the metadata and the actual implementation in the program code can be detected by the update module. The update module can then remove the corrupt supplement module and / or prevent or cancel its installation.
  • the program code, the metadata and the value of the hash function are additionally signed by a digital signature, as known from the prior art. This allows the update module to verify that the add-on module was created by a trusted source and that no manipulation of the add-on module's code has occurred.
  • control units In vehicles, the control units are usually connected to each other via bus systems, in particular serial bus systems. Most widely used are so-called CAN bus systems and Flexray bus systems. These are different bus systems equipped with a standardized transmission protocol. While in CAN bus systems, the individual messages sent have an identifier that identifies their contents, the time available for a message transmission is subdivided into cycles on a Flexray bus system. In each cycle there is a period of time in which static time windows, so-called slots, are assigned to individual communication nodes. In addition, a cycle comprises a dynamic section in which the different communication users can prioritize transmit messages of variable length according to their associated identification.
  • the individual control devices are usually designed such that an application which controls the communication interface filters the messages arriving on the communication interface with regard to their identifier.
  • an application which controls the communication interface filters the messages arriving on the communication interface with regard to their identifier.
  • supplementary modules in order to extend the functionality of the supplementary modules to give the opportunity to send messages to other vehicle control units and thus to other application modules and / or supplementary modules in other vehicle control units or To evaluate messages from these, it is provided in a preferred embodiment that already in the production of the vehicle control unit one or more message IDs reserved for messages from supplementary modules that are used by the controller to send information from supplementary modules or information about them to convey.
  • the communication interface is a message-based interface and the individual vehicle control units are assigned communication identifiers and at least one communication identifier, preferably a group of communication identifiers, reserved for messages from and to supplementary modules of the vehicle control unit can be transmitted and received.
  • the communication identifiers can be used as message identifiers in the CAN bus.
  • the communication identifier can be used as ID.
  • Fig. 1 is a schematic representation of an integrated into a vehicle
  • a motor vehicle 1 with a plurality of therein control devices 1 1- 14 is shown schematically.
  • the control units 1 1 -14 are connected via a bus 15 communication technology.
  • a vehicle-external tester 16 is connected to the bus 15, via which diagnostic and maintenance work on the control units 1 1-14 of the motor vehicle 1 can be made. Of course, in normal driving mode, the tester 16 is not connected to the motor vehicle 1.
  • control units 1 1 -14 the total number can vary in the vehicles, one of the control units 1 1 is shown here enlarged by way of example.
  • the other controllers 12-14 are preferably structurally similar.
  • the control unit 1 which is provided so that its functionality can be subsequently changed and / or expanded, comprises a processor unit 21 and a memory 22 coupled thereto. Furthermore, the control unit 1 1 comprises a communication interface 25, which accesses the vehicle bus 15 allows. Furthermore, the control unit has via further interfaces 26, 27, which are connected to sensors 28, 29. Instead of the sensors 28, 29 and actuators, actuators or the like may be connected to the controller via interfaces. A number of the existing interfaces depend on the function or functions performed by the controller in the vehicle.
  • the memory 22 typically includes a program memory area 31 and a data memory area 32. These may be hardware different or equal, even embodied in the same memory module.
  • the program memory areas 31 must always be a non-volatile memory.
  • For the data storage is a prerequisite that this is suitable as a read and write memory.
  • flash memory or EEPROM memory may be used.
  • memory components which provide volatile memory as known to the person skilled in the art, can also be used as data memories.
  • a program code 40 of an operating system 41 is stored.
  • the operating system is statically associated with a data or working memory 42 required for its execution.
  • 22 memory areas for application modules in the example shown, for example, for h-application modules, reserved and statically assigned in the memory.
  • Each of the application modules 51-1 to 51-h includes program codes 52-1 to 52-h stored in the program memory 31 of the memory 22.
  • Each application module is also assigned an area of the data memory 53-1 to 53-h, which the corresponding application module requires as data and working memory for the provision of its functionality. Ensuring exactly the required amount of memory for each application module 51-1 to 51-h ensures that there will not be a resource bottleneck when all application modules are executed. Side effects such as race conditions around resources, e.g. Storage areas are excluded from the outset.
  • the operating system can also be regarded as a virtually equivalent application module, which performs the function of, in particular, distributing the computing time on the processor 21 between the individual application modules 51-1 to 51-h.
  • the individual application modules 51 -1 to 51 -h are statically assigned fixed access times to the processor 21. This can ensure that each application module 51-1 to 51-h receives the required processor time to perform its functionality. Between the individual application modules 51-1 to 51 -h, so-called intermodule communication can be performed very efficiently by using common Memory areas are realized. This is also possible in the case of static allocation by allocating identical memory areas which are used for intermodule communication to different application modules. Moreover, the application modules 51-1 to 51 -h may interact with each other by allowing function calls which is easily possible due to the fixed memory allocation by the different application modules 51-1 to 51-h. However, such a procedure has the disadvantage that the processor time assigned to an application is altogether extended when a function of another module is called.
  • This method of intermodule communication can only be used if the additional execution time at the time of development is known exactly and can be taken into account in the allocation of the required processor time.
  • intermodule communication is performed via statically provided so-called message queues. These are memory areas into which data to be exchanged are queued in the form of so-called messages. Other processes can then fetch and process the data stored there asynchronously and store their own results in the form of a new message in the same or another message queue (message queue).
  • message queues are memory areas into which data to be exchanged are queued in the form of so-called messages.
  • Other processes can then fetch and process the data stored there asynchronously and store their own results in the form of a new message in the same or another message queue (message queue).
  • messages queue message queue
  • Such inter-module communication can lead to an overflow of the message queue in unfavorable cases in which the messages are not fetched from the message queue on time, this impairs the sending, i. not posting the news, process not.
  • the sender and receiver each work with their own copy of the exchanged data, avoiding adverse interference by inconsistent shared access to the same memory.
  • This runtime environment module 61 is configured to interpret the program code 72-1 to 72-i, typically in the form of script code (SC), and to translate it into machine instructions of the existing processor, thereby executing the supplemental modules 71-1 to 71-i can.
  • a significant advantage of such a procedure is that the functionalities originally provided in the control unit 1 1, which are provided by the application modules 51 -1 to 51-h-1, are almost unaffected by execution of supplementary modules 71-1 to 71-i are.
  • Supplementary modules 71-1 through 71-i can not access memory areas of application modules 51-1 through 51-h-1, nor do they interfere with their processor time, which is statically assigned to them for execution.
  • the data memories 73-1 to 73-i respectively used by the individual supplementary modules 71-1 to 71-i are also assigned to the individual supplementary modules 71 -1 to 71 -i dynamically at the execution time of the respective modules. As a result, an improved resource consumption can be realized. Only memory that is statically assigned to the runtime environment module can be used for this.
  • the application modules 51-1 to 51 -h are designed such that they communicate with one another via static message queues (sMq j ) 91 -1 to 91 -m.
  • sMq j static message queues
  • a so-called message bridge 94 is implemented in the runtime environment of the runtime environment module 61, 51-h.
  • This provides accessibility of the supplementary modules 71-1 to 71 -i on static message queues 91 -1 to 91-m available by these in the data storage area 53-h of the runtime environment module 61, 51-h are displayed 92-1 to 92-m.
  • the supplementary modules 71-1 to 71 -i can generate and use dynamic message queues 93-1 to 93-n for communicating with each other.
  • both the processes of the application modules 51 -1 to 51-h and the supplemental modules 71 -1 to 71-i may define parameters that affect their execution and may be read out and / or changed by the external texter 16. While the parameters for the application modules are already set in terms of type and value range during the production of the control unit, only the memory areas which store the parameter value 101 -1 to 101 -h need to be defined for these parameters and assigned statically. These parameters are thus stored in a parameter memory 100 which is stored in the non-volatile memory area, which can also serve as a program memory area 31, of the memory 22. In the parameter memory 100, moreover, the parameters for the supplementary modules can be stored. These are preferably stored as key-value pairs (key value storage) 102-1 to 102-1.
  • a key-value pair each has a key which uniquely characterizes the parameter and additionally a value and optionally a type of the parameter.
  • the key makes it possible to find the corresponding parameter value even if the memory location where the key-value pair is stored is unknown, so that it can be used by the corresponding supplementary module 71 -1 to 71-i. Since access of the supplementary modules 71 -1 to 71-i to memory areas that are not statically assigned to the runtime environment module 61, 51-h is not permitted, the parameter value memory 100 is stored in the memory of the runtime environment module 61, preferably in the non-volatile memory area. displayed.
  • a copy 110 of the parameter value memory 100 in which the copied parameter values 1 1 1 -1 to 1 1 1 -k and the key-value pairs 1 12-1 to 1 12-1 are present as copies.
  • one of the supplemental modules 71-1 to 71-i may also instruct the runtime environment 61 to access the parameter memory 100 and provide values to the supplemental module 71-1 to 71-i.
  • one of the application modules 51-1 to 51 -h-1 is designed as a so-called update module 62.
  • This functionality is often provided by an application module that also provides Unified Diagnostic Services.
  • This application module 51-1, 62 provides functionality over the tester 16 may cause the program code 72-1 to 72-i of a supplementary module 71-1 to 71-i transmitted to the controller 11 to be installed in the non-volatile program memory 52-h of the runtime environment module 61, 51-h.
  • the supplementary modules 71-1 to 71 -i are each assigned meter information 74-1 to 74-i in which the required resources, for example in the form of required communication objects, memory requirements, processor power, etc., are indicated.
  • a metadata memory 95 exists in the control unit 11, in which the associated resources (for example still available memory 52h, 53h, unused processor time, available message queues) available in the control unit 11 are stored.
  • the update module 51 -1, 62 checks on the basis of the transmitted metadata 74-1 to 74-i of the supplementary module 71 -1 to 71-i, whether this executable in the control unit will be. If the adjustment is positive, the program code 72-1 to 72-i of the supplementary module 71 -1 to 71-i is installed in the program memory 52-h of the runtime environment module 61.
  • a download of the program code 72-1 to 72-i is aborted, rejected, or an already stored program code data is cleared by deleting the corresponding program code 72-1 to 72-i.
  • the metadata memory 95 is allocated to those resources, e.g. new message queues, supplemented, which provides the corresponding supplementary module 71 -1 to 71-i. The remaining unused resources are reduced in the same step.
  • the control unit described as well as the method for updating thus enable a simple adaptation of the functionality of a vehicle control unit 11 and at the same time ensure that the functionality already provided in the original application modules 51-1 to 51-h is not provided by the supplementary modules 71-1 to 71-i is impaired.
  • the application modules 51-1 to 51-h are already aligned in such a way that they provide the necessary communication objects (eg message queues) so that supplementary modules 71 -1 to 71-i can subsequently interact with them.
  • message identifiers are already reserved and provided for possible future supplement modules 71 -1 to 71 -i or a mechanism is provided via the supplementary modules 71 -1 to 71-i of a bus interface can tell which messages are needed by the corresponding supplement module 71-1 bisi for their function.
  • CPU Processor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)
  • Programmable Controllers (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)

Description

Beschreibung
Funktional erweiterbares Fahrzeugsteuergerät und Verfahren zum Ergänzen der Funktionalität eines Fahrzeugsteuergeräts
Die Erfindung betrifft ein Fahrzeugsteuergerät, dessen Funktionalität nachträglich verändert werden kann, sowie ein Verfahren zum Ergänzen der Funktionalität eines Fahrzeugsteuergeräts.
Moderne Fahrzeuge, insbesondere moderne Kraftfahrzeuge, umfassen ein oder mehrere Fahrzeugsteuergeräte, welche einzelne Funktionalitäten zum Regeln, Steuern oder zum Diagnostizieren von Fahrzeugkomponenten bereitstellen. Der von einem Steuergerät bereitgestellte Funktionsumfang wird hierbei bei der Entwicklung des jeweiligen Steuergeräts festgelegt. Hierbei sind die Funktionen häufig auf Signale oder Informationen von bestimmten Sensoren oder anderen Steuergeräten angewiesen, um ihre spezielle Funktionalität bereitzustellen. Häufig kommt es jedoch vor, dass im Laufe einer Serienfertigung neue Fahrzeugvarianten angeboten werden sollen, welche einen erweiterten Funktionsumfang aufweisen oder in welche von dem ursprünglichen Modell abweichende Steuergerätekombinationen und Modelle eingebaut werden sollen. In solchen Situationen ist es wünschenswert, ein bereits fertig entwickeltes Steuergerät anpassen zu können und keine komplette Neuentwicklung erforderlich zu machen.
Die EP 0 869 417 B1 beschäftigt sich mit diesem Problem. Dort ist eine Fahrzeugsteuerungseinheit zur Steuerung eines Fahrzeugs mit Sensoren zur Bestimmung eines Betriebszustands des Fahrzeugs und der Fahrzeugeinrichtung mit Steuerstellgliedern zur Steuerung des Fahrzeugs auf Basis der Sensorsignale beschrieben, welche einen Einchipmikrocomputer mit einem ersten Speicher, der ein Programm zur Steuerung der Stellglieder speichert, und eine CPU umfasst, die die Berechnung des Programms durchführt. Vorgesehen ist, dass das Programm ein Anwendungssoftwareprogramm zur Steuerung der Fahrzeugeinrichtung und ein Schnittstellensoftwareprogramm enthält. Die CPU ist ausgebildet, das Anwendungssoftwareprogramm und das Schnittstellensoftwareprogramm auszuführen. Der Einchipmikrocomputer umfasst einen zweiten Speicher zur Speicherung von Daten, beispielsweise dem Ergebnis der Verarbeitung der Anwendungssoftware. Das in dem ersten Speicher gespeicherte Programm ist so gestaltet, dass das Schnittstellensoftwareprogramm entsprechend der Fahrzeugtypänderungen unabhängig von dem Anwendungssoftwareprogramm geändert werden kann, sodass das Anwendungssoftwareprogramm gemeinsam für verschiedene Fahrzeugtypen ohne Änderung genutzt werden kann und lediglich Änderungen des Schnittstellensoftwareprogramms von Fahrzeug zu Fahrzeug notwendig sind.
In der DE 10 2009 018 761 A1 ist ein Verfahren zum Aktualisieren zumindest einer Softwarekomponente eines Kraftfahrzeugs beschrieben, bei der ein Ersetzen von einer Softwarekomponente nur unter Mitwirkung des Fahrers möglich ist.
Auch die US 2010/0179720 A1 befasst sich mit einem System und einem Verfahren zum Ausführen von Wartung und Reparatur eines Fahrzeugs. Beschrieben ist ein System, bei dem Teile eines Programmcodes einer Software beispielsweise durch Patches ergänzt oder ersetzt werden.
In der DE 10 2008 036 71 1 A1 ist vorgeschlagen, softwarebasierte Fahrzeugfunktionen eines Kraftfahrzeugs unter Anwendung einer Ersetzungs-, Erweiterungs- und/oder Freischaltungssoftware vorzunehmen, wobei eine bereits vorhandene fahrzeugspezifische Software durch die Ersetzungs-, Erweiterungs- und/oder Freischaltungssoftware zumindest teilweise ersetzt, erweitert bzw. freigeschaltet wird. Die Ersetzungs-, Erweiterungs- und/oder Freischaltungssoftware wird mittels einer in das Kraftfahrzeug integrierten Einrichtung über eine Onlineverbindung von einem anbieterseitigen Server heruntergeladen.
Alle bekannten Verfahren gehen davon aus, dass zumindest ein Teil des bestehenden Programmcodes ersetzt oder modifiziert wird. Solche Änderungen sind jedoch mit hohen Risiken verknüpft, da Nebeneffekte solcher Änderungen auf andere Softwarebestandteile des Steuergeräts sich nur begrenzt abschätzen lassen. Daher ist ein Aufwand hinsichtlich der Verifikation und Absicherung solcher Softwareänderungen enorm hoch und vergleichbar mit dem Aufwand zur Absicherung einer kompletten Softwareneuentwicklung.
Der Erfindung liegt somit das technische Problem zugrunde, verbesserte Steuergeräte zu schaffen, bei denen eine Funktionserweiterung oder Änderung nach deren Fertigstellung und/oder im Betrieb möglich ist und mögliche Nebeneffekte durch die Änderung der Funktionalität zumindest hinsichtlich ihren Auswirkungen begrenzt sind. Ebenso wird ein verbessertes Verfahren zum Ergänzen der Funktionalitäten eines Steuergeräts benötigt. Die Aufgabe wird erfindungsgemäß durch eine Vorrichtung mit den Merkmalen des Patentanspruchs 1 sowie ein Verfahren mit den Merkmalen des Patentanspruchs 7 gelöst. Vorteilhafte Ausführungsformen der Erfindung ergeben sich aus den Unteransprüchen.
Der Erfindung liegt die Idee zugrunde, die Steuergerätefunktionalitäten bei der Herstellung in einem oder mehreren Anwendungsmodulen zu programmieren, welche die zum Zeitpunkt der Konstruktion gewünschten Funktionalitäten bereitstellen. Zusätzlich wird eine weitere Softwareanwendung in das Steuergerät integriert, welche eine Laufzeitumgebung zum Ausführen von Programmcodes bereitstellt. Die Anwendungsmodule, welche die Basisfunktionalität zum Zeitpunkt der Konstruktion des Steuergeräts bereitstellen, sowie dasjenige Anwendungsmodul, welches die Laufzeitumgebung bereitstellt, werden in dem Steuergerät so realisiert, dass diesen jeweils statische Prozessorzugriffszeiten als auch statische Speicherbereiche zugewiesen sind. Zu der Basisfunktionalität des Steuergeräts, die in einem der Anwendungsmodule realisiert ist, gehört es, dass es über eine Kommunikationsschnittstelle des Fahrzeugsteuergeräts möglich ist, ein Programmcode eines Ergänzungsmoduls zu dem Fahrzeugsteuergerät zu übertragen und eine Speicherung des Programmcodes des Ergänzungsmoduls in einem Programmspeicherbereich des Laufzeitumgebungsmoduls zu erreichen. Die erweiterte Funktionalität wird somit von dem in der Laufzeitumgebung ausgeführten Programmcode des Ergänzungsmoduls bereitgestellt. Darüber, dass die dem Laufzeitumgebungsmodul und den anderen Anwendungsmodulen zugewiesenen Prozessorzeiten von vornherein festgelegt sind, ist sichergestellt, dass die bei der Herstellung des Steuergeräts realisierten Funktionen, welche in den Anwendungsmodulen ausgeführt sind, jeweils eine ausreichende Prozessorzugriffszeit erhalten, um ihre Funktionen bereitzustellen. Darüber hinaus ist durch eine statische Trennung der Speicherbereiche eine negative Beeinflussung eines der Anwendungsmodule aufgrund nicht ausreichend vorhandenen Speichers oder aufgrund eines Überschreibens von Speicherbereichen ausgeschlossen. Eine Funktionsbeeinträchtigung durch die Ergänzungsmodule ist somit nicht zu befürchten. Lediglich die in der Laufzeitumgebung ausgeführten Programmcodes unterschiedlicher Ergänzungsmodule können einander in dieser Hinsicht nachteilig beeinflussen. Nebeneffekte sind somit ausschließlich auf die Ergänzungsmodule beschränkt.
Insbesondere wird somit ein Fahrzeugsteuergerät vorgeschlagen, welches umfasst: mindestens einen Prozessor, einen mit dem Prozessor gekoppelten Speicher, wobei in dem Speicher auf dem Prozessor ausführbare Programmcodes eines Betriebssystems und mehrerer Anwendungsmodule, die die Funktionalitäten des Steuergeräts bereitstellen, gespeichert sind sowie mindestens eine Kommunikationsschnittstelle zum Datenaustausch mit anderen Fahrzeugsteuergeräten oder einer externen Einrichtung, wobei den Anwendungsmodulen jeweils die für ihre jeweilige Ausführung benötigten Programm- und Datenspeicherbereiche des Speichers statisch zugeordnet sind und wobei das Betriebssystems ausgebildet ist, den einzelnen Anwendungsmodulen einen Zugriff zur Ausführung ihres Programmcodes zu vorher statisch festgelegten Zeitabschnitten auf den Prozessor zu gestatten, wobei eines der mehreren Anwendungsmodule als Updatemodul ausgebildet ist, um über die mindestens eine Kommunikationsschnittstelle einen Programmcode eines oder mehrerer Ergänzungsmodule zu empfangen und in dem Speicher abzulegen, um eine Erweiterung und/oder Änderung der Funktionalität des Fahrzeugsteuergeräts zu bewirken, wobei eines der mehreren Anwendungsmodule als Laufzeitumgebungsmodul ausgebildet ist, welches eine Laufzeitumgebung bereitstellt, um den Programmcode des einen oder der mehreren Ergänzungsmodule auszuführen, und das Updatemodul ausgebildet ist, den Programmcode des oder der Ergänzungsmodule in dem dem Laufzeitumgebungsmodul zugeordneten Programmspeicherbereiche abzulegen, wobei das Laufzeitumgebungsmodul ausgebildet ist, den ihm zugewiesenen Datenspeicherbereich sowie die ihm zur Verfügung stehende Prozessorzugriffszeit dynamisch zur Laufzeit aufzuteilen, um den Programmcode des einen oder der mehreren Ergänzungsmodule auszuführen.
Ferner wird ein Verfahren zum Ergänzen der Funktionalität eines Fahrzeugsteuergeräts, wie es oben beschrieben ist, geschaffen, welches die Schritte umfasst: Bereitstellen oder Erzeugen eines Programmcodes eines Ergänzungsmoduls, welches eine neue oder veränderte Funktionalität des Fahrzeugsteuergeräts bei dessen Ausführung bewirkt, Ausbilden einer Kommunikationsverbindung mit dem Updatemodul des Fahrzeugsteuergeräts über die mindestens eine Kommunikationsschnittstelle, Übertragen des Programmcodes des Ergänzungsmoduls zu dem Fahrzeugsteuergerät und Speichern des Programmcodes in einem dem Laufzeitumgebungsmodul zugewiesenen Programmspeicherbereich, sodass das Laufzeitumgebungsmodul den Programmcode des Ergänzungsmoduls ausführt.
Ein wesentlicher Vorteil der Erfindung besteht darin, dass eine zu einem späteren Zeitpunkt eingebrachte Erweiterung in Form eines Ergänzungsmoduls bei ihrer Erstellung die konkrete Ausprägung des Steuergerätes oder der Steuergeräte, auf dem oder denen das Ergänzungsmodul ausgeführt werden soll, nicht kennen muss. Dies betrifft vor allem das verwendete Prozessorderivat, die Anzahl der Prozessorkerne sowie das Speicherlayout des Steuergeräts. Die Erweiterung wird deshalb in einer plattformunabhängigen Form als Programmcode oder Skriptcode eines Ergänzungsmoduls implementiert, der im Steuergerät durch die Laufzeitumgebung ausgeführt wird. Um die in einem Steuergerät realisierten Funktionen an ein spezielles Fahrzeug oder an spezielle Fahrzeugsteuergerätekombinationen anpassen zu können, ist es üblich, in einem nicht flüchtigen Speicherbereich Parameter abzulegen, welche die bereitgestellten Funktionalitäten beeinflussen.
Bei einer bevorzugten Ausführungsform der Erfindung ist somit vorgesehen, dass der Speicher einen nicht flüchtigen Bereich umfasst, in dem Parameter für die Anwendungsmodule abgelegt sind oder ablegbar sind, wobei eines der Anwendungsmodule eine Funktionalität bereitstellt, welche ein Auslesen und/oder Ersetzen der Parameter über eine Kommunikation über die mindestens eine Kommunikationsschnittstelle gestattet, und wobei Parameter für Ergänzungsmodule in Form von Schlüssel-Wert-Paaren in dem Parameterspeicher abgelegt werden. Eine Verwendung eines Formats in Form eines Schlüssel-Wert-Paares ist deshalb vorteilhaft, da eine Anzahl der für die einzelnen Ergänzungsmodule benötigten Parameter und deren Format im Voraus nicht bekannt ist. Über den Schlüssel kann jedoch der jeweilige benötigte Parameter einfach und zuverlässig identifiziert und der entsprechende zugehörige Parameterwert aufgefunden werden. Der Speicherbereich, in dem die Parameter abgebildet sind, oder zumindest der Speicherbereich, in dem die Schlüsselparameterwertpaare abgelegt sind, wird vorzugsweise in den statisch zugewiesenen Speicherbereich gespiegelt, der dem Laufzeitumgebungsmodul zugeordnet ist. Somit können die Ergänzungsmodule auf die Parameterwerte zugreifen, ohne dass unmittelbare Zugriffe auf Speicherbereiche auf der Betriebssystemebene des Steuergeräts stattfinden.
Grundsätzlich birgt die Verwendung von Speicherbereichen durch mehrere Anwendungsmodule die Gefahr, dass unbeabsichtigte Effekte auftreten. Zwar ist es bei der Verwendung von statisch zugewiesenen Speicherbereichen möglich, eine Kommunikation zwischen unterschiedlichen Anwendungsmodulen oder unterschiedlichen Programmcodesträngen dadurch zu realisieren, dass diese auf einen gemeinsamen Speicherbereich zugreifen. Diese Kommunikation ist jedoch nur dann zuverlässig, wenn gewährleistet ist, dass beispielsweise von einem Programmcodestrang geschriebene Werte von dem anderen Programmcodestrang ausgelesen werden, bevor der eine Programmcodestrang die Werte erneut aktualisiert. Da eine Kommunikation zwischen den Anwendungsmodulen und den Ergänzungsmodulen nicht auf diese Weise realisiert werden soll, um Nebeneffekte, welche nicht beabsichtigt sind, zu vermeiden, ist bei einer bevorzugten Ausführungsform vorgesehen, dass die Kommunikationsstruktur im Steuergerät statisch zur Herstellungszeit des Fahrzeugsteuergeräts festgelegt ist oder sind, und diese so genannte Message-Queues umfasst, über die zumindest das Laufzeitumgebungsmodul mit den übrigen Anwendungsmodulen Daten austauschen kann. Bereits zum Zeitpunkt der Herstellung des Fahrzeugsteuergeräts werden die Schnittstellen und Funktionen bzw. Funktionalitäten festgelegt, welche möglicherweise später zugefügte Ergänzungsmodule nutzen können sollen. Für den Datenaustausch, welcher erforderlich ist, um beispielsweise Funktionen aufzurufen oder auf bereitgestellte Schnittstellen zuzugreifen, werden daher statische Message-Queues auf Betriebssystemebene bereitgestellt, welche eine spätere Anbindung der Ergänzungsmodule an die Anwendungsmodule ermöglicht. Ein Vorteil der Realisierung einer Zwischenmodulkommunikation, d.h. einer Kommunikation zwischen unterschiedlichen Anwendungsmodulen, über Message-Queues liegt darin, dass ein Datenaustausch asynchron erfolgen kann. Die auszutauschenden Daten werden von der einen Anwendung in eine definierte Message-Queue abgelegt und zu einem anderen Zeitpunkt von einer anderen Anwendung aus der Message-Queue ausgelesen. Diese kann dann wiederum Daten in dieselbe oder eine andere Message-Queue ablegen, um Daten zu dem einen Prozess zurück zu übertragen. Vorzugsweise nutzen auch die Anwendungsmodule statische Message- Queues für die Zwischenmodulkommunikation.
Um auch eine Kommunikation zwischen den unterschiedlichen Ergänzungsmodulen zu ermöglichen, ist es vorteilhaft, wenn das Laufzeitumgebungsmodul in seiner Laufzeitumgebung einen Message-Queuemanager bereitgestellt, der statische Laufzeitumgebungs-Message- Queues bereitstellt, die auf die statischen Message-Queues der Betriebssysteme abgebildet werden und den Ergänzungsmodulen hierüber eine Kommunikation mit den übrigen Anwendungsmodulen ermöglichen, und die eine Ausbildung dynamischer Message-Queues zur Laufzeit gestattet, um eine Kommunikation zwischen den Ergänzungsmodulen zu ermöglichen. Der Message-Queuemanager der Laufzeitumgebung muss somit auch dynamische Message- Queues zulassen und verwalten, da im Vorfeld nicht bekannt ist, welcher Datenaustausch zwischen den einzelnen Ergänzungsmodulen notwendig sein könnte.
Eine besonders einfache und hinsichtlich eines Ressourcenverbrauchs sparsame Umsetzung eines Laufzeitumgebungsmoduls umfasst eine virtuelle Maschine in Form einer Stack- Maschine. Der Programmcode der Ergänzungsmodule muss dafür so implementiert sein, dass die virtuelle Maschine diesen interpretieren und in Maschinenbefehle des tatsächlich vorhandenen Prozessors überführen kann. Die konkrete Speicherallokation wird bei dieser Umsetzung ebenfalls durch die virtuelle Maschine vorgenommen, so dass bei der Implementierung der Ergänzungsmodule keine absoluten Speicheradressen verwendet werden. Somit wird für die Ergänzungsmodule erreicht, dass diese unabhängig von der tatsächlich vorhandenen Hardware programmiert werden können. Notwendig sind jedoch die Kenntnisse über die einzelnen von den Anwendungsmodulen bereitgestellten Funktionen und Schnittstellen, auf die die Ergänzungsmodule über eine Kommunikation über die bereitgestellten Message-Queues zugreifen können.
Um sicherzustellen, dass ein Ergänzungsmodul auf einem Steuergerät auch tatsächlich ausführbar ist, ist bei einer Ausführungsform vorgesehen, dass dem Ergänzungsmodul Metadaten zugefügt werden, welche zumindest Anforderungsinformationen über zur Ausführung benötigte Ressourcen umfassen, und die Metadaten vor einer Übertragung des Programmcodes oder mit dem Programmcode zu dem Fahrzeugsteuergerät übertragen werden und das Updatemodul, jenes Modul, welches eine Installation von Ergänzungsmodulen in dem Steuergerät ermöglicht, anhand der Metadaten überprüft, ob das Fahrzeugsteuergerät die Anforderungen hinsichtlich der benötigten Ressourcen erfüllt und, wenn dies der Fall ist, die Programmdaten in dem Programmdatenspeicherbereich des Laufzeitumgebungsmoduls ablegt oder andernfalls, wenn die Anforderungen hinsichtlich der benötigten Ressourcen nicht erfüllt sind, eine Übertragung der Programmdaten des Ergänzungsmoduls abbricht, abweist, verwirft oder bereits abgelegte Programmdaten aus dem Speicher wieder löscht. Zu den benötigten Ressourcen eines Ergänzungsmoduls gehören vor allem: Benötigter Speicher, benötigte Prozessorzeit, Kommunikationsschnittstellen zu anderen Anwendungs- oder Ergänzungsmodulen. Durch die Überprüfung der Metadaten kann sichergestellt werden, dass auf einem Steuergerät nicht fälschlicherweise Programmdaten eines Ergänzungsmoduls abgelegt und zur Ausführung gebracht werden, welche dort bei der Ausführung Fehler verursachen. Dieses könnte möglicherweise andere in der Laufzeitumgebung ausgeführte Ergänzungsmodule ebenfalls an einer korrekten Ausführung hindern. Ein bevorzugtes Verfahren zum Ändern oder Ergänzen der Funktionalität eines Fahrzeugsteuergeräts sieht somit eine solche Überprüfung der Metadaten oder, verallgemeinert ausgedrückt, eine Ressourcenprüfung vor.
Eine weitere Ausführungsform sieht vor, dass der Programmcode sowie die Metadaten eines Ergänzungsmoduls durch eine kryptographische Hashfunktion, die dem Updatemodul bekannt ist, gesichert werden, so dass versehentliche Veränderungen und damit einhergehende Inkonsistenzen zwischen der Beschreibung der Funktionalität in den Metadaten und der tatsächlichen Umsetzung im Programmcode vom Updatemodul erkannt werden kann. Das Updatemodul kann das korrupte Ergänzungsmodul dann wieder entfernen und/oder dessen Installation verhindern oder abbrechen. Eine weitere Ausführungsform sieht vor, dass der Programmcode, die Metadaten sowie der Wert der Hashfunktion zusätzlich durch eine digitale Signatur, wie sie aus dem Stand der Technik bekannt ist, signiert werden. Dadurch kann das Updatemodul überprüfen, ob das Ergänzungsmodul von einer vertrauenswürdigen Quelle erstellt wurde und dass keine Manipulation des Programmcodes des Ergänzungsmoduls stattgefunden hat.
Um die Funktionen eines Fahrzeugsteuergeräts zu erweitern, ist in manchen Fällen jedoch nicht nur eine Kommunikation mit Anwendungsmodulen des eigenen Steuergeräts notwendig, sondern auch eine Kommunikation mit Anwendungsmodulen anderer Steuergeräte und/oder eine Kommunikation mit anderen Ergänzungsmodulen auf anderen Fahrzeugsteuergeräten des Fahrzeugs von Vorteil.
In Fahrzeugen werden die Steuergeräte in der Regel über Bussysteme, insbesondere serielle Bussysteme, miteinander verbunden. Am weitesten verbreitet sind so genannte CAN- Bussysteme und Flexray-Bussysteme. Dies sind unterschiedliche mit einem genormten Übertragungsprotokoll ausgestattete Bussysteme. Während bei CAN-Bussystemen die einzelnen versandten Nachrichten eine Kennung aufweisen, die deren Inhalt kennzeichnet, wird auf einem Flexray-Bussystem die für eine Nachrichtenübertragung zur Verfügung stehende Zeit in Zyklen unterteilt. In jedem Zyklus existiert ein Zeitabschnitt, in dem statisch Zeitfenster, so genannte Slots, einzelnen Kommunikationsknoten zugewiesen sind. Ein Zyklus umfasst darüber hinaus einen dynamischen Abschnitt, in dem die unterschiedlichen Kommunikationsteilnehmer priorisiert nach ihrer ihnen zugeordneten Identifikation Nachrichten variabler Länge übertragen können.
Ferner sind die einzelnen Steuergeräte in der Regel so ausgelegt, dass eine Anwendung, welche die Kommunikationsschnittstelle steuert, die auf der Kommunikationsschnittstelle eingehenden Nachrichten hinsichtlich ihrer Kennung filtert. So werden nur die Nachrichten, welche Informationen enthalten, die eines der Anwendungsmodule des Fahrzeugsteuergeräts auch tatsächlich auswertet, diesen Anwendungen zu ihrer Verarbeitung zugeführt. Andere Nachrichten werden bereits beim Eingang gefiltert und verworfen. Hierdurch kann die Speicherkapazität, welche zum Zwischenspeichern der Nachrichten benötigt wird, und ein Verarbeitungsaufwand der einzelnen Anwendungsmodule reduziert werden.
Um jedoch bei einer Erweiterung der Funktionalität den Ergänzungsmodulen die Möglichkeit zu geben, Nachrichten an andere Fahrzeugsteuergeräte und somit an andere Anwendungsmodule und/oder Ergänzungsmodule in anderen Fahrzeugsteuergeräten zu versenden oder Nachrichten von diesen auszuwerten, ist es bei einer bevorzugten Ausführungsform vorgesehen, dass bereits bei der Herstellung des Fahrzeugsteuergeräts eine oder mehrere Nachrichtenkennungen für Nachrichten von Ergänzungsmodulen reserviert werden, die von dem Steuergerät genutzt werden, um Informationen von Ergänzungsmodulen zu versenden bzw. um Informationen zu diesen zu übermitteln.
Bei einer Ausführungsform ist vorgesehen, dass die Kommunikationsschnittstelle eine nachrichtenbasierte Schnittstelle ist und den einzelnen Fahrzeugsteuergeräten Kommunikationskennungen zugeordnet sind und mindestens eine Kommunikationskennung, vorzugsweise eine Gruppe von Kommunikationskennungen, dafür reserviert werden, dass Nachrichten von und zu Ergänzungsmodulen des Fahrzeugsteuergeräts übermittelt und empfangen werden können. Die Kommunikationskennungen können im CAN-Bus als Nachrichtenkennungen verwendet werden. Bei Flexray-Bussystemen kann die Kommunikationskennung als ID verwendet werden.
Nachfolgend wird die Erfindung unter Bezugnahme auf eine Zeichnung näher erläutert. Hierbei zeigt:
Fig. 1 eine schematische Darstellung eines in ein Fahrzeug integrierten
Fahrzeugsteuergeräts.
In Fig. 1 ist schematisch ein Kraftfahrzeug 1 mit mehreren darin befindlichen Steuergeräten 1 1- 14 schematisch dargestellt. Die Steuergeräte 1 1 -14 sind über einen Bus 15 kommunikationstechnisch miteinander verbunden. Ferner ist mit dem Bus 15 ein fahrzeugexterner Tester 16 verbunden, über den Diagnose- und Wartungsarbeiten an den Steuergeräten 1 1-14 des Kraftfahrzeugs 1 vorgenommen werden können. Im normalen Fahrbetrieb ist der Tester 16 selbstverständlich nicht mit dem Kraftfahrzeug 1 verbunden.
Von den Steuergeräten 1 1 -14, deren Gesamtanzahl in den Fahrzeugen variieren kann, ist hier eines der Steuergeräte 1 1 exemplarisch vergrößert dargestellt. Die anderen Steuergeräte 12-14 sind vorzugsweise strukturell ähnlich aufgebaut.
Das Steuergerät 1 1 , welches dafür vorgesehen ist, dass dessen Funktionalität nachträglich verändert und/oder erweitert werden kann, umfasst eine Prozessoreinheit 21 und einen hiermit gekoppelten Speicher 22. Ferner umfasst das Steuergerät 1 1 eine Kommunikationsschnittstelle 25, welche einen Zugriff auf den Fahrzeugbus 15 ermöglicht. Ferner verfügt das Steuergerät über weitere Schnittstellen 26, 27, die mit Sensoren 28, 29 verbunden sind. Anstelle der Sensoren 28, 29 können auch Aktoren, Stellglieder oder Ähnliches mit dem Steuergerät über Schnittstellen verbunden sein. Eine Anzahl der vorhandenen Schnittstellen ist abhängig von der Funktion oder den Funktionen, die das Steuergerät in dem Fahrzeug ausführt.
Der Speicher 22 umfasst in der Regel einen Programmspeicherbereich 31 und einen Datenspeicherbereich 32. Diese können hardwaretechnisch unterschiedlich oder gleich, sogar in demselben Speichermodul ausgeführt sein. Der Programmspeicherbereiche 31 muss in jedem Falle ein nicht flüchtiger Speicher sein. Für den Datenspeicher ist Voraussetzung, dass dieser als Lese- und Schreibspeicher geeignet ist. Zur Anwendung kann beispielsweise Flash- Speicher oder EEPROM-Speicher kommen. Als Datenspeicher können jedoch auch Speicherbausteine, welche flüchtige Speicher bereitstellen, wie sie dem Fachmann bekannt sind, verwendet werden.
In dem Speicher 22 ist ein Programmcode 40 eines Betriebssystems 41 abgelegt. Dem Betriebssystem ist statisch ein für dessen Ausführung benötigter Daten- oder Arbeitspeicher 42 zugeordnet. Daneben sind in dem Speicher 22 Speicherbereiche für Anwendungsmodule, im dargestellten Beispiel beispielsweise für h-Anwendungsmodule, reserviert und statisch zugewiesen. Jedes der Anwendungsmodule 51-1 bis 51-h umfasst Programmcodes 52-1 bis 52-h, welcher in dem Programmspeicher 31 des Speichers 22 abgelegt ist. Jedem Anwendungsmodul ist darüber hinaus ebenfalls ein Bereich des Datenspeichers 53-1 bis 53-h zugewiesen, den das entsprechende Anwendungsmodul als Daten- und Arbeitsspeicher zur Erbringung seiner Funktionalität benötigt. Dadurch, dass jedem Anwendungsmodul 51-1 bis 51-h genau die benötigte Menge an Speicher zur Verfügung gestellt wird, wird sichergestellt, dass es nicht zu einem Ressourcen-Engpass kommt, wenn alle Anwendungsmodule ausgeführt werden. Seiteneffekte wie Wettlaufbedingungen um Ressourcen, z.B. Speicherbereiche, sind von vornherein ausgeschlossen. Das Betriebssystem kann bei einer solchen Ausführungsform auch als ein nahezu gleichwertiges Anwendungsmodul betrachtet werden, welches die Funktion übernimmt, insbesondere die Rechenzeit auf dem Prozessor 21 zwischen den einzelnen Anwendungsmodulen 51-1 bis 51-h zu verteilen.
Den einzelnen Anwendungsmodulen 51 -1 bis 51 -h sind statisch feste Zugriffszeiten auf den Prozessor 21 zugewiesen. Hierdurch kann sichergestellt werden, dass jedes Anwendungsmodul 51-1 bis 51-h die benötigte Prozessorzeit erhält, um seine Funktionalität auszuführen. Zwischen den einzelnen Anwendungsmodulen 51-1 bis 51 -h kann eine so genannte Zwischenmodulkommunikation sehr performant durch die Nutzung gemeinsamer Speicherbereiche realisiert werden. Dieses ist auch bei statischer Zuweisung möglich, indem unterschiedlichen Anwendungsmodulen gleiche Speicherbereiche, welche zur Zwischenmodulkommunikation genutzt werden, zugewiesen werden. Darüber hinaus können die Anwendungsmodule 51 -1 bis 51 -h miteinander in Wechselwirkung treten, indem Funktionsaufrufe zugelassen werden, welches aufgrund der festen Speicherzuweisung durch die unterschiedlichen Anwendungsmodule 51-1 bis 51-h auf einfache Weise möglich ist. Ein solches Vorgehen weist jedoch den Nachteil auf, dass die einer Anwendung zugewiesene Prozessorzeit bei Aufruf einer Funktion eines anderen Moduls insgesamt verlängert wird. Hierdurch kann es dazu kommen, dass eine Funktion des einen Anwendungsmoduls nicht "rechtzeitig fertig" wird, wenn diese eine Funktion eines anderen Anwendungsmoduls aufruft. Diese Methode der Zwischenmodulkommunikation kann nur verwendet werden, wenn die zusätzliche Ausführungszeit zum Zeitpunkt der Entwicklung genau bekannt ist und diese bei der Zuteilung der benötigten Prozessorzeit berücksichtigt werden kann.
Bevorzugt wird jedoch eine Zwischenmodulkommunikation über statisch bereitgestellte so genannte Message-Queues ausgeführt. Dies sind Speicherbereiche, in die auszutauschende Daten in der Form von so genannten Nachrichten (Messages) in eine Warteschlange abgelegt werden. Andere Prozesse können dann asynchron die dort abgelegten Daten abholen und verarbeiten und selber Ergebnisse in Form einer neuen Nachricht in dieselbe oder eine andere Message-Queue (Nachrichtenschlange) ablegen. Eine solche Zwischenmodulkommunikation kann zwar in ungünstigen Fällen, bei denen aus der Message-Queue die Nachrichten nicht zeitgerecht abgeholt werden, zu einem Überlaufen der Message-Queue führen, jedoch beeinträchtigt dies den sendenden, d.h. die Nachrichten ablegenden, Prozess nicht. Sender und Empfänger arbeiten jeweils mit einer eigenen Kopie der ausgetauschten Daten, sodass eine nachteilige gegenseitige Beeinflussung durch inkonsistenten gemeinsamen Zugriff auf denselben Speicher vermieden wird.
Während bei Steuergeräten nach dem Stand der Technik für ein Erweitern einer Funktionalität eines Steuergeräts der Programmcode eines der Anwendungsmodule modifiziert werden musste oder Programmcode eines neuen Anwendungsmoduls zugefügt werden musste, ist bei der hier beschriebenen Ausführungsform des Steuergeräts eine andere Realisierung vorgeschlagen. Zum Zeitpunkt der Herstellung des Steuergeräts werden die ursprünglich vorhandenen Anwendungsmodule festgelegt und die von diesem benötigten Speicherbereiche diesen zugewiesen. Ferner wird die jeweils benötigte Prozessorzeit ermittelt und diesen statisch zugewiesen. Verbleibende Ressourcen im Hinblick auf den vorhandenen Speicher als auch im Hinblick auf vorhandene Prozessorzeit werden dem einen Anwendungsmodul, welches hier als Laufzeitumgebungsmodul 61 , 51-h bezeichnet wird, statisch zugewiesen. Dieses Laufzeitumgebungsmodul 61 ist so ausgebildet, dass es den Programmcode 72-1 bis 72-i, in der Regel in Form von Skriptcode (SC), interpretieren und in Maschinenbefehle des vorhandenen Prozessors überführen und dadurch die Ergänzungsmodule 71-1 bis 71-i ausführen kann. Ein wesentlicher Vorteil eines solchen Vorgehens besteht darin, dass die ursprünglich in dem Steuergerät 1 1 vorgesehene Funktionalitäten, welche durch die Anwendungsmodule 51 -1 bis 51-h-1 bereitgestellt werden, durch ein Ausführen von Ergänzungsmodulen 71-1 bis 71-i nahezu unbeeinflusst sind. Die Ergänzungsmodule 71-1 bis 71-i können weder auf Speicherbereiche der Anwendungsmodule 51 -1 bis 51-h-1 zugreifen, noch deren Prozessorzeit, die ihnen für die Ausführung jeweils statisch zugewiesen ist, beeinträchtigen. Eine Ausführung der Ergänzungsmodule 71-1 bis 71 -i, d.h. der Programmcodes 72-1 bis 72-i der jeweiligen Ergänzungsmodule 71 -1 bis 71-i, findet nur in der Prozessorzeit statt, die dem Laufzeitumgebungsmodul 61 zugewiesen ist.
Während den Anwendungsmodulen 51 -1 bis 51-h, einschließlich des Laufzeitumgebungsmoduls 51 -h, 61 , ein direkter Zugriff auf den Prozessor zu den jeweils festgelegten Zugriffszeiten gewährt wird, wird die für die Ausführung der Ergänzungsmodule 71 - 1 bis 71-i jeweils zur Verfügung gestellte Ausführungszeit dynamisch durch die Laufzeitumgebung festgelegt. Diese interpretiert den Code und führt diesen in der Laufzeitumgebung aus. Auch der von den einzelnen Ergänzungsmodulen 71-1 bis 71-i jeweils genutzte Datenspeicher 73-1 bis 73-i wird den einzelnen Ergänzungsmodulen 71 -1 bis 71 -i jeweils dynamisch zur Ausführungszeit der jeweiligen Module zugewiesen. Hierdurch kann ein verbesserter Ressourcenverbrauch realisiert werden. Hierfür kann nur Speicher genutzt werden, der dem Laufzeitumgebungsmodul statisch zugewiesen ist.
Bevorzugt sind die Anwendungsmodule 51-1 bis 51 -h so ausgebildet, dass diese miteinander über statische Message-Queues (sMqj) 91 -1 bis 91 -m miteinander kommunizieren. Um den Ergänzungsmodulen die Möglichkeit zu geben, auf Funktionen oder Schnittstellen zugreifen zu können, die die Anwendungsmodule 51 -1 bis 51 -h-1 bereitstellen, einschließlich eines Zugriffs auf den Datenbus 15, ist es notwendig, dass bei der Konstruktion des Steuergeräts die hierfür erforderlichen Kommunikationsobjekte definiert und bereitgestellt werden.
Für eine Zwischenmodulkommunikation der Ergänzungsmodule 71 -1 bis 71-i sowie für eine Kommunikation mit den Prozessen der Anwendungsmodule 51 -1 bis 51 -h-1 ist in der Laufzeitumgebung des Laufzeitumgebungsmoduls 61 , 51 -h eine so genannte Messagebridge 94 realisiert. Diese stellt eine Zugriffsmöglichkeit der Ergänzungsmodule 71-1 bis 71 -i auf die statischen Message-Queues 91 -1 bis 91-m zur Verfügung, indem diese in den Datenspeicherbereich 53-h des Laufzeitumgebungsmoduls 61 , 51-h eingeblendet werden 92-1 bis 92-m. Zusätzlich können die Ergänzungsmodule 71-1 bis 71 -i für die Kommunikation untereinander dynamische Message-Queues 93-1 bis 93-n erzeugen und nutzen.
Zusätzlich können sowohl die Prozesse der Anwendungsmodule 51 -1 bis 51-h als auch die Ergänzungsmodule 71 -1 bis 71 -i Parameter definieren, die deren Ausführung beeinflussen und von dem externen Texter 16 ausgelesen und/oder verändert werden können. Während die Parameter für die Anwendungsmodule bereits bei der Herstellung des Steuergeräts hinsichtlich des Typs und Wertebereichs festgelegt werden, brauchen für diese Parameter nur die Speicherbereiche definiert zu werden und statisch zugewiesen zu werden, welche den Parameterwert 101 -1 bis 101 -h speichern. Diese Parameter werden somit in einem Parameterspeicher 100 abgelegt, der im nicht flüchtigen Speicherbereich, der auch als Programmspeicherbereich 31 dienen kann, des Speichers 22 abgelegt ist. In dem Parameterspeicher 100 können darüber hinaus die Parameter für die Ergänzungsmodule abgelegt werden. Diese werden vorzugsweise als Schlüssel-Wert-Paare abgelegt (Key-Value- Speicherung) 102-1 bis 102-1. Ein Schlüssel-Wert-Paar weist jeweils einen Schlüssel auf, der eindeutig den Parameter charakterisiert und zusätzlich einen Wert und gegebenenfalls einen Typ des Parameters. Über den Schlüssel ist es möglich, auch bei Nichtkenntnis des Speicherortes, an dem das Schlüssel-Wert-Paar abgelegt ist, den entsprechenden Parameterwert aufzufinden, sodass dieser durch das entsprechende Ergänzungsmodul 71 -1 bis 71-i genutzt werden kann. Da ein Zugriff der Ergänzungsmodule 71 -1 bis 71-i auf Speicherbereiche, die nicht statisch dem Laufzeitumgebungsmodul 61 , 51-h zugewiesen sind, nicht zugelassen ist, wird der Parameterwertspeicher 100 in den Speicher des Laufzeitumgebungsmoduls 61 , vorzugsweise in den nicht flüchtigen Speicherbereich, abgebildet. Dort existiert somit eine Kopie 1 10 des Parameterwertspeichers 100, in dem die kopierten Parameterwerte 1 1 1 -1 bis 1 1 1 -k sowie die Schlüssel-Wert-Paare 1 12-1 bis 1 12-1 als Kopien vorliegen. Alternativ kann auch eines der Ergänzungsmodule 71-1 bis 71 -i die Laufzeitumgebung 61 anweisen, auf den Parameterspeicher 100 zuzugreifen und Werte an das Ergänzungsmodul 71-1 bis 71-i zu liefern.
Um ein neues Ergänzungsmodul zum Erweitern der Funktionalität oder Ändern der Funktionalität des Steuergeräts 1 1 in dieses zu integrieren, ist eines der Anwendungsmodule 51-1 bis 51 -h-1 als so genanntes Updatemodul 62 ausgebildet. Diese Funktionalität wird häufig durch ein Anwendungsmodul bereitgestellt, welches auch so genannte Unified Diagnostic Services bereitstellt. Dieses Anwendungsmodul 51-1 , 62 stellt eine Funktionalität bereit, über die der Tester 16 veranlassen kann, dass an das Steuergerät 1 1 übermittelter Programmcode 72-1 bis 72-i eines Ergänzungsmoduls 71-1 bis 71-i in den nicht flüchtigen Programmspeicher 52-h des Laufzeitumgebungsmoduls 61 , 51-h installiert wird.
Bei einer bevorzugten Ausführungsform ist vorgesehen, dass den Ergänzungsmodulen 71-1 bis 71 -i jeweils Meterinformationen 74-1 bis 74-i zugeordnet werden, in welchen die benötigten Ressourcen, beispielsweise in Form von benötigten Kommunikationsobjekten, Speicherbedarf, Prozessorleistung usw. angegeben sind.
In dem Steuergerät 1 1 existiert ein Metadatenspeicher 95, in dem die zugehörigen in dem Steuergerät 1 1 vorhandenen Ressourcen (z.B. noch verfügbarer Speicher 52h, 53h, unbenutzte Prozessorzeit, verfügbare Message-Queues) abgespeichert werden. Bei dem Vorgang des Installierens eines neuen Ergänzungsmoduls 71 -1 bis 71-i prüft das Updatemodul 51 -1 , 62 anhand der übermittelten Metadaten 74-1 bis 74-i des Ergänzungsmoduls 71 -1 bis 71-i, ob dieses in dem Steuergerät ausführbar sein wird. Verläuft der Abgleich positiv, so wird der Programmcode 72-1 bis 72-i des Ergänzungsmoduls 71 -1 bis 71-i in dem Programmspeicher 52-h des Laufzeitumgebungsmoduls 61 installiert. Andernfalls wird ein Herunterladen des Programmcodes 72-1 bis 72-i abgebrochen, abgewiesen oder eine bereits erfolgte Einspeicherung von Programmcodedaten über ein Löschen des entsprechenden Programmcodes 72-1 bis 72-i rückgängig gemacht. Anhand der dem Ergänzungsmodul 71-1 bis 71-i beigefügten Metadaten 74-1 bis 74-i wird der Metadatenspeicher 95 um jene Ressourcen, z.B. neue Message-Queues, ergänzt, die das entsprechende Ergänzungsmodul 71 -1 bis 71-i zur Verfügung stellt. Die weiterhin verfügbaren ungenutzten Ressourcen werden im gleichen Schritt reduziert.
Das beschriebene Steuergerät sowie das Verfahren zum Aktualisieren ermöglichen somit eine einfache Anpassung der Funktionalität eines Fahrzeugsteuergeräts 1 1 und sichern zugleich, dass die bereits in den ursprünglichen Anwendungsmodulen 51-1 bis 51-h bereitgestellte Funktionalität durch die Ergänzungsmodule 71-1 bis 71 -i nicht beeinträchtigt wird. Die Anwendungsmodule 51-1 bis 51-h werden bei der ursprünglichen Konzeption bereits so ausgerichtet, dass sie die notwendigen Kommunikationsobjekte (z.B. Message-Queues) bereitstellen, sodass anschließend Ergänzungsmodule 71 -1 bis 71-i mit ihnen zusammenwirken können. Um auch eine Kommunikation mit anderen Steuergeräten 12-14 zu ermöglichen, ist es vorteilhaft, wenn bei der Konzeption Nachrichtenkennungen bereits für mögliche zukünftig zugefügte Ergänzungsmodule 71 -1 bis 71 -i reserviert und bereitgehalten werden bzw. ein Mechanismus vorgesehen ist, über den Ergänzungsmodule 71-1 bis 71-i einer Busschnittstelle mitteilen können, welche Nachrichten von dem entsprechenden Ergänzungsmodul 71-1 bisi für deren Funktion benötigt werden.
versteht sich, dass lediglich beispielhafte Ausführungsformen beschrieben sind.
Bezugszeichenliste
Kraftfahrzeug
- 14 Steuergeräte
Bus
Tester
Prozessor (CPU)
Speicher
Kommunikationsschnittstelle
, 27 Schnittstellen
, 29 Sensoren
Programmspeicherbereich
Datenspeicherbereich
Programmcode des Betriebssystems
Betriebssystem des Steuergeräts
Arbeitsspeicher
-1 - 51-h Anwendungsmodule
-1 - 52-h Programmcode der Anwendungsmodule
-1 - 53-h Datenspeicher der Anwendungsmodule
Laufzeitumgebungsmodul
Updatemodul
-1 - 71-i Ergänzungsmodule
-1 - 72-i Programmcode der Ergänzungsmodule
-1 - 73-i Datenspeicher/Arbeitsspeicher der Ergänzungsmodule-1 - 74-i Metadaten der Ergänzungsmodule
-1 - 91 -m statische Message-Queues
-1 - 92-m abgebildete (kopierte) statische Message-Queues-1 - 93-n dynamische Message-Queues
Messagebridge
Metadatenspeicher
0 Parameterspeicher
1-1 - 101 -k Parameterwert
2-1 - 102-1 Schlüssel-Wert-Paare
0 Parameterspeicherkopie
1-1 - 1 1 1 -k Parameterwertkopie
2-1 - 1 12-1 Schlüsselwertepaarkopie

Claims

Ansprüche
1. Fahrzeugsteuergerät (1 1 ) umfassend:
mindestens einen Prozessor (21 ),
einen mit dem Prozessor gekoppelten Speicher (23),
wobei in dem Speicher auf dem Prozessor (21 ) ausführbare Programmcodes (40; 52-1 bis 52-h) eines Betriebssystems (41 ) und
mehrere Anwendungsmodule (51-1 bis 51-h), die Funktionalitäten des Fahrzeugsteuergeräts (1 1 ) bereitstellen,
gespeichert sind, sowie
mindestens eine Kommunikationsschnittstelle (25) für einen Datenaustausch mit anderen Fahrzeugsteuergeräten (12-14) oder einer externen Fahrzeugeinrichtung (16),
wobei den Anwendungsmodulen (51-1 bis 51 -h) jeweils die für ihre jeweilige Ausführung benötigten Programm- und Datenspeicherbereiche des Speichers (22) statisch zugeordnet sind, und
wobei das Betriebssystem (41 ) ausgebildet ist, den einzelnen Anwendungsmodulen (51 -1 bis 51-h) einen Zugriff zur Ausführung ihres Programmcodes (52-1 bis 52-h) zu vorher statisch festgelegten Zeitabschnitten auf den Prozessor (21 ) zu gestatten,
wobei eines der mehreren Anwendungsmodule (51 -1 ) als Update- Modul (62) ausgebildet ist, um über die mindestens eine Kommunikationsschnittstelle (25) Programmcode (72-1 bis 72-i) eines oder mehrerer Ergänzungsmodule (71-1 bis 71 -i) zu empfangen und in dem Speicher (22) abzulegen, um eine Erweiterung und/oder Änderung der Funktionalität des Fahrzeugsteuergeräts (1 1 ) zu bewirken,
dadurch gekennzeichnet, dass
eines der mehreren Anwendungsmodule (51 -1 bis 51-h) als Laufzeitumgebungsmodul (61 ) ausgebildet ist, welches eine Laufzeitumgebung bereitstellt, um den Programmcode (72-1 bis 72-i) des einen oder der mehreren Ergänzungsmodule (71 -1 bis 71 -i) auszuführen, und
das Updatemodul (51-1 , 62) ausgebildet ist, den Programmcode (72-1 bis 72-i) des oder der Ergänzungsmodule (71-1 bis 71-i) in dem dem Laufzeitumgebungsmodul (61 ) zugeordneten Programmsspeicher (52-h) abzulegen, wobei das Laufzeitumgebungsmodul (61 ) ausgebildet ist, den ihm zugewiesenen Datenspeicherbereich (53-h) sowie die ihm zur Verfügung stehende Prozessorzugriffszeit dynamisch zur Laufzeit aufzuteilen, um den Programmcode (72-1 bis 72-i) des einen oder der mehreren Ergänzungsmodule (71 -1 bis 71 -i) auszuführen.
2. Fahrzeugsteuergerät (1 1 ) nach Anspruch 1 , dadurch gekennzeichnet, dass der Speicher (22) einen nicht flüchtigen Parameterspeicher (100) umfasst, in dem Parameter (101-1 bis 101 -h) für die Anwendungsmodule (51-1 bis 51 -h) abgelegt sind oder ablegbar sind, wobei eines der Anwendungsmodule (51-1 bis 51-h) eine Funktionalität bereitstellt, welche eine Auslesen und/oder Setzen der Parameter über eine Kommunikation über die mindestens eine Kommunikationsschnittstelle (25) gestattet, wobei Parameter für Ergänzungsmodule (71-1 bis 71 -i) in Form von Schlüssel-Wert-Paaren (102-1 bis 102-h) in dem Parameterspeicher (100) abgelegt werden.
3. Fahrzeugsteuergerät (1 1 ) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Kommunikationsstruktur in dem Steuergerät (1 1 ) statisch zu Herstellungszeit des Fahrzeugsteuergeräts (1 1 ) festgelegt ist, welche Massage-Queues (91 -1 bis 91-m) umfasst, über die das Laufzeitumgebungsmodul (62) mit den übrigen Anwendungsmodulen (51 -1 bis 51-h-1 ) Daten austauschen kann.
4. Fahrzeugsteuergerät (1 1 ) nach Anspruch 3, dadurch gekennzeichnet, dass das Laufzeitumgebungsmodul (61 ) in seiner Laufzeitumgebung einen Massage-Queue- Manager (94) bereitstellt, der statische Laufzeitumgebungsmessagequeues (92-1 bis 92- m) bereitstellt, die auf die statischen Message-Queues (91-1 bis 91-m) der Betriebssystemebene abgebildet werden und den Ergänzungsmodulen (71-1 bis 71-i) eine Kommunikation mit den übrigen Anwendungsmodulen (51-1 bis 51 -h-1 ) ermöglichen, und eine Ausbildung dynamischer Message-Queues (93-1 bis 93-n) zur Laufzeit gestattet, um eine Kommunikation zwischen den Ergänzungsmodulen (71-1 bis 71 -i) zu ermöglichen.
5. Fahrzeugsteuergerät (1 1 ) nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Laufzeitumgebungsmodul (61 ) eine virtuelle Maschine (VM) in Form einer Stackmaschine umfasst.
6. Fahrzeugsteuergerät (1 1 ) nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Kommunikationsschnittstelle (25) als nachrichtenbasierte Schnittstelle ist, und den einzelnen Fahrzeugsteuergeräten Kommunikationskennungen zugeordnet sind und mindestens eine Kommunikationskennung, vorzugsweise eine Gruppe von Kommunikationskennungen, festgelegt ist, die für eine Kommunikation eines oder mit einem Ergänzungsmodul (71 -1 bis 71 -i) vorgesehen sind. Verfahren zum Ergänzen der Funktionalität eines Fahrzeugsteuergeräts (1 1 ) nach einem der vorangehenden Ansprüche, umfassend die Schritte:
Bereitstellen oder Erzeugen eines Programmcodes (72-1 bis 72-i) eines Ergänzungsmoduls (71-1 bis 71 -i), welches eine neue oder veränderte Funktionalität des Fahrzeugsteuergeräts (1 1 ) bei dessen Ausführung bewirkt, Ausbilden einer Kommunikationsverbindung mit dem Updatemodul (51-1 ) des Fahrzeugssteuergeräts (1 1 ) über die mindestens eine Kommunikationsschnittstelle (15), Übertragen des Programmcodes (72-1 bis 72-i) des Ergänzungsmoduls (71 -1 bis 71-i) zu dem Fahrzeugsteuergerät und Speichern des Programmcodes (72-1 bis 72-i) in einem dem Laufzeitumgebungsmoduls (61 ) zugewiesenen Programmspeicherbereich (52-h), so dass das Laufzeitumgebungsmodul (61 ) den Programmcode (72-1 bis 72-i) des Ergänzungsmoduls (71-1 bis 71 -i) ausführt.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass dem Programmcode (72-1 bis 72-i) des Ergänzungsmoduls (71-1 bis 71-i) Metadaten zugefügt werden, welche zumindest Anforderungsinformationen über zur Ausführung benötigte Ressourcen umfassen, und die Metadaten (74-1 bis 74-i) vor einer Übertragung des Programmcodes (72-1 bis 72-i) oder mit dem Programmcode (72-1 bis 72-i) zu dem Fahrzeugsteuergerät (1 1 ) übertragen werden, und das Updatemodul (51 -1 ) anhand der Metadaten (74-1 bis 74-i) überprüft, ob das Fahrzeugsteuergerät (1 1 ) die Anforderung hinsichtlich der benötigten Ressourcen erfüllt, und, wenn dieses nicht der Fall ist, eine Übertragung der Programmdaten (72-1 bis 72-i) des Ergänzungsmoduls (71-1 bis 71 -i) abbricht, abweist , verwirft oder aus dem Speicher wieder löscht.
PCT/EP2013/059663 2012-05-12 2013-05-08 Funktional erweiterbares fahrzeugsteuergerät und verfahren zum ergänzen der funktionalität eines fahrzeugsteuergeräts Ceased WO2013171122A2 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201380024821.2A CN104272255B (zh) 2012-05-12 2013-05-08 功能可扩展的机动车控制器和用于补充机动车控制器的功能的方法
US14/400,565 US9880927B2 (en) 2012-05-12 2013-05-08 Functionally expandable vehicle control device and method for supplementing the functionality of a vehicle control device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102012009482.5A DE102012009482B4 (de) 2012-05-12 2012-05-12 Funktional erweiterbares Fahrzeugsteuergerät und Verfahren zum Ergänzen der Funktionalität eines Fahrzeugsteuergeräts
DE102012009482.5 2012-05-12

Publications (2)

Publication Number Publication Date
WO2013171122A2 true WO2013171122A2 (de) 2013-11-21
WO2013171122A3 WO2013171122A3 (de) 2014-01-16

Family

ID=48407562

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/059663 Ceased WO2013171122A2 (de) 2012-05-12 2013-05-08 Funktional erweiterbares fahrzeugsteuergerät und verfahren zum ergänzen der funktionalität eines fahrzeugsteuergeräts

Country Status (4)

Country Link
US (1) US9880927B2 (de)
CN (1) CN104272255B (de)
DE (1) DE102012009482B4 (de)
WO (1) WO2013171122A2 (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011079399A1 (de) * 2011-07-19 2013-01-24 Bayerische Motoren Werke Aktiengesellschaft Steuervorrichtung für ein Kraftfahrzeug, Programmiervorrichtung und Programmiersystem
US9779247B2 (en) * 2015-05-29 2017-10-03 GM Global Technology Operations LLC Boot control systems and methods for vehicles
DE102015213522A1 (de) * 2015-07-17 2017-01-19 Robert Bosch Gmbh Bussystem, Teilnehmerstation dafür und Verfahren zur Konfiguration eines statischen Bussystems für eine dynamische Kommunikation
DE102015214376A1 (de) * 2015-07-29 2017-02-02 Robert Bosch Gmbh Verfahren und Vorrichtung zur On-Board-Diagnose bei einem Steuergerät mit einem Hypervisor und mindestens einem unter dem Hypervisor betriebenen Gastsystem
US10223294B2 (en) 2015-09-01 2019-03-05 Nxp Usa, Inc. Fast secure boot from embedded flash memory
DE102015115855A1 (de) * 2015-09-21 2017-03-23 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH System und Verfahren zur Verteilung und/oder Aktualisierung von Software in vernetzten Steuereinrichtungen eines Fahrzeugs
US10235218B2 (en) * 2016-05-03 2019-03-19 International Business Machines Corporation Automatic correction of cryptographic application program interfaces
DE102016217636A1 (de) * 2016-09-15 2018-03-15 Robert Bosch Gmbh Bildverarbeitungsalgorithmus
DE102016221108A1 (de) * 2016-10-26 2018-04-26 Volkswagen Aktiengesellschaft Verfahren zum Aktualisieren einer Software eines Steuergeräts eines Fahrzeugs
DE102017200669A1 (de) * 2017-01-17 2018-07-19 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Steuergeräts, Computerprogramm und Verfahren zum Generieren des Computerprogramms
DE102018131134A1 (de) 2018-12-06 2020-06-10 Bayerische Motoren Werke Aktiengesellschaft Modulares elektronisches Steuergerät für ein Kraftfahrzeug sowie Kraftfahrzeug mit einem solchen Steuergerät und Rechenmoduleinheit für das Steuergerät
US10606786B2 (en) * 2019-01-29 2020-03-31 Intel Corporation Upgradable vehicular computing methods and apparatuses
CN112947953A (zh) * 2019-12-10 2021-06-11 浙江荷清柔性电子技术有限公司 模块化更新方法、装置、计算机设备和存储介质
DE102020110874A1 (de) 2020-04-22 2021-10-28 Audi Aktiengesellschaft Kraftfahrzeug, System und Verfahren zum Aktualisieren und/oder Hinzufügen zumindest einer Funktion eines Fahrzeuggerätes
DE102020116714A1 (de) * 2020-06-25 2021-12-30 Audi Aktiengesellschaft Steuergerät für ein Fahrzeug, System, Verfahren und Kraftfahrzeug mit einem solchen Steuergerät
CN113859391B (zh) * 2021-10-13 2024-07-19 秦皇岛奥卡深软件开发有限公司 通过添加车型连接模块应用汽车新零部件的方法
CN116954942B (zh) * 2023-06-29 2024-06-11 广州汽车集团股份有限公司 接口调用方法、装置、车辆及存储介质
CN121029137A (zh) * 2024-09-11 2025-11-28 深圳引望智能技术有限公司 一种代码开发方法及相关装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0869417B1 (de) 1993-07-26 2003-03-26 Hitachi, Ltd. Steuerungseinheit für Fahrzeug
DE102008036711A1 (de) 2008-08-07 2010-02-11 Volkswagen Ag Verfahren zum Ändern einer softwarebasierten Fahrzeugfunktion eines Kraftfahrzeugs
US20100179720A1 (en) 2009-01-13 2010-07-15 Gm Global Technology Operations, Inc. Autonomous vehicle maintenance and repair system
DE102009018761A1 (de) 2009-04-27 2010-10-28 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Aktualisierung von Softwarekomponenten

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3424548B2 (ja) 1998-04-08 2003-07-07 松下電器産業株式会社 組み込み機器用ソフトウエア論理シミュレータ
US6487717B1 (en) 1999-01-15 2002-11-26 Cummins, Inc. System and method for transmission of application software to an embedded vehicle computer
US8090811B2 (en) * 2000-06-06 2012-01-03 Panasonic Electric Works Co., Ltd. Service provider for embedded devices using a message store
US7779407B2 (en) 2002-05-29 2010-08-17 Adams Phillip M Computer-hardware, life-extension apparatus and method
US7389411B2 (en) * 2003-08-29 2008-06-17 Sun Microsystems, Inc. Secure transfer of host identities
US20050090941A1 (en) * 2003-10-22 2005-04-28 General Motors Corporation Telematics based programming gateway
US7376945B1 (en) 2003-12-02 2008-05-20 Cisco Technology, Inc. Software change modeling for network devices
US7844964B2 (en) * 2004-09-23 2010-11-30 Hewlett Packard Development Company, L.P. Network for mass distribution of configuration, firmware and software updates
US7730472B2 (en) 2004-09-24 2010-06-01 Hewlett-Packard Development Company, L.P. Dynamic linking of modules in a pre-operating system environment
US8510732B2 (en) * 2005-02-22 2013-08-13 Connectif Solutions Inc. Distributed asset management system and method
DE102005050304A1 (de) 2005-10-17 2007-04-19 Netccm Gmbh Verfahren und Programm für die Generierung automatisch verteilbarer Clients von Application-Servern
US7823020B2 (en) * 2006-08-30 2010-10-26 International Business Machines Corporation System and method for applying a destructive firmware update in a non-destructive manner
US8352231B2 (en) 2007-08-30 2013-01-08 International Business Machines Corporation System for performing a co-simulation and/or emulation of hardware and software
US20090119657A1 (en) * 2007-10-24 2009-05-07 Link Ii Charles M Methods and systems for software upgrades
US8332838B2 (en) * 2007-11-14 2012-12-11 Continental Automotive Systems, Inc. Systems and methods for updating device software
US8490074B2 (en) * 2007-11-27 2013-07-16 The Boeing Company Aircraft software part library
US20120017019A1 (en) 2008-09-03 2012-01-19 Kabushiki Kaisha Toshiba In-vehicle display device, extension device, and individual functional device
US8296411B2 (en) 2010-03-01 2012-10-23 International Business Machines Corporation Programmatically determining an execution mode for a request dispatch utilizing historic metrics
US20110238980A1 (en) * 2010-03-23 2011-09-29 Fujitsu Limited System and methods for remote maintenance in an electronic network with multiple clients
CN102262540A (zh) 2011-08-11 2011-11-30 浙江大学 一种应用于autosar ecu配置的基础软件参数定义扩展方法
US9197314B1 (en) * 2013-11-08 2015-11-24 Gogo Llc Data delivery to devices on vehicles using multiple forward links

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0869417B1 (de) 1993-07-26 2003-03-26 Hitachi, Ltd. Steuerungseinheit für Fahrzeug
DE102008036711A1 (de) 2008-08-07 2010-02-11 Volkswagen Ag Verfahren zum Ändern einer softwarebasierten Fahrzeugfunktion eines Kraftfahrzeugs
US20100179720A1 (en) 2009-01-13 2010-07-15 Gm Global Technology Operations, Inc. Autonomous vehicle maintenance and repair system
DE102009018761A1 (de) 2009-04-27 2010-10-28 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Aktualisierung von Softwarekomponenten

Also Published As

Publication number Publication date
US20150154113A1 (en) 2015-06-04
US9880927B2 (en) 2018-01-30
CN104272255B (zh) 2017-05-10
DE102012009482A1 (de) 2013-11-14
CN104272255A (zh) 2015-01-07
WO2013171122A3 (de) 2014-01-16
DE102012009482B4 (de) 2020-06-25

Similar Documents

Publication Publication Date Title
DE102012009482B4 (de) Funktional erweiterbares Fahrzeugsteuergerät und Verfahren zum Ergänzen der Funktionalität eines Fahrzeugsteuergeräts
DE102014201682A1 (de) Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
DE102010038466A1 (de) Gemeinsame Elektronische Steuereinheit und in dieser Implementiertes Weiterleitungsprogramm
DE112012003795T5 (de) Fahrzeugnetwerksystem und Fahrzeug-Informationsverarbeitungsverfahren
EP4315090B1 (de) Verfahren zum laufzeitbasierten konfigurieren einer geräteinternen signalübertragung in einem steuergerät sowie entsprechend betreibbares steuergerät und kraftfahrzeug
DE102011075776A1 (de) Verfahren und System zum Aktualisieren eines gemeinsam genutzten Speichers
DE102006044182A1 (de) System und Verfahren zur bedarfsgerechten Funktionalisierung von Steuer-/Regeleinrichtungen
DE102012016539A1 (de) Konfigurationstechnik für ein Steuergerät mit miteinander kommunizierenden Anwendungen
DE102018110020A1 (de) Verfahren zum Erzeugen eines auf einem Testgerät ausführbaren Modells eines technischen Systems und Testgerät
DE102013213314A1 (de) Hinterlegen mindestens eines berechenbaren Integritätsmesswertes in einem Speicherbereich eines Speichers
DE102015119202A1 (de) Schnittstelleneinheit zur Weiterleitung priorisierter Eingangsdaten an einen Prozessor
DE102014206989A1 (de) Verfahren und System zur deterministischen Autokonfiguration eines Gerätes
DE102022107393A1 (de) Center, verteilungssteuerungsverfahren undnicht-transitorisches speichermedium
EP4309033B1 (de) Computerimplementiertes verfahren und vorrichtung zur automatisierten aktualisierung einer kommunikationseinheit einer steuereinheit eines fahrzeugs
DE112013007676T5 (de) Informationsvorrichtung
DE102013021231A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät
WO2005022382A2 (de) Verfahren zur installation einer programmkomponente
DE102020215763A1 (de) Verfahren zur Optimierung der Übertragungsdatenrate in einem Sensornetzwerk im Teilnetzbetrieb in einem Ethernetnetzwerk
DE102004002020A1 (de) Steuerungssoftwarearchitektur zur Realisierung einer dezentralisierten kooperativen Steuerung mehrerer elektronischer Steuerungsvorrichtungen, die über ein Netzwerk verbunden sind
DE102018105724A1 (de) Verfahren zur Konfiguration von Steuergeräten
DE112015002881T5 (de) Speichervorrichtung, Flash-Speicher-Steuervorrichtung und Programm
DE102012208179B4 (de) Verfahren zum Betreiben einer Elektronikeinrichtung eines Kraftfahrzeugs sowie eine entsprechende Elektronikeinrichtung
DE102022105132A1 (de) Verfahren zum Simulieren von einem Steuergeräte-Antwortverhalten in einer Produktionslinie zum Fertigen eines Kraftfahrzeugs
DE102009047974B4 (de) Verfahren zur Programmierung eines Steuergeräts
DE102015214389A1 (de) Verfahren und Vorrichtung zum Aktualisieren einer auf einer physischen Maschine unter einem Hypervisor betriebenen virtuellen Maschine

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: 13721754

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 14400565

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 13721754

Country of ref document: EP

Kind code of ref document: A2