DE102004008869A1 - Control unit for a vehicle combustion engine, has modular hierarchical software with an upper control, safety and monitoring module and with modules linked by overlapping interfaces - Google Patents

Abstract

Control device (100) for a vehicle combustion engine (300) has modular control software (100b) with a multiplicity of module overlapping interfaces to permit flexible interconnection of the modules. In a first upper hierarchical software module, control, safety and monitoring function units of the device are collected. The invention also relates to a corresponding computer program for method implementation.

Description

The invention relates to a control device and a computer program for controlling a device, in particular an internal combustion engine of a vehicle.

State of technology

Such control devices with each Hardware and software are generally known in the prior art. The hardware of these control units typically includes at least one processor and at least one a storage element. The software of these control units includes on the other hand, typically a plurality of in the memory element stored functional units with different functions. Communicate for the purpose of controlling a device of the vehicle at least some of these functional units together. The immediate one Control of the device is based on the stored Software using a circuit connected between the control unit and the device Sensor / actuator configuration.

However, the functional units mentioned were not all developed and implemented in the software at the same time, but are only in the course of time in the course of progressive development successively added to the software of the control unit. When adding So far, only new functional units have been considered that the new functional units with all other functional units, where necessary, could communicate. Arose over time such a confusing Agglomerate of interfaces between the individual functional units, which in particular through an exchange of known functional units modified functional units or the further addition of new functional units increasingly difficult. The difficulties arose especially because existing dependencies between individuals Functional units when redesigning the overall system from control unit including hardware and software, sensor / actuator configuration and Device or even parts of the same very difficult to understand were.

Based on this state of the art it is the object of the present invention, a known control device and a Computer program for controlling a device of a vehicle to further develop that individual parts of the control unit and in particular can be implemented independently of one another by its computer program and are interchangeable.

This task is the subject of Claim 1 solved. Accordingly, the software of the control device is modular in the form of a plurality of modules built for the purpose of cross-module Communication with each other through a plurality of module interfaces are connected and in a first of the modules those of Functional units are summarized, which is a realization of control, safety and / or monitoring functions for the device enable.

The device in the sense of the invention can alternatively be different domains represent a vehicle. So it can represent the drive unit of the vehicle as a first domain; the device is then, for example, in the form of an internal combustion engine, an electric drive or a fuel cell drive. Alternatively, the device can also be designed as a transmission be and in this way represent a second domain of the vehicle.

Users in the sense of the invention can for example the driver of the vehicle, the legislator, a vehicle supplier or be a vehicle manufacturer.

Physical level in the sense of Invention means an abstraction of hardware specifics. This means that at the physical level, based on the interface of the sensor to its surroundings, only physical quantities such as for example the speed of the drive unit can be considered, but not their hardware implementation in the form of an electronic signal with a hardware-specific, representing the speed Amplitude or frequency.

The terms software and computer program are basically used synonymously in the description.

Advantages of invention

The main advantage of the claimed modularization is that the individual modules are easily interchangeable and independently are realizable from each other. An exchange of individual modules is especially easy because in the defined Module Interfaces All dependencies between the functional units between the individual modules taken into account in the various modules are; about that additional dependencies can exist at the level of the functional units, but are at the level of the parent Encapsulated modules and therefore no longer visible; therefore they need not to be taken into account when exchanging the modules.

The proposed modularization is associated in particular with cost and time savings. When using a different control unit hardware or a different sensor / actuator configuration, the entire software of the control unit no longer has to be analyzed and, if necessary, adapted, but rather it is sufficient if only the corresponding module is considered is tested.

The claimed summary of the named functional units for the first module was chosen so that they in particular from the point of view of vehicle manufacturers and from a physical point of view Point of view makes sense.

The claimed first module is preferably by the manufacturer of the control unit as a kind of basic software module included. It advantageously allows due to its defined Interfaces to the other modules an easy integration of these other modules in the overall software of the control unit too then if these other modules or parts thereof are not from the manufacturer the control unit, but from third parties, for example the car manufacturers themselves, were developed or programmed. This applies in particular to a fifth, so-called Application software module. High expenditure to adapt incompatible Interfaces that support the implementation of platform solutions severely hinder automobile manufacturers or their suppliers, belong with it the past.

The ones summarized in the first module Functional units are all for a specific device of the vehicle. This is the first module as a whole almost inevitably device respectively domain-specific educated. By combining the domain-specific functional units in the first module domain-specific Infrastructure functional units from other modules, in particular be kept out of the CORE module, so that at least largely independent of the domain and programmed easier and reusable for other domains can be.

The ones summarized in the first module Represent functional units Functions of great importance for the reliable Functioning of the overall system consisting of control unit, sensor / actuator configuration and Contraption. These functional units are therefore often in this regard very specific and partly include protected, i.e. secret Interfaces, for example to manipulate the system from outside too prevent. The summary of such functional units in the first module allows one clear assignment of responsibility for these parts to the manufacturer of the first module, usually the control unit provider. The separation caused by the claimed training of the first module or separation of these critical functional units of other modules, in particular the user software module, advantageously enables easier development or programming of these other modules (ASW); this applies because then there is no specific one Know-how about the critical functional units summarized in the first module is required. In particular, this means programming of Vehicle and engine functions also using central Control signals from the control unit for the User software module possible without it Knowledge of the sensitive functional units would be required in the first module.

In addition to the first module and the user software module instructs the software of the control unit typically a second module, also called "core", in which those functional units are summarized which an individual programming of the processor of the control unit in the Way enable that the hardware of the control unit is enabled to communicate with the modules of the control unit and which the processing of functions of the functional units in enables the modules. The CORE provides an abstraction from the hardware, so that the application software is independent from the ECU hardware can be developed and used.

A so-called Complex drivers can be provided in which those functional units are summarized, the direct control of special Enable sensor-actuator configurations and one from the ECU hardware dependent Require implementation.

The agglomeration of the first, second and the third module is also referred to below as the U-layer. Optionally, about that in addition, a fourth module, a so-called device encapsulation, be provided in which those functional units are summarized are that an individual adaptation to the sensor / actuator configuration used in the software of the control unit enable in the way that between the individual sensors or actuators of the configuration communication with the rest Modules of the control unit is possible.

All modules are preferably of Invention for the purpose of mutual communication via module interfaces M1-M6 and M1 ', M2' and M3 'connected together.

At least some of the modules, especially that second module, are in turn divided into components. Individual components can be easily replaced if necessary, without having to replace a complete module would.

Are necessarily between The components and modules are provided with interfaces for data exchange. Communication between components advantageously takes place in different modules well-defined, stable module interfaces.

Each of the components is in turn divided into any number of functional units. Interfaces are also at the level of this function units are provided so that different functional units can communicate with each other within a component. Communication between functional units in different components takes place via the component interfaces and communication between functional units in different modules takes place via the module interfaces.

Also for the interfaces between this already applies to the functional units and between the components above for the dependencies generally said, namely that all necessary internal dependencies within modules considered between the functional units are and not internal dependencies become visible at module level. The result is a simple one Interchangeability not only of modules, but also of components or functional units, in particular a simple one and uncomplicated adaptation to customer requirements or new technologies.

A more detailed description of the division as well as the tasks of the individual components in the modules and of the functional units combined in the individual components is the subject of the subclaims.

According to an advantageous training are the functional units, the components and / or the modules and their respective interfaces at least partially as a computer program educated. Training as a computer program allows flexible Implementation of change requests without that a change the hardware of the control unit must be made.

The above task continues through a computer program for the described and claimed control unit solved. The advantages of this computer program correspond to the advantages mentioned above with reference to the control unit.

drawings

The description is a total of six Figures attached, in which

1 the construction of an overall system on which the invention is based;

2 a modular architecture according to the invention for a control unit;

3 an inventive division of individual modules into components;

4 the assignment according to the invention of functional units to an infrastructure component and a hardware capsule component; and

5 shows a functional unit for a device driver element.

description of the embodiments

A detailed description follows of embodiments the invention with reference to the figures.

1 shows an overall system with a control unit 100 , with the reference symbol 100a the hardware and the reference number 100b the software of the control unit 100 represents. The hardware of the control unit 100 comprises at least one processor 100a-1 and at least one storage element 100a-2 , The software 100b is usually in the storage element 100a-2 deposited. The software 100b usually comprises a large number of functional units EPM, IS-1, IS-2, HWE-1, STE, ÜF, SF, which at least occasionally are used to control a device 300 of this vehicle communicate with each other. The direct control of the device 300 takes place in the overall system with the help of a between the control unit 100 and the drive unit 300 switched sensor / actuator configuration 200 ,

• – Funktionseinheit Aggregat-Positions-Management EPM: Diese Funktionseinheit hat die Aufgabe, eine Positions- und Drehzahlerfassung der Kurbel- und Nockenwelle des Antriebsaggregates durchzuführen.
• – Funktionseinheit Dienstebibliotheken IS-1: Sie hat die Aufgabe, allgemeine, sehr häufig verwendete Funktionen bereitzustellen, die von unterschiedlichen Funktionseinheiten nachgefragt beziehungsweise benutzt werden. Sie bietet eine zentrale Bereitstellung dieser Funktionen mit dem Vorteil, dass diese nicht mehrfach dezentral bereitgestellt werden müssen.
• – Funktionseinheit Diagnosemanager IS-2: Diese Funktionseinheit übernimmt die Aufbereitung eines Fehlersignals, welches zum Beispiel einen Defekt in der Hardware 100a des Steuergerätes 100 repräsentiert. Die Aufbereitung besteht insbesondere in einer Entprellung des Fehlersignals und einer Abspeicherung desselben, damit zu einem späteren Zeitpunkt eine Auswertung des Fehlersignals erfolgen kann.
• – Funktionseinheit Signalaufbereitung HWE-1: Sie führt eine Bereinigung eines analogen Sensorsignals nach dessen Digitalisierung durch zum Beispiel im Hinblick auf unerwünschte Signalmodulationen, die in dem Steuergerät eventuell entstanden sein können.
• – Funktionseinheit Steuerungsfunktion STE: Sie dient zur Generierung beziehungsweise zur Gewährleistung einer zeit- beziehungsweise drehzahlabhängigen Ansteuerung der Vorrichtung und koordiniert die zeitliche Abarbeitung von Anforderungen unterschiedlicher Funktionseinheiten. Insbesondere wenn es sich bei der Vorrichtung um das Antriebsaggregat des Fahrzeugs handelt, dann ist eine Ansteuerung von zum Beispiel den Einspritzventilen und eine Einstellung des Zündzeitpunktes zwingend notwendig mit der Drehzahl oder dem Kurbelwellenwinkel zu synchronisieren zwecks Festlegung geeigneter Umschaltzeitpunkte zwischen Betriebszuständen der Vorrichtung. Ganz generell lässt sich der Betrieb der Vorrichtung in eine Initialisierungsphase, eine Normalbetriebsphase und eine Abschaltphase unterteilen; diese unterschiedlichen Betriebsphasen sind in der Software des Steuergerätes abgebildet. Die Initialisierungsphase dient typischerweise zwecks Definition beziehungsweise Vorbesetzung von Variablen zur Systemsteuerung. Wenn es sich bei der Vorrichtung um eine Brennkraftmaschine mit Direkteinspritzung handelt, kann während des Normalbetriebs zunächst zum Beispiel ein Homogenbetrieb eingestellt und als Betriebszustand überwacht werden. Bei Erreichen vorbestimmter Änderungs- oder Umschaltkriterien kann die Funktionseinheit STE dann innerhalb des Normalbetriebs eine Umschaltung von Homogen- auf Schichtbetrieb mit Lambda ≥ 1 veranlassen.
• – Funktionseinheit Überwachungsfunktionen ÜF: Sie dient zur Überwachung des Betriebs der Vorrichtung. Die ÜF-Funktionseinheit gewährleistet, dass die Vorrichtung keine unzulässigen Betriebszustände einnimmt. So darf beispielsweise ein Antriebsaggregat als Vorrichtung während des Betriebs des Fahrzeugs niemals mehr Drehmoment liefern als vom Fahrer gewünscht.
• – Funktionseinheit Schutzfunktionen SF: Die Funktionseinheit Schutzfunktionen ist ausgebildet, eine unautorisierte Nutzung der Vorrichtung 300 beziehungsweise des Fahrzeugs zu verhindern. So kann sie insbesondere ausgebildet sein, eine unzulässige Manipulation von Daten, insbesondere in der Software des Steuergerätes oder eine unzulässige Inbetriebnahme beziehungsweise einen Diebstahl der Vorrichtung oder des Fahrzeugs zu verhindern.

Examples of functional units in the software 100b for the control unit 100 to control the device 300 , in particular as a drive unit, are:

• - EPM unit position management function unit: This function unit has the task of detecting the position and speed of the crankshaft and camshaft of the drive unit.
• - Service unit service libraries IS-1: Its task is to provide general, very frequently used functions that are requested or used by different function units. It offers these functions to be provided centrally, with the advantage that they do not have to be provided locally multiple times.
• - Functional unit diagnostic manager IS-2: This functional unit takes over the preparation of an error signal, which, for example, is a defect in the hardware 100a of the control unit 100 represents. The preparation consists in particular in debouncing the error signal and storing it so that the error signal can be evaluated at a later point in time.
• - Functional unit signal processing HWE-1: It performs a cleanup of an analog sensor signal after it has been digitized, for example with regard to unwanted signal modulations that may have arisen in the control unit.
• - Functional unit control function STE: It serves to generate or to guarantee a time- or speed-dependent control of the device and coordinates the time processing of requests from different functional units. In particular, if the device is the drive unit of the vehicle, then, for example, the injection valves are actuated and the ignition is adjusted point of time is absolutely necessary to synchronize with the speed or the crankshaft angle in order to determine suitable switching times between operating states of the device. In general, the operation of the device can be divided into an initialization phase, a normal operating phase and a shutdown phase; these different operating phases are shown in the software of the control unit. The initialization phase is typically used to define or preset variables for system control. If the device is an internal combustion engine with direct injection, during normal operation, for example, homogeneous operation can initially be set and monitored as the operating state. When predetermined change or changeover criteria are reached, the functional unit STE can then initiate a changeover from homogeneous to shift operation with lambda ≥ 1 within normal operation.
• - Functional unit monitoring functions ÜF: It serves to monitor the operation of the device. The ÜF functional unit ensures that the device does not assume any impermissible operating states. For example, a drive unit as a device must never deliver more torque than the driver requests during the operation of the vehicle.
• - Functional unit protective functions SF: The functional unit protective functions is designed for unauthorized use of the device 300 or to prevent the vehicle. In particular, it can be designed to prevent unauthorized manipulation of data, in particular in the software of the control device, or unauthorized commissioning or theft of the device or the vehicle.

Individual of these functional units are in 1 within the software 100b of the control unit exemplified.

2 shows a modularization of the software according to the invention 100b in the control unit 100 , The software modules ASV, CO, DE, CD, ASW formed by the modularization are characterized in that functional units are suitably combined or grouped in them.

According to the invention, those functional units STE, ÜF and SF which implement control, safety and / or monitoring functions for the device are combined in a first module ASV 300 enable. The summary of the functional units described represents a domain-specific control and monitoring entity, that is to say a control which is aimed specifically at the device to be controlled 300 is adjusted. In other words, these functional units or this status control are then individually tailored to whether the device to be controlled is a drive unit or a transmission control, etc. With regard to detailed tasks of the individual functional units, reference is made to the explanations for the individual functional units in the above list of functional units. Based on the basic mechanisms of the second module CO described below, the first module ASV according to the invention creates a domain-specific frame, which supports the integration of a fifth module ASW, described in more detail below, in the best possible way for a particular application.

In a second module CO, on the one hand those functional units IS-1, IS-2 and HWE-1 are combined, which individually program the hardware of the control unit 100 in such a way that the hardware is enabled with the modules of the control unit 100 to communicate. Furthermore, the second module CO includes those functional units that enable the functions of the functional units in the modules ASV, ASW, CO, DE, CD to be processed (operating system, memory management). In addition, the second module CO can also have functional units which enable the ASW module and / or a fourth module DE to communicate with other control units.

A third module, Complex Driver CD, summarizes those functional units that directly control complex sensor / actuator configurations with complex interfaces to the control unit 100 through the first module. These specific sensor / actuator configurations are to be distinguished from the non-specific sensor / actuator configurations that do not depend on the control unit hardware. In contrast to non-specific configurations, in which communication with a fifth module ASW described in more detail later is only possible via the second and a fourth module, communication with the fifth module ASW takes place directly via the third module DE in the specific configurations ,

In the fourth module DE, those functional units are combined that allow the sensor / actuator configuration used to be individually adapted to the control unit 100 enable communication between the individual sensors or actuators of the configuration with the other modules of the control unit 100 is possible.

Finally, in the fifth module, user software ASW, those functional units are summarized which influence the device 300 serve on a physical level in response to a user request.

Between the modules ASV, ASW, CO, DE, CD are module interfaces M1, M2, M3, M4, M5, M6, respectively and M7 are provided, on the one hand communication between the modules, but also enable the exchange of individual modules. This is how the interface serves M1 between the first module ASV and the second module CO that the first module ASV the basic mechanisms of the second Module can use, for example, to access the hardware of the control unit or to save errors that have occurred. Via the interfaces M2, M3 and M7 monitored the first module ASV the third, fourth and fifth module regarding the correct one Processing the tasks assigned to them and bringing the vehicle in the event of incorrect processing of the tasks in a safe Status. Moreover the first module informs the third, fourth and fifth module about the Operating state of the control unit with the consequence that these informed modules then the them process the tasks assigned to the respective operating state of the control unit. In addition to the interface M7, the fifth module typically has ASW further direct module interfaces to the modules CO, DE and CD on.

Basically, the modules mentioned can be provided independently of each other to the extent necessary depending on the application. The first, second and third module, hereinafter also referred to as U-layer U, represent a particularly advantageous combination. Such a U-layer includes all necessary drivers for standard input and output variables and the complex signals of a sensor / actuator configuration used in each case 200 , In addition, the complex couplings between a component HWE described below of the second module CO and the third module CD are implemented and there are no longer any access conflicts between the component HWE and the fourth module DE when accessing common hardware resources. In such a U-Layer U, the first module ASV uses the methods and services of the second module CO and the input signals of the third module CD to determine device-specific control signals, but also to be able to configure and provide the time slots required for its control function. The function of an immobilizer within the functional unit protective function of the first module ASV has interfaces to the component HWE within the second module CO and to so-called shutdown paths or complex drivers within the third module CD; these interfaces are advantageously encapsulated in the U-layer and therefore need no longer be taken into account when programming further modules. In addition to these interfaces, interfaces of the functional unit monitoring of the hardware and interfaces of the functional unit protective function are already solved and encapsulated within the U-layer. As part of its monitoring function function unit, the first ASV module can also provide mechanisms for switching off the device in the event of an error.

The control unit 100 together with the U-Layer represents an ideal platform or an ideal framework for the development of user software by third parties or for the use of existing user software. The main reason for this is that due to the U-Layer structure the development of the user software largely without consideration of basic complex and hardware-dependent domain-specific tasks that do not offer any differentiation potential or are highly relevant for the robustness of the overall system and ensuring the functions of the overall system. The basic domain-specific functions are, in particular, the necessary basic functions of injection, ignition, position detection, system control, monitoring or immobilizer, as have already been described above in the scope of functions of the first module or the complex driver CD. The aforementioned simplification in the programming of user software on the basis of the claimed U-layer U has the advantage that when programming the user software one can concentrate fully on aspects that are important for the user software. These partial aspects can be, for example, the needs of the future driver of a vehicle with the overall system or the requirements of the legislator. The needs of the driver can be, for example, the aspects of "driving pleasure" or "fuel consumption", while the requirements of the legislator can be, for example, compliance with emission limit values or the possibility of implementing diagnostic functions. Finally, the U-Layer U enables the hardware of the control unit to be easily changed over or changed without the user software (ASW) having to be changed in these cases and thus having to do without its tried and tested functionalities.

If the U-Layer U is supplemented by the fourth module DE described above, this offers the advantage that the user continues to experience complex diagnosis and monitoring of input and output variables of the sensor / actuator configuration 200 , which are also relevant to warranty and safety, is relieved.

3 shows an inventive grouping of components within the previously described modules ASW, and CO. The fifth module ASW essentially represents user- or user-oriented functions. With regard to planned applications, in which devices from different domains, such as drive units or gears, are controlled by the control unit , it makes sense to subdivide this ASW module into a vehicle component VF and a drive unit component EF.

The vehicle component includes VF preferably those functional units that are not specific for one certain type of drive unit, such as diesel, Petrol or electric motor. This is - if the Device is designed as a drive unit - in particular around the functional units drive VF-1, vehicle coordinator VF-2, Vehicle movement VF-3 or driving state variables VF-4 as described above were.

In contrast, the drive unit component EF then preferably summarizes all those functional units that are used as a device for the drive unit used 300 are specific, such as knock control, injection, ignition, exhaust gas aftertreatment, idle control. When changing from the control unit 100 device to be controlled 300 it is then no longer necessary to replace the entire first ASW module, but it is advantageously sufficient if only the drive unit component EF is replaced.

Similar to the ASW module, it is recommended for the second CO module, for example, with regard to different ones in the control unit 100 usable processors to subdivide the second module CO into an infrastructure component IS and into a hardware capsule component HWE. All those functional units that offer or represent basic services that other functional units can access are preferably combined in the infrastructure component IS. These are preferably the functional units service libraries IS-1 and diagnosis manager IS-2, as also described above. The services of these functional units are provided in a central location in the infrastructure component and therefore do not have to be duplicated in a decentralized manner and take up unnecessary storage space.

In the hardware capsule component HWE, all those functional units are summarized which allow individual programming of the hardware 100a of the control unit 100 in the way that allow the hardware 100a is enabled with the modules ASV, ASW, CO, DE or CD of the control unit 100 to communicate. So it is with an exchange in the control unit 100 processor used by a processor of a different type is only required to replace the hardware capsule component HWE and no longer the entire second module of the control device.

In addition to the infrastructure component mentioned and the hardware capsule component, the second module CO can be optional still have a communication component COM, in which those functional units are summarized which one Enable communication with other control devices (not shown here).

In addition to the module interfaces already mentioned above M1 ... M7 at the module level also include component interfaces Component level provided within the individual modules. These component interfaces K0 ... K3 enable data exchange between at least some of the components within a module. There is an interface K0 in the ASW module between the vehicle component VF and the drive unit component EF. Within the second Module CO there is a component interface K1 between the Infrastructure component IS and the communication component COM, a second interface K2 between the infrastructure component IS and the hardware capsule component HWE and a third interface K3 between the hardware capsule component HWE and the communication component COM.

4 shows the already described assignment of the functional units IS-1 and IS-2 explained above to the infrastructure component IS and the functional unit HWE-1 to the hardware capsule component HWE within the second module CO. The functional units within a component can communicate with one another via functional unit interfaces F7. Communication between functional units that are assigned to different components within the same module takes place via said component interface, for example K2.

5 illustrates the already mentioned advantageous division of the third module CD into at least one functional unit. This functional unit is, for example, the functional unit aggregate position management EPM described above, which represents a complex device driver. Complex device drivers within the third module are advantageously programmed by the manufacturer of the control device, since there is a strong coupling to the control device hardware.

The functional units, components or modules are preferably implemented as computer programs. It is then possible to store these computer programs, possibly together with other computer programs for controlling the device, on a computer-readable data carrier. The data carrier can be a floppy disk, a compact disc, a so-called flash memory or the like. The computer program stored on the data carrier can then be sold to a customer as a product. In addition, in the case of software implementation, it is possible to transmit the computer program, in turn, possibly together with other computer programs, even without the aid of a data carrier, via an electronic commu transmission network as a product to a customer and thus sell it. The communication network can be, for example, the Internet.

Claims (15)

Control unit ( 100 ) to control a device ( 300 ) of a vehicle, in particular an internal combustion engine or a transmission, with the aid of a between the control unit ( 100 ) and the device ( 300 ) switched sensor / actuator configuration ( 200 ); the control unit being hardware ( 100a ) with at least one processor ( 100a-1 ) and at least one storage element ( 100a-2 ) and software ( 100b ) with a plurality of in the storage element ( 100a-2 ) includes functional units; characterized in that the software ( 100b ) has a modular structure in the form of a plurality of modules which are connected to one another for the purpose of cross-module communication by means of a plurality of module interfaces (M1-M7); and those functional units are combined in a first (ASV) of the modules which enable control, safety and / or monitoring functions to be implemented for the device. control unit according to claim 1, characterized in that the first module (ASV) a module interface (M7) for connecting a user software module (ASW). Control unit ( 100 ) according to claim 2, characterized in that the user software module (ASW) comprises: - a vehicle component (VF), in which those functional units are summarized that are not specific for a particular type of drive unit used ( 300 ) are; and - a drive unit component (EF), in which those functional units are summarized which are suitable for the type of drive unit used ( 300 ) are specific. Control unit ( 100 ) according to one of the preceding claims, characterized in that the software ( 100b ) has a second module (CO), in which those functional units are summarized which allow individual programming of the processor ( 100a-1 ) of the control device in such a way that the hardware ( 100a ) is enabled with the modules of the control unit ( 100 ) and which enables the processing of functions of the functional units in the modules, the ASW components (VF, EF) being independent of the specific design of the control unit (HW). Control unit ( 100 ) according to claim 4, characterized in that the second module (CO) comprises: - an infrastructure component (IS), in which those functional units are summarized that offer or represent basic services that other functional units can access; and - a hardware capsule component (HWE), in which those functional units are combined which allow individual programming of the hardware ( 100a ) of the control unit ( 100 ) in such a way that the hardware is enabled with the modules (ASW, CO, DE, CD) of the control unit ( 100 ) to communicate. Control unit ( 100 ) according to claim 5, characterized in that the infrastructure component (IS) preferably comprises the functional units service libraries (IS-1) and / or diagnostic manager (IS-2). Control unit ( 100 ) according to one of claims 5 or 6, characterized in that the hardware capsule component (HWE) comprises in particular a functional unit signal conditioning (HWE-1). Control unit ( 100 ) according to one of claims 4-7, characterized in that the second module (CO) further comprises a communication component (COM), in which those functional units are combined which enable communication with other control units. control unit according to one of the preceding claims, characterized in that that the software has a third module (CD) in which those Functional units are summarized, which direct control enable specific sensor-actuator configurations. Control unit ( 100 ) according to claim 9, characterized in that the third module (CD) has in particular a functional unit aggregate position management (EPM). Control unit ( 100 ) according to one of the preceding claims, characterized in that the software ( 100b ) has a fourth module (DE), in which those functional units are summarized that allow individual adaptation of the sensor / actuator configuration used ( 300 ) to the control unit ( 100 ) in such a way that communication with the other modules of the control device is possible between the individual sensors or actuators of the configuration. Control unit ( 100 ) according to one of the preceding claims, characterized in that at least in the second module (CO) and / or in the user software module (ASW) component interfaces (K0 ... K3) for data exchange between at least some of the components (IS, COM, HWE) within the module, in particular but also between functional units in different components. control unit according to one of the claims 5 to 12, characterized in that within a component (VF, EF, IS, HWE, COM) Functional unit interfaces (Fi) for one Data exchange between at least some of the functional units are provided within the same component. Control unit ( 100 ) according to one of the preceding claims, characterized in that the functional units, the components and / or the modules and the interfaces between them are at least partially designed as a computer program. Computer program for a control device ( 100 ) according to one of claims 1-14 for controlling a device ( 300 ) a vehicle, comprising a program code which is suitable for mapping the functional units, components or modules and for realizing communication between them for the purpose of controlling the device.